Verification, by reviews, analyses and tests defined in the verification plan with assessment of results, assures the implementation meets its requirements; it may be applied at any level, repeatedly for safety requirements, and certain levels need independence (Appendix A). Hardware requirements verified during software, hardware/software integration or system verification may be credited, and changes may be re-verified through similarity, analysis, newly designed tests or repeating part of the original verification; informal testing helps find errors but earns credit only when formalised. Objectives: evidence that the implementation meets the requirements; traceability between hardware requirements, implementation, and verification procedures and results; acceptance test criteria identified, implementable and consistent with the functions' assurance levels; omissions and errors fed back.
This control maps to 2 controls across 2 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 2 it maps to, and the evidence behind each claim, over MCP and REST.