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

What the clause actually demands

DFARS 252.204-7012 requires "rapid reporting" of cyber incidents that affect covered defense information or your ability to perform critical support — within 72 hours of discovery, to DoD, via the DIBNet portal. Not to your prime's program manager, not to your cyber insurer's hotline first. To DoD, through DIBNet, inside three days.

And here is the mechanical detail that ends more reporting timelines than any technical failure: submitting through DIBNet requires a DoD-approved Medium Assurance Certificate. That certificate takes time to obtain. The classic failure mode is discovering at hour 6 of an incident that you can't even log in to report it — and watching your 72-hour window bleed out on a certificate application. Get it before you need it. There is no version of this story where getting it during the incident goes well.

The report is only the beginning of the obligations. You must preserve images of affected systems and relevant monitoring and packet data for at least 90 days from report submission — which presumes you have somewhere to put forensic images and a process for capturing them under pressure. When malicious software is isolated, it gets submitted to the DoD Cyber Crime Center (DC3). And if you're a subcontractor, you must also notify your prime — a second reporting path with its own contacts and its own clock, running in parallel.

3.6 is what makes the clock survivable

None of this is separate from your NIST SP 800-171 work — it's the payoff. The 3.6 Incident Response family is the operational capability the 72-hour clock assumes you have: prepare, detect, analyze, contain, recover, and test the capability. That last one isn't our editorializing — 3.6.3 literally requires testing your incident response capability. A plan that has never been exercised is a document, not a capability, and the difference becomes vivid at 2 a.m. on a Saturday.

Detection depth matters just as much, because the clock starts at discovery — and discovery is a function of 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. We've mapped what that tooling covers against 800-171 in our Microsoft stack mapping — the audit and integrity families are exactly what 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. Flip that. Tabletop the report: who drafts it, who approves it, what fields DIBNet wants — and can the person holding the Medium Assurance Certificate 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 fails quietly.

The before-the-incident checklist, in full:

• Medium Assurance Certificate obtained — issued, installed, and assigned to a named human, not a former employee's laptop.
• DIBNet account verified — someone has logged in recently and confirmed access works.
• IR plan names the reporter — a specific person drafts, a specific person approves, with backups for both.
• 90-day preservation storage identified — you know where forensic images and packet captures will live before you need the space.
• Prime notification path written down — contact, channel, and timing for every prime you sub to.
• Tabletop run this year — including the report itself, not just the containment story.

If you can't check every box today, that's the gap to close this quarter — not after the first incident grades your homework. A gap assessment will surface 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.