Blog · Incident Response

The 72-hour clock: DFARS incident reporting nobody practices.

DFARS 252.204-7012 gives you 72 hours from discovery to report a cyber incident to DoD. The requirements are mechanical and unforgiving, and they reliably fail for one reason: the first time anyone reads them is during the incident.

What the clause actually demands

DFARS 252.204-7012 requires you to "rapidly report" cyber incidents that affect covered defense information or your ability to perform operationally critical support: within 72 hours of discovery, to DoD, through the DIBNet portal. A call to your prime's program manager or your cyber insurer's hotline doesn't meet that requirement. The report goes to DoD, through DIBNet, inside three days.

The detail that ends more reporting timelines than any technical failure is a mechanical one: submitting through DIBNet requires a DoD-approved Medium Assurance Certificate, and that certificate takes time to obtain. The classic failure is discovering at hour 6 of an incident that you can't even log in to report it, then watching your 72-hour window bleed out on a certificate application. Get the certificate before you need it. Applying for one in the middle of an incident never goes well.

72 hrsfrom discovery to DIBNet report
90 daysminimum evidence preservation
DC3where isolated malware goes

Filing the report is only the first obligation. You must preserve images of affected systems, along with relevant monitoring and packet capture data, for at least 90 days from report submission. That assumes you have somewhere to put forensic images and a process for capturing them under pressure. Malicious software you isolate goes to the DoD Cyber Crime Center (DC3). And if you're a subcontractor, you file the DIBNet report yourself, then give your prime (or next higher-tier subcontractor) the incident report number DoD assigns, as soon as practicable. The 72-hour deadline covers the DoD report. Any separate deadline for telling your prime comes from your subcontract.

3.6 is what makes the clock survivable

This is where your NIST SP 800-171 work pays off. The 3.6 Incident Response family describes the operational capability the 72-hour clock assumes you have: prepare, detect, analyze, contain, recover, and test the capability. The testing comes straight from the requirements: 3.6.3 requires testing your incident response capability. A plan nobody has exercised is still just a document, which becomes obvious at 2 a.m. on a Saturday.

Detection depth matters just as much, because the clock starts at discovery, and you can only discover what you can see. An environment with Defender XDR and Sentinel properly deployed discovers the incident at hour zero, with the packet data and system images the preservation requirement demands already flowing. An environment without that depth discovers it in week three, when a prime or an agency calls to ask about it. Our Microsoft stack mapping shows what that tooling covers against 800-171. The audit and integrity families decide whether "72 hours from discovery" is a manageable window or a forensic archaeology project.

Tabletop the report itself

Most tabletop exercises rehearse containment and skip the paperwork. Run one on the report instead: who drafts it, who approves it, which fields DIBNet asks for, and whether the person holding the Medium Assurance Certificate can actually be reached on a weekend. The technical response has professionals and adrenaline on its side. The report has a deadline, a portal, and a certificate, and it can fail without anyone noticing until the deadline has passed.

Before an incident, you should be able to check off every item on this list:

If you can't check every box today, close that gap this quarter, before the first incident grades your homework. A gap assessment will show where your 3.6 family actually stands. Or bring your current IR plan to a strategy call and we'll walk the 72-hour timeline against it, hour by hour.

Rehearse before it's real

Would your IR plan survive contact with the clock?

A practitioner will walk your plan through the DFARS reporting timeline (certificate, portal, preservation, prime notification) and show you where it breaks before an incident does. Or email rj@indirectit.com directly.