Why it matters for security
Many incidents and outages come from changes: a firewall rule opened for testing and never closed, a cloud setting changed without review, an update deployed without testing. A controlled process reduces these risks and, when something does go wrong, makes it possible to know what changed and roll it back.
How it works
A change is requested and described, its impact and risk are assessed, it is approved by someone other than the person making it, tested in a separate environment, deployed and verified, with a rollback plan ready. Changes are usually classified as standard (low risk and pre approved), normal (assessed and approved each time) and emergency (made quickly and reviewed afterwards).
Lightweight in practice
Change management does not need heavy committees. In software teams, pull requests with peer review, automated tests and deployment pipelines with approvals are a form of change management that auditors accept, as long as the records are kept. For infrastructure, a ticket with an approval and a link to the change is often enough.
Where it shows up in compliance
ISO 27001 requires changes to information processing facilities and systems to follow change management procedures (Annex A 8.32), and development, test and production environments to be separated (8.31). SOC 2 includes change management in its common criteria, and the ENS, NIS2 and DORA expect changes to be controlled. Related practices are patch management, configuration checks through CSPM and secure development with SAST and DAST.
