What the System Boundary Description Actually Is
The system boundary description is the section of your System Security Plan that defines what is inside your CMMC assessment scope and what is outside it. It tells your C3PAO assessor exactly which systems, networks, users, locations, and external services are part of the environment being assessed — and by extension, which controls apply where.
It is not a network diagram. It is not a list of IP addresses. It is a written narrative, supported by documentation, that establishes the logical and physical perimeter of your CUI environment with enough specificity that an assessor can independently verify it.
C3PAO assessors review the system boundary description before they look at anything else in your SSP. If it is vague, they will probe harder. If it is inconsistent with what they observe during assessment, everything built on top of it becomes suspect. If it is accurate, specific, and well-supported, it sets a credible foundation for the rest of the assessment.
What the System Boundary Description Must Cover
NIST SP 800-171 requirement CA.L2-3.12.4 requires that the SSP describe the system boundary, the operational environment, how the requirements are implemented, and the relationships with or connections to other systems. The CMMC Assessment Guide expands on what assessors expect to see. A complete boundary description addresses all of the following.
The system name and purpose
Name the system being described and state its purpose in plain terms. What does it do? What CUI does it process, store, or transmit? Which DoD contracts or programs does it support? This grounds the boundary in a specific operational context rather than treating it as an abstract IT environment.
Physical locations
List every physical location where in-scope systems reside or where CUI is accessed. This includes your primary office, any secondary locations, home offices if employees access CUI remotely, and any colocation or data center space. Each location should be identified by address or descriptor. "Our main facility" is not sufficient — assessors will ask which facility and where.
Hardware in scope
Identify the categories and counts of hardware within the boundary: workstations, laptops, servers, network devices (firewalls, switches, routers, access points), printers, and any other devices that process, store, or transmit CUI or provide security functions for systems that do. This should align directly with your asset inventory. If your asset inventory lists 14 workstations and your boundary description says "employee computers," that mismatch will be noted.
Software and applications
Identify the applications in scope — the software that handles CUI directly and the software that provides security functions for systems that do. This includes your operating systems, productivity applications where CUI is created or stored, engineering tools that process technical data, email platforms, collaboration tools, and security software. Version numbers are not required in the boundary description but should be in your asset inventory and baseline configuration documentation.
Network architecture summary
Describe how the network is structured in terms relevant to the boundary. Are CUI systems on a dedicated VLAN or network segment? How is the boundary separated from the general corporate network or guest networks? What controls exist at the boundary (firewall, IDS, proxy)? This does not need to be an exhaustive technical specification, but it must establish that a boundary exists and how it is enforced.
Users and roles
Identify who has access to in-scope systems. This means the count of users, their general roles (administrators, standard users, remote workers), and any privileged accounts. If contractors or third-party personnel have access, they must be included. The boundary description does not need to name every individual, but it should establish the population of users within scope.
External connections and dependencies
List every connection between your in-scope environment and external systems or services. This includes internet access, VPN connections, cloud services that store or process CUI, your MSSP or managed service provider, and any government systems you connect to. For each connection, identify what data flows across it, how it is protected, and whether the external party is also subject to CMMC requirements.
What is explicitly out of scope
A credible boundary description states not just what is in scope but what is deliberately excluded and why. If your marketing systems are separated from CUI systems by a firewall and no CUI flows to them, say so explicitly. If your accounting software runs on an isolated network with no CUI, document that. Explicit exclusions show the assessor that you have thought carefully about the boundary rather than simply drawing a line around your entire IT environment.
Strong vs. Weak: What the Difference Looks Like
The most common problem with SSP boundary descriptions is that they describe a boundary without actually defining one. Here is the same content written two ways.
This tells an assessor almost nothing. How many systems? Which cloud services? What firewall? Where are the systems located? What CUI categories are involved? This description will generate questions before the assessment even starts.
This gives an assessor a complete picture. They know what they are assessing before they walk in the door.
The Diagram Question
A network diagram is not a substitute for a written boundary description — but it is a required companion to it. The CMMC Assessment Guide expects both. The written narrative establishes the boundary in words. The diagram shows it visually. Together they give an assessor two ways to verify that the documented environment matches the real one.
Your network diagram should show all in-scope systems, network segments, boundary protection devices, and external connections. It does not need to be produced by a professional tool — a clear, accurate diagram produced in Visio, draw.io, or even PowerPoint is acceptable. What matters is accuracy. A polished diagram that does not match the actual network is worse than a rough one that does.
The diagram and the written boundary description must be consistent with each other and with your asset inventory. If the diagram shows three VLANs and the boundary description mentions two, assessors will ask. These inconsistencies signal that the documentation was assembled rather than developed from a real understanding of the environment.
Common Problems Assessors Find
The boundary doesn't match the asset inventory
Your SSP says 10 workstations are in scope. Your asset inventory has 13. Assessors reconcile these numbers and ask about the difference. If three workstations were excluded because they don't touch CUI, that exclusion needs to be documented in the boundary description with a rationale. Undocumented discrepancies look like oversights, not decisions.
Cloud services are omitted or vaguely described
Microsoft 365, Google Workspace, SharePoint, OneDrive, Dropbox — if CUI touches any of these, they are in scope and must be described in the boundary. "We use cloud services for email" does not tell an assessor which service, what CUI is in it, or how it is secured. Cloud services that handle CUI must be named, their FedRAMP authorization status noted, and the data flows documented.
The MSSP or MSP is not addressed
If a managed service provider has administrative access to your in-scope systems, they are part of your boundary whether you document them or not. An undocumented MSSP with RMM agent access to every in-scope endpoint is a finding waiting to happen. The boundary description must identify external parties with system access, what access they have, how it is controlled, and what their CMMC status is.
Home offices are ignored
If employees access CUI from home — through VPN, through a company-issued laptop, through a cloud application — those access points are part of your environment. The boundary description should address how remote access is controlled and what, if any, requirements apply to home office environments. Ignoring remote work in the boundary description when half the company works remotely is a credibility problem.
The boundary is written once and never updated
A boundary description that was accurate in 2024 may not reflect a new server, a new cloud application, a new office location, or a new MSSP added in 2025. Your SSP must reflect your current environment. An outdated boundary description that doesn't match what an assessor observes during assessment generates findings even if your actual security controls are solid.
What Assessors Will Ask
During a C3PAO assessment, the system boundary description is a starting point for a line of questions designed to verify that the documented environment matches the real one. Expect these.
| Assessor Question | What They Are Testing |
|---|---|
| Walk me through your CUI boundary. | Whether you can explain it in your own words. If you can't do it fluently, it signals the SSP was written by someone other than the people who run the environment. |
| How did you determine what was in scope? | Whether scoping was deliberate or arbitrary. Did you start with CUI data flows, or did you just draw a line around your IT department? |
| Show me the systems that are explicitly out of scope and why. | Whether exclusions are justified. "We decided not to include it" is not sufficient — the assessor wants to verify that excluded systems have no path to CUI. |
| Your diagram shows a connection to [external service]. Walk me through how that connection is protected and what data crosses it. | Whether every external connection in the boundary description has documented controls. Each one becomes its own line of questioning. |
| Has anything changed in your environment since the SSP was last updated? | Whether the SSP is maintained or static. New systems, new users, new services, or configuration changes since the last update are all fair game. |
Keeping the Boundary Description Current
The boundary description is a living document. Any significant change to your environment — a new server, a new application that handles CUI, a new office location, a change in your MSSP — should trigger a review and update of the boundary description and the relevant SSP sections.
At minimum, the SSP should be reviewed annually. Many organizations tie SSP reviews to their annual SPRS self-assessment cycle, which creates a natural forcing function. The review should verify that the boundary description, the asset inventory, and the network diagram are all consistent with each other and with the current environment.
Document the review even when nothing changes. A dated review record showing that someone verified the boundary description on a specific date is evidence of an active compliance program. No record of review is evidence of a static document that may not reflect reality.
How 1TEN Builds Your System Boundary Description
1TEN generates your system boundary description from the environment data you enter during setup — your asset inventory, your network architecture, your user roster, your external service connections. As you document your environment through the platform's guided interview process, the SSP Builder assembles your boundary description automatically from your actual configuration data.
The result is a boundary description that is specific to your environment, internally consistent with your asset inventory, and formatted for C3PAO review. When your environment changes, updating the relevant platform records updates the SSP. You are not maintaining a Word document separately from your compliance data — they are the same thing.
Every boundary description 1TEN generates addresses all the elements C3PAO assessors expect: physical locations, hardware and software inventory, network architecture, user population, external connections, and explicit out-of-scope exclusions with documented rationale.