Define three change classes by risk. Standard changes are routine and pre-approved, normal changes get review before they ship, and emergency changes proceed immediately under named authority and are reviewed afterwards. The classes are a design choice, not something a regulation dictates.
Why classes help
If every change gets the same heavy review, people stop following the process. If none do, risky changes ship untested. NIST SP 800-53 CM-3 asks you to identify which types of changes are subject to configuration control, and CM-4 asks for impact review before changes are made. Classes let you apply that effort where it pays.
Standard changes
A standard change is low risk, well understood, repeatable and has a known procedure. Examples: rotating a certificate using an approved runbook, adding a user to a group by role template, deploying a dependency patch through a pipeline with passing tests.
To qualify, a change type needs:
- A written procedure.
- Automated tests or checks where possible.
- A tested rollback.
- A named owner who approved the type once.
After that, individual instances need only a record, not a fresh approval.
Normal changes
A normal change is anything not standard. It needs a request, an impact check, a reviewer who is not the author, a test result, a rollback plan and a scheduled window. Database schema changes, new network paths, identity configuration, and new third-party integrations belong here.
Emergency changes
An emergency change fixes an active outage or a live security issue where waiting costs more than the risk of acting. It needs:
- A named approver with authority to say yes at any hour, plus a backup.
- A short definition of emergency. "Customer-facing outage or actively exploited vulnerability" is clearer than "urgent".
- A time limit for the retrospective record. For example, a full change record within two business days.
- A post-implementation review that asks whether it really qualified and what should change in the standard path.
Emergency changes still get logged. The shortcut is on approval timing, not on record keeping.
Preventing abuse
Emergency paths decay into the normal way to ship when the normal way is slow. Watch the ratio. If more than a small fraction of changes are flagged as emergencies, fix the slow path. Report the count to your security or engineering leadership monthly.
Also review standard change types yearly. A routine change can stop being routine when the system around it changes.
Link to the policy
These classes belong in the procedure under your policy. See what a change management policy should include.
Safeguard's autonomous remediation can open fix pull requests, off by default with every category set to Manual, so a patch still passes through your normal review class.
Quick check
Can a security patch be a standard change?
Yes, if the type is pre-approved, tested in a pipeline and reversible. Critical patches for exploited flaws may use the emergency path instead.
Who reviews emergency changes afterwards?
Someone other than the person who made them, ideally the same group that handles normal change oversight.
Sources
- CM-3 Configuration Change Control, NIST SP 800-53 Rev. 5
- CM-4 Impact Analyses, NIST SP 800-53 Rev. 5
Last reviewed: 19 October 2026.
