CMMC scoping and enclaves: what defines Level 2 scope

How do you define CMMC scoping and enclaves before an assessment?

Under 32 CFR 170.19(a), the CMMC assessment scope must be specified before any self-assessment or certification assessment begins. Scope is the set of assets that will be assessed against CMMC requirements, so every system, device and service in that set needs a documented role before anyone scores a single practice. If a prime contract requires CMMC and nobody has drawn that boundary yet, the first task is to decide what goes inside it. For Level 1, the scope is the systems that process, store or transmit Federal contract information (FCI). Specialized assets such as IoT, operational technology, government furnished equipment, restricted information systems and test equipment fall outside Level 1 assessment, and out-of-scope assets need no documentation. Level 2 is more involved, because its scope is built from five asset categories: CUI assets, security protection assets, contractor risk managed assets, specialized assets and out-of-scope assets. Each category carries different documentation and assessment effort, and the size and complexity of the network in scope is one of the main drivers of assessment cost. Confirm the category of each asset against the current scoping guidance before you price or plan the work. The organization owns the scope decision and must be able to justify it, including why any out-of-scope asset cannot handle CUI. An implementation partner can prepare the network, the asset inventory, the system security plan and, where it makes sense, a VDI or enclave design that narrows the boundary. Only the independent assessor or certifying body judges whether that scope is correct and whether the evidence supports it. Ask any partner to put the scope boundary, deliverables and handoff points in writing before work starts.

Which of the five Level 2 asset categories does each system fall into?

Under 32 CFR 170.19(c), every system in a CMMC assessment scope takes one of five Level 2 categories, and the category sets how many requirements the assessor tests and how much documentation you produce. Work through the categories from the most demanding to the least, and record the reasoning for each asset before you draw the scope boundary.

CUI assets

CUI assets store, process or transmit Controlled Unclassified Information, so they carry the full load of the assessment. Under table 3 of 32 CFR 170.19(c), each one is assessed against all 110 Level 2 requirements. Expect the largest share of evidence, configuration review and sampling effort here. Check every system that touches CUI, including email, file shares, backups and collaboration tools, because a missed CUI asset is the most common reason a scope is wrong.

Security protection assets

Security protection assets do not hold CUI but provide security functions to the scope, such as firewalls, identity providers, log collectors, endpoint protection and configuration management servers. Table 3 of 32 CFR 170.19(c) assesses them only against the requirements relevant to the capabilities they provide. Your effort depends on how many security functions each asset supplies. Document each one in the asset inventory, the system security plan and the network diagram, because an undocumented security device can undermine the controls it is meant to enforce.

Contractor risk managed assets

Contractor risk managed assets can process CUI, but policy and practice keep them from doing so. They do not have to be physically or logically separated from CUI assets, and the system security plan reviews them. An assessor may run limited checks, but those checks must not materially increase assessment time or cost. Reducing the number of assets that fall here is usually cheaper than proving they are controlled, so confirm the policy, the technical controls and the staff practice that support the classification before you rely on it.

Specialized assets

Specialized assets include Internet of Things devices, operational technology, government furnished equipment, restricted information systems and test equipment. The assessment treats them differently from general IT, so they need their own entries in the scope analysis rather than being left to the default. Confirm with your assessor and the CMMC Scoping Guides how each device type is handled, and document the reasoning for each. Specialized assets often carry the highest documentation burden per device because they may not support the controls you apply elsewhere.

Out-of-scope assets

Out-of-scope assets cannot process, store or transmit CUI and provide no security protection to CUI assets, or they are physically or logically separated from CUI assets. They need no CMMC documentation, but you must be ready to justify why each one cannot handle CUI. A thin-client endpoint that only passes keyboard, video and mouse traffic to a virtual desktop is a common example of this category. Keep the separation evidence current, because a single shared network path can move an asset back into scope.

How network size changes effort

The 2024 final rule says the size and complexity of the network within the assessment scope affects assessment cost. A flat network with many CUI assets costs more to assess than a segmented enclave with a small set of in-scope systems. Before you assign categories, count the systems, users and connections that would fall into each one. Ask any consultant or assessor to quote effort against the written scope, and ask how each category changes the hours.

Which scope approach fits your environment?

This table compares four ways to bound a CMMC Level 2 assessment: enterprise-wide scope, a dedicated CUI enclave, a VDI model with a thin client, and a separate environment for specialized assets. Read each row against your own network to see what an assessor would examine and where the documentation burden falls. Confirm the chosen design against the DoW CIO scoping guidance with your assessor before you commit to it.

Scope model	What gets assessed	What you must document	Main effort driver	When it fits
Enterprise-wide scope	Every system that processes, stores or transmits CUI, plus the security protection and contractor risk managed assets that touch it, usually across the whole corporate network	Asset inventory, network diagram and SSP treatment for each in-scope category, including identity, logging and endpoint tools	Number of users, endpoints and network segments that handle CUI	Small organizations whose CUI already sits in a few systems, or firms with no practical way to separate CUI from other work
Dedicated CUI enclave	Only the enclave boundary, its CUI assets and the security protection assets that serve it, provided other systems are separated from CUI	Boundary definition, justification for each out-of-scope system, the enclave's own diagram and inventory, and evidence of separation controls	Cost of building and isolating the enclave, plus the boundary controls that keep out-of-scope systems from reaching it	Organizations that can route CUI workflows into one controlled environment and keep engineering or sales tools outside it
VDI with thin clients	The virtual desktop environment hosting CUI. Endpoints running a VDI client that passes only keyboard, video and mouse traffic are out of scope at Levels 1, 2 and 3 under 32 CFR 170.19	Virtual desktop infrastructure, hypervisor and broker configuration, client restrictions proving no other data leaves the endpoint, and the scope boundary	Hardening and monitoring of the virtual desktop platform, and proof that clients cannot redirect files, clipboard, printers or drives	Teams that already run VDI or can deploy it, where many users need CUI access from ordinary devices
Separate environment for specialized assets	Specialized assets such as IoT, OT, government furnished equipment or test equipment, assessed only as the rules for their category require, and kept apart from the CUI boundary	Asset records, the reason each asset is specialized, its isolation from CUI systems, and any residual Level 2 treatment in the SSP	Number of specialized devices and how cleanly they can be separated from CUI networks	Manufacturers, labs and facilities with production or test equipment that cannot run standard Level 2 controls

How scope differs at Level 1, Level 2 and Level 3

At Level 1, the scope is the set of systems that process, store or transmit Federal contract information (FCI). Under 32 CFR 170.19(b), specialized assets are excluded from the Level 1 assessment, and out-of-scope assets need no documentation. The boundary is usually much smaller than at Level 2, but the contractor still has to define it precisely before a self-assessment begins, as described in the eCFR text of 32 CFR 170.19.

FCI systems: Email, file shares, accounting and collaboration tools that hold contract information are in scope. The key question is whether a system touches FCI at all, because the answer sets the boundary.
Specialized assets: Internet of Things devices, operational technology, government furnished equipment, restricted information systems and test equipment are excluded from the Level 1 assessment.
Out-of-scope assets: Systems that never handle FCI need no documentation at Level 1, but the contractor should be able to explain why each one sits outside the boundary.
Shared infrastructure: An identity provider or directory service that supports FCI systems may be in scope even if it holds no FCI itself. Confirm this dependency with the scoping guidance before you finalize the list.

Before scoring, write down the in-scope list and record a reason for each excluded asset, because the scope must be fixed before the self-assessment starts.

How to build an assessment scope step by step

This sequence turns a general sense of where CUI lives into a documented CMMC assessment scope that an assessor can test, with one named output for each step in the assessment file.

Inventory every system that touches FCI or CUI
Start with a complete list of systems, applications, cloud tenants, endpoints, mobile devices, and network devices that process, store, or transmit federal contract information or CUI. Include data flows that move between systems, such as email, file shares, collaboration tools, and backups, because those paths often carry CUI without anyone naming them. Involve the people who own each system and the contract owners who know which data the company receives. The step is done when every candidate asset has an entry with an owner and a stated data type. The output is the initial asset inventory.
Classify each asset into a 32 CFR 170.19(c) category
Assign each inventoried asset to one of the five Level 2 asset categories: CUI assets, security protection assets, contractor risk managed assets, specialized assets, or out-of-scope assets. Work from the rule's definitions rather than from how IT labels systems internally. Mark any asset that provides security functions to the scope, such as directory services, logging collectors, or firewalls, because it can bring requirements into scope even if it never touches CUI. The step is done when each asset carries exactly one category and a short written reason. The output is the classified asset inventory, which the assessor will compare against the network diagram.
Draw the network diagram of the assessment scope
Draw the boundary of the assessed environment, showing the CUI assets, security protection assets, contractor risk managed assets, and the connections between them and to any out-of-scope networks. Show where VDI endpoints, enclaves, and segmentation controls sit, since these determine whether the boundary holds. Keep the diagram consistent with the inventory, so every in-scope asset appears and every boundary crossing has a control behind it. Check the diagram against the data flows you recorded in step one. The step is done when a person outside the project can trace how CUI enters, moves within, and leaves the scope. The output is the scope network diagram.
Document each in-scope category in the system security plan
Write the treatment of each in-scope category into the system security plan: what each category is, how it is protected, which requirements apply to it, and how contractor risk managed assets are kept from processing CUI by policy and practice. For security protection assets, state which capabilities they provide to the scope. Make sure the SSP describes the same boundary as the diagram and the inventory. The step is done when an assessor could read the SSP alone and understand the scope. The output is the system security plan section covering scope and asset treatment.
Justify each out-of-scope asset in writing
For each asset you exclude, record the reason it cannot process, store, or transmit CUI, and confirm that it gives no security protection to CUI assets or is physically or logically separated from them. Be ready to explain the separation with evidence such as network rules, device policies, or account restrictions. Assets that cannot meet this test belong in scope, not out. A VDI client that allows only keyboard, video, and mouse traffic to the virtual desktop is treated differently under the rule, so document that configuration precisely. The step is done when every excluded asset has a written justification that a reviewer can verify. The output is the out-of-scope justification record.
Identify external service providers that handle CUI or security data
Review every external provider that hosts, manages, or supports in-scope systems, and ask whether it handles CUI or security protection data such as logs and configuration data. A provider that handles either brings its services into the assessment scope under 32 CFR 170.19(c)(2). A provider that handles neither is not an external service provider under CMMC. Record each provider, the data it touches, and whether it is in scope. Confirm with each provider how it treats CUI, because contract language alone may not answer the question. The step is done when every provider has a documented classification. The output is the external service provider register, which feeds the responsibility matrices covered in later preparation work.
Check the scope against the DoW CIO scoping guides
Before you finalize the scope, compare your inventory, diagram, and classifications against the CMMC Scoping Guides for Levels 1, 2, and 3 published by the DoW CIO, which 32 CFR 170.19 names as additional scoping guidance. Look for asset types or environments your scope does not address, and resolve each gap in writing. Confirm that the guides you use are the current versions on the DoW CIO site, since guidance can change while the program is in transition. The step is done when you can show a reviewer where each guide point was considered and how it was handled. The output is a scoping review record that accompanies the assessment file.
Confirm the scope before any assessment
Under 32 CFR 170.19(a), the assessment scope must be specified before any self-assessment or certification assessment begins. Bring together the inventory, classification record, diagram, SSP scope section, out-of-scope justifications, ESP register, and guide review, and confirm that they describe the same environment. Obtain sign-off from the executive or affirming official responsible for the scope, and set a process for updating the scope when systems change. Ask any independent assessor or consultant to review the package before it is final, and record any changes. The step is done when a signed scope baseline exists and changes to it are controlled. The output is the approved scope baseline, the anchor document for the assessment file.

Can VDI and an enclave shrink CMMC scope without shrinking the controls?

A VDI client that passes only keyboard, video and mouse traffic can sit outside CMMC scope at Levels 1, 2 and 3, but the virtual desktop and the infrastructure behind it stay in scope. Under 32 CFR 170.19, the endpoint does not carry the CUI requirements, so a thin client or repurposed laptop does not need its own full Level 2 treatment. The hypervisor, the virtual desktop images, the broker, the storage and the identity systems that serve those desktops still process or protect CUI, so they must be assessed against the requirements that apply to their capabilities. The organization should confirm, with its own architecture in hand, that the client truly allows nothing beyond display and input, since file redirection, clipboard sharing, USB passthrough or printer mapping would move the endpoint back into scope.

An enclave shrinks the assessed population only when CUI stays out of other systems through separation or through policy and practice. Contractor risk managed assets can handle CUI but are kept from doing so, and they do not have to be physically or logically separated from CUI assets. They still need to be recorded in the asset inventory, explained in the system security plan and drawn on the network diagram, and an assessor may run limited checks on them as long as those checks do not materially increase assessment time or cost. Access policy, data handling rules, segmentation and the enforcement points that keep CUI inside the boundary are decisions the organization owns and must be able to defend. An implementation partner can help design the segmentation, document the SSP narrative and prepare evidence that the controls operate, but the partner does not decide what the boundary is.

The assessor decides where the boundary sits, so the organization should test its scope claims before the assessment rather than assume them. Ask the assessor, or the C3PAO during readiness planning, how it will verify each out-of-scope claim and what it expects to see for each risk managed asset. Confirm that every enclave, VDI pool and shared service is listed in the scope statement required before any self-assessment or certification assessment, and that the network diagram matches the actual flows. Any Level 3 data enclave must equal or sit inside the Level 2 scope, so a smaller Level 2 boundary also limits what a future Level 3 program can claim. Smaller scope generally lowers assessment effort, but the controls that protect CUI still apply in full wherever the CUI actually resides.

What documentation must every in-scope asset have?

Under 32 CFR 170.19(c), every in-scope Level 2 asset category must appear in three places: the asset inventory, the system security plan and the network diagram of the assessment scope. Assessors trace an asset across all three, so a gap in one usually shows up as a finding in the others.

Asset inventory record

Every CUI asset, security protection asset, contractor risk managed asset and specialized asset in scope needs its own inventory entry. Check that each entry names the asset, its owner, its location, its category and the function it performs. Assessors compare the inventory against the network diagram and the system security plan, so names must match exactly. The most common gap is a missing entry for security tooling such as log collectors, identity servers or backup systems, which provide security protection to CUI assets and so belong in scope.

System security plan treatment

The system security plan must state how each in-scope asset category is treated and how it meets the requirements that apply to it. A CUI asset is assessed against all 110 Level 2 requirements, while a contractor risk managed asset is documented through the plan and reviewed by policy and practice. Check that the plan describes each asset category, not only the main servers. Drafts do not count as final evidence, so the plan must be approved, dated and current before the assessor starts.

Network diagram placement

Each in-scope asset category must appear in the network diagram of the assessment scope, with its boundary and data flows visible. Show where CUI enters and leaves, which assets sit inside the boundary, and where external service providers connect. Confirm that the diagram matches the inventory and the system security plan line by line. Diagrams that show a flat network with no enclave boundary, or that omit cloud tenants and remote access paths, are a frequent source of scope disputes.

Out-of-scope justifications

Assets left out of scope need no documentation under the rule, but the contractor must be ready to explain why each one cannot process, store or transmit CUI and gives no security protection to CUI assets. Write one short justification per excluded asset or group, and tie it to a physical or logical separation you can demonstrate. Assessors often test these claims by checking whether an excluded device shares a directory, a management plane or a backup target with in-scope systems.

ESP responsibility matrices

Any external service provider that handles CUI or security protection data brings its services into scope, so the contractor needs a responsibility matrix showing which party implements each requirement. Ask each provider for its own documentation, then record which controls it covers and which remain with your organization. Missing matrices are common with managed service providers and cloud tenants, where administrators assume the provider owns logging or patching that the contract never assigns.

Final evidence and version control

Every artifact above must be final, approved and dated before the assessment, with a version history that shows what changed and when. Keep the inventory, system security plan and network diagram under one change process so a server added in one place appears in all three. Before assessment, confirm that the documents reflect the environment as it is today, because an assessor who finds a diagram older than the last infrastructure change will question the rest of the package.

Why a Level 3 scope cannot be wider than its Level 2 enclave

A Level 3 assessment scope must equal or sit inside the Level 2 scope. Under 32 CFR 170.19(e), the rule's example is a Level 3 data enclave located inside a Level 2 enclave. The practical consequence is that Level 3 cannot be used to pull in systems, users or networks that were never assessed at Level 2. An organization that expects to need Level 3 someday should design its Level 2 enclave with that nesting in mind from the start, because a Level 2 boundary drawn too narrowly leaves the Level 3 data enclave with nowhere to sit, and a boundary drawn too broadly carries every asset in it into the more demanding assessment.

Design decisions made now carry forward. Confirm with your assessor and your contracting officer which assets would hold the Level 3 data, and check whether those assets can be isolated inside the Level 2 enclave with clear network boundaries, a current asset inventory and a network diagram that shows the nesting. Every in-scope Level 2 asset still needs its treatment documented in the system security plan, and the Level 3 assessment builds on that same documentation rather than replacing it. Ask whether the Level 2 scope document is written so that a later Level 3 subset can be traced back to it without reconstructing the boundary.

Level 3 is assessed by DCMA DIBCAC under 32 CFR 170.18, not by a C3PAO, so the assessment relationship and timing differ from Level 2. Keep the scoping decisions in this section focused on design: a clean nested boundary, controlled data flows between the two enclaves and documentation that supports both assessments. The Level 3 guide covers the NIST SP 800-172 requirements, the assessment process and how a program decides to require Level 3.

What usually inflates scope and how to avoid it

Most oversized CMMC assessments trace back to a few avoidable decisions made early: drawing boundaries around org charts instead of data, leaving CUI copies outside the boundary, and claiming assets are out of scope without proof. Each card below names one common problem, the fix, and the team that should own it.

Scoping by department

Teams often draw the boundary around a department or business unit instead of following where CUI actually moves. Build a data flow diagram from intake of the contract data through engineering, storage, sharing and disposal, then scope every asset on that path. Engineering or program leads should own the data flow, and the security lead should validate it against the network diagram before the assessment scope is locked.

CUI in email, shares and backups

CUI frequently sits in mailboxes, file shares, collaboration sites and backup sets that were never listed as in scope. Each location that stores or transmits CUI is a CUI asset and must appear in the asset inventory, the system security plan and the network diagram. Run a targeted search of mail, shares and backup catalogs for controlled markings, and assign IT operations to own the remediation or the inclusion decision.

Undocumented out-of-scope claims

Declaring an asset out of scope is only defensible if the contractor can show it cannot process, store or transmit CUI and gives no security protection to CUI assets, or is separated from them. Without a written rationale, assessors will treat the claim as unsupported and expand the scope. For each excluded asset, record the separation mechanism and the reason in the system security plan, and have the compliance lead sign off before the assessment.

Shared admin accounts left out

Domain controllers, identity providers, privileged access tools and shared administrator accounts often sit outside the boundary because they belong to infrastructure teams. These systems usually provide security protection to CUI assets, which brings them into scope against the requirements their capabilities provide. Identity and infrastructure owners should inventory every system that authenticates users or administers the enclave, and document how each one is treated.

Unlisted external service providers

Logging platforms, backup services, remote monitoring tools and configuration management services often receive security protection data such as logs and configuration data, even when they never see CUI itself. Under the scoping rule, a provider that handles either CUI or security protection data is an external service provider whose services come into scope. Procurement and the security lead should list every provider that receives such data and request a responsibility matrix from each.

Questions buyers ask about CMMC scope

Does CMMC scope have to be defined before a self-assessment?

Yes. Under 32 CFR 170.19(a), the assessment scope, meaning the set of assets assessed against CMMC requirements, must be specified before any self-assessment or certification assessment starts. Scope is the foundation for everything that follows: which assets need documentation, which requirements apply to each one, and what the system security plan and network diagram must show. Changing scope later means reworking the evidence you have already collected, so the decision is best made early and written down with its reasoning.

Can our organization define its own CMMC scope?

Yes, you define your own scope, but the assessor makes the final call. You must describe the systems that process, store or transmit CUI, the assets that protect them, and the assets you exclude. Every exclusion needs a justification you can defend, such as physical or logical separation from CUI assets or a documented policy and practice that keeps a system from handling CUI. Expect an assessor to test those claims against your network, so treat the scoping decision as a position you must prove, not a preference.

How does scope affect the cost of a CMMC assessment?

Scope is the largest driver of assessment effort you control. The 2024 CMMC final rule states that the size and complexity of the network in assessment scope affects assessment costs, so every additional system, segment or cloud tenant placed in scope adds documentation, evidence and assessor time. Costs fall into two groups: the internal effort to document and evidence each in-scope asset, and the external assessment fees paid to a certifying body. Ask any quote to show the asset count, network segments and external service providers it assumes, so you can compare scenarios that shrink the boundary.

Does a VDI setup take endpoints out of CMMC scope?

Under 32 CFR 170.19, an endpoint running a VDI client that allows nothing beyond keyboard, video and mouse traffic to the virtual desktop is treated as out of scope at Levels 1, 2 and 3. The virtual desktop environment itself remains in scope if it processes or stores CUI, so the boundary moves rather than disappears. Confirm that the client restricts traffic to keyboard, video and mouse only, that file transfer and clipboard redirection are blocked where required, and that the VDI back end is documented as an in-scope asset with its own controls.

What does an implementation partner do for CMMC scope, and what does it not do?

An implementation partner prepares the systems, documentation and evidence that support your scope. For example, it can build the asset inventory, draft the network diagram and data flow maps, configure enclave boundaries, and set up logging so the evidence exists when an assessor asks for it. It does not issue assessment results, certifications or attestations. Under CMMC, only an independent certifying body or the organization itself, through a self-assessment, produces the official result. Ask any partner to put the division of responsibilities in the written scope before work begins.

Can our internal team define CMMC scope without outside help?

Yes, many organizations scope their own environment, particularly when their network is small and their CUI flows are well understood. The work requires a current asset inventory, a network diagram that shows where CUI enters, is stored and leaves, and a clear view of every external service that touches CUI or security data. Internal teams often underestimate hidden flows such as email, backups, administrator jump hosts and managed service accounts. An outside reviewer can test your boundary before an assessor does, which is useful even when your own team does the writing.

What must our organization supply before scoping starts?

Start with an asset inventory that lists every system, device, cloud tenant and service account, along with its owner and location. Add a network diagram showing boundaries, segments, remote access paths and connections to external service providers. Then build data flow maps that trace how FCI and CUI enter, move through, are stored in and leave your environment. Finally, collect the list of external service providers and their responsibilities. Under 32 CFR 170.19(c), each in-scope asset category must appear in the inventory and network diagram, so these three documents are the first deliverables any scoping effort needs.

Can a Level 3 scope be larger than the Level 2 scope?

No. Under 32 CFR 170.19(e), a Level 3 data enclave inside a Level 2 enclave is the example given of a Level 3 scope that must equal or be a subset of the Level 2 scope. A Level 3 assessment therefore builds on a Level 2 boundary that is already defined and evidenced, rather than replacing it. Organizations planning for Level 3 should design the Level 2 enclave with a tighter inner boundary in mind, because the Level 3 scope inherits every decision made at Level 2. Confirm the current requirement with the DoW CIO scoping guidance before relying on this structure.

How DeployOpen scopes and documents a CMMC environment

DeployOpen works on the self-hosted open-source platforms inside your own cloud accounts, data centers or networks, and prepares the systems, documentation and evidence that define a CMMC assessment scope. The organization owns its scope decisions and controls, and only an independent assessor can issue a CMMC result.

How we scope

We map which systems process, store or transmit CUI or FCI before any build work starts.
Our written scope lists each in-scope asset by Level 2 category, with the reason for each treatment.
We document where VDI endpoints, enclaves and out-of-scope assets sit relative to CUI assets for your assessor.

How we build

We deploy the open-source platforms in your environment and separate the CUI enclave from general IT where the scope requires it.
We configure security protection assets such as logging, identity and boundary controls to the capabilities they provide to the scope.
We test each in-scope boundary against the scope decisions and record gaps before they reach an assessment.

How we hand over

You receive an asset inventory, system security plan sections and a network diagram that match the defined assessment scope.
Documentation covers each in-scope asset category, including how contractor risk managed assets are kept from processing CUI.
We train your staff to keep the inventory, diagrams and evidence current after the engagement closes.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer if your scope changes after the initial work.
Changes to enclaves, cloud services or external service providers can be reviewed against the written scope on request.