Verification of each phase is planned and documented alongside development, referring to all criteria, techniques and tools, specifying activities that confirm correctness and consistency with the phase inputs, and considering verification strategies and techniques, test equipment, the choice and recording of activities, and how results are evaluated. Each design and development phase must show the functional and integrity requirements are met. Each verification result is documented as pass or with reasons for failure, considering items not conforming to lifecycle requirements, design standards or safety management requirements. After the design requirements are written and before design begins, verification checks they are adequate against the safety requirements specification and checks for incompatibilities between the safety requirements, design requirements, planned tests and user and system documentation. After design and development and before integration, verification checks the system tests are adequate for the design, that the design is consistent and complete down to module level against the safety requirements, and that safety requirements, design requirements, design and tests are mutually compatible. Integration is verified against 7.5, and test cases and results are documented.
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.