How to write a change management policy

Why change management is an audit staple

Most outages and many incidents are self-inflicted, caused by an unreviewed change. A change management policy defines how changes to systems and code are requested, assessed, approved, tested and rolled back — giving you safety and an audit trail.

What to include

Scope — which changes are covered (production systems, infrastructure, code, configuration).
Change types — standard (pre-approved, low risk), normal (reviewed) and emergency (expedited with retro-approval).
Request and assessment — what a change request captures: purpose, risk, impact, rollback plan.
Approval — who approves which risk level; segregation of duties.
Testing — validation before production.
Rollback — a defined way to revert.
Records — every change logged for traceability.

Common mistakes

No emergency-change path, so urgent fixes bypass the process entirely.
Approvals with no segregation of duties (author approves own change).
No rollback plan captured in the request.

Framework alignment

Maps to ISO 27001:2022 Annex A 8.32 (change management), the SOC 2 change-management criteria, and NIST CSF Protect.

Primary sources

NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems (csrc.nist.gov/pubs/sp/800/128/final).
ISO/IEC 27001:2022 — Annex A control 8.32, change management (iso.org/standard/27001).
NIST — Cybersecurity Framework (CSF) (nist.gov/cyberframework).

Generate it in minutes

See a sample change management policy or generate yours free.

Frequently asked questions

What is the difference between normal, standard, and emergency changes?

A normal change follows the full review-and-approval path. A standard change is pre-approved and low-risk (for example a routine patch) and can proceed without per-instance sign-off. An emergency change fixes an urgent issue and is approved retroactively, with documentation completed straight after.

Does ISO 27001 require a change management policy?

Annex A 8.32 requires changes to information processing facilities and systems to be subject to change management procedures. It does not prescribe a tool, but it expects documented requests, impact assessment, approval, testing, and the ability to roll back a change that goes wrong.

What should a change record contain?

At minimum: a description of the change, the reason, a risk and impact assessment, the approver, a back-out plan, test evidence, and the implementation window. This record is what an auditor samples to confirm changes are controlled rather than ad hoc.