DFARS 7012 Cyber Incident Reporting: 72-Hour Obligations

DFARS 252.204-7012 puts you on a 72-hour clock from discovery of a cyber incident, and the contract expects a DIBNet report, evidence preservation for 90 days, and malware submission to DC3 when applicable.

DFARS 7012 reporting duty

DoD sets the incident reporting obligation in DFARS 252.204-7012. Your contract uses the clause to define rapidly report as reporting within 72 hours of discovery. The reporting duty applies when an incident affects covered defense information on a covered contractor information system, or when the event degrades your ability to provide operationally critical support.

The clause ties reporting to the Defense Industrial Base portal, DIBNet, and expects you to file within the 72-hour window. You update the submission as you learn more, and you coordinate with DoD points of contact during follow-up.

For a broader view of the clause, see our overview, DFARS 252.204-7012 requirements.

Scope and trigger conditions

You report when an incident meets either condition:

The event compromises or has a likely effect on covered defense information on your covered contractor information system.
The event degrades your ability to provide operationally critical support under the contract.

You do not wait for a full root-cause analysis. You start the report as soon as the team confirms discovery of a qualifying incident. You continue triage and enrich the report as you validate facts.

Clock start at discovery

Discovery starts the 72-hour clock. Your incident handler marks the discovery timestamp, opens the DIBNet case, and documents the initial facts you can validate within the window.

Two practical moves keep the timeline intact:

Pre-stage a DIBNet account for your security lead, contracts lead, and one alternate.
Pre-approve a short list of facts you can share without delay, including contract numbers and basic system identifiers.

The clause expects speed and accuracy, in that order. The DIBNet form accepts partial data, and you update entries as your investigation produces confirmed details.

Report content and submission

DFARS 252.204-7012 lists the data elements DoD requests in a cyber incident report. You gather and provide the required items the team can validate within the window. You add more as you confirm them. The set includes contract identifiers, system impact, and technical indicators relevant to the incident.

Two preparation steps simplify this work:

Maintain a current contract-to-system crosswalk that maps contracts containing DFARS 7012 to the systems that process the related information.
Keep a minimal incident report template that mirrors the DIBNet fields and your internal approval flow.

You also prepare for DoD follow-up. DoD can request additional data, including images or logs from affected systems. Your playbook should assign owners for those requests and set an internal response clock that beats 72 hours.

Evidence preservation and malware handling

The clause requires you to preserve and protect images of affected systems and relevant monitoring or packet-capture data for at least 90 days from the date you submit the DIBNet report. You hold that data so DoD can request it. You plan for that hold before an incident.

Two controls support this requirement:

Configure logging and packet capture retention that can meet 90 days for systems in scope, and document the storage locations and contacts.
Establish a repeatable imaging procedure for affected hosts, including chain-of-custody, storage, and access control.

If you discover malicious software in the course of the incident, the clause requires you to submit it to the DoD Cyber Crime Center (DC3) for analysis, using the submission process DoD designates. You build an internal gate in your playbook that routes samples through your security lead and counsel, then submits to DC3 with the match to the DIBNet case.

Cloud service considerations

DFARS 252.204-7012 also addresses cloud service providers that handle covered defense information on your behalf. You remain the contractor of record, but your cloud contracts and configurations need to support your reporting, evidence preservation, and cooperation duties under the clause.

Microsoft states that its Government Cloud services help defense contractors meet DFARS requirements applicable to cloud service providers for services such as Azure Government and Office 365 U.S. Government Defense. Treat that as platform support for the provider obligations in the clause. You still need to configure your tenant, document data flows, and maintain the incident response processes that meet your contract.

Two tasks reduce friction during a cloud-hosted incident:

Document where covered defense information lives in your cloud environments, including storage accounts, mailboxes, and collaboration spaces.
Validate that your logging, packet capture, and imaging approaches work in those environments, and that your team can export artifacts that satisfy DoD requests.

For broader Microsoft program decisions on regulated data, see our guide, GCC High migration decision framework.

Practical preparation steps

Preparation closes most of the timing risk in 7012 incidents. Build these elements into your program and keep them current.

Define a 7012-specific incident playbook that sets the discovery trigger, the 72-hour timeline, and the DIBNet submission steps, and train your handlers on that flow.
Assign a contracts lead to validate contract identifiers, flowdown obligations, and customer points of contact during the first hour of a qualifying event.
Pre-stage a contact roster with names, phone numbers, and emails for your IR lead, contracts lead, counsel, and your prime contractor if you are a subcontractor.
Store a clean copy of the DFARS 252.204-7012 clause with your playbook, along with your contract numbers and CAGE codes.
Inventory the systems that process covered defense information, and tag them in your CMDB so your team can find them during a response.
Configure telemetry that you can preserve for 90 days, including system logs and packet capture where feasible.
Build a malware submission checklist that links your DC3 submission to the DIBNet case, and define a safe handling path for samples.
Rehearse the playbook against a lab scenario that exercises DIBNet reporting, artifact preservation, and DC3 submission in one flow.

You can capture these steps in your System Security Plan and related procedures. If your team tracks gaps in incident response processes, align remediation items in your POA&M and burn them down on a schedule that matches contract risk. For reference posts, see System Security Plan, NIST 800-171 and POA&M management.

DFARS 7012 drives reporting and cooperation duties. CMMC requirements, when present through DFARS 252.204-7021, address assessment of your NIST SP 800-171 implementation. Treat these as separate obligations that can intersect during incident handling.

Control alignment with NIST 800-171

NIST SP 800-171 Rev. 2 places incident response at Level 2 in the IR family. You can use these controls to anchor your 7012 playbook:

IR.L2-3.6.1, establish an operational incident-handling capability for your systems.
IR.L2-3.6.2, track, document, and report incidents to designated officials and authorities.

Testing matters as well:

IR.L2-3.6.3, test the incident response capability on an organizational basis.
Include a 72-hour timeline drill that forces a DIBNet submission, an image capture, and a DC3 submission.

These controls support the mechanics that DFARS 7012 expects. The clause sets the contract duty. The controls help you build the capability that meets it.