Skip to content
ControlVerdict
CM.L2-3.4.4addresses
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.

View full control

A one-page security impact analysis that has to name what could go wrong

ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
Community 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

Was this example useful?

Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.

Discussion(0)

No discussion on this example yet

Verdicts capture a conclusion. Use a thread when the interesting part is the argument.

Sign in to start a thread.