Part 1 clause 6 applies, plus: functional safety planning sets out how software will be bought in, developed, integrated, verified, validated and changed, to the extent the SIL demands. Software configuration management applies administrative and technical controls across the software safety lifecycle so changes keep the safety requirements satisfied; ensures every operation needed to show the required systematic capability has been done; uniquely identifies and maintains every configuration item needed for safety integrity (at least safety analyses and requirements, specifications and designs, source modules, test plans and results, verification records, pre-existing elements and packages, and all tools and environments used to create or test the software); runs change control that blocks unauthorised changes, records requests, analyses impact, approves or rejects, records approved changes and their authority, sets baselines with their partial integration testing, and guarantees how every baseline is composed and built, including rebuilding earlier ones; ensures valid software and data are loaded correctly into the run-time system; records configuration and release status and the justification and approval of every change for later audit; and formally documents release, keeping master copies of software, documentation and in-service data versions for the operational life.
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.