CMMC "Significant Changes": Do They Really Invalidate Your Certification?

Paul Netopski

Welcome back to CMMC Unlocked. I’m Paul Netopski, and today we’re gonna unpack one phrase that’s been stressing out a lot of small defense contractors and consultants: “significant change.” You’ve probably heard it referenced in the CyberAB town halls, in the 32 CFR Part 170 preamble, and in the CMMC Scoping Guide for Level 2. And depending on who you listened to, you might have walked away thinking, “Any big change kills my certificate and I’m back to square one.” That’s… not what the rule actually says. So let’s ground this in the source material.

Paul Netopski

In the February 2026 CyberAB Town Hall, Matt Travis talked about “significant changes” and suggested that if the Affirming Official decides there’s been a significant change, the assessment would be invalidated and you’d need a new one. Remember: the CyberAB is not the government. They’re trying to be helpful to the ecosystem, but they don’t make policy. We have to go back to 32 CFR Part 170 and the official DoD guidance.

Paul Netopski

In the preamble to the rule — that long Federal Register explanation that sits in front of the regulatory text — DoD answered a bunch of public comments about self-assessments and the SPRS affirmation. One of those responses says, in plain language: if an Organization Seeking Assessment makes significant changes within its CMMC Assessment Scope, then a new assessment and a new affirmation are required. It also says OSAs are not required to use a C3PAO just to prep for their annual affirmation, and that DoD didn’t want to use SAM.gov for this because SPRS is more appropriate for sensitive cybersecurity information.

Paul Netopski

The key point: that preamble discussion is about keeping your Level 2 self-assessment and your SPRS affirmation honest and up to date. It’s not about automatically voiding a C3PAO certification the moment you make a big IT change. Now, fast forward to the CMMC Scoping Guide – Level 2, Version 2.13. In the “Separation Techniques” section it says that self-assessments and certification assessments are valid for a defined CMMC Assessment Scope. A new assessment is required if there are “significant architectural or boundary changes” to that scope. They even give examples: network expansions, mergers, and acquisitions. Then the guide contrasts that with “operational changes within a CMMC Assessment Scope” — adding or subtracting resources within the existing boundary that follow the existing SSP. Those do not require a new assessment; they’re handled through your annual affirmations of continuing compliance.

Paul Netopski

So we’ve got two related but distinct ideas that keep getting blended together. First, the preamble: significant changes inside the scope should trigger you to reassess and, if warranted, update your self-assessment score and your SPRS affirmation. That’s about integrity of your self-reporting. Second, the Scoping Guide: only significant architectural or boundary changes — things that reshape where CUI lives or what’s in scope — drive the need for a brand-new certification assessment by a C3PAO. Everything else, as long as it’s within your existing boundary and consistent with your SSP, is part of normal operations and gets covered by your annual affirmation.

Paul Netopski

Another important anchor is 32 CFR § 170.17. When it talks about maintaining a Level 2 (C3PAO) status, the rule focuses on the three‑year assessment cycle: to stay compliant, you have to complete the next certification within three years of the last one. It does not say “any significant change immediately invalidates your Level 2 certification.” What it does expect is that your environment changes over time and that your program — policies, procedures, and risk management — keeps control of those changes. So when you hear, “A significant change will automatically invalidate your cert,” that’s an over-simplification. The actual structure is: use your risk process to decide whether a change is significant, use that decision to update your self-assessment and SPRS, and if the change crosses into architectural or boundary territory, then you coordinate for a new certification assessment scoped to the new reality.

Paul Netopski

Bottom line for small OSAs and the consultants helping them: “significant change” is a trigger for you to think — not a doomsday switch that erases your C3PAO result. Your job is to define what “significant” means in your context, document how you’ll recognize it, and then align your self-assessments, affirmations, and, when necessary, certification scope to that definition.

Paul Netopski

If you’ve listened to our earlier episodes on NIST-style risk management — things like 800‑37, 800‑53, and 800‑53A — you’ve already seen this movie. Those documents talk about event‑driven reauthorization when there’s a “significant change” to a system: you don’t re-authorize just because the calendar rolls over; you do it when the risk picture really shifts. The same logic applies to CMMC. In my own write‑up I summarized “significant change” as any change likely to substantively affect the security or privacy posture of a system, its common controls, or its operating environment. That’s exactly the kind of thing that should trigger re‑assessment activity.

Paul Netopski

I like to use a simple matrix — ten categories of change that come straight out of that NIST worldview: 1) Threat, vulnerability, or risk changes. 2) Continuous monitoring findings. 3) Architecture and technology changes. 4) Data processing changes. 5) Security control changes. 6) Mission or business changes. 7) Governance or leadership changes. 8) Supply chain changes. 9) Environment of operation changes. And 10) Organizational or threshold-based triggers. You don’t need a giant bureaucracy to use this. For a 50‑person machine shop, it can be a one‑page checklist that your IT lead walks through whenever a big change ticket comes in.

Paul Netopski

Let me make this concrete with a few small‑business examples. Imagine architecture and technology first. You move your CUI enclave from an on‑prem file server into a new Microsoft 365 GCC High tenant. That’s a major architectural change to where CUI is processed and stored. Your boundary has shifted from a local network with a VPN to a cloud service with different security dependencies. That should absolutely trigger a new Level 2 self‑assessment and a fresh SPRS affirmation. And, because your Level 2 certification scope has fundamentally changed, you’d work with your C3PAO to plan a certification assessment of that new architecture.

Paul Netopski

Now contrast that with an operational change in the same enclave. You add five new engineering workstations inside the existing segmented CUI network, built from the same hardened image, managed by the same tools, and documented in the same SSP. That’s additional capacity, not a new boundary. The Scoping Guide is very explicit: adding or subtracting resources within the existing assessment boundary, following the existing SSP, does not require a new assessment. That’s the kind of thing you capture in your annual affirmation — “we’re still doing what we said we do, at the same level of rigor, just with more endpoints.”

Paul Netopski

Take mission and data processing changes. Suppose you win a new contract that introduces a different CUI category — maybe export-controlled technical data you didn’t handle before — and to deliver it you start pushing that data through a new CAD platform and a new external manufacturing partner. You’ve changed what’s being processed, where it flows, and who is involved. That’s a multi‑category significant change: mission/business, data processing, and supply chain. Even if your network topology barely moves, your risk posture has, and you should treat that as grounds for a new self‑assessment and affirmation at a minimum. Depending on how much of your certified scope is affected, you may decide to bring your C3PAO back in to certify the updated boundary.

Paul Netopski

What about things that probably stay in the “annual affirmation” bucket? Typical examples: you rotate to a new firewall model but apply the same rule set and same segmentation; you replace laptops on a three‑year refresh cycle using the same secure baseline; or your vulnerability scanning program switches tools but keeps the same coverage, frequency, and process. Those do change your technical stack, but if you can show they follow the existing SSP and don’t expose new CUI paths, they’re operational changes within the boundary. You still do a security impact analysis under 800‑53 style CM, you still update diagrams and inventories, but you don’t automatically trigger a new certification engagement.

Paul Netopski

All of this leads to the role of the Affirming Official — the person who signs your Level 2 affirmation in SPRS. In the preamble, DoD essentially says, “That person must decide when a significant change has occurred.” They’re the one accepting risk on behalf of the organization. Practically, that means they need a written definition of “significant change” that’s tuned to your business and aligned with those ten categories. And they need that definition embedded into your change‑management program: every RFC, every major project, every M&A activity should explicitly ask, “Does this meet our Significant Change criteria?” If the answer is yes, it triggers a mini risk assessment: what controls are impacted, what’s our plan to assess them, and do we need to update SPRS and our certification scope. That’s how you pull this out of the rumor mill and root it in disciplined risk management.

Paul Netopski

Let’s wrap up with a practical playbook you can actually plug into your ticketing system. Think of this as a three‑path decision tree for every major change. Step one: catalog the change. That’s just good configuration management — CM.L2‑3.4.3 and 3.4.4 in NIST 800‑171 language. You document what’s changing: systems, data flows, external parties, facilities. Step two: do a quick security impact and risk check. Use those ten change categories as prompts. Which ones light up? Does this alter where CUI is processed, stored, or transmitted? Does it bring in a new External Service Provider that will hold CUI or Security Protection Data? Does it change the separation techniques that you relied on to keep assets out of scope?

Paul Netopski

From there, you choose one of three paths. Path one: “no significant change.” You’ve done the analysis and concluded the risk posture is essentially unchanged — say, swapping out a like‑for‑like firewall or refreshing endpoints with the same image. You still update your inventories, your SSP where needed, and your network diagrams, but you don’t rerun the full self‑assessment just for that event. It rolls up into your periodic RA.L2‑3.11.1 risk assessment and your annual affirmation that “nothing materially changed our conformity to the requirements.”

Paul Netopski

Path two: “significant change, same boundary.” This is where the preamble language really applies. Example: you re‑platform your SIEM to a new cloud provider that’s now hosting all your Security Protection Data, but your CUI network segments and asset categories are the same. Or you adopt a new M365 configuration baseline that materially changes how you implement several controls. You decide this is significant because it affects multiple controls and your risk picture, but it doesn’t redraw the outer edge of the CMMC Assessment Scope. In that case, you should conduct a focused Level 2 self‑assessment on the impacted controls, update your overall score as necessary, and submit a new SPRS affirmation tied to that assessment date. You do not automatically need a new C3PAO certification; your existing certificate remains valid for that scope and three‑year window, as long as your implementations continue to meet the objectives.

Paul Netopski

Path three: “significant architectural or boundary change.” This is the Scoping Guide language. If your change looks like their examples — network expansions that connect new sites into the CUI enclave, major consolidations, or mergers and acquisitions that pull in new business units handling CUI — you’re outside “operational change” territory. You’ve changed the CMMC Assessment Scope itself. Here, you do both: you reassess and reaffirm in SPRS so your self‑assessment stays honest, and you coordinate with your C3PAO to plan a new certification assessment scoped to the new boundary. That might be a full re‑engagement; in some cases it may be an assessment of the expanded enclave. Either way, it’s a deliberate decision, not a panic button.

Paul Netopski

A couple of related myths to clear up. First, a properly scoped Level 2 certification is not retroactively voided every time DCMA DIBCAC shows up later for a Level 3 and finds issues. The Scoping Guide explains that for Level 3, DIBCAC may check any Level 2 requirement on any in‑scope asset, including Contractor Risk Managed Assets and Specialized Assets. If they find problems, you’ll have to fix them, and it’ll affect your Level 3 outcome — but it doesn’t rewrite history and say your earlier Level 2 assessment never existed. Second, normal operational churn doesn’t reset the three‑year clock. The regulatory text is clear: your obligation is to get the next Level 2 certification done within three years of the last C3PAO status date, not every time you swap a switch.

Paul Netopski

So what should you actually build? My recommendation is three artifacts. One, a written “Significant Change Criteria” annex to your System Security Plan. This is where you define, for your environment, how those ten NIST categories map to significant vs operational changes, and which ones are boundary‑affecting. Two, an annex to your Change Management Plan that adds a mandatory check box: “Does this change meet our Significant Change criteria?” with a short impact analysis when the answer is yes. That keeps your Affirming Official in the loop before the change goes live, not months after. Three, train your IT staff and key business owners — contracts, operations, engineering — to flag potential significant changes early. M&A isn’t usually run out of the help desk; if your leadership team doesn’t know that pulling in a new division’s network could trigger a CMMC scope redesign, you’ll always be reacting late.

Paul Netopski

If you put those pieces in place and run them through your existing risk assessment process — the same RA and CA requirements you’re already supposed to meet — “significant change” stops being this scary, vague phrase from a town hall slide. It becomes a structured decision point you can defend to your C3PAO, to DoD, and to yourself. And that’s really the goal: decisions driven by documented risk analysis and the official guidance — the 32 CFR 170 preamble, the Level 2 Scoping Guide, and the Level 2 Assessment Guide — instead of fear or rumor.

Paul Netopski

Alright, we’ll leave it there for today. If you found this useful, go back to our earlier discussions on risk assessments and configuration management — they tie directly into how you operationalize this. I’m Paul Netopski, this is CMMC Unlocked, and we’ll keep breaking this stuff down so you can stay mission‑focused and compliant without losing your mind. Talk to you next time.