CM-3 is the change management control, and it is one of the most requested items in any audit. Auditors sample changes and follow each one from request to deployment. If the trail is clean, the control passes quickly. If it is not, the sample expands.
800-53 binds US federal systems and others by contract. For a small or mid size company it is a reference, and the same change evidence satisfies many customer reviews.
What the control asks
The statement lists seven duties.
- Determine and document which types of change are configuration controlled.
- Review proposed changes and approve or disapprove them, with explicit consideration of security and privacy impact analyses.
- Document the change decisions.
- Implement approved changes.
- Retain records of configuration controlled changes for a period you define.
- Monitor and review activities associated with those changes.
- Coordinate oversight through an element you define that convenes at a frequency or on conditions you define.
NIST's guidance frames this as the systematic proposal, justification, implementation, testing, review and disposition of changes. It includes changes to baselines, configuration items, operational procedures, settings, vulnerability remediation, and unscheduled or unauthorized changes. It names Configuration Control Boards and Change Advisory Boards as the usual review bodies.
What it means in practice
Not every change needs a committee. The first duty lets you decide which types are controlled. A common approach is to sort changes into tiers.
- Standard changes with pre approved patterns, such as a routine dependency update that passes tests.
- Normal changes with a peer review and an approver, such as a new service or a schema migration.
- Emergency changes that go first and get reviewed after, with a written justification.
In modern teams the pull request is the change record. It carries the description, the review, the approval, the test results and the merge. The deploy pipeline carries the implementation. The weak point is usually the impact analysis, which is where CM-4 comes in.
Evidence to collect
- The change policy defining controlled change types and tiers.
- A sample of changes, each linking a ticket, a pull request, an approval, test results and a deployment record.
- Approver identity and proof they are authorized to approve, which links to CM-5.
- Emergency change records with after the fact review.
- The retention setting for change records.
- Minutes or records from the change board or review forum.
- Evidence of monitoring, such as an alert for production changes made outside the pipeline.
Common gaps
- Direct production access allows changes that skip the pipeline.
- Approvals are by the author, or rubber stamped in seconds.
- No impact analysis is recorded, so security and privacy consideration cannot be shown.
- Emergency changes are frequent and never reviewed.
- Records are retained only in a tool whose history rolls off after ninety days.
- Infrastructure console changes drift from the code.
How to implement it
Make the pipeline the only path to production. Protect the main branch, require at least one reviewer who is not the author, and have the pipeline record the deploy with a link back to the pull request. Add a field or template section for security and privacy impact so the analysis is written down at review time.
Add a gate that blocks a release when defined checks fail, such as failing tests or a new critical vulnerability. The demo below shows a production gate in action.
Click through it at your own pace, or open it full screen.
Enhancements extend the baseline. CM-3.1 is Automated Documentation, Notification, and Prohibition of Changes. CM-3.2 is Testing, Validation, and Documentation of Changes. CM-3.3 is Automated Change Implementation. CM-3.4 is Security and Privacy Representatives. CM-3.5 is Automated Security Response. CM-3.6 is Cryptography Management. CM-3.7 is Review System Changes. CM-3.8 is Prevent or Restrict Configuration Changes. For a small team, CM-3.2 and CM-3.7 are the most natural next steps.
Mapping to other frameworks
SOC 2, ISO 27001 and other frameworks have their own change management criteria. Mappings vary by source and version, so check an authoritative crosswalk for the editions you are assessed against.
Quick check
What is the minimum record for one change?
A description, a reviewer and approver who can be identified, a decision, the test result and the deployment. The statement also expects security and privacy impact to be considered.
Do emergency changes break the control?
Not by themselves. They need a documented justification and a review afterward, so the record is complete even when the order differs.
