CMMC Scoping: Step 0 on the Critical Path to Asset Identification and Assessment Success

Before a single requirement is assessed, before policies are reviewed or controls are tested, there’s one step that lays the groundwork for everything else: scoping. According to the CMMC Assessment Process (CAP) v2.0 (December 2024), “The CMMC Assessment Scope is the set of all assets in the OSC’s environment that will be assessed against CMMC security requirements. It must be specified prior to the commencement of the Assessment.” This requirement is codified in 32 CFR §170.19(c), which governs CMMC Level 2 scoping.

Whether you're pursuing Level 1, Level 2, or Level 3 certification—or any evidence-based security assessment—accurate scoping is your foundation. If you don’t know what’s in scope, you don’t know what to protect or how to demonstrate that protection to your leadership or to a CMMC Assessment Team.

CMMC Scoping Starts with the Contract

Scoping begins with understanding how Controlled Unclassified Information (CUI) enters the organization. This typically starts with the contract management team, who handle communications from the DoD or a prime contractor. Ask them:

• What type of CUI is being received?

• How is it being transmitted or accessed?

• What systems are involved in managing it?

This gives you the initial data to begin mapping CUI flow through the organization.

Build an Entity/Activity Matrix (EAM)

To “follow the information,” we recommend starting with an Entity/Activity Matrix (EAM)—a proven method adapted from other quality and security frameworks. A basic EAM includes four columns, typically in a spreadsheet:

• Entity – The person, process, or system authorized to access the information. It begins and ends with an external entity (e.g., the DoD, a prime contractor, or another internal business unit).

• Activity – What is being done with the CUI (e.g., received via email, reviewed, updated, printed, stored, or transmitted).

• System – As defined in 32 CFR § 170.4, this refers to a discrete set of resources used to process and manage information. An Information System (IS) is a type of asset.

• Asset – Any tangible or intangible item of value to stakeholders. This includes hardware, data, software, personnel, and capabilities—as defined in NIST SP 800-160 Rev. 1.

Map the Flow of CUI Across the Organization

Once you have the entry point, trace the flow of CUI throughout the business process—from contract receipt to final deliverable handoff. Identify every system and process it touches. Meet with operational and manufacturing leads, IT stakeholders, and information security personnel to ensure all:

• CUI Assets (that process, store, or transmit CUI)

• Security Protection Assets (that enforce security boundaries)

• Contractor Risk Managed Assets (non-segmented IT assets that are capable of handling CUI but aren't intended by the organization to do so.

• Specialized Assets (e.g. manufacturing and test equipment)

are properly cataloged and assigned to the correct CMMC asset categories.

Confirm Scope and Prepare for Assessment

By now, your organization should have:

1. A well-documented EAM and/or Data Flow Diagram (DFD)

2. A defined list of all assets in scope

3. Mapped roles and responsibilities

4. A working understanding of the CUI lifecycle in your environment

This becomes the foundation for implementing or verifying applicable CMMC practices and gathering assessment-ready evidence.

The System Security Plan: Documenting Scope and Protections

With this newfound information, an OSC can create (or update) the System Security Plan (SSP).

In the context of CMMC, the confidentiality impact level for Controlled Unclassified Information (CUI) has already been predetermined as Moderate, eliminating the need for Organizations Seeking Certification (OSCs) to perform a separate FIPS 199 impact analysis. Instead, the focus shifts to defining appropriate system boundaries and identifying where CUI is processed, stored, or transmitted. This boundary determination is critical, as it forms the foundation for applying the applicable NIST SP 800-171 controls and documenting them in the System Security Plan (SSP). Agencies or OSCs have flexibility in defining what constitutes an information system—whether as a general support system or major application—so long as the grouping supports effective management, security control implementation, and risk accountability.

When defining system boundaries, OSCs should consider whether the components are under the same management authority, serve a common function or mission, and operate in similar environments. Subsystems within a boundary may vary in function but are typically governed under a single SSP. Major applications are defined by their distinct mission-related roles and specific security requirements, even if they reside on general support systems. Minor applications, on the other hand, often inherit the majority of their security controls from the parent system and are typically documented as appendices to that system’s SSP. The responsibility for defining boundaries and ensuring appropriate control coverage should involve close collaboration among system owners, authorizing officials, and security staff to support a risk-informed and resource-efficient approach to cybersecurity compliance.

In the CMMC context, the selection of security controls has already been determined through the requirements in NIST SP 800-171, which are derived from FIPS 200 minimum security controls and the NIST SP 800-53 moderate confidentiality baseline. Therefore, OSCs are not expected to perform their own control selection or tailoring. Instead, their primary responsibility is to develop a comprehensive System Security Plan (SSP) that accurately documents how each of the 110 NIST SP 800-171 requirements is implemented within the defined system boundary.

While FIPS 200 and NIST SP 800-53 allow for tailoring activities—such as scoping, compensating controls, and agency-defined parameters—this flexibility is largely outside the scope of CMMC Level 2, where control requirements are fixed. However, the SSP must still reflect any relevant implementation nuances, such as shared or inherited controls (e.g., from cloud providers), and should clearly describe how each requirement is met within the organization’s unique operational and technical environment. If elements like scoping guidance or compensating measures are applicable due to specific architectural or contractual conditions, they must be clearly documented and approved. Ultimately, the SSP serves as the authoritative source for assessors to evaluate how the organization has implemented the required protections for CUI.

Closing Thought

Scoping isn’t just a checkbox—it’s your blueprint for success. When done right, it aligns technical controls with business reality, avoids costly surprises, and builds the confidence needed to face any CMMC assessment.

If you’re not sure where to begin, start by following the information—and let scoping guide the way.