This article is based on a recent webinar featuring experts from Coalfire Federal, Teramis, and DTC Global. It provides a written, on-demand resource for those who prefer to explore the discussion at their own pace.
Watch the full webinar here.
For defense contractors, CMMC can sometimes appear to be a standalone compliance requirement. In practice, it is one part of a broader contractual and cybersecurity framework that begins with the contract and extends through Controlled Unclassified Information (CUI), FAR and DFARS requirements, NIST SP 800-171, Supplier Performance Risk System (SPRS) reporting, and ultimately CMMC assessment and certification.
That broader context is particularly important during periods of uncertainty around CMMC implementation. Even when the timing or mechanics of third-party certification change, the underlying obligations to protect covered information do not necessarily change with them. Contractors therefore need to understand not only what CMMC requires, but how the requirements that precede CMMC fit together and what responsibilities already exist within their contracts.
The most effective way to approach these requirements is to view them as an interconnected chain rather than a collection of separate compliance initiatives: the contract establishes the organization's obligations; the work being performed determines what information is involved; those obligations determine how CUI must be identified and protected; NIST SP 800-171 defines the applicable security controls; SPRS provides a mechanism for reporting assessment results; and CMMC adds independent verification to the process.
The first step in understanding cybersecurity obligations should be to review the actual contract and its applicable flowdowns, rather than starting with a generic CMMC checklist. The contractual language establishes the requirements that apply to the contractor, and those requirements can exist independently of whether a formal CMMC certification requirement is currently present.
This distinction is particularly important when considering CUI. Contractors may receive information from the government or a prime contractor that is clearly marked as CUI, but they may also create additional CUI while performing the work described in the contract. Information developed in the course of contract performance can become CUI even when it was not originally delivered with a CUI marking. In other words, the absence of a marking does not necessarily mean an organization is free from CUI handling obligations.
The contract therefore provides the context needed to understand what information must be protected. Contractors need to consider what they receive, what they create or modify, and what information is directly related to the performance of the work. Where uncertainty exists, the appropriate response is not to make an unsupported assumption. Organizations can seek clarification from a prime contractor, procurement official, or other appropriate contracting resource and use that determination as a defensible basis for how the information is handled.
This is also why contractors should not assume that the absence of a CMMC clause means there are no cybersecurity obligations. Requirements associated with protecting CUI can exist through DFARS provisions even when CMMC certification language has not yet been incorporated into a particular agreement. CMMC is the verification mechanism being introduced around an existing set of cybersecurity obligations; it does not create the underlying obligation to safeguard CUI.
Identifying CUI is one of the most important, and most misunderstood, steps in the compliance process.
In practical terms, CUI is information that an organization receives or develops in performance of a contract and that falls within established CUI categories. For many organizations in the Defense Industrial Base, controlled technical information and export-controlled information represent a significant portion of the CUI they encounter. That can include technical specifications, drawings, part numbers, bills of material, and other technical information associated with the performance of the contract.
The challenge is that contractors often approach CUI as though the question were simply whether a document has been stamped or labeled correctly. In reality, identifying CUI requires understanding the work being performed, the information associated with that work, and the definitions and guidance that apply. The statement of work can be particularly important because it often contains the details needed to determine what information is unique to the performance of the contract and therefore potentially subject to CUI requirements.
Contractors should also account for derivative CUI. Information created from existing CUI can itself become CUI, which means the volume and location of controlled information can expand significantly beyond what an organization initially receives. This makes CUI identification an ongoing responsibility rather than a one-time labeling exercise.
At the same time, the answer is not to simply designate everything as CUI. Overmarking can create its own compliance and operational problems. Treating an entire enterprise as though it contains CUI can unnecessarily expand the assessment boundary, increase costs and complexity, and make the resulting security program more difficult to maintain. It can also obscure which information actually requires the enhanced protections associated with CUI. The objective should instead be to identify where CUI actually exists and establish the smallest defensible boundary around it.
The importance of CUI identification extends directly into scoping. An organization cannot define an accurate assessment boundary without first understanding where CUI is stored, processed, and transmitted.
For many organizations, this is more difficult than expected. CUI can exist in file shares, email, endpoints, applications, backups, cloud environments, and other systems that employees may not initially associate with the CUI environment. It can also move beyond the organization's direct environment through subcontractors and other external service providers. Relying exclusively on interviews or assumptions about where the information should be can therefore produce an incomplete picture of the actual environment.
Discovery can involve both manual review and technology-assisted methods. The important point is that the resulting scope should be based on where the data actually exists and flows, rather than where the organization assumes it exists. A well-defined scope gives the contractor a clearer understanding of which systems are subject to the requirements, what resources will be required to secure them, and what the eventual assessment will need to cover.
Poor scoping creates problems in both directions. An underscoped environment can leave CUI in systems that were never secured or assessed. An overscoped environment can force an organization to spend resources protecting systems that do not need to be part of the CUI boundary. In either case, the resulting assessment and SPRS score may be measuring something other than the environment that actually matters.
For that reason, CUI discovery is not merely an assessment-preparation activity. It is foundational to the entire compliance strategy. Without a reliable understanding of the data, the organization cannot reliably define its scope, assess its controls, estimate its costs, or demonstrate that its cybersecurity program addresses the environment covered by its contractual obligations.
Once an organization understands that it handles CUI, the contractual requirements become the mechanism for translating that responsibility into specific cybersecurity obligations.
DFARS 252.204-7012 serves as a central requirement for protecting covered information and implementing NIST SP 800-171 safeguards, while related DFARS provisions establish assessment and reporting expectations. CMMC then adds an independent assessment and certification mechanism to verify that the applicable requirements have been implemented.
This creates an important distinction between implementing NIST SP 800-171 and becoming ready for a CMMC assessment. Organizations can be in the process of implementing and maturing their cybersecurity program while still having gaps that need to be addressed. They may assess themselves, document deficiencies, develop plans of action and milestones, and improve their posture over time. Becoming assessment-ready, however, means moving from a state of improvement toward a state in which the applicable requirements are implemented and can be demonstrated through objective evidence.
The difference is ultimately one of trust versus verification. Historically, organizations could assess themselves and report their status. CMMC introduces a formal mechanism for independently verifying those claims. The objective is not simply to establish that an organization says it is compliant, but to determine whether the controls are actually implemented across the assessed environment.
SPRS provides the government with visibility into an organization's cybersecurity assessment posture, but the value of that score depends on the accuracy of the underlying assessment.
Several disconnects can occur. An organization may report an inflated score by treating planned or partially implemented controls as though they were fully implemented. It may have a score that is technically accurate for the environment that existed when it was calculated but no longer reflects the environment after cloud migrations, new SaaS applications, changes to managed service providers, or other significant changes. Or the organization may have defined its boundary incorrectly in the first place, meaning that even a high score is measuring the wrong environment.
For organizations with older scores, the appropriate question is whether the score remains accurate today. The answer should not be based on how convenient the existing score is to maintain. A meaningful reassessment should revisit the organization's risk assessment, security controls, scope, and evidence and make adjustments where necessary.
This is particularly important because reporting obligations and contract eligibility requirements depend on the accuracy of the underlying assessment. A favorable score that cannot be substantiated creates a significantly different risk profile from an accurate score that reflects the organization's actual posture and clearly identifies the remaining areas for improvement.
CUI rarely remains within a single organization. Defense programs can involve large and complex networks of primes, subcontractors, suppliers, and service providers, and the information associated with contract performance can move through multiple tiers of that ecosystem.
As CUI flows through the supply chain, the need to understand how it is protected follows it. Prime contractors have responsibilities associated with the organizations within their supply chain, while subcontractors that receive and share CUI have responsibilities of their own. Organizations should therefore understand not only what CUI they receive, but where they send it and whether the organizations receiving it are positioned to protect it appropriately.
The same principle applies when organizations rely on external IT and security providers. Cloud service providers, managed service providers, managed security service providers, and other third parties can become important components of the CUI environment and therefore need to be evaluated as part of the overall compliance strategy.
Outsourcing technology does not eliminate the contractor's responsibility to understand its environment. Instead, it changes how that responsibility must be managed. Organizations need to understand what a provider is responsible for, what remains the customer's responsibility, and what evidence or assurances the provider can supply to support the organization's compliance posture.
The objective of CMMC is not simply to help an organization prepare for a certification event. It is intended to establish confidence that the required cybersecurity controls are actually operating within the environment where CUI is handled.
That means certification should be viewed as a point within a broader lifecycle. Organizations continue to change after an assessment. They adopt new applications, move workloads to the cloud, add employees, change service providers, update infrastructure, and modify how information moves through the business. Any of those changes can affect scope or control implementation.
This is why an organization can successfully complete an assessment and still create risk afterward if it does not maintain the environment that was assessed. A certification only provides meaningful assurance when the organization continues to operate the environment in a manner consistent with the requirements and the scope on which that certification was based.
It is also why independent validation before a formal assessment can be valuable. A mock assessment provides an opportunity to test whether the organization can demonstrate its controls, produce the necessary evidence, and withstand the type of scrutiny it will encounter during an independent assessment. More importantly, it can expose differences between what the organization believes is true and what it can actually demonstrate.
The path from CUI to CMMC is ultimately less about checking individual boxes and more about establishing a defensible understanding of the environment.
That begins with the contract. From there, organizations need to understand what information they receive and develop in performance of the contract, accurately identify CUI, discover where that information is stored, processed, and transmitted, and use that understanding to establish an appropriately defined scope. The applicable NIST SP 800-171 requirements then need to be implemented within that environment and supported by evidence that demonstrates the controls are operating as intended. Assessment results and SPRS reporting should reflect that reality, and organizations should continue validating their posture as the environment changes.
The common thread through all of these activities is accuracy. A CUI inventory that does not reflect reality creates an inaccurate scope. An inaccurate scope creates an unreliable assessment. An unreliable assessment produces an unreliable SPRS score. And a score that cannot be substantiated provides little protection when an organization is asked to demonstrate that its cybersecurity claims are true.
For defense contractors, the most important questions are therefore foundational: Do we know what CUI we handle? Do we know where it exists? Do we understand which contractual requirements apply to us? Have we defined the right environment? Can we demonstrate that the required controls are actually implemented? And does our documented and reported posture accurately reflect the environment today?
Those questions remain valuable regardless of changes to the CMMC implementation timeline. Organizations that can answer them with confidence are better positioned not only for CMMC assessment, but for the broader responsibility of protecting CUI throughout the life of their contracts.