The standard's objectives are met, and conformance claimed, by satisfying the requirements of clauses 5 to 9 as tailored to the software safety integrity level, with the techniques and measures of Annex A applied at the grade the level demands and the roles of Annex B filled. Before software development starts the system inputs are provided as EN 50126 and EN 50129 require: a functional and interface description, the application conditions, the system configuration or architecture, the hazards to be controlled, the safety integrity requirements, the split of requirements and the SIL allotted to hardware and software, and timing constraints (2011 requirement 4.1). The software safety integrity level is decided from the risk associated with the software's use within the system and from the system's own safety integrity level, and is at least the system's level unless mechanisms prevent a software failure from taking the system to an unsafe state; it is one of five levels, Basic Integrity (SIL 0, no specific safety requirement) and SIL 1 to SIL 4, recorded in the software requirements specification and, where components differ, in the architecture specification.
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.