What is a security impact analysis?

A security impact analysis (SIA) is the process of evaluating a proposed change to your information systems before you implement it to find out whether the change affects your security controls. Before you change anything in your CUI environment, someone qualified asks, "Does this break a control?"

For defense contractors, the requirement comes from NIST 800-171 requirement 3.4.4: "Analyze the security impact of changes prior to implementation." It sits in the Configuration Management (CM) family, alongside requirements to maintain baseline configurations (3.4.1) and to track, review, approve, and log system changes (3.4.3). Together, these requirements reflect a simple principle: know what your environment looks like, control how it changes, and understand the security consequences of each change before it happens.

If you've worked with NIST SP 800-53, this requirement will also look familiar. Requirement 3.4.4 derives from control CM-4, Impact Analyses, in the 800-53 catalog. NIST SP 800-128, the agency's guide to security-focused configuration management, provides detailed guidance on how to build change control and impact analysis into your operations. You don't need to read all of 800-128 to comply, but it's the reference NIST points to when contractors ask what a mature process looks like.

Where the SIA requirement comes from: NIST 800-171 and CMMC

DFARS clause 252.204-7012 requires contractors that handle CUI to implement NIST SP 800-171. The CMMC program, codified in 32 CFR Part 170, is how the Department of Defense verifies that implementation. Requirement 3.4.4 is one of the 110 security requirements assessed at CMMC Level 2.

The SIA isn't optional or simply best practice. If CUI touches your systems, analyzing the security impact of changes is a contractual obligation that’s part of your self-assessment and annual affirmations.

Security impact analysis vs. significant change

These two concepts are easily confused, but they play different roles in how you manage compliance.

A security impact analysis is a routine control. You run it on every change to in-scope systems, from a software patch to a data center migration. Most SIAs can be completed in minutes and confirm the change is low risk.

A significant change is a regulatory threshold defined in the CMMC Program rule at 32 CFR Part 170. The CMMC Level 2 Scoping Guide describes it as "architectural or boundary changes to the previous CMMC Assessment Scope." When a significant change occurs, your existing assessment may no longer reflect your environment, and a new assessment of the affected systems may be required, even if your CMMC status hasn't expired.

The SIA is the decision engine that tells you which side of the line a change falls on. Rather than eyeballing which changes qualify as significant, you run every change through the same lightweight analysis and let the results tell you the severity.

DoD's CMMC guidance adds two details that shape how you handle significant changes.

First, the significance call belongs to your Affirming Official. According to DoD's CMMC FAQ, determining whether a change is significant enough to require reassessment is the responsibility of the Affirming Official, the senior company official who signs your annual affirmation in SPRS and bears the legal and contractual risk of continued compliance. That makes the SIA more than an IT process. It's the documentation trail that lets your executive sign an affirmation with confidence.

Second, how you document a gap depends on when it's found. If a significant change introduces a temporary deficiency after your system was initially compliant, DoD guidance allows an Operational Plan of Action (OPA) to document the remediation plan. If the gap is instead identified during a CMMC assessment and a requirement is scored NOT MET, it becomes a POA&M item subject to the 180-day remediation window under 32 CFR 170.21. 

An SIA that catches a significant change first gives you the OPA path instead of a self-assessment finding.

What changes trigger a security impact analysis?

Any change to the hardware, software, or configuration settings of systems in your CMMC Assessment Scope calls for a security impact analysis. This includes routine activity like applying patches and updates, installing new software, modifying security configuration settings, and adding or removing hardware. Your change management plan can document specific exclusions for low-risk change types, but anything not excluded gets analyzed.

Many of these changes will only take minutes to analyze and document. The changes that are most likely to cross into significant change territory are those that alter your architecture or assessment boundary:

• Cloud migrations. Moving CUI to a new cloud environment introduces new systems, data flows, and shared responsibility questions.
• Switching MSPs or MSSPs. Your service providers are part of your assessment scope. A new provider means new external connections, new personnel with access, and new inheritance assumptions.
• Mergers and acquisitions. Combining networks, identity systems, and user populations almost always changes your boundary.
• Standing up or collapsing an enclave. Changing where CUI lives changes what's in scope.
• New SaaS tools that touch CUI. A new file-sharing, collaboration, or email tool expands your boundary the moment CUI flows through it.
• Network architecture changes. New segmentation, VPNs, remote access paths, or boundary devices change how controls are enforced.

If a change on this list is on your roadmap, run the SIA during planning rather than deployment. The analysis is far more useful when you can still adjust the plan.

How to conduct a security impact analysis

When you're ready to conduct a formal security impact analysis, here are the steps to follow:

1. Define what counts as a change and who reviews it

Write down the categories of change that require analysis (reference the triggers above) and name the person or team responsible for review. In many SMBs this is the IT lead plus whoever owns compliance.

2. Document the proposed change

Capture what's changing, why, which systems and assets are affected, and when it's planned.

3. Compare the change against your documentation

Review the proposed change against your System Security Plan, network diagram, and data flow diagram, and note whether the change alters anything these documents describe.

4. Identify affected controls

Walk through the requirements the change could touch. A new file-sharing tool, for example, raises questions across access control (who can log in and how), identification and authentication (does it enforce MFA), media protection (where is CUI stored), and system and communications protection (is data encrypted in transit and at rest).

5. Determine severity

Based on the analysis, classify the change. Does it leave all controls functioning as described? Does it create a gap that needs remediation before go-live? Does it alter your architecture or assessment boundary enough to qualify as a significant change?

6. Approve, modify, or reject

Proceed with low-risk changes. For changes that create gaps, either adjust the plan to close them or document a remediation path before implementation. For potential significant changes, escalate to your Affirming Official before moving forward.

7. Update your documentation

After implementation, update your SSP, diagrams, and asset inventory to reflect the new state of your environment. If the change affected your self-assessment score, update SPRS. Documentation that slowly shifts from reality is how compliance drift starts.

Security Impact Analysis (SIA) example

Say your engineering team wants to adopt a new cloud file-sharing tool to collaborate with a prime contractor, and engineering drawings marked CUI will move through it.

The documentation review comes first: your current SSP and data flow diagram show CUI leaving the environment only through encrypted email, so this tool creates a new egress path and both documents will need updates.

Walking through the affected controls also raises questions across access control (external sharing permissions), identification and authentication (SSO and MFA enforcement), system and communications protection (encryption in transit and at rest), and media protection (where files are stored and how they're sanitized).

The analysis surfaces a key finding: the tool's standard tier doesn't meet the FedRAMP Moderate or equivalent baseline that DFARS 7012 requires for cloud services handling CUI.

After review, the team decides is to modify the plan. The team procures the tool's government tier, restricts CUI sharing to approved workspaces, and updates the SSP and diagrams before rollout.

Maintaining your SIA process between affirmations

Completing an SIA should be part of your routine process, not a one-off task. Make the SIA a standing checkpoint in your existing change management process, and if you use a ticketing system, add the SIA fields to the change ticket itself.

You can batch low-risk changes: routine patching can be covered by a single recurring analysis rather than a per-patch review. Then review your change log quarterly to catch anything that slipped through and keep your SSP accurate.

Automation can take most of this routine work off of your team’s shoulders. Continuous monitoring platforms like Secureframe Defense track your environment against NIST 800-171 requirements and flag drift as it happens, so changes that affect your compliance posture surface immediately instead of during your next self-assessment.