Ask ten defense contractors to define their CMMC scope and you'll get ten answers about technology. "Our enclave." "The GCC High tenant." "Everything behind the firewall." Those are boundary implementations. None of them is a scope.

Scope is a formal, regulated concept. It has a definition in the rule, a required categorization method, and documentation an assessor is obligated to check. Getting it wrong doesn't just cost you time — it invalidates the score you posted to SPRS and it is the single most common reason an assessment goes sideways before the controls are even discussed.

This is the second brief in a series working through CMMC from the ground up. The first covered why readiness is usually overestimated. This one goes deep on scoping, because everything downstream depends on it.

Definition

What CMMC scope officially means

The governing text is 32 CFR § 170.19(c). Before an assessment — self-assessment or certification — the organization must specify its CMMC Assessment Scope, which defines which assets in the environment will be assessed and how. The Department's CMMC Assessment Scope: Level 2 guidance, published by DoD CIO, is the companion document that explains how to do it.

Three points from those sources are worth stating plainly, because they're routinely misunderstood.

You propose the scope. The assessor validates it. Scope is not assigned to you and it is not negotiated during the assessment. You define it, you document it, and it becomes the thing your evidence has to defend.

Scope is determined by assets, not by networks. The rule works through asset categorization. Every asset in your environment is placed into one of five categories based on its relationship to CUI and to the security of the CUI environment. The boundary is the consequence of that exercise, not the input to it.

Classified systems are outside the CMMC program entirely, even where they hold applicable CUI. They're governed elsewhere.

The boundary is the output of asset categorization. Most companies treat it as the input — they draw the line first, then try to make the assets fit.

The rule

The five asset categories, from the rule

Under § 170.19(c)(1), Table 3, every asset lands in one of five buckets. What differs between them is not whether they're in scope — four of the five are — but what you must document and how they get assessed.

Two of these deserve more attention than they usually get.

Security Protection Assets are wider than people expect

An SPA doesn't have to touch CUI. It qualifies by protecting the environment or by holding Security Protection Data — security-relevant information that would help an attacker if disclosed. Configuration data for a security tool counts. So do log repositories, vulnerability scan results, and authentication infrastructure.

The practical consequence: your SIEM, your MFA provider, your EDR console, your firewall management platform and the MSP tooling that reaches into your environment are all in scope. If your MSSP holds your logs, that provider is inside your assessment story whether or not CUI ever reaches them.

Contractor Risk Managed Assets are the category people abuse

CRMAs are assets that could handle CUI but don't, because your policies stop them. They stay in scope, they get documented, and they are not assessed against the requirements — unless your documentation is thin or something during the assessment raises a question. Then they get assessed.

That conditional is the whole game. CRMA is not a way to shrink your assessment by relabelling inconvenient systems. It's a category that has to be earned with policy, enforcement and evidence. Label a workstation a CRMA, then have an assessor find a CUI drawing in its downloads folder, and you have converted a documentation shortcut into a finding — and put every other CRMA claim under suspicion.

Interactive

Which category is this asset?

Work through one real asset at a time. The questions follow the order the rule applies them.

Method

The official scoping process, step by step

The guidance implies an order. Skipping steps is what produces the boundary-first mistake.

1. Identify your CUINot "we handle CUI" — which categories, from which contracts, under which markings. Controlled Technical Information behaves differently from procurement-sensitive material. Your contracts team holds this answer, not IT.
2. Trace how it movesFollow actual documents from arrival to disposal. This is the step that gets skipped, and section six of this brief is entirely about why.
3. Inventory every asset that appears in those flowsIncluding the ones that surprised you. An asset that appeared once in a trace is an asset in your inventory.
4. Categorize each assetApply Table 3 honestly. Where you're tempted to argue an asset into a lighter category, write down the argument — you'll need it.
5. Decide your boundary strategyEnclave, segmented network, or whole environment. This is where technology finally enters, and it should be chosen to fit the flows you traced.
6. Document it four waysAsset inventory, SSP, network diagram, data flow diagram. They have to agree with each other and with reality.
7. Re-run it when the environment changesScope is not a one-time artifact. New SaaS tool, new supplier, new workflow — scope moves.

Strategy A — Enclave

Corporate network

CUI enclave

VDI · file store
email · apps
SPA tooling

In scope

Sales · CRM
HR systems
Marketing

Out of scope

Small scope. Hard boundary to hold.

Strategy B — Flat network

Corporate network

workstations · file servers
email · ERP
engineering apps · backups · print
SPA tooling · MSP access · VPN
shop floor gateways · test rigs

All in scope

Large scope. Nothing to defend at the edge.

The core problem

Where it breaks: nobody traces the data

Here is the failure I see most, and it's remarkably consistent. A company builds a scope from an architecture diagram rather than from observed data movement. The diagram shows how the network was designed. It does not show what people actually do with documents.

Tracing means taking one real CUI item — a specific drawing, a specific contract deliverable — and following it end to end, asking at each hop: where did it land, who touched it, what copy was left behind. Every organization I've done this with finds at least one path nobody had documented.

None of these are exotic. They're ordinary work. The problem isn't that they exist — it's that they exist and aren't on the diagram, so the scope you documented describes a company that doesn't quite exist.

Scoring

What scoping means to your SPRS score

People treat the SPRS score as an arithmetic exercise. It is — but the arithmetic runs over your scope, which means a wrong scope produces a wrong score no matter how carefully you added up the points.

The mechanics, from the NIST SP 800-171 DoD Assessment Methodology: you begin at 110, one point for each requirement. For each requirement not fully implemented, a weighted value of 5, 3 or 1 is subtracted depending on its impact. There is no partial credit — a requirement is met or it isn't, with narrow exceptions for MFA and FIPS-validated encryption where partial deductions apply. The floor is −203. A contractor self-assessment is a Basic assessment; Medium and High are performed by the government.

• 110All 110 met
• 8880% threshold
• −203Floor

Weighted deductions per unmet requirement

• −5 pointshighest impact requirements
• −3 pointssignificant impact
• −1 pointlimited impact

Now the scoping connection. The score is calculated against a system security plan, and that SSP is mapped to specific CAGE codes. So the score answers a narrow question: how completely are the 110 requirements implemented across the system this SSP describes?

Which produces three failure modes:

• Scope drawn too small — you score against an enclave while CUI lives outside it. The number is high and wrong.
• Scope drawn without tracing — assets you never inventoried aren't in the calculation at all, so requirements you'd fail were never tested.
• SSP doesn't match the CAGE codes on the contract — the score doesn't cover the system doing the work.

The methodology is explicit that an assessment can't be conducted without a system security plan; its absence is itself a finding of non-compliance with DFARS 252.204-7012. A plan describing the wrong system is a subtler version of the same problem.

And this matters commercially right now. Contracting officers check SPRS before award under DFARS 252.204-7019. An inflated score isn't just a compliance issue — a representation you can't support carries False Claims Act exposure, which the Department has been increasingly willing to pursue.

Assessment

What scoping means to a C3PAO assessor

Third-party certification is currently suspended under the Phase 2 pause, but the assessment methodology hasn't changed and self-assessments follow the same scoping rules. Understanding how an assessor treats scope is useful either way.

Scope is validated first, in pre-assessment. Before anyone looks at a control, the C3PAO reviews the SSP, confirms the assessment scope, and validates that you've correctly identified CUI Assets, Security Protection Assets and Contractor Risk Managed Assets. Your asset inventory and diagrams are the evidence for that conversation.

Every requirement is evaluated by examine, interview and test. Documents alone won't carry it. The assessor reads the artifact, asks the owner to explain it, and watches the control operate.

Findings are binary. Each objective is met or not met. There's no partial credit at the objective level, which is why "we're mostly doing that" is not an answer that survives.

A bad scope is expensive mid-assessment. If an assessor finds CUI on an asset you categorized as a CRMA or excluded entirely, that asset comes into scope and gets assessed. You now have an unprepared system inside a live assessment — and the assessor has a reason to question your other categorizations.

On outcomes: a Level 2 certification assessment that clears the bar with some eligible items outstanding yields Conditional status, requiring a POA&M closeout within 180 days to become Final. Certain requirements can't be deferred to a POA&M at all, and there's a minimum score threshold to qualify for conditional status in the first place. A Final certification lasts three years, with annual affirmations throughout.

Worth internalizing: the 180 days runs from conditional status, not from when you get around to it. A scope problem discovered during assessment eats that window fast.

Documentation

The four documents that must agree

Scoping produces four artifacts. Assessors read them against each other, and contradictions between them are the fastest way to lose credibility.

• Asset inventory — every in-scope asset with its category and owner
• System Security Plan — boundary, architecture, categorization rationale, how each requirement is implemented
• Network diagram — the assessment scope drawn, including Specialized Assets
• Data flow diagram — how CUI actually moves through that architecture

The data flow diagram is the one most often missing, and it's the one that proves the other three. Without it, your categorization is an assertion. With it, categorization becomes a conclusion someone else can follow.

FAQ

Common questions

Does an enclave automatically reduce my scope?

Only if CUI genuinely stays inside it. An enclave is a claim about data movement, and the claim has to hold under tracing. If people email documents out, download them locally, or print them, the enclave is a diagram rather than a boundary.

Are Contractor Risk Managed Assets a way to shrink the assessment?

Not reliably. CRMAs stay in scope and are documented; they escape assessment only while your risk-based policies and documentation hold up. Weak evidence or a contrary finding pulls them in.

Is our MSP in scope?

If their tooling provides security functions to your environment or holds Security Protection Data, that tooling is a Security Protection Asset. If CUI reaches their systems, more follows. Either way it belongs in the SSP with responsibilities described at the control level.

What about machines on the shop floor?

OT, IoT and test equipment are Specialized Assets. They're in scope, must appear in the SSP and on the diagram with a risk-based management approach described — but they aren't assessed against the other requirements.

Do out-of-scope assets need documentation?

The rule imposes no documentation requirement for them. In practice, be ready to explain why they can't touch CUI — separation, function, or enforced policy. "We didn't think about it" isn't a justification.

How often should scope be revisited?

Whenever the environment changes materially: a new cloud service, a new provider, a new CUI workflow, a migration. Tie scope review to change management rather than to the assessment calendar.

This brief reflects program status as of 19 August 2026 and cites the rule text in force at that date. Verify current requirements against your contract clauses and the published DoD guidance before making scoping decisions.