Before your organization can implement a single CMMC control, patch a single system, or engage a C3PAO for assessment, you must answer one foundational question: What exactly are you trying to protect, and where does it live?
This nugget addresses the three topics that belong at the very beginning of every organization’s CMMC journey — yet are consistently the most overlooked:
1. How to identify Controlled Unclassified Information (CUI) using the NARA CUI Registry
2. How to define your assessment scope What’s in, what’s out, and how to keep it manageable
3. Supply Chain Risk Management (SR) The two controls most organizations don’t know they have to implement
Getting these right before doing anything else will save your organization significant time, money, and assessment risk. Getting them wrong means you may spend a year protecting the wrong things — or leave the right things unprotected.
Part 1: What Is CUI and How Do You Know If You Have It?
CUI is not classified information. It is sensitive government information that requires safeguarding but does not rise to the level of classified. The term covers a wide range of data types that appear throughout the defense supply chain.
The authoritative source for what qualifies as CUI is the NARA CUI Registry, maintained by the National Archives and Records Administration at:
The registry organizes CUI into categories and subcategories. Common categories encountered by defense contractors include:
- Controlled Technical Information (CTI) — Technical data with military or space application, subject to export controls
- Export Controlled — Information subject to ITAR or EAR restrictions
- Procurement and Acquisition — Pre-award source selection information, cost/price data
- Privacy — Personally identifiable information (PII) in government-related contexts
- Law Enforcement — Investigative data, sensitive law enforcement information
- Naval Nuclear Propulsion Information (NNPI) — Specific to applicable contractors
Practical Tip: The best way to identify your CUI is to trace it from the source. Ask these questions:
- What does your government contract require you to handle, store, or transmit?
- Are there DD-250s, technical drawings, specifications, or engineering data exchanged with the government or prime contractor?
- Do your contracts contain FAR 52.204-21 or DFARS 252.204-7012 clauses? If so, you almost certainly handle Federal Contract Information (FCI) and likely CUI.
- Does any information in your environment have CUI markings, distribution statements (e.g., “Distribution B” through “F”), or handling caveats?
Common Mistakes:
- Over-scoping: Treating all internal business data as CUI. This inflates your assessment scope and compliance costs unnecessarily. Only information that meets a CUI category definition and was received from or created for the government requires CMMC-level protection.
- Under-scoping: Assuming CUI only arrives as formally marked documents. CUI frequently flows through email, collaboration tools, file shares, and verbal discussions… often without explicit markings! If the content qualifies as CUI, it must be protected regardless of whether it was formally labeled.
- Missing derived CUI: Information your organization creates based on government-provided CUI (such as analysis, test results, or modified specifications) may itself become CUI. Check your contracts and the applicable CUI category definitions.
Part 2: Defining Your Assessment Scope
Once you know what CUI you have, the next step is determining which systems, personnel, and locations touch that CUI. This defines your assessment scope or CUI enclave.
Your assessment scope directly determines the cost and complexity of your CMMC assessment. A well-defined, properly bounded enclave can dramatically reduce both. An improperly defined scope, either too broad or artificially narrow, creates risk.
The Five Asset Categories (Review)
CMMC scoping guidance defines five categories of assets relative to your CUI environment:
| Asset Category | Description | Assessment Impact |
|---|---|---|
| CUI Assets | Systems that process, store, or transmit CUI | Fully in scope & all 110 controls apply |
| Security Protection Assets (SPA) | Systems that protect CUI assets (firewalls, IAM, SIEM) | In scope & assessed for their protective function |
| Contractor Risk Managed Assets (CRMA) | Systems that are capable of handling CUI and require controls to prevent it | In scope but assessment objectives focus on segregation |
| Specialized Assets | IoT, OT/ICS, GFE, test equipment that are unable to be fully secured | In scope & assessed for proper management |
| Out-of-Scope Assets | Systems with no pathway to CUI, physically and logically separated | Not assessed |
Key Scoping Principles
Logical and physical separation matter. A system is only truly out of scope if there is no realistic pathway by which it could reach CUI. A marketing workstation on a flat network with CUI systems is almost certainly in scope, even if it is “not supposed to” access CUI. Network segmentation, VLANs, jump servers, and data diodes are common mechanisms for legitimately reducing scope.
Cloud services affect scope significantly. If your organization uses a cloud service provider (CSP) to store, process, or transmit CUI, that CSP must meet FedRAMP Moderate authorization (or an equivalent assessed by DoD). The CSP’s authorization status does not automatically bring your systems into compliance, you must still satisfy controls not covered by the CSP’s authorization, documented in a Customer Responsibility Matrix (CRM).
External Service Providers (ESPs) and MSPs may be in scope. If a managed service provider has privileged access to systems within your CUI environment, they may themselves be subject to CMMC requirements. Do not assume that outsourcing IT management moves controls outside your assessment boundary.
Document your scoping decisions. Your System Security Plan (SSP) must describe your assessment boundary, the rationale for in/out-of-scope determinations, and how CUI flows through your environment. Assessors review scoping documentation first — a poorly documented boundary is itself a finding.
Part 3: Supply Chain Risk Management (SR.L2-3.17.1 & 17.2)
**The SR family is new to NIST 800-171 Rev 3** and not currently applicable to CMMC 2.0.
This family was added as a direct response to modern supply chain attacks like SolarWinds. Despite Rev 3 being finalized in May 2024, the DoD issued Class Deviation 2024-O0013 mandating that contractors continue to use Rev 2 for compliance with DFARS 252.204-7012. As of mid-2025, CMMC Level 2 assessments still rely on the 110 controls from Rev 2. Watch for DoD guidance on Rev 3 transition timelines and consider addressing it early. There are only two controls both requiring deliberate, documented action.
SR.L2-3.17.1 – Periodically assess the risk of using products and services from external sources
This control requires your organization to evaluate the supply chain risks associated with IT products and services you use. This includes hardware, software, and managed services sourced from external vendors.
What assessors will be looking for:
- A documented supply chain risk assessment process not just a vendor list, but an actual evaluation of risk factors
- Evidence that you have considered risks such as: counterfeit components, malicious code insertion, poor vendor security practices, vendor financial stability, and geographic risk (e.g., components manufactured in adversarial nations)
- A defined frequency for reassessment (at minimum annually, or when significant vendor changes occur)
- Documentation of which vendors were assessed and what risk determinations were made
Practical Implementation:
- Develop a Supply Chain Risk Management (SCRM) policy that defines your assessment criteria, frequency, and responsible parties
- Prioritize vendors with access to or that provide components for your CUI environment. Not every vendor requires the same depth of assessment
- Consider questionnaires, review of vendor certifications (e.g., ISO 27001, SOC 2), and public threat intelligence when assessing vendor risk
- Document your assessments and retain them as evidence
Common Failure: Organizations confuse SR.L2-3.17.1 with vendor management generally. CMMC’s supply chain risk focus is specifically on cybersecurity risks including the possibility that a product or service could introduce vulnerabilities, backdoors, or malicious code into your environment. A standard vendor performance review does not satisfy this control.
SR.L2-3.17.2 – Develop a plan to address weaknesses or deficiencies identified in supply chain elements
Once you assess supply chain risks (3.17.1), this control requires you to have a documented plan for addressing weaknesses you find. It is the supply chain equivalent of a Plan of Action and Milestones (POA&M). Findings must lead to documented remediation plans, not just notes in a spreadsheet.
What assessors look for:
- Evidence that identified supply chain weaknesses are tracked and have documented remediation plans with owners and timelines
- A process for escalating significant supply chain risks to organizational leadership
- Documentation showing that remediation plans are actually followed through, not just created and subsequently forgotten
- Integration of supply chain risk findings into your broader risk management process
Practical Implementation:
- Create a supply chain risk register that captures identified risks, their severity, planned mitigations, responsible parties, and target remediation dates
- Establish a formal review cadence for the risk register — at least quarterly
- Define clear criteria for what constitutes an acceptable residual risk vs. what requires mitigation
- Where a vendor weakness cannot be fully remediated (e.g., a critical vendor with known security gaps), document your compensating controls and risk acceptance rationale
Common Failure: Organizations that conduct supply chain risk assessments often produce findings but have no formal mechanism for tracking and resolving them. Assessors will ask to see evidence that identified weaknesses led to documented remediation action, not just that the assessment was conducted.
Putting It All Together: The Sequence That Matters
These three elements: CUI identification; scope definition; and supply chain risk management are not just foundational to cyber compliance, they are also interdependent: Proper scope and identification are current requirements for CMMC, and supply chain risk is soon to follow.
- You cannot define your assessment scope until you know what CUI you have and where it flows.
- You cannot conduct a meaningful supply chain risk assessment until you know which vendors touch your CUI environment.
- You cannot write a complete System Security Plan (SSP) until all three are documented.
Organizations that start their CMMC journey by jumping directly to technical controls such as installing MFA, configuring logging, deploying endpoint protection, frequently discover months later that they scoped their environment incorrectly, or missed CUI they didn’t know they had. In the case of future SR controls, a failure to address supply chain controls that their assessors will specifically evaluate.
Get the foundation right first. Everything else builds on it!