Where Table A.1 requires, the Designer writes an Application Preparation Plan that defines the application development process with its activities, deliverables and responsible roles (reusable across a class of applications); sets a documentation structure; chooses Table A.11 techniques justified against 4.8 and 4.9; names procedures and support tools with their 6.7 class, and a tool class for every hardware or software tool in the preparation lifecycle; includes verification and validation that the data are complete, correct and mutually compatible and compatible with the generic application whose application conditions they meet (this may instead rest on verification and validation of the data-producing tools), and that tools and software suit each other and the specific application; for safety-related software, is validated by a failure analysis of the whole preparation process including tools and procedures; sets independence between verification, validation and preparation staff per 5.1; and favours notations application engineers know, with documentation and training for any new notation. The Verifier's Application Preparation Verification Report confirms the plan's readability, traceability, specific content and internal consistency, and the plan's implementation is verified and validated for every specific application.
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.