1Overview
CM.L2-3.4.4 adds a security check to change control. It requires that the security impact of a change be analyzed before the change is implemented, so that a modification made for functional reasons does not quietly open a security hole. It is a one-point requirement with a single assessment objective, and it may be deferred on a plan of action.
Changes are usually made for functional reasons, to fix a problem or add a capability, and their security consequences are easy to overlook in the moment. Opening a port, granting an access, installing a component, each can weaken security in ways the person making the change may not consider. This control asks that, before a change is implemented, someone analyze what it does to the security of the system, so that security consequences are seen in advance rather than discovered after the fact. It is the security conscience of the change process in 3.4.3.
Analyze the security impact of changes prior to implementation.
The requirement is focused and its timing is the point: the analysis happens before implementation, not after. Analyzing security impact means considering how a proposed change affects the system's security posture, what it exposes, what it weakens, what new risk it introduces, so the change can be adjusted or rejected if the impact is unacceptable. It fits naturally into the review step of change control, giving that review a specifically security dimension.
2The Assessment Objective
NIST SP 800-171A frames 3.4.4 as a single objective: analyze security impact before implementation.
The security impact of changes to the system is analyzed prior to implementation. Proposed changes are assessed for their security consequences before they are made.
The single objective is the pre-implementation security analysis. The common failure is analyzing impact only after a change has caused a problem, which defeats the timing the control depends on. The assessor looks for evidence that security impact is considered before changes go in.
3Failure Patterns
The failures are about skipping the analysis or doing it too late.
Analysis after the fact
Considering security impact only after a change has been made, usually because it caused a problem, misses the point of the control. The analysis has to precede implementation so an unacceptable change can be caught before it is live.
Functional focus only
Where changes are evaluated only for whether they work, their security consequences go unexamined. The analysis has to specifically consider security, not just function.
No record of the analysis
An impact analysis that happens informally with nothing recorded cannot be demonstrated. Tying the analysis to the change record shows it occurred.
Emergency changes skipping analysis
Urgent changes made without any security analysis, and never analyzed afterward, carry unassessed risk. Even emergency changes should receive an impact analysis, before implementation where possible and promptly after where not.
4Ownership
This is an IT and security-owned control folded into the change review of 3.4.3.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Analyzes the security impact of proposed changes before implementing them, recording the analysis with the change. Owns the evidence. |
| Security or compliance lead | Provides the security perspective for the analysis and confirms it happens before implementation. |
| Change authority | Uses the impact analysis in the approve or disapprove decision of the change process. |
5Tooling
The control is largely a process embedded in change control, supported by the change record.
| Objective | Tooling | What it provides |
|---|---|---|
| analysis | Security impact step in the change process | A required pre-implementation assessment of a change's security consequences. |
| record | Change record with impact analysis field | Documentation that the analysis occurred before implementation. |
The caveat is that the analysis has to precede implementation and consider security specifically. A change process that reviews function but not security, or that analyzes impact only after problems arise, does not meet the control. The assessor looks for security impact analysis recorded before changes go in, so the timing and the security focus both have to be evident.
6Evidence
The satisfied version of 3.4.4 shows pre-implementation security analysis tied to changes.
| Evidence | What it demonstrates |
|---|---|
| Impact analysis in change records | The objective. Security impact analyzed before implementation. |
| Change process documentation | The objective. The required security analysis step in the process. |
The evidence should show that changes carry a security impact analysis performed before they were implemented. Change records with a pre-implementation impact analysis are the clearest demonstration of the control.
Ask what a change does to security before it goes in
A change made for a good functional reason can open a security hole no one intended, and this control asks for the pre-implementation analysis that catches it. Folding a security impact step into the change process is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.4.4. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objective 3.4.4. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov