The CUI boundary you documented in a System Security Plan is a snapshot in time. But your organization keeps moving: new contracts arrive, tools get adopted, people change roles, infrastructure migrates. Each change can alter where CUI lives and flows, affecting your CUI scope.

The organizations that keep their CUI scope accurate don't rely on someone remembering to check on it just before an annual affirmation or prime review. They tie scope reviews to specific events.

1. A new contract, task order, or contract modification

New work can introduce new CUI exposure, new marking requirements, new flowdown obligations, or a different CMMC level than anything in your current portfolio.

Review your contract clauses and any CUI-identifying documents before performance starts, and confirm whether the information coming with the work fits inside your existing boundary or requires expanding it.

2. A new system, application, or service that could touch CUI

Every tool adoption is a potential scope event: a new collaboration platform, file sharing service, engineering application, or AI tool your team wants to try.

The question to ask before adoption: will this system store, process, or transmit CUI, protect systems that do, or have the ability to access them?

The answer determines whether the tool enters your boundary, needs to be technically prevented from touching CUI, or sits outside scope.

3. Infrastructure changes and cloud migrations

Moving workloads between environments, changing cloud providers, restructuring your network, or consolidating file storage all redraw data flows even when the information itself doesn't change.

A migration that moves a CUI file share to a new platform moves your boundary with it, and the new platform inherits every safeguarding requirement the old one carried, including the FedRAMP Moderate equivalent expectation for cloud services holding CUI.

4. Personnel and access changes

People are in scope too. New hires who need CUI access require training and provisioning. Departures require prompt access revocation. Role changes require review as well: someone moving from a CUI-handling program to one without CUI should lose access they no longer need. A quarterly access review catches what individual transitions can miss.

5. New or changing subcontractors

Bringing a subcontractor into CUI-involved work extends your obligations beyond your own boundary: flowdown clauses, verification of their compliance posture, and controlled transfer mechanisms all become part of your scoping picture.

The same applies in reverse when a subcontract ends: confirm what CUI the subcontractor holds and what your contract requires for its return or destruction.

6. Mergers, acquisitions, and organizational restructuring

An acquisition brings an entire second environment whose CUI posture is now your responsibility, and integration decisions (shared identity, consolidated file storage, merged networks) can connect previously separate environments in ways that expand scope dramatically and instantly.

7. The self-assessment and annual affirmation cycle

The annual affirmation of your SPRS score is the natural checkpoint to re-verify that your documented scope still matches reality. Review the asset inventory, re-trace the data flows, and confirm the SSP describes the environment you're running today. Affirming a score built on last year's boundary is the kind of representation that creates False Claims Act exposure.

Where "significant change" under CMMC fits in

Under 32 CFR Part 170 and the CMMC Level 2 Scoping Guide, a significant change is one that alters your assessment scope or architecture: changes to your boundary, to where CUI lives, or to how it's protected. The scoping guide draws the line between changes like these and operational changes within your existing boundary, like routine patching, replacing like-for-like hardware, or adding users to an already-documented system, which don't rise to the same level.

When a trigger on this list produces a significant change, re-run your self-assessment against the affected requirements and update your score. Don't wait for the calendar to flip over to your annual affirmation date.

A brief, written analysis of each material change, what changed, whether it affected your boundary or control implementations, and what you did about it, is what turns that judgment into a defensible record. A structured security impact analysis is the cleanest way to run and document that determination.

Building scope change triggers into daily operations

The triggers above only work if they reliably reach whoever owns your scope documentation. Integrating these four practices into your operations will help ensure they do.

Integrate scope reviews into existing processes

Contract review already happens before signature, so add a CUI clause check to it. Procurement already approves new tools, so add the four scoping questions to the intake form. Onboarding and offboarding processes already have checklists — CUI access provisioning and revocation should be on them.

The goal is to attach scope questions to processes that have already been established, rather than creating a new, parallel process that needs to be owned and adopted.

Designate an owner

One named owner, with the authority to update the SSP and asset inventory, makes trigger events become actual documentation updates instead of Slack notifications that go unread.

Log every review

A review that determines "no scope change" should still be recorded. This log demonstrates your scope review discipline exists and shows that your documentation is actively maintained.

Update documentation as a set

When scope changes, the asset inventory, data flow diagrams, boundary description, and affected SSP implementation statements should all change as well.