Modification procedures are available before any software change. A change starts only from an authorised software modification request under the safety planning procedures, naming affected hazards, the proposed change and the reasons. An impact analysis decides whether a hazard and risk analysis is needed and which software lifecycle phases are repeated, and is documented. Changes affecting functional safety return to the appropriate lifecycle phase, with later phases repeated and safety planning detailing them. Modification planning meets Part 1 clause 6, identifying staff and their competence, the detailed change specification, verification planning, and revalidation and test scope to the SIL. The change is carried out as planned and documented with references to the request, the impact analysis and decisions, configuration history, deviations from normal conditions and all affected information, including the re-verifying and re-validating of data and results; the assessment of the change depends on the impact analysis and the systematic capability.
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.