Scope & boundary.
Draw the boundary before the assessment starts.
Before any assessment happens, an organization has to say what it’s actually assessing — which assets, which systems, which people, which providers. Get the boundary wrong and it fails in one of two directions: it misses something that matters, or it drags in things that don’t need to be there.
01Boundary before assessment
Scoping happens first, on paper, before an assessor ever looks at anything. The rule is explicit about what’s being defined:
The rule says
“The CMMC Assessment Scope must be specified prior to assessment… The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.”
32 CFR 170.19(a)(1)In practice
A bad boundary fails in two different ways, and they don’t cancel out. Draw it too narrow, and systems that genuinely touch CUI sit outside the assessment — a gap that surfaces later, at the worst time. Draw it too wide, and systems with no real connection to CUI get pulled in, adding assessment cost and time for no security benefit. Getting the boundary right is its own piece of work, separate from meeting the requirements inside it.
02The five asset categories
The Level 2 Scoping Guidance sorts everything in an environment into one of five categories — never four. Each one carries different documentation and assessment treatment.
| Category | What it is | How it’s treated |
|---|---|---|
| CUI Assets | Assets that process, store, or transmit CUI. | Documented in the asset inventory, SSP, and network diagram. Assessed against all Level 2 security requirements. |
| Security Protection Assets | Assets that provide security functions or capabilities to the assessment scope — firewalls, logging infrastructure, and similar. | Documented the same way as CUI Assets. Assessed against the Level 2 requirements relevant to the capability they provide, not the full 110. |
| Contractor Risk Managed Assets (CRMA) | Assets that can, but aren’t intended to, touch CUI, managed under the contractor’s own risk-based policy. Not required to be separated from CUI Assets. | Documented in the SSP. If the SSP documentation is sufficient, no further assessment against other requirements — though an assessor can run a limited check if something raises a question. |
| Specialized Assets | Assets that can touch CUI but can’t be fully secured: IoT/IIoT devices, Operational Technology, Government Furnished Equipment, Restricted Information Systems, and Test Equipment. | Documented in the SSP, showing risk-based management. Not assessed against other CMMC security requirements — an assessor reviews the SSP only. |
| Out-of-Scope Assets | Assets that cannot touch CUI and provide no security protection for CUI Assets, physically or logically separated from them. | No CMMC assessment. The contractor should be able to justify why the asset can’t process, store, or transmit CUI. |
Table 3 to 32 CFR 170.19(c)(1); CMMC Level 2 Scoping Guidance. Specialized Assets that involve operational technology overlap with the lab’s threat research on OT/ICS — a different lens on the same systems.
03Enclave vs. whole-company
Two honest starting points for drawing the boundary, with real trade-offs either way.
Whole-company. The entire environment is in scope. There’s no separate enclave to build, maintain, or defend as a boundary — but the assessment now covers everything, including systems that never come near CUI, and every future system added to the network potentially widens what has to be assessed again later.
Enclave. A logically or physically separated part of the network is built to contain where CUI lives and travels, so the CMMC Assessment Scope can be smaller than the whole company. Done well, this can meaningfully shrink what gets assessed. It also trades that smaller boundary for ongoing discipline: the enclave only stays smaller if CUI, and everything that touches it, genuinely stays inside the line that was drawn — a new integration, a convenience exception, or an admin account reaching in from outside can quietly erase the boundary’s value.
Neither is the correct answer in the abstract. Which one fits depends on how the organization already operates, not on which one sounds more rigorous.
04External Service Providers
An External Service Provider (ESP) is external people, technology, or facilities used for IT or cybersecurity services. 32 CFR 170.4 Under CMMC, a provider only counts as an ESP if CUI or Security Protection Data actually moves through its assets. A regional MSP running remote monitoring or backup is a textbook example.
A non-CSP ESP does not make the client’s responsibility disappear. Its services, responsibility matrix, and the client infrastructure that connects to it become part of the assessment story.
| The ESP handles | If it’s a CSP | If it’s not a CSP |
|---|---|---|
| CUI (with or without Security Protection Data) | The CSP must meet FedRAMP requirements. | The ESP’s services are in the OSA’s assessment scope and are assessed as part of the OSA’s own assessment. |
| Security Protection Data only (no CUI) | In scope, assessed as a Security Protection Asset. | In scope, assessed as a Security Protection Asset. |
| Neither CUI nor Security Protection Data | Not an ESP under CMMC’s definition. | Not an ESP under CMMC’s definition. |
Table 4 to 32 CFR 170.19(c)(2)(i).
This is the mechanism behind the point above: for a non-CSP ESP touching CUI, its services sit inside the OSA’s own assessment, not outside it. The relationship, the services provided, and each party’s responsibilities have to be documented — in the OSA’s SSP, and in the ESP’s service description and customer responsibility matrix.
Blanchard Tool & Machining is the desk’s fictional composite (any resemblance to an actual company is coincidental). Blanchard Tool & Machining’s two-person IT team leans on a regional MSP for remote monitoring (RMM) and backup — neither of which is a cloud service. Because CUI-bearing systems are reachable through that MSP’s tooling, the MSP’s services fall inside Blanchard’s own assessment scope, documented in Blanchard’s SSP with a customer responsibility matrix spelling out who does what. The MSP relationship doesn’t shrink Blanchard’s assessment; it becomes part of it.
05Cloud Service Providers
A Cloud Service Provider (CSP) is a specific kind of ESP — and one that clears a higher, specific bar when CUI is involved.
The rule says
“The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.”
32 CFR 170.19(c)(2)(i), Table 4In practice
A cloud provider that stores, processes, or transmits CUI needs FedRAMP Moderate authorization, or an accepted equivalency under the DFARS 7012 path — not simply a general security reputation or a SOC 2 report. Confirming this is a specific, checkable fact about a specific vendor, worth verifying directly rather than assuming.
06Common boundary mistakes
A flat network. If CUI-bearing systems and everything else share one unsegmented network, the boundary is effectively the whole company, whether or not anyone planned it that way. Segmentation, not a policy document, is what actually draws the line.
Shadow SaaS. A tool an employee signs up for directly — a file-conversion site, a project-tracking app, a personal cloud account used for convenience — can end up holding CUI without ever appearing on an asset inventory, simply because nobody scoped it in the first place.
Unmanaged email paths. Forwarding rules to a personal address, a shared inbox nobody owns, or a distribution list with no clear membership review can all carry CUI outside the boundary quietly, one message at a time.
CUI on personal devices or home drives. A drawing opened on a personal laptop to work from home, or saved to a personal cloud drive for convenience, moves CUI onto an asset that was never inventoried, never assessed, and often never even considered part of the environment.
None of these are exotic failure modes. They’re what happens when scope gets defined once, on a diagram, and daily operations drift away from it without anyone noticing.