DFARS 252.204-7012: What the Regulation Actually Requires — and What It Doesn't

DFARS 252.204-7012 is the clause that made cybersecurity a defense contracting issue. If your organization holds a DoD contract that involves Controlled Unclassified Information, this clause is in your contract — and its requirements flow down to every subcontractor in your supply chain who touches that CUI.

Most contractors have heard of DFARS 252.204-7012. Fewer have read it carefully enough to understand exactly what it requires — and the gap between "we're DFARS compliant" and "we meet the specific technical and reporting requirements DFARS actually establishes" is where most compliance failures live.

This post reads the regulation straight. What it requires. What it doesn't require. Where the common misreadings are. And what the specific data-layer implications are for the contractors who have been told to "just get compliant" without being told what compliant means.

What Does DFARS 252.204-7012 Actually Do?

DFARS 252.204-7012, titled "Safeguarding Covered Defense Information and Cyber Incident Reporting," establishes two core obligations for defense contractors who process, store, or transmit Covered Defense Information (CDI):

1. Adequate security. Contractors must provide adequate security on all covered contractor information systems — defined as internal unclassified information systems on which CDI is processed, stored, or transmitted.

2. Rapid reporting. Contractors must report cyber incidents involving CDI or covered systems to DoD within 72 hours of discovery.

The clause also establishes subcontractor flowdown requirements, preserves DoD's right to conduct damage assessments, and sets up the mechanism for DoD to access contractor systems and data in the event of a required investigation.

That is the complete scope of what the clause establishes. It does not specify a particular security architecture, a specific vendor, or a precise checklist of controls. What it does is reference a technical standard that defines those controls.

What Technical Standard Does DFARS 252.204-7012 Reference?

The "adequate security" requirement is defined by reference to NIST Special Publication 800-171, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations." This reference is what connects DFARS to CMMC — CMMC Level 2 is an assessment framework built on top of NIST 800-171's 110 security requirements.

NIST 800-171 maps to 14 requirement families. The ones most directly relevant to data protection at the file layer are:

• System and Communications Protection (SC) — encryption requirements, including the FIPS-validated cryptography mandate
• Access Control (AC) — who can access CUI, under what conditions, and how that access is authorized and revoked
• Audit and Accountability (AU) — what access events are logged, how long logs are retained, and how they can be reviewed

The encryption requirements within SC — specifically 3.13.10 (FIPS-validated cryptography) and 3.13.16 (protection of CUI at rest) — are the controls most frequently implemented incorrectly or incompletely.

What Does DFARS Actually Require at the Data Layer?

At the file and data level, DFARS 252.204-7012's requirements (via NIST 800-171) come down to four things:

FIPS-validated cryptography for CUI in transit and at rest: NIST 800-171 Practice 3.13.10 requires "employ FIPS-validated cryptography when used to protect the confidentiality of CUI." FIPS 140-3 validation is a property of a specific cryptographic module — not of an algorithm. AES-256 implemented in a non-validated module does not satisfy this requirement. The implementing organization must use a module that appears on NIST's Cryptographic Module Validation Program (CMVP) list.

Protection of CUI at rest: Practice 3.13.16 requires that CUI stored within your system boundary is protected against unauthorized access. Encryption is the standard implementation, but the requirement extends to wherever CUI at rest exists — file servers, endpoints, cloud storage, backup systems, and removable media.

Access control over CUI: Practices 3.1.1 through 3.1.22 require that access to CUI is limited to authorized users, authorized system components, and authorized functions. The access control model must be able to demonstrate, with audit evidence, who accessed which CUI under what circumstances.

Audit logging: Practices 3.3.1 and 3.3.2 require logging of user access events — specifically the events that would reveal unauthorized access to CUI if it occurred. These logs must be retained and protected.

What DFARS does not require is a specific platform, a specific cloud architecture, or a specific vendor. It requires cryptographic controls that meet NIST standards and access controls that can be evidenced. The architecture that delivers those controls is the contractor's choice.

What Does DFARS 252.204-7012 Not Require?

This is where the compliance consulting industry has done the most damage.

DFARS does not require GCC High: Microsoft 365 Government Community Cloud High is one implementation approach for achieving DFARS compliance. It is not the only one, and for most defense contractors — particularly Tier 2 and Tier 3 subcontractors — it is dramatically overbuilt and overpriced for what the regulation actually demands. GCC High solves a data residency and government-specific licensing problem. DFARS 252.204-7012 requires cryptographic protection and access control, neither of which is exclusive to GCC High.

DFARS does not require an on-premises enclave: Air-gapped systems and isolated enclaves were an early implementation pattern for DFARS compliance, and they remain legitimate approaches. They are not mandated. The regulation requires controls over CUI — not a particular physical or logical architecture in which CUI must live. If the controls travel with the data, the data does not have to be confined to a specific location to be compliant.

DFARS does not require CMMC certification yet for all contracts: CMMC certification is being phased in. Phase 1 (self-attestation for Level 1 and some Level 2 contracts) began in November 2025. Phase 2 (C3PAO assessments for Level 2 contracts involving CUI) requires assessments starting in November 2026. Understanding what CMMC compliance software covers and what DFARS itself requires are related but distinct questions, and the enforcement timelines are different.

DFARS does not require you to prevent all breaches: The "adequate security" standard is not a guarantee against compromise. It is a requirement to implement controls commensurate with the sensitivity of the data. What the regulation requires you to do when a compromise occurs is governed separately — by the 72-hour cyber incident reporting requirement.

What Are the Most Common DFARS Compliance Gaps at the Data Layer?

Scope underestimation: Contractors identify their primary CUI storage system and treat compliance as applying only there. CUI also flows through email, is shared with subcontractors, is accessed on endpoints, is backed up to cloud services, and sometimes lands in personal storage. DFARS compliance applies to covered contractor information systems — wherever CUI is processed, stored, or transmitted.

Algorithm vs. module confusion: A contractor implements AES-256 and assumes the requirement is satisfied. SC.L2-3.13.10 requires a FIPS-validated module — not just the AES-256 algorithm. The distinction is auditable. An assessor will ask for the CMVP certificate number, and "we use AES-256" is not the answer.

Container security mistaken for data security: SharePoint permissions, folder-level access controls, and portal-based security protect CUI while it resides in a managed container. When a file is downloaded, emailed, or shared externally, the container's protection ends. The difference between container security and file-level encryption is precisely the gap that DFARS assessors probe.

Subcontractor flowdown treated as the subcontractor's problem: DFARS 252.204-7012 requires prime contractors to flow the clause down to subcontractors who process, store, or transmit CDI. The prime's compliance program is responsible for ensuring that flowdown happened. If a Tier 2 subcontractor is not DFARS-compliant and holds CUI that the prime shared with them, the prime has a documented compliance gap.

Incident response planning without incident response capability: Many contractors have written incident response plans that include DFARS cyber incident reporting as a required action. Fewer have tested whether their systems can produce the specific information that report requires: what systems were affected, what CUI was involved, what the scope of the incident was, and what containment steps were taken. The 72-hour window does not accommodate building the answer from scratch.

How Does DFARS Interact With CMMC, ITAR, and Other Defense Regulations?

DFARS 252.204-7012, CMMC, and ITAR are related but distinct frameworks that sometimes overlap and sometimes diverge.

DFARS and CMMC: CMMC is the government's assessment framework for verifying DFARS compliance. It does not create new technical requirements — it creates an assessment and certification mechanism for the NIST 800-171 requirements that DFARS already mandated. CMMC Level 2 certification is the evidence that a contractor has implemented the controls DFARS requires. DFARS is the obligation; CMMC is the proof.

DFARS and ITAR: ITAR (International Traffic in Arms Regulations) is a separate framework governing export-controlled technical data — defense articles and services on the US Munitions List. Contractors handling ITAR data often also have DFARS obligations, but they are distinct requirements from distinct authorities (DoD DFARS vs. State Department ITAR). Protecting ITAR-controlled files requires controls adequate to prevent unauthorized access by foreign nationals or unauthorized parties — which in practice requires file-layer encryption with access controls that can demonstrate who accessed which file under what circumstances.

DFARS and EAR: The Export Administration Regulations govern commercial dual-use technology rather than defense articles. Like ITAR, EAR creates independent data protection obligations that often co-exist with DFARS on the same contractor's data environment.

When a contractor holds CUI under DFARS, ITAR-controlled data under State Department regulations, and export-controlled technology under EAR, the same file-layer encryption and access control architecture can serve all three — because the underlying requirement across all three is that sensitive data must be protected at the point of the data, not only at the system perimeter.

What Does an Adequate DFARS Data-Layer Implementation Look Like?

Working from the specific requirements — FIPS-validated cryptography, access control, audit logging, and 72-hour incident reporting capability — an implementation that satisfies DFARS at the data layer includes:

A CMVP-validated cryptographic module applied to CUI at rest and in transit: The module must be on the NIST CMVP list. The certificate number must be documentable. The module must apply to CUI in every location where it is stored or transmitted, not only in the primary system.

Per-file encryption with a unique key per document: Container-level encryption protects data within a managed environment. When CUI is shared externally, backed up, or accessed on endpoints, container-level protection does not follow it. Per-file encryption with a unique key per file limits the impact of a key compromise to a single file and provides protection that travels with the file regardless of where it goes.

Access control that covers the full scope of CUI movement: Access control must cover CUI as it moves through your environment, to subcontractors, to external parties, and to endpoints. Controls that apply only to the primary SharePoint tenant or file server leave coverage gaps that assessors will find.

Audit logging at the file level: Logs must capture who accessed which file, from which system, at which time. Logs at the system level ("user authenticated to SharePoint on Tuesday") do not satisfy the specificity that DFARS cyber incident response requires. File-level telemetry is what enables you to answer the scope assessment questions required under the 72-hour reporting framework.

A documented incident response procedure for the 72-hour reporting window: The procedure must name the DIBNet portal, the specific information required in the report, who is responsible for filing, and how the scope assessment is conducted. CUI spillage response and DFARS cyber incident reporting share the same 72-hour window, the same documentation requirements, and the same evidence chain.

FAQs: DFARS 252.204-7012 Compliance