What Is Actually In Scope for CMMC?

CMMC scope is not automatically the entire company.

The right scope depends on where Controlled Unclassified Information (CUI) exists, how it moves through the organization, which systems and people interact with it, and what technology or service providers protect or support that environment.

Getting scope wrong can make CMMC dramatically more expensive and complicated than necessary, or leave important parts of the environment outside the assessment boundary when they should be included.

Hotman Group helps organizations define practical CMMC scope by tracing CUI, identifying relevant assets and dependencies, understanding external service providers and designing an assessment boundary that reflects the real environment.

The objective is not the smallest possible scope. It is the correct scope.

What Determines CMMC Scope?

CMMC scope is driven largely by the systems, people, services and environments involved in protecting, processing, storing or transmitting CUI.

That means scope should begin with understanding:

• What CUI the organization receives or creates.
• Where the CUI comes from.
• Where it is stored.
• Where it is processed.
• How it is transmitted.
• Who can access it.
• What systems support the environment.
• What external providers are involved.

The assessment boundary should reflect those actual information flows and dependencies.

What Is CUI?

Controlled Unclassified Information is information that requires safeguarding or dissemination controls under applicable laws, regulations or government-wide policies but is not classified information.

For CMMC purposes, organizations need to understand what contract-related information they handle that qualifies as CUI and where that information exists in the environment.

Simply working for the Department of Defense does not mean every file, system or employee handles CUI.

Why Should We Start With CUI Instead of With Systems?

Because starting with a system inventory often causes organizations to assume far more of the environment is in scope than necessary.

Start by tracing the information.

Ask:

• Where does CUI enter the organization?
• Who receives it?
• Where is it saved?
• Which applications process it?
• How is it shared?
• Where is it backed up?
• Which administrators can access systems containing it?
• Which providers support those systems?

Then determine which assets and services participate in or support those flows.

What Types of Assets Can Be In Scope for CMMC?

Depending on the environment, in-scope assets may include:

• Workstations.
• Servers.
• Cloud services.
• File repositories.
• Email systems.
• Identity systems.
• Network infrastructure.
• Security tools.
• Administrative systems.
• Backup systems.
• Mobile devices.
• Virtual desktops.
• Applications.
• External services.

The reason an asset is in scope matters as much as the asset type itself.

Are All Employees In Scope for CMMC?

No.

Employees who handle CUI or administer, support or protect the CMMC environment may be relevant to the assessment boundary.

Other employees may have no interaction with CUI or the systems that protect it.

The organization should understand which users actually participate in the environment rather than assuming every employee is automatically subject to the same scope.

Are Administrators In Scope Even If They Do Not Normally Read CUI?

Potentially, yes.

Privileged administrators may have the technical ability to access or affect systems that contain or protect CUI.

The organization should evaluate administrative access carefully when defining the boundary.

This is one reason CMMC scope can extend beyond only the end users who directly work with CUI.

Are Security Tools In Scope?

They can be.

Security protection assets that provide security functions to the CMMC environment may be relevant even if they do not normally store CUI.

Examples may include:

• Identity and access management.
• Endpoint protection.
• Security monitoring.
• Vulnerability management.
• Logging systems.
• Network security.

The architecture and role of the security capability determine how it should be treated.

Are Systems That Never Touch CUI Automatically Out of Scope?

Not always.

A system can matter to the assessment because it provides security protection or supports the CUI environment even if CUI itself does not reside there.

Conversely, systems with no connection to CUI or the protection of the environment may be outside the assessment boundary.

Scoping should be based on function and dependency rather than only whether a CUI file is stored on the system.

What About Corporate Systems Shared With the CMMC Environment?

Shared systems require careful evaluation.

Examples may include:

• Identity infrastructure.
• Email.
• Networking.
• Endpoint management.
• Security monitoring.
• Backup systems.
• Ticketing systems.

A shared service can expand the effective CMMC boundary if the scoped environment depends on it.

This is one reason organizations sometimes consider creating a more isolated CUI environment.

Would a CMMC Enclave Reduce Our Scope?

It can.

An enclave may separate CUI work from the broader enterprise so fewer systems, users and services need to meet the CMMC requirements.

But the design has to work operationally.

The organization should consider:

• Who needs access to CUI.
• What applications they need.
• How information enters and leaves the enclave.
• How identity and administration work.
• How users collaborate.
• What security tools support the enclave.
• What external providers are required.

A badly designed enclave can create workarounds that undermine the intended scope reduction.

Should We Scope the Entire Microsoft 365 Tenant?

Not automatically.

The answer depends on how Microsoft 365 is configured and used, where CUI resides and how identities, email, collaboration and administration are structured.

If a shared enterprise service supports both CUI and non-CUI users, the organization should understand the effect of that architecture on the assessment boundary.

The technology choice does not determine scope by itself. The actual implementation and data flow do.

Does Using GCC High Automatically Solve CMMC Scope?

No.

GCC High may be part of an appropriate architecture for some organizations, but it does not automatically establish a correct CMMC boundary or satisfy all CMMC Level 2 requirements.

The organization still needs to understand:

• Where CUI exists.
• Who accesses it.
• What systems support it.
• What controls are implemented.
• How the environment is operated.
• What external services are involved.

Does Every CMMC Level 2 Organization Need GCC High?

No.

The right Microsoft environment depends on the organization's specific contractual obligations, export-control considerations, data types, architecture and security requirements.

CMMC scoping should not begin with the assumption that one cloud product is universally required.

What About Email Containing CUI?

If CUI is transmitted through email, the email environment becomes relevant to the CUI flow and assessment boundary.

Organizations should understand:

• Who can send and receive CUI.
• Where messages are stored.
• What security protections apply.
• What external recipients receive CUI.
• How administrators access the environment.

If the organization intends to keep email outside the CMMC boundary, its business process needs to prevent CUI from entering that environment.

What About Teams, SharePoint and Collaboration Platforms?

If those platforms store, process or transmit CUI, they become part of the CUI environment.

Organizations should understand how collaboration actually occurs rather than defining a paper scope that employees cannot realistically follow.

Usable workflows are critical because users will often find alternative methods if the approved environment does not support the work they need to perform.

What About CUI on Employee Laptops?

If CUI is stored or processed on an endpoint, that endpoint is relevant to the CMMC environment.

The organization should understand how endpoints are configured, managed, monitored and protected.

If the architecture is designed so CUI remains within a controlled virtual or cloud environment and is not stored locally, that may affect the endpoint's role in the scope, but the actual technical implementation needs to support that design.

Can We Use Virtual Desktops to Reduce CMMC Scope?

Potentially.

A virtual desktop or cloud-based workspace can help centralize the CUI environment and reduce local storage or processing.

But scope still depends on the complete architecture, including:

• Endpoint access.
• Identity.
• Administration.
• Network connectivity.
• Security monitoring.
• Data transfer controls.
• External service providers.

Virtualization is a scoping tool, not an automatic exemption.

What About Personal Devices?

If personal devices can access, store, process or transmit CUI, they can create significant scope and security concerns.

Organizations seeking a more constrained boundary often prevent CUI from being stored or processed on unmanaged personal devices.

The technical and policy controls should enforce the intended boundary rather than depending solely on employee behavior.

What About Printers and Printed CUI?

Physical CUI matters too.

If users print CUI, the organization needs to consider physical protection, storage, access, disposal and the systems involved in printing.

CMMC is not limited to cloud and endpoint technology.

What About Backups?

If backups contain CUI, they are part of the CUI lifecycle and need appropriate protection.

Organizations should understand:

• Where backups are stored.
• Who can access them.
• How they are protected.
• How long they are retained.
• How recovery works.

Backup architecture is easy to overlook during initial scoping.

What About Logs?

Logs may or may not contain CUI, but logging systems can still be relevant because they provide security functions to the environment.

The organization should understand what information flows into security monitoring tools and what role those tools play in satisfying CMMC requirements.

What About Our MSP?

An MSP can materially affect scope if it administers systems in the CMMC environment, has privileged access, hosts services or performs security-related functions.

Organizations should understand:

• What the MSP can access.
• What systems it manages.
• What credentials it holds.
• Where its administrators connect from.
• What tools it uses.
• What evidence it can provide.
• What contractual responsibilities exist.

Outsourcing administration does not make the function disappear from the CMMC architecture.

What About Our MSSP or SOC Provider?

Security providers can also be relevant because they may receive security data, administer security tools or perform security functions supporting the scoped environment.

The organization should understand exactly what service is being provided and how that service interacts with the CUI environment.

What About Cloud Service Providers?

Cloud services used to store, process or transmit CUI must be evaluated against the applicable DoD requirements for cloud environments.

The organization should not assume that a mainstream commercial cloud service is automatically appropriate for CUI simply because it has strong security.

Applicable FedRAMP, contractual and other requirements should be evaluated as part of architecture and scoping.

What About SaaS Applications?

If a SaaS application handles CUI or performs an important function within the scoped environment, it needs to be evaluated.

Organizations should inventory SaaS use carefully because CUI can move into applications through normal business workflows without anyone intentionally expanding the CMMC boundary.

What About Ticketing Systems?

Ticketing systems can become relevant if they contain CUI, sensitive system information or evidence supporting the CMMC environment.

For example, support staff may copy customer or contract information into tickets while troubleshooting.

The organization should understand actual usage rather than assuming a system is outside scope based only on its intended purpose.

What About HR Systems?

HR systems may support security requirements involving personnel processes and training, but their role in the assessment boundary depends on the architecture and information involved.

The organization should determine whether the HR platform itself participates in the CUI environment or simply provides supporting business records.

What About Physical Locations?

Locations where CUI is accessed, stored or discussed may be relevant to physical protection requirements.

This can include:

• Corporate offices.
• Manufacturing locations.
• Labs.
• Remote work locations.
• Secure rooms.

The organization should understand where CUI work actually occurs.

Can Employees Work Remotely With CUI?

Potentially, but remote work needs to be designed into the CMMC environment.

The organization should consider:

• Endpoint security.
• Network connections.
• Physical protection.
• Printing.
• Local storage.
• Household access.
• Approved collaboration methods.

Remote work should not operate as an informal exception to the defined CMMC boundary.

What About CUI Shared With Subcontractors?

If CUI is shared with subcontractors, the organization needs to understand the contractual flow-down and how those parties protect the information.

Subcontractors can become part of the broader CUI ecosystem even though they are separate organizations.

Third-party relationships should therefore be considered during scoping and contracting.

Can We Just Stop Handling CUI?

Sometimes changing the business process can materially reduce CMMC scope.

For example, an organization may be able to:

• Limit which employees receive CUI.
• Use a dedicated environment.
• Change how information is exchanged.
• Reduce local storage.
• Separate CUI and non-CUI workflows.

But the decision needs to reflect actual contractual and operational requirements.

You cannot remove something from scope simply by declaring that users are not supposed to put CUI there if normal business processes still cause them to do so.

How Do We Document CMMC Scope?

Organizations should maintain enough documentation to explain and support the assessment boundary.

That may include:

• CUI data-flow diagrams.
• Network diagrams.
• System inventories.
• Asset categorizations.
• User and role information.
• External service providers.
• System Security Plan information.
• Descriptions of how CUI enters, moves through and leaves the environment.

The documentation should match the actual architecture.

How Detailed Should Our CUI Data Flow Be?

Detailed enough that the organization and assessor can understand where CUI travels and what systems or services participate in that flow.

A useful data flow should make it easier to answer:

• Where does CUI enter?
• Who accesses it?
• Where does it reside?
• How is it transferred?
• Where is it backed up?
• How does it leave the environment?

If those answers are still unclear after reviewing the diagram, the scope probably needs more work.

Can We Change CMMC Scope Later?

Yes, environments change.

But material architecture changes should be evaluated for their effect on CMMC requirements, evidence and assessment status.

Adding new systems, vendors or workflows can expand the boundary.

Removing systems or changing data flows can sometimes reduce it.

Scope should be actively governed rather than documented once and forgotten.

What Are the Biggest CMMC Scoping Mistakes?

• Assuming the entire enterprise is automatically in scope.
• Assuming only systems containing CUI matter.
• Ignoring privileged administrators.
• Ignoring security protection assets.
• Ignoring external service providers.
• Ignoring backups.
• Ignoring collaboration and email workflows.
• Ignoring physical CUI.
• Designing a scope users cannot realistically follow.
• Documenting an intended data flow that does not match actual behavior.
• Buying technology before the scope is understood.

Should We Finalize Scope Before Performing a CMMC Gap Assessment?

You need a sufficiently defined scope before a meaningful gap assessment can occur.

Otherwise, the organization may assess systems that do not need to be included or overlook controls and assets that actually matter.

Scoping and assessment may refine each other, but scope should not be treated as an afterthought.

See where to start when you need CMMC Level 2.

Can Existing Security Controls Be Reused Once We Know the Scope?

Yes, where they meet the specific requirement within the scoped environment.

Existing controls should be evaluated against the CMMC requirements and assessment objectives rather than discarded simply because they were originally implemented for another purpose.

See how to reuse existing security controls for CMMC.

How Does Hotman Group Help With CMMC Scoping?

Hotman Group helps organizations understand CUI flows, identify relevant systems and users, evaluate external service providers, define assessment boundaries and design architectures that are both secure and operationally practical.

HG can also help organizations determine whether an enclave or other architectural approach makes sense, document the environment, assess the resulting scope and move directly into remediation and implementation.

The goal is not to shrink scope at any cost.

The goal is a defensible boundary that includes what needs to be protected without unnecessarily expanding CMMC across parts of the organization that do not need to participate.

Where Should We Start If Our CMMC Scope Is Unclear?

Start with the information.

Identify the CUI, trace how it moves through the organization and then determine what people, systems and services participate in or protect those flows.

If the broader CMMC implementation is still unclear, see where to start with CMMC Level 2.

About Hotman Group

Hotman Group is a cybersecurity and Cyber GRC professional services firm that helps organizations solve complex cybersecurity, risk, governance and compliance problems. Hotman Group designs, builds, implements, remediates, operates and matures cybersecurity and GRC programs.

Learn more about Hotman Group's approach to solving complex cybersecurity and Cyber GRC problems.