As part of your assessment against NIST 800-171, it’s critical to understand what parts of your environment are in scope. This is where CMMC scoping comes in. In our first blog in this series, we discussed the importance of assessments; now we’ll explore scoping and why it matters for the platforms that handle Controlled Unclassified Information (CUI).
What does CMMC scoping mean?
Scoping is establishing the boundaries for where CUI is processed, stored, or transmitted. To accomplish this task, you need to talk to the right people who understand how CUI is engaged including what platforms it touches, how it comes into the environment, where it goes, where it lands, where it is stored, and where it is transmitted from there.
Scoping is not theoretical—it’s the practical identification of people, platforms, and pathways related to CUI. The CMMC Scoping Guide helps formalize what’s in scope through assignment of asset categories.
- CUI assets are in scope.
- Security protection assets should meet the NIST 800-171 requirements as those are the tools you’re using to protect the CUI assets.
- Specialized assets are legacy and operational equipment often in shop floor and lab environments. You have some flexibility with these assets. Take action or at least some scoping limiters to put them in a particular place and tell a narrative on how they are compliant to the best of their abilities.
- Contractor risk managed assets may handle CUI but are protected through risk-based controls rather than full NIST 800-171 implementation.
Know what CUI is and where it resides in your environment
Note that CUI is commonly unmarked or overmarked. Don’t wait for a label or formal guidance—follow the contract, DFARS 252.204-7012, and the nature of the work. CUI examples often include drawings, specs, and bills of materials.
Once you know what information the contract identifies as CUI, identify CUI flows based on data types, contract requirements, and operational context. Consider legacy markings and controlled data such as For Official Use Only (FOUO), International Traffic in Arms Regulations (ITAR), or export-restricted information as indicators of potential CUI handling. Adjust flows and boundaries as clarification is provided by the DOD or contracting officer.
Who decides what CUI is?
Per DoDI 5200.48, the DOD must identify and mark CUI when providing it to contractors, making the DOD the classification authority. Contractors are not responsible for self-declaring or inventing CUI categories. The NARA and DOD CUI Registries define official CUI categories. Contractors may reference them to understand CUI types but may not create or reinterpret CUI categories on their own.
Your contract should indicate what CUI is or your contracting officer should clarify it. When in doubt, ask upstream. You can make informed assumptions about CUI flows, but do not make your own determination about what is and is not CUI.
Follow the flow of CUI
Once you have a handle on what the CUI is in your environment, follow the data to understand the in scope platforms. This step informs the assessment itself because if you know what the platforms are, you know where to apply the controls.
- How does CUI arrive? Does it come in via DoD SAFE (the DOD’s means to exchange information), email, portals, mail, DVDs, or USBs?
- Where does it land? Is it stored on M365, shared drives, or user endpoints?
- Where does it go next? Is it sent to subcontractors, suppliers, storage, or back to the DOD?
Involve the right people in this exercise. Scoping is a cross-functional endeavor. Pre-award this could include business development and contracts team members as they might receive CUI data sets to develop or respond to an RFP. Post-award it can encompass project managers, engineers, and operations folks as these people are touching the data set as they engage in the contract work.
It’s the people who touch the CUI that matter. When you’re scoping, talk to them, understand the data flows and the tools they use because those tools, capabilities, systems, and components are where the controls need to be applied.
Common scoping mistakes
- Not discovering legacy platforms that touch CUI, including Linux boxes, operational technology (OT) equipment. If you’re running an assessment and ask questions related to IT controls and the only person provided to represent it is a Windows administrator, they might tell you they’re doing great things from a compliance standpoint. Later on, you might find out that CUI is introduced to a Linux environment, which introduces compliance requirements to that platform. Pay attention to the in scope platforms.
- Ignoring external systems like Box, OneDrive sync, cloud file shares, and not understanding FedRAMP obligations per DFARS. Think of end users storing CUI in their end user device. They might not be aware that OneDrive is profile syncing that device, introducing this cloud service to a situation where it at first glance appears CUI exists only on the end user device. Keep your cloud services and backup services in mind. Anything that’s moving data around as it relates to in scope platforms and CUI needs to be considered. DFARS 7012 clause states that cloud services storing, processing, or transmitting CUI must meet FedRAMP Moderate or equivalent security requirements.
- Failing to include compliance for components that secure CUI assets. Security protection assets are expected to implement the same 110 controls as the CUI assets themselves. Make sure you’re selecting tools that can meet the requirements.
- Over-including or under-including assets because CUI flows weren’t defined. That’s why scoping is so critical. You don’t want to find out at the tail end of an assessment that assets were not included that you needed to account for during your assessment.
As you examine your environment to determine your CUI and data flows, contact us with any questions. We’re the CMMC experts, and we’re here to help.