Aim: identify, monitor and control every technical and managerial activity needed for the required quality, as the qualitative protection against systematic faults and to leave an audit trail for verification and validation, and evidence that it was done. All plans are issued at the start and updated during the lifecycle, and every organisation involved runs a Quality Assurance System. A project-specific Software Quality Assurance Plan specifies or references at least: the lifecycle model (activities and tasks consistent with system-level plans such as the Safety Plan, entry and exit criteria, each activity's inputs and outputs, main quality activities and who owns each), the documentation structure, document control (writing, checking and approval roles, distribution, archiving), tracking of deviations, and the techniques chosen from Tables A.2, A.3, A.4 and A.9 justified against 4.8 to 4.10. Where content lives in other plans (configuration management, maintenance, verification, validation) the plan references them and those documents are reviewed for completeness; quality activities demanded anywhere in the standard are specified or referenced and tailored. Each plan states how, how often and by whom it is updated. Every software document and deliverable is under configuration control from first release, with changes authorised and recorded; configuration management also covers the development environment (tools, translators, data files, test files, parameter files and the hardware platforms) so builds are reproducible. Procedures control external suppliers so supplied software meets its requirements (earlier software at the required integrity level; new software under the supplier's or an aligned plan) and requirements passed to them are complete. Traceability, a configuration item itself, links requirements to design, design to implementation, and requirements and design to the component, integration and overall tests and analyses, to the degree the level needs; for pre-existing or prototyped software it can be built after coding but before verification and validation if shown equally effective; anything untraceable is shown to have no bearing on safety or integrity. Where several organisations share the work, each one's tasks are defined, documents cross-reference and are available, and the subcontractor applies the standard to its share while the contracting organisation stays responsible; the plan should describe the organisational interfaces.
This control maps to 11 controls across 4 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 11 it maps to, and the evidence behind each claim, over MCP and REST.