CM-3 asks you to decide which kinds of changes are configuration-controlled, review them with security and privacy impact in mind, document the decision, implement only approved changes and keep records. For dependencies, that means a defined path for updates, with a ticket and evidence. It is a control statement, not a tool.
What the control text says
NIST SP 800-53 Rev 5 lists the parts of CM-3. In summary, the organisation should:
- Determine and document the types of changes that are configuration-controlled.
- Review proposed changes and approve or disapprove them with explicit consideration for security and privacy impact analyses.
- Document configuration change decisions.
- Implement approved changes.
- Retain records of changes for a period the organisation sets.
- Monitor and review change control activities.
- Coordinate oversight through a body the organisation defines.
The related control CM-4 covers impact analysis before the change, and enhancement CM-3(2) covers testing, validation and documentation of changes before finalising them.
Which baseline applies to your system, and whether you must meet it, depends on your contracts and regulators. This post does not say that it does.
Mapping each part to dependency work
| CM-3 element | Dependency practice |
|---|---|
| Types of controlled changes | Policy that lists new package, major upgrade, minor and patch update, emergency fix |
| Review with security impact | Scan results, advisory check, licence and maintainer review |
| Documented decision | Ticket or pull request approval with reviewer notes |
| Implement approved changes | Merge gated on approval and checks |
| Retain records | Tickets, pull requests and scan output kept for your retention period |
| Monitor and review | Periodic review of change data and exceptions |
| Oversight body | A change advisory group, or a delegated owner for small teams |
A minimal workable setup
- Write the change types in your policy and say which are pre-approved. See standard versus normal change for dependency updates.
- Make the pull request the unit of review, with a link to the ticket.
- Run the security check automatically and attach the output.
- Require an approver other than the author.
- Store the evidence where you can export it by date range.
- Review the data quarterly and record what you changed in the process.
Where teams stumble
- Treating the control as met because a tool exists, without a documented change type list.
- Leaving out automated updates from the record.
- Keeping evidence in chat or in a person's head.
- Having an oversight body on paper that never meets.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one technical record can support several framework controls.
Quick check
Is CM-3 a certification?
No. It is a control in a NIST catalog. Whether and how you are assessed against it depends on your own programme and any assessor.
Do small teams need a change advisory board?
Not necessarily. The control asks for coordinated oversight through a body you define, which a small team can fill with a named owner and a regular review.
Safeguard compliance and evidence automation can map change records to framework controls; mapping does not mean a certification. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
