Quality assurance identifies, monitors and controls all technical and managerial activities necessary for the software to achieve the required quality, providing the qualitative defence against systematic faults and the audit trail that lets verification and validation be done effectively, and evidences that these activities were carried out. The supplier or developer uses a quality system compliant with EN ISO 9001 (compliance mandatory at every SIL, accreditation recommended, Table A.9) and prepares per project a software quality assurance plan implementing this standard, expressed in measurable terms where possible, updated through the project (frequency, responsibility, method stated), and specifying or referencing the lifecycle model with each phase's activities, criteria for starting and finishing, its inputs and outputs, quality activities and responsible organisational unit, requirements and documentation traceability, the documentation of development, verification, validation, operation and maintenance, system integration procedures, coding standards, the assessment of previous validation tests and the metrics on product and process (6.5.4.1 to 6.5.4.9). Configuration management is mandatory: every document is under configuration control before release of its approved version and source code before documented component testing, unauthorised change is impossible, errors in machine-readable code while it is stored, transferred or copied are prevented or detected, and the controlled configuration covers the environment (configuration files, assemblers, compilers, debuggers and tools) so development and maintenance are reproducible (6.5.4.10 to 6.5.4.12). External supplier control assures that supplied and previously developed software meets the SIL and that requirements given to suppliers are adequate; problem reporting and corrective action procedures define documentation, analysis of causes, reporting, tracking and resolution, preventive actions to the SIL, responsibilities, controls on effectiveness, forms and what repeat testing, verification, validation and assessment is required, applied at least from software integration and throughout maintenance; traceability is maintained between requirements, design, implementation and tests (6.5.4.13 to 6.5.4.17).
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.