Defence Industrial Base Cybersecurity Programme Guide: Running CMMC, DFARS, ITAR and OT as One Programme

US defence suppliers face overlapping obligations from DFARS clauses, the CMMC programme, export control rules and their own production environments, and most of them run these as separate compliance projects that duplicate work and still leave the factory floor and export-controlled data exposed. A defence industrial base (DIB) cybersecurity programme brings them together: one scope, one system security plan, one incident process and one set of controls covering controlled unclassified information (CUI), ITAR technical data and the operational technology that builds the product. This guide is for security leads, compliance managers and IT and OT owners at prime contractors and subcontractors. It explains how the pieces fit, what the current rules actually require (status checked on the official sources on 27 October 2026), how to design the programme, and where it commonly fails. It does not repeat the requirement-level detail in the NIST SP 800-171 and CMMC 2.0 Guide or the CMMC Scoping Guide.

Key takeaways

• DFARS 252.204-7012 is the constant. Whatever happens to CMMC, the clause still requires NIST SP 800-171 security, 72-hour incident reporting to DoD, FedRAMP Moderate equivalent cloud services and flowdown to subcontractors handling covered defense information.
• CMMC Phase II has been suspended. Phase I began on 10 November 2025. Published legal analyses report that the Department announced on 13 July 2026 a suspension of Phase II (due 10 November 2026) pending a CMMC Reform Task Force review, with Phase I self-assessment requirements remaining in effect. The status may have changed since, so check the DoD CIO CMMC pages and the Federal Register for the latest position.
• ITAR data needs its own controls on top of CUI controls. Export-controlled technical data brings access restrictions by nationality and location; the ITAR carve-out for end-to-end encrypted data has specific conditions that cloud and collaboration choices must meet.
• OT is in scope, but differently. Under 32 CFR 170.19, OT, IoT, IIoT and test equipment that can handle CUI are Specialized Assets at Level 2: documented in the SSP and managed under risk-based policy rather than assessed against every requirement.
• One programme beats four projects. A single asset inventory, data flow map and system security plan that covers CUI, ITAR data and OT reduces cost and closes the gaps between separately scoped efforts.

The obligations at a glance

Because CMMC status is under active review, design the programme around the requirements that do not change (NIST SP 800-171 controls, the 7012 reporting process, SPRS scoring) and treat the CMMC assessment route as the variable. See the CMMC Level 2 Assessment Guide for the assessment mechanics.

Designing one scope for CUI, ITAR data and OT

The programme starts with a single data and asset map. Build it once and derive each regime's scope from it.

1. Identify information types: federal contract information, CUI (including covered defense information), ITAR technical data and EAR-controlled technology, plus proprietary design data. Much ITAR technical data is also CUI, but the access rules differ. See the CUI Guide.
2. Trace the flows: follow each type from receipt (customer portal, email, removable media) through engineering (CAD, PLM, simulation), manufacturing (CAM, CNC programs, inspection), and delivery, including suppliers.
3. Categorise assets: apply the 32 CFR 170.19 categories: CUI assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets and Out-of-Scope assets, and record the justification for each out-of-scope decision.
4. Overlay export control: mark where ITAR data lives and who can reach it, including administrators, managed service providers and cloud support staff.
5. Choose an enclave or whole-company scope: a dedicated CUI and ITAR enclave limits cost for organisations where only engineering handles controlled data; a whole-company scope suits organisations where controlled data is everywhere.

ITAR technical data in a cyber programme

• Access by person, not just role: ITAR restricts release of technical data to foreign persons, including inside the US. Identity attributes for citizenship or authorisation status, and access policies that use them, are therefore part of access control design. Treat this as a legal determination owned by export compliance, implemented by IT.
• Encryption carve-out: under 22 CFR 120.54(a)(5), sending, taking or storing unclassified technical data is not an export if it is end-to-end encrypted with FIPS 140-2 (or successor) modules or at least 128-bit security strength, decryption means are not given to third parties, and it is not intentionally sent to or stored in, or sent from, a country listed in 22 CFR 126.1. Cloud designs that rely on this need customer-controlled keys and evidence that the provider cannot decrypt. See the FIPS 140-3 and Cryptographic Module Validation Guide.
• Administrators and support: cloud and managed service support staff with access to unencrypted data are a common export control gap. Confirm where support personnel are located and what they can see.
• Collaboration: engineering collaboration with foreign partners needs licences or agreements in place before any access is granted, and logs that show who accessed which data. See the Encryption Export Controls Guide.
• Classification records: keep a register of which programmes, drawings and data sets are ITAR, EAR or uncontrolled, with the export compliance decision behind each. Security tooling such as data labelling, DLP rules and repository permissions should be driven from that register, so a reclassification changes controls automatically rather than relying on engineers to remember.

Operational technology on the shop floor

DIB manufacturers run machine tools, inspection systems and test rigs that receive controlled part programs and models. These rarely support modern authentication or patching, which is why 32 CFR 170.19 treats them as Specialized Assets. The risk-based management the rule expects should include:

• Segmentation: place OT in its own zones with controlled conduits from engineering; only file transfer services, not general network access, should reach machines. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
• Controlled transfer: move CNC programs through a managed transfer point that logs who sent what, rather than USB sticks or shared drives.
• Vendor remote access: machine builders' remote support goes through brokered, recorded, time-limited sessions. See the OT Remote Access Guide.
• Data at rest on machines: remove programs and models from controllers when jobs finish where practical, and include machines in media sanitisation at disposal.
• Monitoring: passive OT network monitoring gives asset inventory and anomaly detection without touching fragile devices. See the NIST SP 800-82 OT Security Guide.

Incident reporting and evidence

The 7012 clause shapes the incident process. Build these into the incident response plan and test them:

• 72-hour clock: reporting runs from discovery of a cyber incident affecting covered defense information or a covered system, not from confirmation of data loss. Define who decides discovery has happened.
• Prerequisites: obtain the DoD-approved medium assurance certificate before an incident; without it the report cannot be filed.
• Preservation: retain images of affected systems and relevant monitoring and packet capture data for at least 90 days from the report, and be ready to give DoD access for forensic analysis.
• Malware: isolated malicious software goes to the DoD Cyber Crime Center, not the contracting officer.
• Subcontractors: subcontractors report to DoD and pass the report number to the prime as soon as practicable; primes should require this in purchase orders.
• Other regimes: map 7012 against other reporting duties you have. See the Cyber Incident Reporting Requirements Map.

Building the programme

1. Governance: one programme owner with a steering group of security, IT, OT, export compliance, contracts and legal. Put CMMC status monitoring on the agenda.
2. Scope and SSP: complete the data and asset map, choose enclave or enterprise scope, and write a single system security plan that covers CUI assets, ITAR controls and Specialized Assets.
3. Self-assess and post: run a NIST SP 800-171 DoD Assessment, post the summary score in SPRS, and open POA&Ms with owners; aim to close them within the 180 days CMMC allows at Level 2.
4. Cloud and identity: select FedRAMP Moderate equivalent services for CUI, confirm export control posture of the cloud tenant, and enforce MFA and least privilege, including for service accounts and API keys that reach controlled data. See the FedRAMP Guide and the Defence Industrial Base Identity Security Guide.
5. OT controls: segment, implement controlled transfer and vendor access brokering, then document each Specialized Asset in the SSP.
6. Supply chain: flow down 7012 and CMMC requirements, collect subcontractor SPRS and affirmation evidence, and provide secure channels for sharing controlled data with them.
7. Annual cycle: refresh affirmations, rerun the self-assessment at least every three years (or sooner after major change), and exercise the incident process. Keep each change to scope under change control so a scoping decision can be reversed with its evidence intact.

Decision guidance

• Enclave vs enterprise: choose an enclave when controlled data is confined to a few teams and systems; choose enterprise scope when manufacturing, quality and engineering all touch it, because enclave boundaries then leak.
• Commercial cloud vs government cloud tenants: where ITAR data is in scope, choose services whose support model and data residency fit the export control analysis, or rely on the encryption carve-out with customer-held keys.
• Small subcontractors: a managed enclave service can provide a compliant environment quickly; check its SSP inheritance and shared responsibility matrix rather than assuming coverage.
• Large primes: run a supplier assurance function that tracks SPRS scores and affirmations across the supply base and supports small suppliers with templates and shared services.

Detection and measurement

• SPRS summary score per system and the trend across assessments.
• Number of open POA&M items and the percentage closed within 180 days.
• Percentage of CUI and ITAR data repositories with access policies enforcing person-level export restrictions.
• Percentage of Specialized Assets segmented and receiving CUI only through the managed transfer point.
• Time from incident discovery to DIBNet report in exercises (target under 72 hours with margin).
• Percentage of subcontractors handling CUI with current SPRS scores and affirmations on file.

Common failure patterns

• Waiting for CMMC: treating the CMMC pause as a reprieve, although 7012 and 7019 obligations and False Claims Act exposure for inaccurate affirmations remain.
• Shop floor forgotten: CUI part programs flow to machines outside the SSP, with no segmentation or transfer control.
• Export control in a separate silo: the security team builds CUI controls without knowing which repositories hold ITAR data or which administrators are foreign persons.
• No reporting prerequisites: the medium assurance certificate is not obtained until an incident happens.
• Cloud assumptions: a service is assumed FedRAMP Moderate equivalent, or export-compliant, without evidence.
• Machine identities ignored: service accounts, integration tokens and shared OT engineering logins reach CUI without MFA or rotation.

Framework mapping

NIST SP 800-171 is derived from SP 800-53. The DoD CIO currently enforces NIST SP 800-171 Rev 2 for CMMC; Rev 3 exists and is reflected in the NIST SP 800-171 and CMMC 2.0 Guide.

Practitioner checklist

• Check the DoD CIO CMMC page for programme status at least quarterly and record it in the steering minutes.
• Build one data and asset map covering FCI, CUI, ITAR data and OT, and categorise assets per 32 CFR 170.19.
• Maintain one SSP that documents CUI assets, Security Protection Assets and every Specialized Asset.
• Post a current NIST SP 800-171 assessment score in SPRS for each relevant system and track POA&Ms to closure.
• Implement person-level access controls for ITAR data with export compliance sign-off.
• Segment OT and move CUI to machines only through a logged transfer point.
• Obtain the medium assurance certificate, rehearse 72-hour reporting and set 90-day evidence retention.
• Flow down 7012 and CMMC requirements and collect subcontractor evidence.
• Bring service accounts and integration credentials that reach CUI under MFA, vaulting and rotation.

Standards and references

• eCFR: DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting
• eCFR: DFARS 252.204-7019 Notice of NIST SP 800-171 DoD Assessment Requirements
• DoD CIO: About CMMC
• eCFR: 32 CFR 170.19 CMMC Scoping
• eCFR: 22 CFR 120.54 Activities That Are Not Exports
• NIST: SP 800-171 Rev. 3
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: NIST SP 800-171 and CMMC 2.0 Guide · CMMC Scoping Guide · CUI Guide · Manufacturing Identity and OT Access Guide. This guide summarises DFARS, CMMC and ITAR requirements and is not legal advice.