DFARS 252.204-7012 and the 72-Hour Cyber Incident Report

When a Defense Industrial Base contractor experiences a cyber incident involving Covered Defense Information, the clock starts ticking. Not in days—in hours. DFARS clause 252.204-7012 requires you to report certain incidents to the Department of Defense within 72 hours. Miss that window, and you're in breach of contract before you've even begun containment.

I've watched contractors scramble when they discover this obligation mid-incident. They're already dealing with containment, forensics, and business continuity. Then someone asks, "Did we report this to DoD?" and the room goes quiet. The answer is often no, because they didn't know they had to, or they thought "report" meant something else entirely.

DFARS cyber incident reporting isn't like notifying your insurance carrier or filing a police report. It's a contractual obligation with specific technical requirements: submission through the DoD's DIBNet portal, preservation of forensic images, and in some cases, submission of malware samples. The clause doesn't care whether you're ready. It cares whether Covered Defense Information was affected.

What Triggers the 72-Hour Reporting Obligation

The DFARS 7012 clause triggers when you have a "cyber incident" that affects CUI residing in or transiting through your network. Not every security event qualifies, but the definition is broader than most contractors initially assume.

A cyber incident, per the clause, includes any event that actually or potentially jeopardizes the confidentiality, integrity, or availability of CUI, or the information system itself. That "potentially" matters. You don't need confirmed exfiltration. If an adversary gained access to a system containing CUI, that's reportable—even if your logs don't show them touching the data.

Here's the pattern I see: contractors wait for certainty before reporting. They want to complete their investigation, confirm what was accessed, and have a clean narrative. But the 72-hour clock doesn't wait for your forensic report. It starts when you discover the incident, not when you finish analyzing it.

What Counts as Discovery

Discovery occurs when you become aware of facts that would lead a reasonable person to conclude an incident occurred. An alert from your EDR tool counts. A call from the FBI counts. An employee reporting suspicious behavior counts. The moment you have information suggesting CUI was potentially affected, the clock starts.

You don't get to delay discovery by not looking. If your logging was inadequate and you learn about a March breach in June, discovery is in June—but you'll have explaining to do about why your monitoring didn't catch it in real time.

What's Explicitly Excluded

The clause does carve out some incidents. Distributed denial-of-service attacks that don't compromise CUI confidentiality or integrity typically don't trigger reporting. Neither do incidents that only affect IT systems with no connection to CUI. If you maintain proper network segmentation and can demonstrate that the affected systems never touched CUI, you may not need to report.

But segmentation has to be real and documented. "We think those systems were separate" doesn't cut it. If you can't prove segregation, DoD will assume the incident affected CUI.

The DIBNet Portal and What Actually Happens When You Report

Reporting happens through the DoD's Defense Industrial Base Collaborative Information Sharing Environment, known as DIBNet. You can't email a PDF to your contracting officer. You can't file a help desk ticket. The clause requires submission through DIBNet, and that means you need access before you have an incident.

Getting DIBNet access isn't instant. You need to register your company, designate authorized users, and complete the approval process. I've seen this take weeks for new registrants. If you're waiting until you have an incident to register, you've already missed the 72-hour window.

What Information You're Required to Submit

The initial report doesn't require a complete forensic analysis. DoD understands you're still in response mode. What they want within 72 hours is notification that an incident occurred, a description of what you know so far, and contact information for follow-up.

You'll need to provide the contract number under which the incident occurred, a description of the CUI affected, and any information about the threat actor or malware involved. If you don't have all the details yet, say so. "Investigation ongoing" is an acceptable status update. Radio silence is not.

The clause also requires you to preserve images of affected systems and submit malware samples to DoD Cyber Crime Center (DC3). These aren't optional add-ons. They're contractual requirements with teeth behind them.

Medium Reports and Ongoing Obligations

After the initial rapid report, you're required to submit a more detailed medium report. This happens after you've had time to investigate but while the incident is still fresh. The medium report should include your findings about what happened, what data was affected, and what you're doing about it.

DoD may also request access to additional information or artifacts. The clause gives them broad rights to obtain information "necessary" for their assessment. In practice, this usually means additional logs, forensic reports, or technical indicators. You don't get to refuse because you're worried about liability or embarrassment.

Media Preservation: What You're Actually Preserving and Why

The requirement to preserve forensic images catches many contractors off guard. You can't just take screenshots or save some log files. The clause requires you to preserve images of all affected systems—and maintain them until DoD tells you otherwise.

This means bit-for-bit copies of drives, memory dumps where feasible, and preservation of logs and network traffic captures. If you're running a modern cloud environment, this gets complicated fast. You can't exactly image an AWS instance the way you would a physical server in your data center.

The pattern I see here is contractors who preserve what's easy and hope it's sufficient. They grab some logs, maybe snapshot a VM, and call it preserved. Then DoD comes back asking for artifacts they can't produce because they didn't preserve comprehensively enough at the outset.

How Long You Need to Keep Evidence

The preservation requirement lasts until "the resolution of any US Government investigation or inquiry." That's deliberately open-ended. I've seen cases where contractors maintained images for years because the investigation remained nominally open.

You need storage capacity and a plan for long-term preservation. Forensic images are large. If you're preserving multiple systems after a significant incident, you could be looking at terabytes of data that need to remain accessible and verifiable for an indefinite period.

And you can't just delete the evidence when you get tired of storing it. The clause requires you to maintain it until DoD explicitly releases you from the obligation. Make sure your evidence storage plan accounts for years, not weeks.

Malware Submission to DC3

If your incident involved malware, the clause requires you to submit samples to the DoD Cyber Crime Center. This isn't optional, and it's not satisfied by uploading to VirusTotal. DC3 has specific submission procedures, and they want samples packaged properly and delivered through their designated channels.

The purpose is intelligence. DoD wants to analyze the malware, understand attribution, and identify other potential targets. Your incident might be part of a broader campaign, and your malware sample could be the key to protecting other DIB contractors—or DoD networks themselves.

In practice, many contractors don't have malware samples to submit because their EDR quarantined and auto-deleted the malicious files before they thought about preservation. By the time they realize they need to submit to DC3, the evidence is gone. If you operate under DFARS 7012, configure your security tools to preserve, not just delete.

How DFARS Cyber Incident Reporting Intersects with CMMC

CMMC includes specific practices related to incident response and reporting. Practice IR.L2-3.6.1 requires you to establish an operational incident-handling capability. Practice IR.L2-3.6.2 requires you to track, document, and report incidents. If you're pursuing CMMC certification, your assessor will look at your incident reporting procedures.

But here's what contractors miss: CMMC assesses whether you have a process. DFARS 7012 requires you to actually execute it under real-world conditions. You can pass a CMMC assessment with a well-documented incident response plan that's never been tested. You can't satisfy 7012 with documentation alone.

The other intersection is scoping. If you're working toward CMMC Level 2, you've presumably scoped an assessment boundary that includes all systems processing CUI. That same boundary defines what's covered under DFARS 7012 reporting requirements. An incident affecting systems in your CMMC boundary almost certainly triggers the reporting obligation.

I've also seen contractors treat POA&Ms as a way to defer incident response capabilities. That doesn't fly for 7012. The reporting obligation is contractual and immediate. You can't POA&M your way out of a 72-hour reporting requirement.

The SPRS Score Connection

Your Supplier Performance Risk System score reflects your self-assessed compliance with NIST 800-171 controls—including incident response controls. If you've scored yourself highly on IR practices but then fail to report an incident properly, that's not just a contract breach. It's evidence that your SPRS score was inaccurate, which opens a different can of worms entirely.

DoD is increasingly correlating incident reporting compliance with SPRS scores. If you claim 110 points but can't execute basic incident reporting, your score is going to come under scrutiny—and potentially get corrected for you.

What Happens If You Don't Report (Or Report Late)

The consequences for failing to report aren't theoretical. The clause makes reporting a material contract requirement. Failure to report—or late reporting—is a contract breach. That means DoD can pursue remedies ranging from corrective action plans to contract termination.

I've seen late reporting trigger show-cause letters asking why the contractor shouldn't be found in breach. I've seen it result in withholding of payments on the affected contract. And I've seen it become a factor in source selection for future contracts, because past performance matters.

But the more immediate risk is operational. If DoD learns about an incident from another source—say, the FBI or a threat intelligence feed—and discovers you failed to report, the trust relationship is damaged. You're now a contractor who can't be relied upon to follow security procedures. That's a hard reputation to fix.

The "We Didn't Think It Was Reportable" Defense

This is the most common excuse, and it almost never works. Contractors convince themselves the incident wasn't "real" because no data was confirmed stolen, or because it was just a phishing attempt, or because they contained it quickly. Then they don't report, and later, DoD disagrees with their assessment.

The safer approach: when in doubt, report. You won't be penalized for over-reporting. You absolutely can be penalized for under-reporting. If you're genuinely uncertain whether an incident crosses the reporting threshold, err on the side of disclosure and let DoD make the call.

Building a Reporting Capability Before You Need It

The contractors who handle DFARS cyber incident reporting well are the ones who prepared in advance. They registered for DIBNet. They documented their reporting procedures. They trained their incident response team on the 72-hour requirement. And they tested the process before an actual incident forced them to use it.

Your incident response plan should explicitly address DFARS 7012 reporting. It should include decision trees for determining reportability, contact information for DIBNet access, procedures for media preservation, and timelines mapped to the 72-hour window. This isn't theoretical planning. This is operational readiness.

You also need to consider who has authority to make the reporting decision. In a real incident, you don't have time for lengthy debates about whether to notify DoD. Someone needs to be empowered to make that call quickly, and the decision criteria need to be clear.

Tabletop Exercises That Include Reporting

Most contractors run tabletop exercises focused on technical response: containment, eradication, recovery. Fewer include the contractual and regulatory obligations. Your tabletops should include a reporting decision point. Walk through what information you'd need to collect, who would make the DIBNet submission, and how you'd preserve media under time pressure.

The first time you think about DFARS reporting shouldn't be during an actual breach when you're already overwhelmed. Test the process when the stakes are low, so you know it works when the stakes are real.

Reporting as a Strategic Capability, Not Just Compliance

It's easy to view DFARS cyber incident reporting as a checkbox—another burden imposed by contract flowdowns. But contractors who view it that way miss the larger picture. The reporting requirement exists because DoD needs situational awareness of threats to the Defense Industrial Base. Your incident might be the early indicator of a broader campaign.

When you report properly, you contribute to collective defense. DoD can issue alerts to other contractors, adjust threat profiles, and coordinate defensive measures. When you don't report, you leave the rest of the DIB vulnerable to threats you've already encountered.

This also matters for your reputation. Defense contracting is a relationship business. DoD program offices talk. Prime contractors share information. If you're known as a company that takes security seriously, reports incidents promptly, and collaborates with DoD on threat response, that's a competitive advantage. If you're known as the contractor who buried an incident and had to be dragged into compliance, that's a scarlet letter.

The companies that thrive in the Defense Industrial Base are the ones that view cybersecurity as mission-critical, not overhead. DFARS 7012 reporting is part of that mission. Treat it accordingly, and you'll be better positioned not just to survive an incident, but to maintain the trust required to keep doing business with DoD.