DFARS Cybersecurity Requirements: Protecting CUI in the Defense Supply Chain

Every company in the US defence supply chain that handles Controlled Unclassified Information (CUI) faces a layered cybersecurity compliance regime built on three interdependent frameworks: DFARS, NIST SP 800-171, and CMMC 2.0. Understanding how these frameworks connect — and where the specific obligations lie — is the difference between a compliant posture and an expensive remediation exercise after the fact.

This guide covers the structure, requirements, and practical implications of CUI protection in the defence supply chain.

The DFARS-NIST-CMMC relationship

These three frameworks operate at different levels but form a single compliance stack:

• DFARS (Defense Federal Acquisition Regulation Supplement) is the contractual mechanism. It imposes cybersecurity requirements through specific clauses in defence contracts. It is the legal basis for requiring compliance.
• NIST SP 800-171 is the technical standard. It defines the 110 security requirements that must be implemented to protect CUI. DFARS points to it; it provides the substance.
• CMMC 2.0 (Cybersecurity Maturity Model Certification) is the verification mechanism. It defines how compliance with NIST SP 800-171 is assessed and certified.

A contractor cannot address any one of these in isolation. DFARS creates the obligation, NIST 800-171 defines what must be done, and CMMC determines how compliance is proved.

DFARS 252.204-7012: the foundational clause

DFARS clause 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting,” has been in defence contracts since 2017. It remains the primary contractual vehicle for CUI cybersecurity requirements.

Core requirements

Security implementation: Contractors must provide “adequate security” on all covered contractor information systems. For systems processing, storing, or transmitting CUI, adequate security means implementing NIST SP 800-171 as it exists at the time of contract award.

Cyber incident reporting: If a contractor discovers a cyber incident that affects covered defence information or the contractor’s ability to provide operationally critical support, the contractor must:

• Conduct a review for evidence of compromise of covered defence information
• Rapidly report the incident to the DoD Cyber Crime Center (DC3) within 72 hours of discovery
• Preserve and protect images of all known affected information systems and relevant monitoring data for at least 90 days
• Provide DC3 with access to additional information or equipment as necessary

The 72-hour reporting requirement is measured from discovery, not from the completion of investigation. Companies that delay reporting while they investigate frequently find themselves in violation of the reporting timeline.

Cloud service requirements: Covered defence information stored in the cloud must be in an environment that meets security requirements equivalent to FedRAMP Moderate baseline. This applies to the contractor’s cloud service provider, not the contractor itself — but the contractor remains responsible for ensuring the CSP meets the requirement.

Flow-down: The clause must be included in all subcontracts where the subcontractor will handle covered defence information. This is not optional and not limited to first-tier subcontractors. Every level of the supply chain that touches CUI must comply.

Related DFARS clauses

Several additional DFARS clauses work alongside 7012:

• 252.204-7019 (NIST SP 800-171 DoD Assessment Requirements): requires contractors to have a current assessment in the Supplier Performance Risk System (SPRS). The assessment produces a score from -203 to 110, reflecting the contractor’s implementation of NIST 800-171 requirements.
• 252.204-7020 (NIST SP 800-171 DoD Assessment Requirements): gives the DoD the right to conduct higher-level assessments (Medium or High) at the contractor’s facility.
• 252.204-7021 (Cybersecurity Maturity Model Certification Requirements): requires the contractor to have and maintain a current CMMC certificate at the level specified in the contract.

A single contract may include all four clauses. Each carries distinct obligations.

NIST SP 800-171: the 110 requirements

NIST SP 800-171 Rev 2 organises its 110 security requirements into 14 families. While most compliance professionals can recite the family names, the challenge lies in the detail within each requirement.

Where the complexity lives

Consider requirement 3.1.1: “Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).”

This single requirement contains multiple discrete obligations:

• Define what constitutes an authorised user for each system
• Implement authentication mechanisms that enforce authorisation decisions
• Manage processes that act on behalf of users (service accounts, automated scripts, APIs)
• Control device-level access (not just user-level)
• Include other systems in the access control scope (system-to-system authentication)
• Review and update authorisation lists periodically
• Revoke access promptly when authorisation is withdrawn

A company that checks “yes, we limit access to authorised users” has performed a rule-level assessment. A company that tests each of these obligations individually has performed an obligation-level assessment. The gap between these two approaches is where audit findings accumulate.

The SPRS scoring model

The DFARS-mandated self-assessment produces an SPRS score. Each of the 110 requirements carries a weighted value. A perfect implementation scores 110. Each unimplemented requirement subtracts its weighted value. Certain high-impact requirements carry values of 5 points; others carry 1 or 3.

The SPRS score creates transparency — and risk. A score below 110 means specific gaps exist. Those gaps must be documented in a Plan of Action and Milestones (POA&M) with remediation timelines. DoD contracting officers can see your score and factor it into contract award decisions.

Companies with scores significantly below 110 are increasingly finding themselves unable to compete for contracts — not because of a formal disqualification, but because primes and contracting officers are selecting suppliers with stronger scores.

CUI marking and handling

CUI is information the government creates or possesses that requires safeguarding but is not classified. The CUI Registry (managed by the National Archives) defines 125 CUI categories across 20 groupings.

Defence-relevant CUI categories

The categories most commonly encountered in defence contracts include:

• Controlled Technical Information (CTI): technical data with military or space application subject to distribution controls
• Export Controlled: information subject to ITAR or EAR controls (creating an overlap between CUI and export control obligations)
• Naval Nuclear Propulsion Information (NNPI): particularly relevant for AUKUS submarine programmes
• Operations Security (OPSEC): information that could reveal military operational capabilities
• Critical Infrastructure Security Information: information about vulnerabilities in defence-related infrastructure

Marking requirements

CUI must be marked with:

• The CUI banner marking (“CUI” or “CONTROLLED”)
• The specific CUI category designator
• The dissemination control indicator (e.g., FEDCON, NOFORN)
• The designating agency

In practice, CUI marking is one of the most consistently problematic areas. Documents arrive from government sources without proper markings. Contractors generate derivative CUI without applying markings. CUI is commingled with uncontrolled information in shared systems. Each of these creates compliance exposure.

Incident reporting in practice

The 72-hour reporting requirement under DFARS 252.204-7012 is operationally demanding. Companies need to have in place:

• Detection capability: you cannot report what you do not detect. NIST 800-171 requirements in the Audit and Accountability (3.3.x) and System and Information Integrity (3.14.x) families are prerequisites for meeting the reporting obligation
• Triage processes: distinguishing a cyber incident that affects covered defence information from routine security events requires trained personnel and documented procedures
• Reporting mechanisms: DC3 reporting is done through the DIBNet portal. Companies must have accounts established and personnel trained before an incident occurs
• Preservation protocols: the 90-day image preservation requirement means forensic imaging capability must be available — either in-house or through a retainer with a forensic services provider
• Subcontractor coordination: if the incident occurs at a subcontractor, the subcontractor must report to the prime, and the prime must report to DC3. The 72-hour clock starts when the subcontractor discovers the incident, not when the prime is notified

Companies that discover they have reporting obligations during an active incident are already behind. The preparation must happen before the incident.

Flow-down: the supply chain dimension

DFARS 252.204-7012 requires flow-down to subcontractors “at all tiers” that handle covered defence information. This means:

• The prime contractor must identify which subcontractors will handle CUI
• The subcontract must include the DFARS clause
• The prime must verify that subcontractors have adequate security (which increasingly means verifying SPRS scores and CMMC certification)
• Subcontractors must flow the clause down to their own subcontractors

Where flow-down breaks

Flow-down failures are systemic in the defence supply chain. Common failure patterns include:

• IT service providers: a managed IT provider that administers a contractor’s CUI-handling systems may not receive the DFARS flow-down, even though they have administrative access to CUI
• Cloud and SaaS providers: contractors often assume the cloud provider’s FedRAMP authorisation satisfies the requirement, without verifying that the specific service tier and configuration meet FedRAMP Moderate equivalency
• Foreign subcontractors: flow-down to non-US subcontractors creates complex interactions with export control requirements, particularly where ITAR-controlled technical data is involved
• Tier 2+ suppliers: primes typically manage Tier 1 flow-down but have limited visibility into whether Tier 1 subcontractors are flowing requirements to their own suppliers

CMMC 2.0: from self-attestation to certification

CMMC 2.0 addresses the fundamental weakness in the DFARS self-assessment model: companies were self-attesting to NIST 800-171 compliance without independent verification, and many self-assessments were inaccurate.

The certification model

• Level 1: self-assessment against 17 practices from FAR 52.204-21. Annual affirmation. For Federal Contract Information (FCI) only.
• Level 2: third-party assessment against 110 NIST 800-171 requirements by a C3PAO. Triennial certification with annual affirmation. For CUI. Some lower-risk contracts may allow self-assessment at Level 2.
• Level 3: government-led assessment against NIST SP 800-172 enhanced requirements. For the most sensitive programmes.

POA&M under CMMC

CMMC 2.0 permits conditional certification with open POA&M items, subject to constraints:

• Not all requirements are POA&M-eligible. Certain requirements must be fully implemented at assessment time.
• POA&M items must be closed within 180 days of the conditional certification.
• Failure to close POA&M items within the timeline results in loss of certification.

This creates a practical path for companies that are substantially but not fully compliant — but it is not a loophole. The 180-day closure requirement is enforced.

Building a defensible compliance posture

The combined obligations across DFARS, NIST 800-171, and CMMC 2.0 are substantial. AuditDSS covers all three frameworks, with 7,483 DFARS obligations mapped at the testable level — far beyond the 110 NIST requirements that most companies assess against.

A defensible compliance posture requires:

• Obligation-level assessment: test at the obligation level, not the requirement level. Each NIST 800-171 requirement contains multiple obligations, and assessors will test at that granularity.
• Cross-framework mapping: identify where DFARS, NIST 800-171, and CMMC requirements overlap and where they impose distinct obligations. A single control implementation may satisfy obligations across all three.
• Continuous monitoring: CMMC annual affirmation means compliance is not a point-in-time event. Implement monitoring that detects control degradation between assessments.
• Supply chain visibility: map your CUI flow through the supply chain and verify that flow-down obligations are actually being met by subcontractors.
• Evidence management: C3PAO assessors will require evidence for every requirement. Build evidence collection into daily operations, not as a pre-assessment exercise.

The defence supply chain is moving from a trust-based model to a verify-based model. Companies that build compliance into operations — rather than treating it as periodic documentation — will be the ones that maintain their position in the supply chain.

---

AuditDSS maps 7,483 DFARS obligations across the full regulatory text, cross-referenced with NIST SP 800-171 and CMMC 2.0 requirements. Assess your CUI protection posture at the obligation level and identify specific gaps before your C3PAO assessment. Start your assessment.