This guide is provided by our sponsor: Kieri Solutions, a Authorized C3PAO offering CMMC assessment services.
If your company needs readiness review, pre-assessment, assessment for certification, or consulting for CMMC you may want to reach out to them!
This scope article has been updated to incorporate guidance from the official CMMC Scoping Guide from the Department of Defense.
I do not know your personal situation or the specifics of your environment. This article is written based on my current understanding of CMMC Scope and may not be perfect, or the DoD may change their stance in the future. I recommend consulting with a CMMC professional before making major decisions about your cybersecurity.
This article will focus on CMMC Level 2 scoping – how to scope for an assessment of systems that handle Controlled Unclassified Information. Level 1 scope is significantly different – do not use this article for your CMMC Level 1 self assessment
Download the CMMC Level 2 Scoping Guidance:
Download the CMMC Level 2 Scoping Analysis (Peer-reviewed)
The above Scoping Scenarios Analysis is extremely helpful in translating the official scoping guide into real-world scope. It includes 12 real network scenarios and shows you how scoping is applied to real assets. A must read!
CMMC terms used in this guide
CMMC = Cybersecurity Maturity Model Certification. DoD cybersecurity requirements which are verified by a third party assessor.
C3PAO = Certified Third Party Assessment Organization. A company that performs official CMMC assessments for certification.
FCI = Federal Contract Information. Mildly sensitive information used to deliver goods or services for a Federal Contract.
CUI = Controlled Unclassified Information. Very sensitive information which needs extensive cybersecurity protections.
Legacy = Equipment or software that is old and doesn’t meet current standards for security or vendor support.
Process = The component accesses, enters, edits, generates, manipulates, or prints CUI data.
Store = The component has CUI data stored on it in memory, in media (hard drives, solid state drives, CDs, DVDs), or in physical form such as documents or film.
Transmit = The component helps CUI data move between other components, such as relaying electronic signals through a switch or router, or performs as a courier for data in physical form (documents, portable media).
What does Out of Scope mean?
The official scoping guide has a very broad definition which is simply “Assets that cannot process, store, or transmit CUI”. This definition is problematic because it could be interpreted to mean other contractor’s systems or the government’s systems or even an adversary’s computer ARE in scope for you because they *could* have CUI. Any reasonable person will immediately tell you that the DoD can’t possibly mean this.
This definition of Out of Scope could also be interpreted as only including assets that literally don’t have the capability to process, store, or transmit CUI. Like rocks? But we could etch the rocks with a diagram. Hmm. Very confusing.
I propose thinking of this using different wording, which is:
Out of Scope = “Systems or components or networks or buildings or people which are prevented through boundaries from accessing CUI that was provided to you OR generated by you on behalf of a DoD contract.”
We think it is safe to say that the DoD only wants you to worry about data you control. But it is more than just “controlling the system” – it is about stopping YOUR CONTRACT’S CUI from going to an out-of-scope system.
This requires you to understand your boundaries.
What are boundaries?
Think of boundaries as ways that you prevent your CUI from leaving your in-scope systems (networks, devices, locations, media, people) without permission.
Boundaries can take many forms. The most obvious example of a boundary is a firewall – but just saying you have a firewall is not enough. You need to be able to explain how it stops CUI from leaving your systems.
What is the difference between physical boundaries and logical boundaries?
Physical boundaries prevent unauthorized people, or the tools they deploy, from reaching your in-scope systems.
The most common example of a physical boundary is a locked door. Here are some less obvious physical boundaries:
- A locked cabinet that protects laptops during non-working hours.
- A metal enclosure that protects network devices in a shared office building from tampering.
- Conduit around critical cabling on the outside of your building.
- The area where your wireless signal runs out of strength (or turning off WI-FI).
- Unplugging a network cable that used to run between buildings.
Use logical boundaries when you can’t implement adequate physical boundaries
Logical boundaries are used to protect things that you cannot protect with physical boundaries. Here are some examples of logical boundaries.
- When access to the internet is required, (which means you have an unbroken physical connection from your network to the rest of the internet), firewalls create logical boundaries.
- When your WI-FI network signal extends outside of your building, the passcode is a logical boundary which prevents unauthorized people from accessing your network.
- A cloud email system has millions of users. The cloud gateway is a logical boundary which only allows access to the individual mailbox.
- A laptop is configured to require a username and password in order to log on to the computer. This is a logical boundary which prevents unauthorized people from gaining access to laptop data and trusted networks.
Here are some ways that boundaries work:
- An external-facing firewall blocks all incoming connections, which prevent hackers from compromising your network from the internet. If they were able to compromise your network, an unauthorized hacker could view the data themselves or they could download the data using unauthorized devices.
- Software firewalls on corporate laptops prevent the laptops from establishing connections with unknown devices on wireless. This prevents the laptops from being compromised by unauthorized people or devices while they are away from the protection of the corporate office.
- Virtual Desktop / Terminal Servers / Remote Desktop sessions can be configured to disable copy-paste, direct hard drive transfers, printing, and other forms of data movement. These prevent the client device from directly storing, transmitting, or processing CUI. Note: There is a lot of disagreement about whether simply viewing CUI based on pixels on a screen would count as processing. The DoD has provided answers about whether they consider this an appropriate boundary. Consult a cybersecurity specialist for more details.
- Forcing all connections to authenticate themselves (and using the principle of least privilege for account permissions) prevents data from being accessed by out-of-scope people.
- Denying connections unless the device is registered and authorized (such as through an Endpoint Management solution) prevents data from being accessed by out-of-scope laptops or cell phones.
- Logic on your company’s email server detects documents labeled <CUI> and prevents them from being sent out through email. This stops CUI from moving through the internet (unauthorized networks) entirely.
- Virtual Private Networks (VPN) and HTTPS connections between client and server are used to encrypt CUI as it is transmitted across out of scope networks. This prevents routers in the home or the Internet from becoming in-scope. Note: CUI that is encrypted using FIPS 140-2 Validated Modules is generally considered “not CUI” while it is in the encrypted form – consult with a cybersecurity specialist for more details.
- Endpoint USB ports and DVD drives are disabled using technical configuration to prevent unauthorized media connections.
- Clean desk policies are enforced by management to prevent unauthorized people from accessing sensitive media.
- The building’s doors are locked 24×7. Visitors are buzzed into the front desk area and escorted when they are allowed to access the rest of the building. This prevents unauthorized people from accessing the trusted area of your building.
- Visitors are given the guest WIFI passcode but not the main corporate WIFI passcode. This prevents unauthorized devices from accessing your in-scope network.
- The building’s windows are opaque and interior rooms cannot be viewed from outside. This prevents unauthorized people from viewing your CUI or security measures.
- All Local Area Network wiring for the company’s information system is kept within controlled spaces. Key network equipment is protected within locked metal cages. This prevents unauthorized people from plugging in unauthorized devices, and prevents insiders from opening connections to unauthorized networks
- Portable media that contains CUI is locked inside a safe when not in use. This prevents unauthorized people from accessing the media.
- All employees sign an agreement stating to only use their corporate-issued devices to access CUI. This prevents unauthorized devices from connecting to the trusted network or becoming CUI assets.
- Each project keeps a list of authorized individuals who may be sent CUI, both internal to the company and external partners/clients. This prevents unauthorized people from being given CUI.
- The security team periodically checks the network for rogue hotspots and will disable them if found. This prevents unauthorized networks from being connected, prevents bypass of technical boundaries.
- Signs are posted in visitor conference rooms which state “Do not discuss or store Controlled Unclassified Information in this space”. This prevents unintentional movement of CUI into an out of scope location.
- Documents are labeled with CUI markings and distribution statements. This prevents unintentional sharing of CUI documents with out of scope (or customer risk managed) persons.
- Your employees are not allowed to bring opaque bags and briefcases into your manufacturing spaces. This prevents movement of CUI assets to out of scope locations.
- Printed blueprints are labeled with a unique serial number and checked in/out from a central point. This prevents unintentional movement of CUI documents to out of scope locations.
OK. Now I understand boundaries. What action should I take?
You should proactively explain your boundaries to your assessor during initial scope discussions. This is typically done by documenting each measure in your system security plan (normally in Section 2: description of in-scope environment).
Why only contract-specific CUI in scope?
In the Out of Scope explanation above, we mention that the definition of out of scope should include, “Systems or components or networks or buildings or people which are prevented through boundaries from accessing CUI that was provided to you OR generated by you on behalf of a DoD contract.”
If any data that fits a CUI category would be in-scope, that means every company in the world would need CMMC Level 2 because of their own employee rosters and financials. You can see this if you browse the CUI categories list at archives.gov – look at the “Privacy” list. This includes information that every person has for themselves. Formal protection of that data isn’t the intent of the CUI program. The intent of the CUI program is for government contractors to protect data that they generate or receive while performing contracts for the government.
Different types of in-scope assets and how they are evaluated
If you want the official definition, read the scoping guide. Below are some additional thoughts and flavor (not official).
– these are assets that process, store, or transmit CUI. Though it is not well discussed, most CMMC professionals feel that CUI assets will be assessed against every practice that can apply to them. Full documentation and full proof required.
Security Protection Assets (SPA)
– these are assets that perform a CMMC-required security function and are described in the system security plan in this regard. For example, the SSP may state: “The antivirus server is used to schedule malware scans.” According to the scoping guide, any asset that provides a security function to any other in-scope asset is considered a SPA. So a building that provides physical protection to Customer Risk Managed Assets would be considered an SPA.
I propose distinguishing between an SPA and a CUI asset using this thought process: If an SPA would need to be changed through malicious activity (insider threat, compromised) or significantly change its design in order to store, process, or transmit CUI, then it is an SPA. If the asset has the capability to store, process, or transmit CUI as part of its standard function (such as a cloud-based antivirus which uploads potentially malicious files for analysis), or a janitor that works in a facility with CUI, then it is a CUI Asset.
Though it is not well discussed, some CMMC professionals feel that SPAs will only be assessed against specific CMMC-required security functions in relation to CUI assets. So the example antivirus server would be evaluated enough to prove that it does schedule malware scans for CUI assets. But an assessor would not verify that the antivirus server has complex passwords implemented, or has had maintenance performed. The CMMC community desperately needs clarification about this topic from the DoD. This is a cry for help!
Contractor Risk Managed Assets (CRMA)
– these are assets that are connected in some way (logically, physically) to CUI assets and could be used in a malicious manner to move laterally or to exfiltrate CUI across a network. The contractor is doing their best to make sure no CUI gets into CRMA assets and has a process to remove the CUI if it does happen. CRMA assets do not perform CMMC-required security functions. The company should apply security to these assets as appropriate (based on a risk evaluation) to reduce threats to their CUI.
Specialized Assets (SA)
– these are assets that cannot meet all the practices required for CUI Assets because the asset is limited in function and critical for performance of the contract. The scoping guide discusses multiple types of Specialized Assets. Most CMMC professionals feel that development systems which are under constant change because they are used to test software code fit into the “Test Equipment” category. The DoD needs to clarify if this is not the case.
Note about encryption: If FIPS 140-2 validated cryptography is used to encrypt CUI, the ciphertext is not considered CUI. Assets that store or transmit this ciphertext are not considered to be storing or transmitting CUI as long as they have no ability to decrypt the data. This interpretation (that ciphertext is not CUI) is held by almost all CMMC professionals, and has been reinforced by occasional guidance from DoD to individual companies. It would be very helpful for the DoD to clarify that this is a correct interpretation.
How do you prioritize when multiple categories could fit?
The DoD needs to give an answer to this question. C3PAOs have submitted this question to the DoD but it has not been answered yet.
In the meantime, until guidance is released, I recommend the following thought process. Always refer back to the scoping guide and consult a paid professional before making decisions which can affect your organization’s cybersecurity.
- If an asset is prevented through boundaries from accessing CUI that was provided to you or generated by you on behalf of a DoD contract, OR it is part of a different accreditation boundary (it is controlled by a different organization and will be assessed in a different engagement), select Out of Scope. Stop.
- If an asset stores, processes, or transmits CUI, AND fits into a Specialized Asset category, select Specialized Asset. Stop.
- If an asset stores, processes, or transmits CUI, and does NOT fit into a Specialized Asset category, select CUI Asset. Stop.
- If an asset does not store, process, or transmit CUI, AND it does not perform security functionality, but it has some level of connectivity to CUI Assets or Specialized Assets, select Contractor Risk Managed Asset. Stop.
- If an asset is mentioned in your System Security Plan as performing a security function for any CUI asset, CRMA, Specialized Asset, or another SPA, select Security Protection Asset. Stop.
So how do you justify your scope to your assessor?
The assessor will tell me what my scope should be, right?
When you engage with a C3PAO to perform an assessment or gap analysis, they should ask you to identify scope.
This isn’t because the C3PAO is lazy. It is because the DoD has repeatedly told contractors that they are responsible for identifying their own scope. From the Scoping Guide: “After categorizing their assets, the contractor then specifies the CMMC Assessment Scope.”
So how do you explain exactly what your scope is to an assessor?
1. Identify where your sensitive data exists
Protecting sensitive data, specifically CUI, is what CMMC is designed to do. You need to ask yourself the following questions:
Q: Where is CUI stored on my systems? Examples are file servers, email servers, manufacturing servers, clouds, PCs, databases.
Q: Which of my staff access CUI? Their workstations probably have FCI or CUI on them too.
Q: Who is responsible for this data? Typically project managers and supervisors are data owners.
Q: Which buildings have CUI stored in them? Which buildings have network connectivity to CUI systems?
Now that you’ve thought these questions through, make a list of each location where CUI is stored.
WidgetsUSA has created a list of sensitive data for the contract(s) that will use the CMMC certified information system. Their Level 2 scope should include every CUI location in this table at a bare minimum.
2. Data flow diagrams are evidence that your scope is realistic
The next documentation you should use to identify scope to an assessor is your data flow diagram. Or diagrams. In a typical organization, there are many ways that sensitive data can be transmitted between systems. When your diagram starts getting cluttered, split it up!
What are some common ways for data to flow?
- Processes (interfaces) which move data between companies automatically
- Digital transmission between people (email, web-based file sharing)
- Physical transfers between offices or departments (mailing, courier, employee carries)
It is important to have a functional and realistic scope
Your data flow diagrams should demonstrate that you have functional ways to move sensitive data into and out of your in-scope system.
If your employees are using undocumented methods to move FCI and CUI around, you will probably have a bad time during your assessment.
WidgetsUSA receives FCI via email from their contract partners and the U.S. Government. The FCI may be transmitted between the email server, end-user computers, the file server, and the printer. WidgetsUSA may send emails out to their contract partners and the U.S. Government which contain FCI.
WidgetsUSA is building a prototype F-18 part for the Department of Defense. Because this part cannot be secured to CMMC Level 2 requirements, it is protected separately from the rest of the network. Test data is sent digitally from the Department of Defense to the secure file share. It is received by an engineer who puts the data onto a USB drive and carries it to the prototype for upload.
The prototype is ready for operational testing by the Department of Defense. It is escorted by the factory supervisor to the shipping dock, where it is prepared for transport according to identified CUI procedures. The package is tracked until delivery and the Department of Defense notifies the WidgetsUSA project manager when they receive it.
Data flow diagrams can show many different methods of moving CUI. Your organization needs to demonstrate that they understand the interim steps that the data moves through and have protections at each step.
Sidebar: Why isn’t the entire data flow in-scope?
You may have noticed that the Partner / Government is not in-scope in the diagrams above. Why not?
Assessors understand that a company can’t control everything. Your responsibility needs to end somewhere.
You need to make a thoughtful decision about where your scope ends. You should be able to describe why you feel that the other side (the Government or Partner) can handle their own security. Perhaps you have flowed-down the regulations in your contract with them. Maybe they flowed-down to you. Maybe they sent you FCI or CUI first. After 2026, the answer should be, “Because I verified they have a CMMC certified information system.”
Your scope assignment shouldn’t be arbitrary. Be prepared to describe why you feel that something isn’t in scope. For items that are not in-scope, how can you trust that the data will be safe?
3. Network diagrams
Network diagrams are the most traditional way of identifying scope to your assessor. You should definitely provide at least one network diagram during the assessment planning stages.
WidgetsUSA plans to use their main business network for DoD contracts. They provide a network diagram to the assessor which shows the external boundaries (their firewall and the gateway of their cloud service provider). Because their remote laptops use VPN, they feel that the corporate firewall acts as an external boundary to protect those remote laptops.
4. Facilities diagrams
WidgetsUSA shows the assessment team their headquarters’ building layout. All networking, devices, and physical documents used for the F-18 contract is kept within a secure portion of the building. Physical security measures will be assessed only at the boundaries and within the in-scope area.
5. Org Charts
Organizational charts to describe scope are optional. They are mentioned here because some companies find it very helpful to identify the people who will access their in-scope network, particularly at CMMC Level 2.
WidgetsUSA considers the president of the company and CFO in-scope because they can exert major influence on security for the F-18 contract. While most of the IT department is out of scope, the CIO and one administrator (United States persons) are in-scope because they have administrative access to the in-scope systems. Operational team members are in-scope because they are performing the day-to-day work on the contract.
How complex do your diagrams need to be?
For purposes of identifying scope to us (Kieri Solutions), we don’t feel that diagrams need to be very detailed. They need to show enough information that an external person can orient themselves and understand major systems and functionality. They should show external and internal boundaries clearly, and serve as a guide to identify whether specific devices or locations are in-scope or not.
Can a scope diagram be too detailed?
Yes. If your diagrams have large amounts of redundancy (such as showing every single device in your organization), it is probably too detailed for an assessor. That amount of information makes it harder for the assessment team to understand the overall network and major systems. Keep those detailed diagrams for management of your IT systems and architectural reviews.
How should you plan your scope for CMMC?
Should you keep your scope as small as possible?
Keeping your scope small is a great idea in most cases. Especially if you seek CMMC Level 2 or higher.
Performing high levels of cybersecurity is expensive. Each device, facility, user, or system added to your scope will add cost. Examples of cybersecurity costs that increase with scope are:
- Labor to screen and monitor personnel
- Labor to maintain and monitor security systems
- Labor to maintain systems (patching)
- Licenses or purchase cost for security systems
- Training and managing your staff
Your assessment is more likely to succeed and cost less with a smaller scope.
- The assessor needs to visit fewer locations
- The assessor needs to consider fewer systems for each security requirement
- You can concentrate your efforts, reducing the risk of problems
What are problems with selecting a small scope?
WidgetsUSA has created a second “in-scope” network to use for Department of Defense projects. For the in-scope network to be functional, they needed to add a second server , a second switch, and a second printer. The existing systems (Server A, Switch A, Printer A) cannot be used for the in-scope systems because the firewall blocks them (due to scoping rules).
When you select a sub-set of your systems to be in-scope, you still need to provide a certain amount of functionality for the in-scope systems. For example, most users need to be able to print and email from their in-scope systems. This can result in duplication or complexity. You may decide to give your in-scope users two laptops: one for the in-scope system, and one for your regular system. This can be frustrating and confusing for your users.
Should you select a larger scope?
In some cases, it makes sense to include your entire company’s networks, facilities, and staff in your scope. This is often the best choice for small contractors seeking CMMC Level 1 certification. It can also be a good choice for contractors that only perform Federal work.
Benefit: If you have all your systems in the same scope, then you can standardize how you operate your systems.
- All of your staff go through the same screening and training process
- Costs related to duplicate systems are saved. Your user don’t need to juggle multiple computers or accounts.
- Your entire company benefits from better cybersecurity (hooray!)
What are the drawbacks of larger scope?
- At CMMC Level 2 and above, your users have way less freedom to customize their computer
- As your scope increases, the skilled labor needed to keep it secure also increases
- Some legacy systems simply cannot meet requirements for CMMC Level 2 and above. You will want to keep those “out of scope”, or you might fail an assessment because of them.
What should I do now?
No matter where you are in your CMMC compliance journey, you should spend time defining your scope as described in this guide.
Starting from scratch? Building these data flow diagrams and lists of where sensitive information exists will help you design systems that support functionality for your users.
Mid-way through your project? This is a good time to update your diagrams, re-evaluate the quality of your boundaries, and consider the systems that provide security.
Ready for CMMC assessment? You should review your scope diagrams to ensure they are understandable by an assessor.
Thanks to Kieri Solutions for this article about how to identify scope to your CMMC assessment team (or in the short term, your CMMC Gap Analysis team).
What do you think? Have you seen any other official guidance on scope?
Please comment and share if this was helpful to you!