A security impact analysis asks, before a change ships, whether it could weaken a control, expose data, or create a new risk, and how you would undo it. Ten short questions, answered in the change ticket, are enough for most changes.
What the control describes
NIST SP 800-53 CM-4 asks organisations to review proposed changes for security and privacy effects before implementing them. The reviewers check existing plans, policies, design documents and procedures, assess whether a change could weaken a control or create new privacy risk, and consider effects on supply chain partners. Enhancement CM-4(2) adds verifying, after the change, that affected controls still work as intended.
The checklist
Answer each in one or two lines.
- What is changing? System, component, setting, version.
- Who and what can reach it? Does this change who can access the system or data?
- Does it touch authentication or authorisation? Login flows, tokens, roles, permission checks.
- Does it change data flow? New storage, new third party, new region, new logging of personal data.
- Does it change network exposure? New public endpoint, opened port, relaxed rule.
- Does it add or update a dependency? New package, base image or service, and where it came from.
- Does it affect logging, monitoring or backups? A change that silently disables an alert is a classic weakness.
- What documents become wrong? Diagrams, policies, runbooks, asset inventory.
- How will you verify the controls still work afterwards? Name the test or check.
- How do you roll back, and how long does it take?
If any answer is "unknown", the change is not ready.
Separate test environments
CM-4(1) describes testing changes in a separate environment before production, to catch flaws, incompatibilities or deliberate tampering. For a small team, even a staging environment that mirrors production's settings counts, as long as the difference is known and written down.
Who answers the questions
The author drafts the answers because they know the change best. A reviewer with security responsibility checks them. For high-risk classes, pair with the person who owns the system.
Do not let the checklist become a copy-paste template. If every ticket says "no impact", test the process by reviewing a few past changes and asking whether that was true.
Keep the verification step
Teams often do the analysis and skip the after-check. Add a task in the ticket: "confirm monitoring still fires". It is the cheapest way to catch a change that quietly broke a control.
See standard, normal and emergency changes to decide which changes need the full list.
Safeguard's dependency scanning and policy gates can supply evidence for question 6 on pull requests. A free scan is available at gold.safeguard.sh/scan.
Quick check
Does every change need this checklist?
Not standard, pre-approved ones. Use it for normal and emergency changes, and review emergency ones afterwards.
Who owns the privacy part of the analysis?
Whoever handles privacy in your company, or the security lead if there is none. The point is that someone reads the data flow question with intent.
Sources
Last reviewed: 19 October 2026.
