3.4.4 — Check Before You Change

The One-Liner

Before any change, ask: does this introduce new risk or weaken an existing control?

What It Says

Analyze the security impact of changes prior to implementation.

What It Actually Means

Before a change goes into production, someone with security knowledge must evaluate whether it introduces new risks or weakens existing controls. This isn’t a full risk assessment for every minor change — it’s a security review proportional to the change.

What the assessor looks for:

1. Security impact analysis is performed. Every change ticket includes evidence that someone evaluated the security implications. For a firewall rule change, that means asking: does this open a port that shouldn’t be open? Does it bypass segmentation? For a software installation: does this software introduce vulnerabilities? Does it need network access it shouldn’t have? For a cloud config change: does this weaken access controls or encryption?

2. The analysis happens before implementation. Not after. The assessor will check timestamps — if the security review is dated after the change was implemented, it doesn’t count.

3. Results feed the approval decision. The security impact analysis informs whether the change is approved, modified, or rejected. If the analysis finds a risk, the change ticket should show how that risk was mitigated, accepted, or the change was altered.

This doesn’t require a dedicated security analyst. In a small company, the IT security lead reviews change tickets and adds a security impact note. What matters is that the evaluation is documented, performed by someone with security knowledge, and completed before the change is implemented.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Is the security impact of changes analyzed prior to implementation?	Change tickets show a security impact assessment with findings — completed before the implementation date

---

What to Have Ready on Assessment Day

Documents they’ll review: Configuration management policy; procedures addressing security impact analysis; configuration management plan; security impact analysis documentation; system security plan; change control records with security review notes; analysis tools and outputs

People they’ll talk to: Personnel responsible for conducting security impact analysis; information security personnel; system or network administrators

Live demos they’ll ask for: “Show me a recent change ticket with the security impact analysis. When was the analysis completed relative to the change?” “Show me a change where the security review identified a risk — what happened?”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me a recent change ticket. Where is the security impact analysis?”
• “Who performs the security review? Are they qualified?”
• “Was the analysis completed before the change was implemented? Show me the dates.”
• “Show me a change where the security review identified a risk. How was it handled?”
• “Are configuration changes tested and validated before being installed in production?”
• “Does every change go through security review, or only some? What’s the threshold?”

Real-World Example

A defense contractor requires a security impact field on every change ticket. Before a sysadmin opens a new inbound port on the perimeter firewall for a vendor integration, the IT Security Lead reviews the ticket and documents: “Opening TCP 443 from vendor IP range 203.0.113.0/24 to internal application server. Risk: expands external attack surface. Mitigations: source IP restricted to vendor range only, TLS 1.2 minimum, traffic logged and monitored via IDS, vendor IP range verified against contract. Residual risk: low.” The security review is completed two days before the implementation date. The CAB reviews the change with the security analysis attached. After implementation, the ticket is updated with verification that only the specified IP range can reach the port. When the assessor reviews five recent change tickets, each has a dated security impact note completed before the implementation date.

---

Where Companies Trip Up

No security review. Changes go through IT approval but nobody evaluates security impact. The assessor looks at change tickets and finds no security analysis. Add a mandatory security impact field to your change ticket template.

Security review after the fact. The change was made Tuesday, and the security review was completed Friday. The assessor checks timestamps and the review doesn’t count. Build the security review into the workflow before the approval step.

Rubber stamp security reviews. Every change ticket has “no security impact” without evidence of actual analysis. The assessor will ask the reviewer about a specific change and check whether they actually evaluated it. A firewall rule change always has a security impact — even if the impact is acceptable.

Only IT reviews, not security. The IT manager approves based on functionality, but nobody with security knowledge evaluates risk. The reviewer doesn’t need to be a dedicated security analyst, but they need security competence relevant to the change.

---

How to Talk About This

To a CEO or Board

Every change to our CUI environment is reviewed for security impact before implementation. We never make a change without understanding whether it introduces new risk — and we document how we’ve mitigated that risk.

To an Engineering Team

Security impact field mandatory on all change tickets. IT Security Lead reviews before approval. Analysis includes: risk introduced, controls affected, mitigations applied, residual risk rating. Completed before implementation date. Proportional to change scope — firewall changes get detailed analysis, standard patches get lightweight review. Results feed CAB approval decision.

---

Connected Requirements

Requirement	Why it matters here
3.4.3 — Control Every Change	Security analysis is part of the change management process
3.11.1 — Assess Risk	Security impact analysis is a focused form of risk assessment
3.4.2 — Harden Everything	Changes that weaken hardening baselines must be caught by security review
3.12.4 — Update the Security Plan	Significant security impacts from changes may require SSP updates

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: CM.L2-3.4.4 | SPRS Weight: 1 point | POA&M Eligible: Yes