Assurance effort rises with failure condition severity, and every level needs a strategy. For Level A or B functions the considerations should address potential anomalous behaviour and design errors; the Figure 2-3 decision process is used for each function; the Appendix B strategies apply to Level A and B on top of Sections 3 to 11; and the strategy reflects architecture, usage and implementation technology. The process: begin the assessment; determine and document the FFPs and their levels, using conventional safety techniques to decide which circuits lie in Level A or B FFPs; for those FFPs decide whether the hardware is simple or complex; for complex Level A or B FFPs choose a strategy from architectural mitigation, product service experience or advanced analysis (more than one may be needed at Level A); check the strategy and data for deficiencies and modify them; document fail-safe aspects with common mode, probability and architecture analyses meeting availability and integrity requirements; document the approach and obtain authority approval in the system certification plan or PHAC, including authority participation milestones; and implement it with evidence of compliance.
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.