Security Impact Analysis
Practice statement
Analyze the security impact of changes prior to implementation.
Quoted verbatim from NIST SP 800-171 Rev. 2 §3.4.4.Source
The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.
Assessment Objectives(1)
An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.
- [a]
the security impact of changes to the system is analyzed prior to implementation.
1 example covers this
Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.
Implementation examples(1)
Submit your own example- addresses
CM.L2-3.4.4Security Impact Analysis
Analyze the security impact of changes prior to implementation.
[a]
the security impact of changes to the system is analyzed prior to implementation.
A one-page security impact analysis that has to name what could go wrong
ControlVerdict Corpus@cv-corpusOSCJul 31, 2026Community is just starting — add yours. No verdicts yet.Implementation
AO coverage. Addresses the single Security Impact Analysis objective: the security impact of a change is analyzed before implementation.
The analysis [a]. No change to an in-scope system leaves the queue without a completed analysis section answering five questions: which practices or controls this change touches; whether it alters who can reach CUI, or how; whether it changes what is logged; what the rollback is and how quickly it can be executed; and what would have to go wrong for this change to expose CUI. The fifth question is the one that catches things, because it forces a failure mode to be named rather than a reassurance to be offered.
Depth scales with risk. A routine patch inside an existing baseline gets a short form referencing the baseline's standing analysis. Anything that adds a network path, changes an authentication or authorization boundary, alters logging, or introduces a new external dependency gets a full analysis with a named security reviewer. The classification criteria are written down so the choice is not left to the implementer's mood.
Who reviews. A rotating security reviewer signs the analysis before the change is scheduled; the reviewer is never the implementer. A reviewer may return a change for more detail, and returns are tracked as a health signal for the process.
Validation before broad rollout. Changes with a plausible security impact deploy first to a canary ring, and the analysis states what to watch there — which log source, which metric, for how long — so verification is specific instead of a vague soak period.
Maintenance. Quarterly sample of five completed analyses reviewed for substance, not just completeness. Post-incident, if a change contributed, the original analysis is re-read to see which question should have caught it, and the template is amended if the answer is none.
Accepted gap. Emergency changes during an active incident perform the analysis verbally and document it within one business day. Those are counted and reviewed at the change board; a rising count is treated as a process problem rather than a fact of life.
What the evidence looks like
- Impact analysis template with the five required questions
- Written criteria for short form versus full analysis
- Two completed analyses, one routine and one boundary-changing, with reviewer signatures
- Canary observation notes for a recent security-relevant change
- Quarterly substance-review notes and any template amendments
Environment
Engineering-led change culture where impact used to be discussed verbally in standup and never written down. Roughly 20 changes a month touch enclave systems.Tools
Discussion(0)
No discussion on this control yet
Edge cases, scoping questions, and “would this pass?” scenarios belong here.
Sign in to start a thread.