Scoping is the most consequential decision in your CMMC compliance program. Define your CUI boundary too broadly and you spend months and tens of thousands of dollars securing systems that don't need it. Define it too narrowly and a C3PAO assessor finds systems that touch CUI but aren't documented, which is an immediate finding that can delay or fail your assessment.
Getting CUI scoping right is not a paperwork exercise. It is a rigorous, systematic analysis of how information moves through your organization: who handles it, what systems it touches, where it lives, and where it goes. This guide covers everything you need to produce a defensible, accurate CUI scope: the five asset categories defined in the official CMMC Scoping Guide, how to construct a CUI data flow diagram, how network segmentation changes your scope, how to handle external service providers and cloud services, and the common scoping mistakes that generate C3PAO findings.
Why CUI Scoping Is the Foundation of Your Entire CMMC Program
Every CMMC compliance obligation — every control you implement, every policy you write, every piece of evidence you collect — derives from your scope. The scope defines what is being protected. The 110 NIST SP 800-171 requirements apply to the systems within your CUI boundary. If a system isn't in your scope, you don't need to apply the requirements to it. If it is in scope and you didn't apply the requirements, that's a finding.
This is why the CMMC Scoping Guide, published by the DoD and referenced in 32 CFR § 170.19, is one of the first documents a C3PAO assessor reviews. They want to understand your boundary before they look at anything else. A well-defined, accurately documented scope tells an assessor that you understand your environment and have made deliberate decisions about what is in and out. A vague or inconsistent scope signals the opposite, and assessors probe harder when the scope isn't credible.
| Scoping Decision | Impact on Compliance Program | Impact on Assessment Cost |
|---|---|---|
| Under-scoped — missing systems that touch CUI | Gaps found by assessor; findings issued; potential assessment failure | Remediation costs after assessment; possible re-assessment fee |
| Over-scoped — including systems that don't touch CUI | More controls to implement, more documentation, more evidence to collect | Higher C3PAO fees; longer assessment duration; unnecessary compliance work |
| Correctly scoped — tight, accurate, well-documented boundary | Controls applied where needed; documentation is specific and credible | Lowest possible assessment cost; fastest assessment timeline |
What Counts as CUI — Getting the Foundation Right
Before you can scope your systems, you need to know what you're scoping around. Controlled Unclassified Information is information the government has designated as requiring safeguarding or dissemination controls under law, regulation, or government-wide policy, but that does not meet the classification standards for Confidential, Secret, or Top Secret designation.
You do not decide what is CUI. The government does. The DoD CUI Registry at the National Archives defines every authorized CUI category, the laws or regulations establishing each one, and any specific handling restrictions. For defense contractors, the practical question is answered by your contract: if DFARS clause 252.204-7012 is present, CUI is involved. Your contracting officer is required to identify the CUI categories in your contract. If they haven't, ask directly.
CUI Categories Defense Contractors Most Commonly Encounter
| CUI Category | What It Includes | Where It Typically Appears |
|---|---|---|
| Controlled Technical Information (CTI) | Technical specs, engineering drawings, design documentation for defense systems and components | Technical data packages, CAD files, engineering workstations, shared drives, FTP transfers |
| Export Controlled (ITAR/EAR) | Technical data subject to International Traffic in Arms Regulations or Export Administration Regulations | Design data, manufacturing processes, operational parameters for controlled items |
| Contract Performance Data | Sensitive contract execution data — cost, schedule, technical approach, subcontractor relationships | Contractor reports, program reviews, financial submissions, email attachments |
| Procurement and Acquisition | Pre-decisional acquisition data, source selection information, pricing | Proposal files, pricing models, RFP-related documentation |
| Privacy (PII) | Personally Identifiable Information about DoD personnel, contractors, or beneficiaries | Personnel records, security clearance data, health information related to DoD programs |
One important nuance for subcontractors: if your prime sends you a technical data package to execute your scope, that data is CUI if the prime's contract with the DoD treats it as such. You inherit the obligation even if your direct contract with the prime does not spell it out explicitly. If you are unsure, ask your prime what CUI categories apply to the data they share with you.
The Five CMMC Asset Categories — The Framework for Your Scope
The CMMC Scoping Guide defines five distinct categories for every asset in your environment. Correctly categorizing each asset is the core of your scoping exercise. Each category carries different assessment obligations, different documentation requirements, and different implications for the number of controls you must implement. Getting categorization wrong is one of the most common sources of assessment findings.
Category 1 — CUI Assets
CUI Assets are systems that directly store, process, or transmit CUI. This is the core of your scope. Every CUI Asset must implement all 110 NIST SP 800-171 requirements and is assessed against the full set of 320 assessment objectives during your C3PAO assessment. There are no exceptions or partial implementations for CUI Assets.
"Process" means any interaction with CUI: accessing, entering, editing, generating, manipulating, displaying, or printing it. A workstation where an engineer opens a technical drawing is a CUI Asset. A file server that stores the drawing is a CUI Asset. The email server that transmitted the drawing is a CUI Asset. If a system can touch CUI, it is a CUI Asset until you implement controls that prevent it from doing so.
Category 2 — Security Protection Assets (SPAs)
Security Protection Assets are tools and systems that provide security functions for CUI Assets — but may not themselves store, process, or transmit CUI. Firewalls, SIEMs, intrusion detection systems, identity providers, MDM platforms, and vulnerability scanners are all SPAs. They protect the CUI environment and often handle Security Protection Data (SPD) — configuration files, log data, credentials, and other security-relevant information that must itself be protected.
SPAs are within your CMMC assessment scope and are assessed against the NIST SP 800-171 requirements relevant to the capabilities they provide — not necessarily all 110. Critically, SPD is treated with the same sensitivity as CUI: if your SIEM logs contain authentication events, access records, or configuration data, that data must be protected with controls appropriate to its sensitivity. This is why cloud-based SIEMs require the same FedRAMP scrutiny as cloud services handling CUI directly.
Category 3 — Contractor Risk Managed Assets (CRMAs)
Contractor Risk Managed Assets are assets that are on the same network as CUI systems, or otherwise connected to the CUI environment, but are not used for CUI tasks. An employee laptop on the corporate network that is never used to access CUI is a potential CRMA. The key word is "risk-based": CRMAs are managed through documented risk-based policies rather than full NIST SP 800-171 implementation.
CRMAs are within your assessment scope and must be documented in your SSP. However, they are not assessed against all CMMC requirements. The risk is classification error: if a CRMA is actually used to access CUI — even occasionally, even by one user — it becomes a CUI Asset. C3PAO assessors will look for evidence that CRMAs are genuinely isolated from CUI access. If your documentation says a system is a CRMA but your access logs show it connecting to CUI repositories, that is a finding.
Category 4 — Specialized Assets
Specialized Assets are non-standard devices that cannot fully implement NIST SP 800-171 controls due to their design or operational requirements. This category includes operational technology (OT) systems, industrial control systems (ICS), Internet of Things (IoT) devices, test equipment, Government-Furnished Equipment (GFE), and legacy systems that cannot be updated to meet modern security requirements.
Specialized Assets are within your assessment scope and must be documented in your SSP — but they are not assessed against the full CMMC requirement set. Instead, you document how they are managed using your organization's risk-based security policies. Some Specialized Assets may be eligible for an Enduring Exception, which must be explicitly documented and justified. The cost savings from correctly categorizing OT/IoT as Specialized Assets rather than CUI Assets can be significant — these devices often cannot implement MFA, audit logging, or encryption controls, and documenting them correctly avoids unnecessary findings.
Category 5 — Out-of-Scope Assets
Out-of-Scope Assets have no interaction with CUI, no connection to CUI systems, and do not provide security protections for the CUI environment. They do not need to be documented, evaluated, or protected under CMMC. Classic examples are sales CRM systems, marketing tools, accounting SaaS platforms that don't handle government data, and general internet-browsing workstations that are physically and logically isolated from CUI systems.
The critical requirement for out-of-scope assets is justification. Your C3PAO must be able to verify that out-of-scope assets truly cannot access CUI — either by the nature of their function or because physical and logical controls prevent it. "We don't use it for CUI" is not sufficient. "It is physically isolated from the CUI network and has no path to CUI repositories" is. Document the separation mechanism, not just the assertion.
Asset Category Reference
| Category | In Scope? | Assessed Against 110 Reqs? | SSP Documentation Required? | Common Examples |
|---|---|---|---|---|
| CUI Assets | Yes | Yes — all 110 | Yes — full control implementation | Workstations, servers, email systems, file shares, laptops that handle CUI |
| Security Protection Assets (SPAs) | Yes | Yes — relevant requirements | Yes — security function description | Firewalls, SIEM, IDS/IPS, MDM, identity providers, vulnerability scanners |
| Contractor Risk Managed Assets (CRMAs) | Yes | No — risk-based policies | Yes — risk management approach | Corporate laptops on same network but not used for CUI tasks |
| Specialized Assets | Yes | No — risk-based policies | Yes — management approach, possible Enduring Exception | OT/ICS systems, IoT devices, GFE, legacy systems, test equipment |
| Out-of-Scope Assets | No | No | No — but separation must be justifiable | Sales CRM, marketing tools, accounting platforms with no CUI access path |
Defining Your CUI Boundary — A Step-by-Step Approach
The CUI boundary is the documented perimeter around the systems and assets that store, process, or transmit CUI. Everything inside the boundary must implement NIST SP 800-171. Everything outside must be genuinely isolated from CUI. The boundary is not a policy assertion. It is an architectural reality that must be verifiable by a C3PAO assessor through documentation, observation, and technical testing.
Defining a defensible CUI boundary follows a systematic sequence. Organizations that shortcut this process consistently end up with either over-scoped systems that inflate their assessment cost or under-scoped systems that generate findings.
| Step | Action | Output |
|---|---|---|
| 1. Contract Review | Identify every contract containing DFARS 252.204-7012. For each contract, document the CUI categories involved and the data elements your customer sends you. | CUI category inventory — what types of CUI your organization handles and under which contracts |
| 2. Data Discovery | Trace CUI from the point it enters your organization (email, FTP, customer portal, physical media) through every system it touches, every person who accesses it, and every location where it is stored or transmitted. | Raw CUI data flow — unsanitized map of where CUI actually lives and moves |
| 3. Asset Categorization | Classify every asset in your environment using the five CMMC asset categories. Every workstation, server, network device, cloud service, and external provider gets a category designation. | Categorized asset inventory — the foundation of your system boundary documentation |
| 4. Boundary Drawing | Define the logical and physical perimeter around CUI Assets and SPAs. Document network segments, VLANs, access controls, and any physical isolation that establishes the boundary. | CUI boundary definition — specific network segments, systems, and locations in scope |
| 5. Diagram Creation | Create a network diagram and CUI data flow diagram that visually represent the boundary, the systems within it, and how CUI moves between them. | Network diagram + CUI data flow diagram — primary visual artifacts for C3PAO review |
| 6. SSP Documentation | Document the boundary, categorized assets, and control implementations in your System Security Plan. Every section of the SSP must be consistent with the boundary you've defined. | System Security Plan — the primary assessment artifact |
| 7. Ongoing Maintenance | Update the boundary and documentation when you add systems, change network architecture, onboard new contracts, or modify how CUI flows through your environment. | Current, accurate scope — required for annual affirmations and re-assessments |
CUI Data Flow Diagrams — What They Must Show and Why Assessors Prioritize Them
A CUI data flow diagram is not optional. While NIST SP 800-171 does not use the exact phrase "data flow diagram," the CMMC Scoping Guide explicitly requires documentation of how CUI flows through your environment. C3PAO assessors routinely request this artifact as one of the first things they review in a Level 2 assessment. Organizations without a current, accurate CUI data flow diagram consistently receive harder assessments with more interviews, more technical testing, and more time on-site.
The diagram serves a specific purpose for the assessor: it allows them to verify that your boundary is accurate and complete. They compare the data flow to your asset inventory, your network diagram, and your SSP control implementations. If CUI flows through a system that isn't in your scope, that's a finding. If a system is in your scope but your data flow shows no CUI contact, that's an over-scope question.
What a Complete CUI Data Flow Diagram Must Show
| Diagram Element | What to Document |
|---|---|
| CUI entry points | Every mechanism by which CUI enters your organization: email, customer portals, FTP/SFTP, physical media, VPN transfers, and API feeds from customer systems |
| Processing systems | Every workstation, server, or virtual machine that opens, edits, generates, displays, or prints CUI — including systems used only occasionally |
| Storage locations | File servers, network attached storage, local hard drives, cloud repositories, backup systems, and archive storage where CUI resides at rest |
| Transmission paths | Every network path over which CUI travels: internal LAN segments, VPN tunnels, email, file transfer protocols, and any API connections |
| Exit points | How CUI leaves your organization: outbound email to customers, file transfers to primes, physical shipment, and remote access by subcontractors |
| Personnel access points | Which users or roles access CUI, from which systems, and through which authentication mechanisms |
| Security protection boundaries | Firewalls, VLANs, access controls, and encryption boundaries that define the CUI enclave |
| External service providers | Any cloud services, managed service providers, or subcontractors that touch CUI or SPD, with FedRAMP authorization status noted |
Network Segmentation as a Scoping Tool
Network segmentation is the single most powerful scoping lever available to defense contractors. By creating a defined, isolated network segment — a CUI enclave — that contains only the systems that must handle CUI, you limit the scope of your CMMC assessment to that segment. Systems outside the enclave are, by architectural design, unable to access CUI. This is a stronger justification for out-of-scope classification than any policy statement.
Contractors who implement a well-segmented CUI enclave before scoping their assessment consistently report smaller scopes, lower assessment fees, and fewer findings than those who allow CUI to flow across a flat, unsegmented network. The architectural investment in segmentation almost always pays back in reduced compliance cost.
Segmentation Approaches That Satisfy C3PAO Scrutiny
| Segmentation Method | How It Works | Assessment Strength |
|---|---|---|
| Physical Separation | CUI systems on dedicated hardware, physically isolated from corporate network. No wired or wireless connection between CUI and non-CUI networks. | Strongest — assessors can observe physical isolation; no technical path for CUI to leave the boundary |
| VLAN Segmentation | CUI systems on a dedicated VLAN with firewall rules preventing traffic between CUI and non-CUI VLANs except for explicitly authorized, logged connections. | Strong — requires documented firewall rule sets and evidence that inter-VLAN traffic is controlled and audited |
| Software-Defined Perimeter | Zero-trust network access controls that authenticate every connection and restrict CUI access to authorized users on compliant devices regardless of network location. | Strong — requires robust authentication logging and access control documentation; assessed against AC and IA domains |
| CUI Enclave on Dedicated Workstations | CUI accessible only from a designated set of hardened workstations, with USB controls, DLP, and network access restrictions enforced. | Moderate — acceptable if access controls are technically enforced and documented; policy-only controls are insufficient |
The requirement driving segmentation is SC.L2-3.13.5 — "Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks." This is a 5-point requirement with no POA&M eligibility. Segmentation is not optional for systems that face the internet; it is a hard requirement. Building your CUI enclave around this requirement simultaneously satisfies it and creates the scoping boundary your assessment needs.
External Service Providers — The Scoping Complexity Most Contractors Underestimate
External Service Providers (ESPs) are one of the most frequently mishandled areas in CUI scoping. An ESP is any external organization that provides services that affect your CUI environment — either by directly handling CUI or by providing security functions that protect CUI systems. If an ESP stores, processes, or transmits CUI, or if they handle Security Protection Data, they are within your CMMC assessment scope.
The key question for every external provider is: does this service touch CUI or the systems that protect CUI? Not all external vendors are ESPs. Your payroll provider, your marketing software, your accounting platform — if these systems have no connection to your CUI environment and no access to SPD, they are not ESPs and are not in scope. But your managed IT provider who has remote access to your servers, your cloud backup service that stores system images, and your email security gateway that processes every email your organization receives — these are ESPs and must be documented.
ESP Decision Framework
| Provider Type | ESP Status | Assessment Implication |
|---|---|---|
| Managed IT/MSP with admin access to CUI systems | Yes — ESP | Must be documented in SSP; personnel may be interviewed by C3PAO; their security practices are relevant to your scope |
| Cloud SIEM / SOC-as-a-Service | Yes — SPA (Security Protection Asset) | In scope; assessed against requirements relevant to SIEM function; SPD must be protected appropriately |
| Email security gateway (processes inbound/outbound email) | Yes — ESP (processes CUI in transit) | If cloud-based and CUI flows through it, FedRAMP Moderate authorization required or equivalent |
| Cloud backup service storing system images | Yes — ESP (stores SPD, potentially CUI) | Must be FedRAMP authorized if storing CUI; SPD storage requires documented protection |
| Payroll / HR SaaS (no CUI access) | No — not an ESP | Out of scope; document why it has no CUI or SPD access if asked |
| General accounting platform (no CUI access) | No — not an ESP | Out of scope; separation from CUI network should be justifiable |
Cloud Services and CUI — Navigating the FedRAMP Requirement
Cloud services that store, process, or transmit CUI must be authorized at FedRAMP Moderate baseline or higher. This is a bright-line rule with no exceptions and enforcement precedent — the MORSECORP False Claims Act settlement included violations related to using non-compliant cloud email services for CUI. This requirement flows from DFARS 252.204-7012 and applies regardless of whether CMMC is in your contract.
The FedRAMP Moderate requirement eliminates a large portion of the commercial SaaS market from consideration for CUI handling. Standard Microsoft 365 commercial, Google Workspace for Business, Dropbox, Box, Slack, and similar mainstream cloud platforms are not FedRAMP Moderate authorized and cannot be used for CUI storage or processing. The authorized alternatives are fewer and more expensive — which is one reason why many small contractors choose to keep CUI entirely on-premises.
Cloud Service Authorization Status — CUI Handling Decision Guide
| Cloud Service | FedRAMP Status | CUI Storage/Processing Allowed? |
|---|---|---|
| Microsoft 365 GCC High | FedRAMP High | Yes — primary choice for DIB email and collaboration |
| Microsoft 365 GCC | FedRAMP Moderate | Yes — for non-ITAR CUI; check specific use case |
| Microsoft 365 Commercial | Not FedRAMP authorized for CUI | No — violation of DFARS 7012 |
| Google Workspace for Government | FedRAMP High | Yes — alternative to M365 GCC High |
| Google Workspace for Business | Not FedRAMP authorized for CUI | No |
| AWS GovCloud | FedRAMP High | Yes — for IaaS/PaaS workloads |
| AWS Commercial | FedRAMP Moderate (some services) | Specific services only — verify per service |
| Dropbox, Box (commercial) | Not FedRAMP authorized for CUI | No |
| Slack, Teams (commercial) | Not FedRAMP authorized for CUI | No — Teams in GCC High is authorized |
Documenting Your Scope in the System Security Plan
The System Security Plan is how your scope becomes an assessment artifact. Every scoping decision you've made — every asset categorization, every boundary definition, every ESP determination — must be captured in the SSP with enough specificity that a C3PAO assessor can verify it without asking you to explain it verbally. If it isn't in the SSP, it doesn't exist from an assessment standpoint.
Scoping-related content appears in multiple SSP sections. System Identification describes the boundary and the systems within it. The asset inventory lists every categorized asset. The network diagrams show the architecture. Control implementation statements for AC.L2 requirements describe how access to CUI is controlled. The ESP section documents every external provider. Collectively, these sections must tell a consistent, coherent story — and that story must match what a C3PAO finds when they look at your actual environment.
Critical SSP Scoping Content — What Assessors Verify
| SSP Element | What It Must Contain |
|---|---|
| System boundary statement | A precise description of what is and is not in scope, with explicit reference to the network segments, physical locations, and organizational units included |
| CUI categories handled | A list of every CUI category your organization encounters, the contracts under which they arise, and the data elements involved |
| Asset inventory with category designations | Every asset in your environment classified as CUI Asset, SPA, CRMA, Specialized Asset, or Out-of-Scope, with justification for each designation |
| Network diagram | Current, accurate network topology showing CUI systems, network segments, external connections, firewalls, and boundary controls |
| CUI data flow diagram | Visual representation of how CUI moves through your environment from entry to storage to transmission to exit |
| ESP documentation | For every in-scope ESP: service description, CUI/SPD handling, FedRAMP status, Customer Responsibility Matrix reference, and relevant control implementations |
| Out-of-scope justifications | For assets claimed as out-of-scope: the technical or physical controls that prevent them from accessing CUI or SPD |
Common CUI Scoping Mistakes That Generate C3PAO Findings
These are the scoping errors that experienced C3PAO assessors find consistently. Each creates a finding that could have been avoided.
1. Undocumented CUI in email. Email is often the primary vector by which CUI enters an organization — customer transmittals, technical data packages, program updates. Many contractors scope their file servers correctly but fail to document their email system as a CUI Asset. If CUI arrives by email and is stored on an email server, that server is a CUI Asset. Your email gateway and email server must be documented in scope, and if they are cloud-based, they must be FedRAMP authorized.
2. Backup systems outside the boundary. Backup systems that replicate CUI servers are CUI Assets (or at minimum SPAs). Many contractors implement excellent controls on production systems but forget that their backup infrastructure creates a second copy of everything — including CUI. If your backups store CUI, that backup system is in scope. If your backups are stored in a cloud service, that service must be FedRAMP authorized.
3. Personal devices used for CUI access. If CUI is accessed from a personal laptop, home computer, or personal mobile device, that device is a CUI Asset. The compliance implication is severe — personal devices are nearly impossible to bring into full NIST SP 800-171 compliance. The correct solution is to prohibit CUI access from personal devices and implement technical controls that enforce the prohibition. Document both the policy and the technical enforcement in the SSP.
4. CRMA misclassification. A system on the same network as CUI systems is a CRMA — not out of scope — unless it is physically or logically isolated from the CUI environment. The statement "we don't use it for CUI" does not justify out-of-scope classification. If a non-CUI workstation is on the same VLAN as CUI servers and there is no firewall rule preventing it from connecting to those servers, it is a CRMA at minimum and potentially a CUI Asset if CUI data could reach it.
5. Stale scope documentation. Your scope was accurate when you wrote it. Then you added a new server, migrated to a cloud service, hired a managed service provider, or moved CUI to a new file share. If your SSP and data flow diagrams don't reflect the current state, you have a gap between documentation and reality — exactly what assessors are trained to find. Treat your scope documentation as a living record that requires update whenever your environment changes.
6. Missing ESP documentation for managed IT providers. If your managed service provider has administrative access to your CUI systems — which most MSPs do — they are an ESP and must be documented in your SSP. Their personnel may be interviewed during your assessment. Their security practices are relevant to your compliance posture. If your MSP has not provided a Customer Responsibility Matrix, request one before your assessment.
Frequently Asked Questions
What is CUI scoping for CMMC?
CUI scoping is the process of identifying all systems, assets, and people in your environment that store, process, or transmit Controlled Unclassified Information — and defining the boundary of what will be assessed during a CMMC Level 2 certification. Your scope determines which assets must implement all 110 NIST SP 800-171 requirements. Getting scoping right is the single most impactful decision in your compliance program — too broad wastes resources, too narrow creates findings.
What are the five CMMC asset categories?
The five CMMC Level 2 asset categories defined in the official CMMC Scoping Guide are: (1) CUI Assets — systems that directly store, process, or transmit CUI, assessed against all 110 requirements; (2) Security Protection Assets (SPAs) — tools that protect CUI but may not touch it directly, like firewalls and SIEMs; (3) Contractor Risk Managed Assets (CRMAs) — assets on the same network as CUI systems but not used for CUI tasks; (4) Specialized Assets — OT systems, IoT devices, and GFE that cannot fully implement NIST 800-171; and (5) Out-of-Scope Assets — systems with no connection to CUI or its protection.
How does proper CUI scoping reduce CMMC assessment cost?
C3PAO assessment fees are typically based on the number of in-scope systems and boundary complexity. A well-scoped, tightly bounded CUI enclave — achieved through network segmentation and access controls — dramatically reduces the number of in-scope assets. Contractors who scope correctly report 30–50% reductions in assessment cost compared to those who approach it without a deliberate strategy. The architectural investment in a tight CUI enclave pays back in reduced C3PAO fees, shorter assessment duration, and fewer findings.
What is a CUI data flow diagram and is it required for CMMC?
A CUI data flow diagram visually maps how CUI enters, moves through, and exits your organization — showing every system, transmission path, and storage location. It is not explicitly named as a mandatory artifact in NIST SP 800-171, but C3PAO assessors routinely request it and the CMMC Scoping Guide references it as essential to defining your assessment boundary. Organizations without a current, accurate CUI data flow diagram consistently receive harder assessments with more interviews and technical testing.
Does cloud storage count as in scope for CMMC?
Yes, if the cloud service stores, processes, or transmits CUI. Cloud service providers handling CUI must be FedRAMP Moderate authorized or equivalent. Standard commercial services — Microsoft 365 commercial, Google Workspace, Dropbox, Box — do not meet this requirement. Authorized options include Microsoft 365 GCC High and Google Workspace for Government. Using an unauthorized cloud service for CUI creates a boundary violation that must be remediated before your assessment.
Does my MSP need to be documented in my CMMC scope?
Yes — if your managed service provider has administrative access to your CUI systems, they are an External Service Provider (ESP) within your CMMC assessment scope. They must be documented in your SSP, their personnel may be interviewed during your assessment, and they should provide a Customer Responsibility Matrix identifying which controls they implement on your behalf. If your MSP cannot provide this documentation, that is a significant compliance risk you need to address before your assessment.