A software safety lifecycle is selected and specified during safety planning; any lifecycle model may be used if all objectives and requirements are met. Each phase is divided into elementary activities with scope, inputs and outputs. The V-model may be tailored to the safety integrity and complexity of the project provided Table 1 is satisfied, and any customisation is justified on functional safety grounds. Quality and safety assurance procedures are built into lifecycle activities. Appropriate techniques and measures are used in every phase, guided by Annexes A and B, recognising that selection alone does not guarantee integrity. Lifecycle results are documented. When a later phase needs a change to an earlier one, an impact analysis decides which modules are affected and which earlier activities are repeated.
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.