Skip to main content
Industry requirement guideDIB

Defense Industrial Base

Prime contractors, subcontractors, and suppliers to the DoD.

How to use this industry guide

Use this page as a sector-specific map, not as a standalone compliance checklist. Defense work is driven by the contract, the data, the customer, and the system boundary. A contractor supporting a commercial item order with only FCI may have a much different obligation set than a subcontractor handling controlled technical information, export-controlled drawings, test data, or mission-system support.

For defense contractors, the first question is usually not whether cybersecurity matters. It is which obligation layer applies: basic safeguarding, CUI safeguarding, CMMC assessment, cyber incident reporting, SPRS scoring, enhanced controls, export-control handling, classified-system rules, or agency/program-specific requirements.

What usually drives cybersecurity obligations in this sector

Defense and aerospace contractors commonly see cybersecurity obligations because they receive nonpublic government information, handle technical data, support DoD systems, build components for weapon or mission systems, operate cloud or managed IT environments, or receive flowdowns from a prime contractor. Even small subcontractors can become subject to defense cybersecurity clauses when their work involves CUI or covered defense information.

The core federal baseline is FAR 52.204-21 for federal contract information. For DoD work involving covered defense information or CUI, DFARS 252.204-7012 typically brings in NIST SP 800-171, cyber incident reporting, malicious software submission where applicable, media preservation, and flowdown obligations. CMMC adds an assessment and affirmation layer to verify implementation of the required cybersecurity practices.

Defense contractors should also watch for contract-specific requirements tied to classified work, export-controlled information, controlled technical information, operations security, supply-chain restrictions, secure software, cloud hosting, foreign ownership/control concerns, facility access, and agency security instructions.

Requirements to review for this sector

Review these areas first:

  • FAR 52.204-21 if the contractor has a covered contractor information system that processes, stores, or transmits FCI.
  • DFARS 252.204-7012 if the work involves covered defense information or operationally critical support.
  • NIST SP 800-171 for CUI security requirements on nonfederal systems.
  • CMMC assessment requirements when included in solicitations or contracts.
  • SPRS assessment and affirmation obligations where applicable.
  • DoD cyber incident reporting and preservation obligations.
  • Subcontractor flowdowns, especially when the prime passes CUI, CDI, technical data, or system-access duties downstream.
  • Export-control and classified-program boundaries where ITAR, EAR, classified contracts, or special access restrictions apply.
  • Agency, program, and facility-specific security clauses.

Implementation focus areas

Defense contractors should build evidence, not just policies. The most useful implementation record usually includes a current system security plan, scoped asset inventory, CUI data-flow map, access-control evidence, multifactor authentication records, vulnerability and patch-management records, incident-response procedures, subcontractor flowdown controls, training records, SPRS/CMMC assessment evidence, and documented decisions about which systems are inside or outside the CUI boundary.

For small businesses, the most important practical step is to define the CUI environment early. Do not let CUI sprawl across email, unmanaged file shares, personal devices, legacy systems, and uncontrolled subcontractor channels. A smaller, well-documented boundary is usually easier to secure, assess, explain, and defend.

This page is an index. The actionable items are the requirements below.

Standards and frameworks commonly adopted

  • Defense Industrial Base

    Prime contractors, subcontractors, and suppliers to the DoD.

    Adopts: NIST SP 800-53Adopts: CMMCAdopts: NISTAdopts: DFARS 7012

Mapped requirements and controls

Cloud Authorization & Continuous Monitoring

32 CFR Part 170; DFARS 252.204-7021

Obtain and Maintain CMMC Certification at the Required Level

X-CMMC

high

Requirement

Obtain and Maintain CMMC Certification at the Required Level in accordance with 32 CFR Part 170; DFARS 252.204-7021.

Plain-English explanation

Informational CUI obligation (Cloud Authorization & Continuous Monitoring).

Required by

DIB32 CFR Part 2002
medium

Requirement

Use FedRAMP-Authorized Cloud for CUI (DoD: FedRAMP-Moderate Equivalent) in accordance with FedRAMP; DFARS 252.204-7012(b)(2).

Plain-English explanation

If you store or process CUI in the cloud, the service generally must be FedRAMP-authorized; for DoD CUI, DFARS 252.204-7012(b)(2) requires at least FedRAMP-Moderate-equivalent security plus the clause's additional terms. Choosing a non-compliant cloud is a frequent gap that can derail an assessment.

Implementation examples

View implementation examples

Cloud authorization steps:

  • Confirm the cloud service's FedRAMP authorization level (or Moderate-equivalent for DoD).
  • Ensure the provider meets DFARS 7012(b)(2)(ii) requirements and supports incident reporting/media preservation.
  • Document the authorization evidence in your SSP.
  • Keep CUI within the authorized boundary and configured services.

Required by

DIB32 CFR Part 2002

Data-Type / Sector-Specific Safeguards

DoDI 5230.24; DFARS 252.204-7012

Protect Controlled Technical Information

CTI

medium

Requirement

Protect Controlled Technical Information in accordance with DoDI 5230.24; DFARS 252.204-7012.

Plain-English explanation

Controlled Technical Information is technical data with military or space application whose distribution is restricted. DoDI 5230.24 governs distribution statements and DFARS 252.204-7012 imposes safeguarding. CTI is one of the most common CUI categories on defense contracts.

Implementation examples

View implementation examples

Protecting CTI:

  • Apply the correct distribution statement (B-F) to technical documents and drawings.
  • Store and transmit CTI on NIST SP 800-171-compliant systems.
  • Restrict access to U.S. persons where export controls apply.
  • Mark CTI as CUI//SP-CTI with any required LDCs.

Required by

DIBDoDI 5230.24; DFARS 252.204-7012
medium

Requirement

Decontrol CUI When Safeguarding Is No Longer Required in accordance with 32 CFR 2002.18.

Plain-English explanation

CUI status is not permanent. 32 CFR 2002.18 lets the designating agency decontrol information when safeguarding is no longer required, and contractors should not keep treating decontrolled data as CUI. Decontrol is an agency decision — contractors follow it rather than make it.

Implementation examples

View implementation examples

Handling decontrol:

  • Follow agency decontrol instructions and remove or update CUI markings accordingly.
  • Note the decontrol decision and date in your records.
  • Do not unilaterally decontrol CUI you received; confirm with the designating agency.
  • Update access controls once data is decontrolled.

Required by

DIB32 CFR Part 2002

32 CFR 2002.14(f); NIST SP 800-88

Destroy CUI Using Approved Methods

DESTROY

medium

Requirement

Destroy CUI Using Approved Methods in accordance with 32 CFR 2002.14(f); NIST SP 800-88.

Plain-English explanation

CUI must be destroyed using methods that make it unreadable and irrecoverable. 32 CFR 2002.14(f) requires approved destruction, and NIST SP 800-88 provides the media-sanitization guidance the government relies on. Improper disposal is a common and avoidable cause of CUI loss.

Implementation examples

View implementation examples

Approved destruction practices:

  • Cross-cut shred or pulp paper CUI to NSA/agency-approved standards.
  • Sanitize digital media per NIST SP 800-88 (clear, purge, or destroy as appropriate).
  • Use destruction logs or certificates of destruction for accountability.
  • Include cloud and backup copies in your destruction process.

Required by

DIB32 CFR Part 2002
medium

Requirement

Apply Limited Dissemination Controls and Lawful Government Purpose in accordance with 32 CFR 2002.16; CUI LDC Registry.

Plain-English explanation

CUI may only be shared for a lawful government purpose, and Limited Dissemination Controls (LDCs) further restrict who may receive it. 32 CFR 2002.16 and the CUI Registry's LDC list govern which controls (e.g., NOFORN, FED ONLY) can be applied and how. Applying the wrong control — or ignoring one — is a disclosure risk.

Implementation examples

View implementation examples

Managing dissemination:

  • Confirm a lawful government purpose before sharing CUI internally or externally.
  • Apply only LDCs listed in the CUI Registry and only when authorized by the designating agency.
  • Restrict distribution lists and shared drives to authorized recipients.
  • Document dissemination decisions for CUI Specified categories.

Required by

DIB32 CFR Part 2002

DFARS 252.204-7012(m); proposed FAR CUI rule

Flow Down CUI Safeguarding Requirements to Subcontractors

FLOWDOWN

medium

Requirement

Flow Down CUI Safeguarding Requirements to Subcontractors in accordance with DFARS 252.204-7012(m); proposed FAR CUI rule.

Plain-English explanation

CUI obligations do not stop at the prime — they flow down to subcontractors that will handle CUI. DFARS 252.204-7012(m) requires the clause be included in covered subcontracts, and the proposed FAR CUI rule would extend flowdown government-wide. Primes remain responsible for ensuring subs are covered.

Implementation examples

View implementation examples

Managing flowdown:

  • Include the applicable CUI/safeguarding clause in subcontracts that involve CUI.
  • Verify subcontractors' safeguarding posture (e.g., SPRS score, SSP) before sharing CUI.
  • Track which subs receive CUI and under which categories.
  • Require subs to report incidents up the chain.

Required by

DIB32 CFR Part 2002

EO 13556; 32 CFR Part 2002; NARA CUI Registry

Identify and Categorize CUI Using the CUI Registry

IDENTIFY

medium

Requirement

Identify and Categorize CUI Using the CUI Registry in accordance with EO 13556; 32 CFR Part 2002; NARA CUI Registry.

Plain-English explanation

Before you can protect CUI you have to recognize it. The CUI program replaced dozens of agency-specific markings with one government-wide system, and the NARA CUI Registry is the authoritative list of what qualifies and under which category. Contractors should map where covered information lives and tag it to a Registry category.

Implementation examples

View implementation examples

Practical steps to identify and categorize CUI:

  • Inventory systems, shares, and email that may hold government information and trace each to a contract or data flow.
  • Match each information type to a NARA CUI Registry category (e.g., Controlled Technical Information, Privacy, Procurement).
  • Confirm categorization with the contracting officer or data owner when a marking is ambiguous.
  • Re-run the inventory when new contracts, tools, or data sources are added.

Required by

DIB32 CFR Part 2002
medium

Requirement

Apply CUI Markings (Banner, Portion, Category, and Limited Dissemination) in accordance with 32 CFR 2002.20; CUI Marking Handbook.

Plain-English explanation

CUI must carry consistent markings so everyone who handles it knows the limits. The ISOO CUI Marking Handbook prescribes banner marks, portion marks, category designators, and limited-dissemination controls. Correct marking is what makes downstream safeguarding and dissemination rules enforceable.

Implementation examples

View implementation examples

Ways to apply CUI markings correctly:

  • Add a CUI banner at the top (and bottom) of documents and a designation indicator identifying the source.
  • Use category markings (e.g., CUI//SP-CTI) for CUI Specified.
  • Apply portion marks where required and add Limited Dissemination Control markings (e.g., NOFORN, FED ONLY) when authorized.
  • Configure templates, email footers, and DLP labels so markings are applied by default.

Required by

DIB32 CFR Part 2002

NIST SP 800-171 Rev 3; 32 CFR 2002.14(g)

Protect CUI on Nonfederal Systems per NIST SP 800-171

NIST171

high

Requirement

Protect CUI on Nonfederal Systems per NIST SP 800-171 in accordance with NIST SP 800-171 Rev 3; 32 CFR 2002.14(g).

Plain-English explanation

For CUI on nonfederal information systems, NIST SP 800-171 is the control set the government expects. Revision 3 (2024) reorganized the families and tightened several controls; DFARS 252.204-7012 and 32 CFR 2002.14(g) make it contractually and regulatorily binding for many contractors. A System Security Plan and POA&M are the core evidence artifacts.

Implementation examples

View implementation examples

Implementing NIST SP 800-171:

  • Maintain a current System Security Plan (SSP) describing how each control is met.
  • Track gaps in a Plan of Action & Milestones (POA&M) with owners and dates.
  • Implement the access-control, MFA, logging, configuration, and incident-response families.
  • Confirm which revision (Rev 2 vs Rev 3) your contract requires before scoping work.

Required by

DIB32 CFR Part 2002
high

Requirement

Apply Enhanced Safeguards for High-Value CUI (APT) in accordance with NIST SP 800-172.

Plain-English explanation

When CUI is associated with a high-value asset or a critical program, agencies can require the enhanced controls in NIST SP 800-172. These are layered on top of 800-171 to defend against the advanced persistent threat (APT). They are imposed by contract, not by default — check the clause before scoping them.

Implementation examples

View implementation examples

Enhanced (800-172) safeguards often include:

  • Network segmentation and isolation of high-value CUI.
  • Dual authorization and stronger access restrictions for critical operations.
  • Deception, threat-hunting, and enhanced monitoring for APT activity.
  • Verify the specific 800-172 controls your contract selects — agencies tailor the set.

Required by

DIB32 CFR Part 2002
medium

Requirement

Protect Proprietary Business Information / Trade Secrets in accordance with 18 USC 1905; FOIA Exemption 4.

Plain-English explanation

Proprietary business information and trade secrets shared with or generated for the government are protected from improper disclosure. 18 USC 1905 (Trade Secrets Act) and FOIA Exemption 4 limit government release of confidential commercial information. Contractors should mark and segregate proprietary data.

Implementation examples

View implementation examples

Protecting proprietary information:

  • Mark proprietary/trade-secret data with appropriate restrictive legends.
  • Segregate it and limit access to a need-to-know basis.
  • Assert confidentiality when submitting data the government might disclose.
  • Track where proprietary data is shared and stored.

Required by

DIB18 USC 1905; FOIA Exemption 4
high

Requirement

Safeguard CUI at the 32 CFR 2002 Baseline in accordance with 32 CFR 2002.14.

Plain-English explanation

This is the baseline duty to protect CUI at rest, in transit, and in use. 32 CFR 2002.14 sets the floor for all CUI; for CUI on nonfederal systems that floor is implemented through NIST SP 800-171. Treat it as the minimum standard every CUI handler owes regardless of category.

Implementation examples

View implementation examples

Baseline safeguarding measures:

  • Limit access to CUI to people with a lawful government purpose and a need to know.
  • Encrypt CUI in transit and at rest using FIPS-validated cryptography.
  • Control physical access to printed CUI and CUI media.
  • Log access and review it; train staff on handling rules.

Required by

DIB32 CFR Part 2002

32 CFR Part 2002 (CUI Specified)

Apply Category-Specific (CUI Specified) Handling Controls

SPECIFIED

medium

Requirement

Apply Category-Specific (CUI Specified) Handling Controls in accordance with 32 CFR Part 2002 (CUI Specified).

Plain-English explanation

Some CUI categories are 'CUI Specified' — a law, regulation, or government-wide policy imposes handling controls beyond the CUI Basic baseline. 32 CFR Part 2002 directs you to the controlling authority for each Specified category. Always check whether a category is Basic or Specified before deciding how to handle it.

Implementation examples

View implementation examples

Handling CUI Specified:

  • Identify the category's controlling law/regulation in the CUI Registry.
  • Apply the category-specific dissemination and safeguarding rules, which may exceed the baseline.
  • Mark Specified CUI with the correct category designator.
  • Escalate questions to the contracting officer or the designating agency.

Required by

DIB32 CFR Part 2002
medium

Requirement

Provide CUI Awareness Training to the Workforce in accordance with 32 CFR 2002.30.

Plain-English explanation

People are the front line of CUI protection, so the program expects workforce awareness training. 32 CFR 2002.30 contemplates training on identifying, marking, handling, and reporting CUI. Document that staff who touch CUI have completed it.

Implementation examples

View implementation examples

Building a CUI training program:

  • Deliver role-based training before staff are granted CUI access and at least annually.
  • Cover identification, marking, dissemination limits, incident reporting, and destruction.
  • Track completion and retain records as evidence.
  • Refresh content when CUI policies or contract requirements change.

Required by

DIB32 CFR Part 2002
medium

Requirement

Protect Unclassified Controlled Nuclear Information in accordance with 42 USC 2168; 10 CFR Part 1017.

Plain-English explanation

Unclassified Controlled Nuclear Information is unclassified information about nuclear facilities/material whose disclosure could harm security. 42 USC 2168 and 10 CFR Part 1017 govern its identification and protection (DOE program). UCNI determinations are made by authorized reviewers.

Implementation examples

View implementation examples

Handling UCNI:

  • Have authorized officials make UCNI determinations and apply markings.
  • Restrict access to those with a need to know.
  • Protect UCNI in storage and transmission per 10 CFR Part 1017.
  • Destroy UCNI by approved methods.

Required by

DIB42 USC 2168; 10 CFR Part 1017

International Data Protection

15 CFR 730-774 (EAR); 22 CFR 120-130 (ITAR)

Comply With Export Controls for CUI (EAR/ITAR)

EXPORT

medium

Requirement

Comply With Export Controls for CUI (EAR/ITAR) in accordance with 15 CFR 730-774 (EAR); 22 CFR 120-130 (ITAR).

Plain-English explanation

Much CUI is also export-controlled. The EAR (15 CFR 730-774) and ITAR (22 CFR 120-130) restrict releasing technical data to foreign persons, including 'deemed exports' to foreign nationals inside the U.S. Export and CUI controls overlap but are separate regimes — comply with both.

Implementation examples

View implementation examples

Export-control measures:

  • Screen personnel for U.S.-person status where access to controlled technical data is restricted.
  • Obtain licenses or use exemptions before exporting or releasing controlled data.
  • Apply technology control plans and access controls to ITAR/EAR data.
  • Train staff on deemed-export risks in mixed-nationality teams.

Required by

DIB15 CFR 730-774 (EAR); 22 CFR 120-130 (ITAR)

External Notification & Reporting

32 CFR 2002; agency incident-reporting policy

Report Loss or Compromise of CUI

INCIDENT

high

Requirement

Report Loss or Compromise of CUI in accordance with 32 CFR 2002; agency incident-reporting policy.

Plain-English explanation

Loss or compromise of CUI must be reported, often on tight timelines. 32 CFR Part 2002 and agency/contract incident-reporting policy (and DFARS 7012's 72-hour rule for DoD) govern when and to whom. Build the reporting path before an incident, not during one.

Implementation examples

View implementation examples

Incident-reporting readiness:

  • Maintain an incident-response plan with defined roles and reporting timelines.
  • Know the reporting channel (e.g., DIBNet for DoD) and required contract notifications.
  • Preserve images and affected media for the period the contract requires.
  • Run tabletop exercises so the team can meet the deadline.

Required by

DIB32 CFR Part 2002

DFARS 252.204-7012(c)

Report Cyber Incidents to DoD Within 72 Hours

X-DFARS7012-RPT

critical

Requirement

Report Cyber Incidents to DoD Within 72 Hours in accordance with DFARS 252.204-7012(c).

Plain-English explanation

NIST SP 800-171 makes you handle incidents internally; DFARS 252.204-7012 adds a hard external duty: tell the Department of Defense within 72 hours, keep the forensic evidence, and require your subs to do the same. Missing the window or the flow-down is a contract-compliance failure, not just a security gap.

Implementation examples

View implementation examples

Examples of meeting this requirement:

  • Obtain a DoD-approved medium assurance certificate in advance so you can actually file at DIBNet when an incident hits.
  • Write the 72-hour clock, the 90-day image-retention step, and the malware-submission step into your incident-response plan and tabletop it.
  • Add the DFARS 7012 flow-down clause to every subcontract that touches CDI and track sub acknowledgements.

Required by

DIB32 CFR Part 2002

Use Find My Requirements to narrow this list

This industry guide shows requirements that commonly arise in this sector. Find My Requirements lets you filter by contract type, agency customer, data categories, and selected jurisdictions to produce a tailored list for your specific situation.

Start Find My Requirements →