Scoping your CUI environment involves a series of determinations: which systems are in scope, how CUI flows between them, and where your boundary sits. Those determinations only carry weight once they're documented, and the document that carries them is your System Security Plan (SSP).

The SSP is where your scoping work becomes something you can defend in your self-assessment, to a prime contractor checking its supply chain, or to an Affirming Official wondering why a system was designated out of scope.

This article covers how scoping decisions translate into SSP content, what the SSP needs to say about your boundary, and why the gap between documented scope and actual scope is one of the most common compliance findings.

What is a System Security Plan?

The System Security Plan is the master document describing how your organization implements NIST 800-171 requirements. It describes your environment, your boundary, and how each of the 110 security requirements is satisfied within that boundary. When you submit a self-assessment score to SPRS, the SSP is the document behind the number: it's the evidence that your score reflects an implemented reality rather than an aspiration.

Scoping sits at the center of your SSP because every implementation statement in the document is scoped by definition. "We enforce multi-factor authentication" is meaningless without a clear boundary that defines where. The SSP documents your scoping work by answering "On which systems, for which users, covering which data?"

How scoping decisions affect your SSP

Your CUI scoping decisions run through the entire document, but they appear most prominently in five places that explain your boundary. Understanding where each scoping decision lands helps you build the SSP deliberately, and it tells you which sections need to be updated when your scope changes.

The system description and boundary definition

The SSP opens by describing the environment it covers, and this is your scoping output directly: what the in-scope environment includes, where its edges are, and how the boundary is enforced.

If you're using a CUI enclave, this section describes it. If your boundary is logical separation within a broader network, this is where you document how that separation works. A reader should be able to determine from this section alone whether any given system in your organization is inside or outside the boundary.

The asset inventory

Every in-scope system, application, device, and service, each assigned to its asset category: CUI Asset, Security Protection Asset, Contractor Risk Managed Asset, or Specialized Asset, with the documented rationale for each designation.

Out-of-scope assets don't need full documentation, but the rationale for excluding them (physical separation, logical separation, no CUI access and no security function) should be recorded, because those exclusions are claims you'll need to support.

Data flow documentation

Your network diagram and data flow diagram show how CUI enters, moves through, and leaves your environment. These diagrams and the SSP need to tell the same story: anyone comparing your diagrams against your written boundary description will flag inconsistencies.

Control implementation statements

Each of the 110 NIST 800-171 requirements needs a written statement describing how it's implemented, and every statement reflects your scope.

Access control statements reference the users and systems inside the boundary. Audit statements reference the logging on in-scope systems. Media protection statements cover the media that carries CUI.

As your environment and scope changes, these statements need to change with it.

Specialized asset handling

For assets that can't meet standard controls such as IoT devices, operational technology, government-furnished equipment, the SSP documents what they are, why standard controls don't apply, and how risk is managed instead. This documentation is what keeps Specialized Assets from becoming a compliance liability.

When documentation doesn't match reality

One of the most common sources of compliance drift is outdated documentation, where the SSP describes an outdated version of your environment. The boundary description predates the cloud migration, or the asset inventory is missing tools that were adopted last quarter.

The SSP was accurate when written, but the environment kept changing and nobody owned the job of keeping the document current. When asked at the Secureframe National Cybersecurity Summit which requirements get marked as NOT MET most often, Mike Gallagher, Senior Director of Federal and Advisory Services at A-LIGN, put scoping first and the SSP right behind it: "If we see issues with the system security plan, and not enough information on how things are being implemented, that's a Not Met right there."

Assign ownership of the SSP, tie updates to the same triggers that prompt scope reviews, and treat the document as operational infrastructure rather than a compliance artifact that's produced once and then shelved.

Your submitted SPRS score is a representation of your compliance posture, and a score supported by an outdated SSP is a representation you can't defend.

How to document scope in your SSP

Most SSPs don't fail because something was left out. They fail because what's there is too vague to apply, too stale to trust, or too inconsistent to defend. These four habits are how you avoid that.

Write the boundary description so a stranger could apply it

Could someone outside your organization could take your SSP and correctly determine which systems are in scope? Vague boundary language ("CUI systems are protected by our security stack") fails this test. Use specific language, like "CUI is confined to the GCC High tenant and the three engineering workstations listed in Appendix A; all other systems are separated by the firewall rules documented in Section 4."

Document category rationale as you go

Write down each category rationale as you complete your asset inventory, rather than trying to reconstruct your decisions later.

Version the document

Date every revision, note what changed and why, and keep prior versions. The revision history is itself evidence that shows your SSP is actively maintained, and it allows you to demonstrate what your documented posture was at any point in time.

Let diagrams and text support each other

When updating one, review the other. Divergence between diagram and description is a clear signal that updates were only partially made.

SSPs can run hundreds of pages. Tightly scoping your CUI environment makes your documentation burden more manageable: the tighter and cleaner your boundary, the shorter the environment you have to describe and the fewer systems each control statement has to cover.