TL;DR
Cybersecurity Maturity Model Certification (CMMC) scoping is where many readiness programs succeed or fail. If your scope is too broad, you spend more than necessary. If it is too narrow, you risk assessment failure, remediation delays, or CUI exposure. The most common mistakes include assuming controlled unclassified information (CUI) only lives in obvious systems, ignoring physical documents, overlooking shadow IT, misunderstanding external service provider responsibilities, and writing an system security plan (SSP) that does not match reality. The best way to avoid these mistakes is to map CUI flows, categorize assets correctly, define a defensible boundary, and collect evidence from day one.
Why CMMC Scope Matters So Much
From an assessor perspective, scoping errors are not minor documentation issues. They can fundamentally change what gets assessed.
Marc Zurcher, Managing Principal at Coalfire, emphasized this point during a recent webinar:
“Any CUI that is appearing outside of the scope that you’ve defined and you’re not enforcing what that scope is has the potentiality to blow up your assessment and blow up your scope for what is going to be assessed.”
That is why CMMC scoping must be validated against actual CUI movement. If sensitive data is discovered outside the boundary, assessors may ask for evidence covering systems, facilities, or workflows the organization did not expect to include.
CMMC scoping is not an administrative exercise. It determines which systems, users, facilities, processes, and service providers must be assessed against CMMC requirements.
Under 32 CFR 170.19, organizations must specify their CMMC Assessment Scope before assessment. The scope defines the assets in the organization’s environment that will be assessed against CMMC security requirements. The DoD Level 2 Scoping Guide further explains that asset categorization informs the boundary for a CMMC assessment.
That makes scoping one of the highest-leverage activities in the entire CMMC program.
Get it right, and the rest of the program becomes more manageable. Get it wrong, and everything downstream becomes harder: controls, documentation, evidence, costs, timelines, and assessor conversations.
At Fortra, we see scoping problems show up in two ways:
- The organization scopes too broadly and makes CMMC more expensive than necessary.
- The organization scopes too narrowly and cannot defend its boundary during assessment.
Both problems can put contracts, budgets, and timelines at risk.
Mistake 1: Starting with the Network Instead of Data
Many organizations begin scoping by drawing a network diagram. That can be useful, but it is not enough.
CMMC scope is driven by information systems and assets that process, store, or transmit FCI or CUI. If the network diagram does not show where CUI moves, it can create a false sense of readiness.
For example, a diagram may show a secure file repository as the approved CUI location. But if users download files to endpoints, email them to suppliers, print them for production, upload them to project management tools, or archive them in unmanaged folders, the real scope is much larger.
Practitioner recommendation:
Build a CUI data flow map before finalizing the technical scope. Identify where CUI enters, where it is stored, how it moves, where it exits, and where it could leak.
Mistake 2: Assuming CUI Only Lives in Obvious Repositories
CUI rarely stays in the system where it was intended to live.
It may begin in a secure portal or approved repository, but daily work often spreads it across collaboration tools, inboxes, endpoints, engineering workstations, PDFs, screenshots, exports, and printouts.
This is especially common in manufacturing, engineering, and defense supply chain environments where teams need to move quickly. A controlled drawing may be downloaded for review. A specification may be printed for a production meeting. A supplier may send updated technical data by email instead of through the approved channel.
Official CUI guidance emphasizes that CUI is sensitive information requiring safeguarding or dissemination controls, and DoD CUI resources explain that markings alert recipients that special handling may be required.
If CUI appears outside the approved boundary, the organization must either expand the scope or stop the flow.
Practitioner recommendation:
Use content, context, and user-based discovery methods to find CUI in unexpected places. Do not rely only on known folders or self-reported storage locations.
Mistake 3: Ignoring Physical CUI
One of the most common scoping mistakes is assuming CUI is only digital. In practice, CUI can appear in physical workflows as well.
As Lansing Nye-Madden, Solutions Engineer at Fortra, explained:
“It could be on endpoints, it could be in the cloud, it could be on file shares. It could even be a printout in somebody’s desk drawer.”
That example is simple, but important. A printed document can bring physical spaces, access controls, storage procedures, destruction processes, and personnel practices into scope.
CMMC scoping is not limited to digital systems. People, processes, and facilities matter.
Printed CUI can create serious scope complications. A document sitting in a desk drawer, production binder, conference room, printer tray, or filing cabinet may bring physical spaces and handling procedures into the assessment conversation.
The DoD CUI marking guidance includes instructions for marking unclassified documents containing CUI, including the use of the “CUI” marking at the top and bottom of pages and designation indicators. Those markings are useful only if organizations know when CUI is being printed and where it is going.
Physical CUI also raises questions about:
- Clean desk policies
- Printer access
- Secure storage
- Visitor controls
- Disposal procedures
- Facility access
- Production floor handling
- Shipping and mailing
Practitioner recommendation:
Include physical workflows in CUI discovery. Interview teams that print, ship, receive, inspect, manufacture, or archive controlled information.
Mistake 4: Treating External Service Providers as “Out of Scope by Default”
“A lot of clients and organizations I have worked with overemphasize and overthink that their external service provider is owning a lot more than they actually are. Make sure you know what’s in scope for that CRM and make sure you know what part that they’re owning and responsible for as of the audit versus what you’re actually responsible for. I’m sorry to tell you, you’re probably responsible for more than what you think you are.”
— Marc Zurcher, Managing Principal, Coalfire
Many organizations assume their cloud provider, MSP, MSSP, file transfer vendor, or SaaS provider owns the compliance burden. That assumption is risky.
CMMC scoping requires organizations to understand which external service providers process, store, or transmit FCI or CUI, or provide security protections for in-scope systems. The CMMC program also applies to contractor systems that process, store, or transmit FCI or CUI, provide security protections for those systems, or are not isolated from systems that do.
Organizations should understand:
- Does the vendor process, store, or transmit CUI?
- Does the vendor provide security services for CUI systems?
- What responsibilities does the vendor own?
- What responsibilities remain with the contractor?
- Is there a customer responsibility matrix?
- Is the vendor environment authorized or appropriate for the intended CUI use case?
- Can the vendor provide evidence?
Practitioner recommendation:
Maintain a responsibility matrix for each external service provider in scope. Do not assume inherited controls without documentation.
Mistake 5: Writing the SSP Before the Scope Is Defensible
The System Security Plan is one of the most important documents in a CMMC readiness program. But an SSP built on weak scope becomes a liability.
NIST SP 800-171 includes a security requirement for developing, documenting, and periodically updating system security plans, and NIST notes that organizations must ensure the required information is conveyed in those plans.
If the SSP says CUI is only stored in one environment, but evidence shows it also appears in email, endpoints, and cloud drives, the SSP is not aligned with reality. That misalignment can undermine assessor confidence.
A strong SSP should describe:
- The system boundary
- CUI data flows
- Asset categories
- In-scope users and roles
- External service providers
- Security controls
- Shared responsibilities
- Evidence sources
- Assumptions and limitations
Practitioner recommendation:
Treat the SSP as the story of how CUI is protected. Every major claim should be supportable with operational evidence.
Mistake 6: Underestimating Shadow IT
Shadow IT can quietly expand CMMC scope. Users may store CUI in unsanctioned cloud apps, collaboration spaces, personal drives, unmanaged devices, or unofficial file-sharing tools.
This often happens when approved workflows are too slow or too restrictive. Users are trying to get work done, not create compliance risk. But the result is the same: CUI appears outside the controlled boundary.
Practitioner recommendation:
Look for unauthorized cloud storage, unmanaged apps, browser uploads, email forwarding, and endpoint copies. Combine discovery with user education and safer approved alternatives.
Mistake 7: Confusing Intended Scope with Actual Scope
An intended scope describes where leadership wants CUI to live. Actual scope describes where CUI really lives.
Assessors care about reality. If CUI is found outside the intended boundary, the organization must address it. That can mean expanding scope, changing workflows, deleting unauthorized copies, reconfiguring controls, retraining users, or updating documentation.
Practitioner recommendation:
Validate the intended boundary through evidence. Use logs, scans, classifications, access records, DLP events, and interviews to confirm that CUI behaves the way the SSP says it does.
Mistake 8: Buying Tools Before Scoping
Tools can help with CMMC readiness, but buying technology before scoping often leads to waste.
Without a defined CUI boundary, organizations may buy tools for systems that do not need them, miss systems that do, or deploy controls that do not match actual risk. Scoping should guide technology decisions, not the other way around.
Practitioner recommendation:
Complete CUI discovery and high-level data flow mapping before major technology purchases. Then choose tools that enforce the defined boundary and generate useful evidence.
How to Build a Defensible CMMC Scope
Follow this sequence:
- Identify contracts and CUI obligations.
- Discover where CUI currently exists.
- Map CUI flows across systems and users.
- Identify approved and unapproved repositories.
- Categorize assets using DoD scoping guidance.
- Define the CUI boundary.
- Validate the boundary with evidence.
- Document the scope in the SSP.
- Apply controls to enforce the boundary.
Monitor continuously for drift.
How Fortra Helps
Fortra helps organizations move from assumed scope to defensible scope by discovering sensitive data, applying classification, enforcing movement controls, and producing evidence that supports the stated boundary. That practical approach helps organizations reduce cost, avoid surprises, and prepare for assessor scrutiny.
Expert Insight Featured in This Article
This article includes insights from a Fortra webinar featuring Skip Chapman, Director of Government Programs at Fortra; Lansing Nye-Madden, CISSP and Solutions Engineer at Fortra; and Marc Zurcher, Managing Principal at Coalfire. The discussion covered CMMC readiness, CUI discovery, scoping, audit evidence, and AI governance for organizations in the defense industrial base.
