Planning for a project defines the activities, responsibilities, deliverables and procedures required for the system to become compliant and fit for the use intended, and it draws on the initial risk assessment, the assessment of system components and their categories, and the supplier assessment. The plan documents how the system will be specified, verified, reported on and released, how it will apply risk management, design review, traceability, change and configuration management, and document management, and how compliance will be maintained after release; it is produced early, approved by the quality unit and the process owner, and updated under project change control if the strategy or scope changes.
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.