Fortinetics
← Insights · CMMC · · · 7 min read

DFARS 252.204-7012: the 72-hour reporting gap most contractors miss until their first incident

What the DFARS cyber incident clause actually requires, why the 72-hour clock starts earlier than most programs assume, and what an evidence-ready reporting response looks like. Including the specific DC3 path and the documentation set your incident response plan needs to pre-stage.

Updated June 2026 — The February 1, 2026 Revolutionary FAR Overhaul restructured the DFARS cybersecurity clauses. DFARS 252.204-7019 was deleted and 252.204-7020 was renumbered to 252.240-7997. DFARS 252.204-7012 itself is unchanged — the safeguarding, 72-hour incident reporting, and cloud computing obligations covered below remain in full force. The change consolidates assessment obligations into DFARS 252.204-7021 (CMMC), eliminating the parallel 7019/7020 self-assessment track. Post-February 2026 practitioner analysis is now converging on a sharper reading of 7997: it recognizes only Medium and High assessments — both government-performed — and quietly eliminates the “Basic” self-assessment tier that 7019 supported. Any 7997 flowdown now invites government Medium/High validation rather than a parallel self-attestation. Contractors who counted on Basic self-assessment as a non-CMMC compliance pathway need to update their assumptions. Our Q2 2026 compliance landscape briefing carries the full context in its June 5 mid-Q2 update.

DFARS 252.204-7012 has been in defense contracts since 2013. Most contractors read the clause, nod at the cybersecurity requirements, and focus their attention on NIST 800-171 implementation. Then an incident happens, the incident response plan kicks in, and the team discovers — in the first hour of the incident, when every minute counts — that the clause requires reporting to the Department of Defense Cyber Crime Center within 72 hours, via a specific portal, with a specific set of information that nobody pre-staged.

This is the gap. What follows is the practitioner’s view of what the clause actually requires, when the clock starts, how to report, and what needs to be ready before an incident occurs rather than during one.

What 252.204-7012 actually requires

The clause applies to any contract involving Covered Defense Information (CDI) — which includes Controlled Unclassified Information. It imposes three obligations that most programs track, and a fourth that many miss:

Implement NIST SP 800-171 security requirements on any Covered Contractor Information System that processes, stores, or transmits CDI. Most programs treat this as the main event, with CMMC as its assessment regime.

Report cyber incidents to DoD within 72 hours of discovery. This is the reporting clause and the focus of this article.

Preserve media and evidence for at least 90 days from the incident report submission. The preservation includes images of affected hosts, malware samples, and packet captures where available. Most teams plan for the first 72 hours and forget about the 90-day preservation window.

Flow the clause down to subcontractors at any tier that handles CDI. The prime is responsible for ensuring subs have equivalent obligations. This is a contract administration obligation, not a cybersecurity one, but it lands on the CISO’s plate frequently.

The reporting and preservation obligations are what create the operational gap, because they require specific preparation that most organizations do not realize they need.

When the clock starts — and why it’s earlier than you think

The clause reads that the contractor must report “within 72 hours of discovery of any cyber incident.” The operational question is: when is an incident discovered? The answer is not when it is confirmed. The answer is when the contractor has “a reasonable basis to conclude” that a cyber incident has occurred.

In practice, this means an EDR alert that passes initial triage — not one that is fully investigated and confirmed — may start the clock. A SIEM correlation rule that fires with enough fidelity to escalate to a human analyst may start the clock. A user-reported phishing compromise that forensic review suggests was successful starts the clock. The clock does not wait for the digital forensics team’s final report.

This is the subtlety most teams get wrong. They design their incident response plan around the assumption that the 72-hour window begins when the security team has declared a confirmed incident, which can be 12 to 48 hours after initial detection. Under DoD interpretation, those 12 to 48 hours are likely inside the reporting window, not before it.

The practical implication: your incident classification criteria need to include a “reportable under DFARS 7012” determination as an early step — not a late step — in the escalation path. A trained analyst should be able to make that determination within hours of initial triage, not days.

The DC3 reporting path

Reports are submitted via the DoD Cyber Crime Center at dibnet.dod.mil. The portal requires a DoD-approved medium assurance certificate to access. If your designated reporter does not have a certificate provisioned ahead of time, getting one is a multi-week process — provisioned during an incident, it arrives long after the 72-hour window has closed.

Pre-stage this. Identify two people who are authorized to submit reports on behalf of your organization. Provision both with DoD medium assurance certificates. Run an annual dry run where each of them logs into the portal and navigates to the incident report form, confirming their access still works. The cost of the certificate is trivial. The cost of needing it and not having it during an incident is substantial.

What the report must contain

The portal form asks for a specific set of information. Not all of it will be known in the first 72 hours — the clause accommodates this by allowing a follow-up report — but the initial report must contain as much as you can determine. Fields include:

Affected systems. Specific systems, not a description. Hostnames, IP ranges, cloud service identifiers, or the asset tags your CMDB uses.

Compromise indicators. What did you observe? Malware hashes, C2 domains, user accounts used, times of activity. If an analyst has produced indicators of compromise, include them.

Data categories affected. What kinds of CUI may have been accessed? “CUI//SP-PROP proposal data” is a reportable categorization. “Some contract information” is not.

Initial response actions. What have you done? Containment steps, credential resets, network isolations, customer notifications. The DoD is not expecting the incident to be closed at report time — they are expecting you to be actively responding.

Preservation status. What evidence have you preserved? Host images, log exports, memory captures, malware samples. If preservation is in progress, say so, and provide the expected completion date.

Contractor POC. A single named individual at your organization with cybersecurity authority and sufficient knowledge to answer follow-up questions. Usually the CISO or incident commander.

The field set is extensive. Composing this during an active incident, with an adrenaline-driven team working the technical response, is the worst time to figure out what the form asks for. Build a template. Pre-populate the fields that do not depend on the specific incident — organizational POC, standard system inventory formats, CUI category definitions. During an incident, the team fills in the deltas rather than starting from a blank form.

The 90-day preservation window

After submission, preserve all media and evidence for 90 days. This means host images, disk snapshots, memory captures, network traffic records, log exports, and malware samples remain available to DoD if they request them. The preservation has specific expectations around chain-of-custody — preserved evidence must be auditable in its provenance.

Most organizations do not have a pre-existing forensic preservation capability. Cloud environments are particularly tricky, because default retention on cloud storage is often shorter than 90 days, and forensic-grade preservation of ephemeral cloud infrastructure requires snapshotting before the infrastructure is destroyed. If your incident response plan’s containment step is “terminate the affected instances,” you have also destroyed the forensic evidence.

Plan for preservation explicitly in the incident response runbook. Pre-identify the storage location for preserved evidence (separate from production environments, access-controlled, auditable). Pre-identify the tooling that will capture the evidence. Where forensic capability is not in-house, have a retainer relationship with an incident response firm that can mobilize within 24 hours.

The tabletop test

The best way to discover the reporting gaps is to run a tabletop exercise that explicitly tests the reporting pathway. Walk through a hypothetical incident — ransomware on a CUI-handling workstation, for example — and at each step of the response, ask: “what does DFARS 7012 require us to do right now?” The tabletop should include:

  • Which role makes the reportability determination, and at what trigger point.
  • How the report gets drafted — the template, the owners, the review and approval flow.
  • Who submits the report, via which credential, from which system.
  • Where evidence is preserved, in what format, for how long.
  • What the flow-down to subcontractors looks like if any are affected.

Most programs running this exercise for the first time discover three to five operational gaps they did not know they had. Addressing those gaps in the calm of a tabletop — rather than during a real incident — is the most consequential investment a DFARS-covered contractor can make.

The checklist

The short-form pre-stage list, for an organization currently operating under DFARS 252.204-7012:

  • Two designated reporters identified, with DoD medium assurance certificates provisioned and access verified within the last 12 months.
  • Incident classification criteria include a “reportable under DFARS 7012” decision point, triggered by initial triage rather than incident closure.
  • Report template pre-populated with organizational POC, standard system descriptors, and CUI category definitions.
  • Evidence preservation capability documented in the incident response plan, with a named storage location and retention procedure.
  • Subcontractor notification procedure for incidents affecting their scope.
  • Annual tabletop that tests the reporting path end-to-end.

If any of these items are not in place, that is a gap worth closing. It is substantially cheaper to close during a quiet quarter than during the week after an incident detection. The clause gives you 72 hours. Most of that window is spent on the technical response, not the reporting. What determines whether the reporting happens on time is what was staged before the incident.

DFARS 7012 incident readiness is built into every CMMC Level 2 engagement we lead. If you are scoping the broader CMMC program and want to understand what a C3PAO assessor will expect on the IR domain, see what assessors actually look for at Level 2.