Fortinetics Book a call →
Menu
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.

Note (2026) — DFARS 252.204-7012 (safeguarding, 72-hour incident reporting, cloud computing) remains in force exactly as covered below. Its companion assessment clauses, 252.204-7019 (self-assessment posting to SPRS) and 252.204-7020 (government assessment access), are also still active. The September 2025 CMMC final rule (DFARS Case 2019-D041) layers the CMMC clause 252.204-7021 onto contracts and adds a new notice clause, 252.204-7025; it does not delete the self-assessment clauses. Updated July 14, 2026: the CMMC Phase 2 transition that was set for November 10, 2026 has been suspended pending a 60-day review, but that changes nothing in this article. The Department of War CIO memo states explicitly that the DFARS 252.204-7012 requirements “are still in effect” and that baseline NIST SP 800-171 Rev 2 compliance continues to be enforced through self-assessment. If anything the suspension raises the stakes here: with third-party assessment off the table, 7012 and your self-attested SPRS score are the obligations actually carrying enforcement risk. For the wider picture, see our Q2 2026 compliance landscape briefing.

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.

Frequently asked

Common questions.

What is DFARS 252.204-7012?
The Department of Defense contract clause that requires covered defense contractors handling Controlled Unclassified Information to (1) implement NIST SP 800-171 security controls, (2) report cyber incidents to the DoD Cyber Crime Center (DC3) within 72 hours of discovery, and (3) make compromised information and systems available for DoD forensic review. It has been in force since 2017 and applies to any DoD contract involving CUI. CMMC implements and formalizes the first prong; the second and third are still the contractor's direct obligation.
What counts as a 'cyber incident' requiring reporting?
A cyber incident is any actual or potentially adverse event on a covered contractor system that affects CUI or the capability of the contractor to perform the contract. The definition is broad by design: attempted phishing that got past one filter layer, an unauthorized access attempt, or a malware detection are all potentially reportable. The 72-hour clock starts at discovery, not investigation, so the on-call decision tree matters enormously.
How do I actually report a cyber incident to DC3?
Via https://dibnet.dod.mil, the DoD DIB Net portal. You need a medium-assurance DoD PKI certificate to submit, which must be pre-provisioned (not obtained at incident time). The portal collects incident details, affected systems, CUI involvement, and response actions. Pre-staging: identify the reporter, the backup reporter, the certificate provisioning lead, and the workflow for getting facts into the portal within 72 hours regardless of who discovers the incident.
Does CMMC Level 2 cover the DFARS 7012 incident-reporting requirement?
CMMC Level 2 assesses whether you have an incident response plan that addresses DFARS 7012 reporting, but CMMC is not a substitute for the contractual obligation. You must actually report under DFARS 7012 regardless of CMMC status. The plan-and-procedure evidence shows the assessor you have the capability; the reporting itself is a direct contractor-to-DoD obligation that CMMC does not mediate.