Modification and change control ensures that modified software still does what is required and keeps its safety integrity and dependability. A change management process is defined (6.6.4.1 and 6.6.4.2, together with 8.4.8.5 for generic software configured by data): every change request is recorded, its impact on the overall system analysed including hardware, software, human interaction, the environment and possible interactions, the modification specified in detail, and re-verification, regression testing, re-validation and re-assessment performed to the extent the SIL requires, with the same independence as the original validation; changed items and affected items are identified so that the extent of revalidation (changed components, all affected components, or the complete system) is decided and justified in the validation plan; an amendment to generic software is installed only once the revised software is shown compatible with the existing application data or the data revised; the authority that approves changed software is defined.
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.