Aim: keep the software doing what is required, with its integrity and dependability intact, whenever it is modified; the Configuration Manager manages this. Inputs are the quality assurance and configuration management plans, the design, development and analysis documents, change requests and the change impact analysis and authorisation; outputs are the updated documents, software change records (9.2.4.10) and new configuration records. The change management process defines at least: the problem-report and corrective-action documentation that feeds back to responsible management; analysis of problem reports for causes; how problems found in development and in maintenance are reported, tracked and resolved; the organisational responsibilities for development and maintenance; controls confirming corrective actions are taken and work; analysis of each change's effect on components in development or already delivered, naming what must be verified, validated and assessed again; the combined effect where several changes accumulate (which may call for a full re-test); and authorisation before implementation. Every change sends the work back to a suitable lifecycle phase, and all later phases are then repeated under their own procedures.
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.