CM-4 is one sentence. Analyze changes to the system to determine potential security and privacy impacts prior to change implementation. It feeds CM-3, which approves changes, with the analysis that makes approval meaningful.
800-53 binds US federal systems and others by contract. For everyone else it is a reference.
What it means in practice
NIST says people with security or privacy responsibilities do the analysis, and they need the skills to judge the change. The analysis covers the relevant plans, policies and procedures, the design and operational documentation, the effect on supply chain partners, and any new risks to individuals' privacy. It can include a risk assessment to decide whether more controls are needed.
For a software team this can be a short section in the change template. Does it touch authentication, data stores, network paths, third party services or personal data? If yes, who reviewed it?
Evidence to collect
- The impact analysis template or checklist.
- Completed analyses linked to sampled changes.
- Reviewer names and their roles.
- Records of changes that triggered extra controls or a risk assessment.
Common gaps
- A checkbox that says no impact on every change.
- The analyst has no security training.
- Supply chain effects are never considered.
How to implement it
Add three to five questions to the pull request template, route changes that answer yes to a security reviewer, and keep the answers with the change. CM-4.1 covers Separate Test Environments and CM-4.2 covers Verification of Controls.
Quick check
When must the analysis happen?
Before the change is implemented. An after the fact review does not meet the wording.
