NIST SP 800-171 Rev. 3: Define the CUI Boundary Before You Build the SSP

Scope Comes Before the SSP

A defensible System Security Plan (SSP) starts with a defensible system boundary. If the boundary is vague, the SSP becomes a list of policies and tools without a reliable answer to the questions an assessor will ask: which CUI is protected, where does it move, which components and people can affect it, and which controls are actually inherited from another service?

NIST SP 800-171 Rev. 3 provides security requirements for protecting Controlled Unclassified Information (CUI) in nonfederal systems and organizations. Its guidance is not, by itself, a universal certification or contract obligation. The applicable contract, solicitation, federal agreement, agency direction, customer flow-down, CMMC rule, or other authority determines what an organization must do and when. Use the authoritative NIST SP 800-171 Rev. 3 publication as the requirements source, then record the contract facts separately.

1. Establish What CUI You Actually Handle

Start with the information, not the product inventory. For each CUI flow, record the category, subcategory if applicable, markings, designating agency or authority, contract or program source, and the business activity that creates or receives it. Validate the category and safeguarding authority against the NARA CUI Registry and the controlling agreement. Ordinary confidential business information is not automatically CUI, and a government customer label is not a substitute for tracing the authority.

Interview contract owners, program managers, engineering, security, records, facilities, and key providers. Ask where CUI enters the organization, where it is stored, who uses it, which systems transform it, and where it leaves. Include paper output and removable media when they are part of the lifecycle. A CUI category without a documented lifecycle is not yet a usable scope decision.

2. Map the Boundary Across People, Places, and Technology

Trace each CUI path from origin to disposition. Your inventory should cover:

• Repositories and processing systems: databases, file shares, collaboration spaces, applications, queues, logs, and temporary storage that store or process CUI.
• Endpoints and identities: workstations, laptops, mobile devices, service accounts, administrators, privileged roles, contractors, and other people who can access or influence the environment.
• Facilities and physical media: offices, data centers, home-work locations where permitted, print areas, shipping locations, removable media, and backup or recovery sites.
• Providers and dependencies: cloud hosting, managed security, SaaS, telecommunications, support vendors, software suppliers, and sub-tier providers that can store, process, transmit, administer, or restore CUI.
• Transfer paths and connections: APIs, VPNs, email, file exchange, integrations, remote administration, network links, portals, partner connections, and interfaces to systems outside the CUI environment.

Draw the boundary around the components that handle CUI and document every external connection that can move CUI across it. Also record systems that do not handle CUI but provide security-relevant services, such as identity, logging, time, endpoint management, backup, vulnerability scanning, or incident response. An exclusion is a reasoned statement about data flow and access, not simply a box left off an asset list.

3. Document External Connections and Inherited Controls

For every provider or connected system, capture the service, data exchanged, direction of flow, access method, tenant or account boundary, administrator responsibilities, contract terms, and review cadence. Identify whether the provider receives CUI, can administer an in-scope component, supplies a common control, or merely supports an operational dependency. Record the evidence you expect from that provider and the evidence your own team must retain.

Inherited controls should make ownership clearer, not make evidence disappear. State the control or requirement, the inherited service, the provider or internal owner, the portion your organization still operates, the assumptions and limitations, and how inheritance will be validated. If a provider supplies MFA, logging, backups, or physical security, retain the relevant agreement, service description, configuration or attestation, review record, and exception path. Do not claim a control is inherited merely because a vendor advertises a security certification.

4. Turn the Boundary Into a Scope and Evidence Register

Once the data-flow map and boundary are drafted, convert them into a working register that can drive the SSP and assessment. At minimum, give each scope item and requirement decision:

• An accountable owner for the system, flow, provider, control, or decision.
• A source and scope statement connecting the item to a CUI category, authority, contract, boundary component, or external connection.
• A target or effective date and the date the item was last reviewed.
• A status such as implemented, partially implemented, planned, inherited, not applicable with rationale, or not implemented.
• An evidence location and validation method describing what will be examined, who will be interviewed, or what will be tested.

Use the register to link architecture diagrams, asset and supplier inventories, access reviews, configuration exports, contracts, policies, tickets, logs, backup tests, and boundary-rule reviews to the relevant requirement or scope decision. Give unresolved items a due date, risk treatment, dependency, and closure test. This creates a traceable handoff from CUI discovery to SSP content instead of asking the SSP to carry undocumented assumptions.

5. Use Rev. 3 and 800-171A Rev. 3 Together

The companion NIST SP 800-171A Rev. 3 assessment publication describes assessment objectives and procedures using examine, interview, and test methods. Use those methods while validating the boundary: examine the diagram, inventories, agreements, and register; interview the people who can explain each flow and inherited service; and test representative boundary rules, access paths, logging, backup recovery, or transfer controls. The assessment publication helps you evaluate implementation; it does not replace the contract or create an obligation that the controlling agreement does not contain.

For a broader sequence from scope through ODPs, SSP, POA&M, and continuous monitoring, follow the full NIST 800-171 Rev. 3 implementation guide. When you are ready to turn the boundary into an initial gap picture, use the NIST 800-171 readiness flow. For related program context, review the CMMC compliance guide and confirm which CMMC or contract requirements actually apply to your engagement.

Readiness Check

You are ready to build or update the SSP when a reviewer can follow every CUI flow to its repositories, endpoints, identities, facilities, providers, backups, and transfer paths; see why each component is in or out of scope; identify inherited-control owners and limitations; and find dated evidence with a status and validation method. If those answers are not available, keep working on the boundary first. A smaller, well-supported boundary is more defensible than a large scope assembled from assumptions.