Aim: corrections, enhancements and adaptations keep the software performing as required with its integrity level and dependability (see also 6.6). Although the standard is not retrospective, 9.2 applies to every change, however minor. Before starting any change the supplier decides and records, with justification, whether it is major or minor so as to judge whether existing maintenance methods suffice; the decision goes to the Validator and, for SIL 1 to 4, to the Assessor, who records the evaluation in the Software Assessment Report. Maintenance should follow ISO/IEC/IEEE 90003:2018 8.5.1.7, and maintainability is designed in through 7.3 to 7.5. A Software Maintenance Plan sets maintenance procedures covering control of error reports and logs, maintenance records, change authorisation, software and system configuration and the Table A.10 techniques; verification, validation and (SIL 1 to 4) assessment of each modification; the authority that approves changed software; and authorisation of each modification. A maintenance record exists for each software item from before its first release and holds references to its change records, change impact evaluation, test cases with revalidation and regression data, and configuration history. A change record per maintenance activity holds the request, version, nature of the fault, change needed and its source; impact on the whole system, covering hardware, software, the environment, human interaction and their interplay; the detailed change specification; and revalidation, regression testing and re-assessment as the level requires, with the validation plan setting responsibility and scope (changed components, all affected components, or the whole system) and revalidation as independent as the original validation. The Verifier checks the plan, maintenance records and change records. Maintenance follows the plan, uses Table A.10 techniques justified against 4.8 and 4.9, and is done with at least the expertise, tools, documentation, planning, management, configuration and document control and independence of the original development; control of suppliers, problem reports and corrective actions follow 6.5. Every reported problem or enhancement gets a safety impact analysis, and proportionate mitigation protects system integrity while reported problems are investigated and fixed.
This control maps to 8 controls across 4 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 8 it maps to, and the evidence behind each claim, over MCP and REST.