72-HourDoDIncidentReporting:FromTabletoptoRegulatorySubmission

The 72-hour DoD cyber incident reporting clock under DFARS 252.204-7012 is not a regulatory abstraction. It is an operational constraint that sits between your security operations team, your general counsel, and a government regulator that has enforcement tools. The clock starts at discovery and does not stop for committee meetings. Organizations that have not rehearsed the workflow invariably miss the deadline on their first real incident.

This runbook is the workflow Techvera's incident response team uses with DIB clients, expressed as the tabletop exercise that surfaces where your current plan breaks.

The clause in operational terms

DFARS 252.204-7012(c) defines a cyber incident as "actions taken through the use of computer networks that result in a compromise or an actual or potentially adverse effect on an information system and/or the information residing therein." It is a broad definition. The reporting obligation triggers when the incident affects:

• Covered defense information (CDI) on the contractor information system
• The contractor's ability to provide operationally critical support

The contractor must "rapidly report" within 72 hours of discovery via the DoD DIBNet portal using a medium assurance certificate. The report must include specific fields; a partial report that misses required fields is not a valid report.

The clock-start problem

The most contentious question in any incident is when the 72-hour clock starts. The clause says "discovery." Operational reality is messier:

• A SOC analyst sees an alert at 02:14. Clock start?
• The analyst escalates to tier 2 at 04:30 with a preliminary assessment. Clock start?
• The security director is notified at 09:00 and treats it as a probable incident. Clock start?
• The IR team completes initial triage at 17:00 and confirms CUI may be affected. Clock start?

The correct answer is the earliest point at which a reasonably trained person should have understood that covered information might be affected. In most enforcement cases, that point is significantly earlier than the contractor's internal "confirmed incident" declaration. Plan for the clock to start at initial escalation with a plausible CUI hypothesis, not at formal incident declaration.

The runbook

Phase 1: Hours 0-4 — detection and preliminary triage

• Detection (SOC alert, user report, threat intel, vendor notification)
• Initial triage by SOC analyst; classification as incident / event / false positive
• Escalation to IR lead if incident and any potential CUI nexus
• IR lead begins clock-tracking log with defensible start time
• Initial scope hypothesis: which systems, which users, which data categories
• Notification to security director, CIO, and internal counsel

Deliverable by hour 4: initial incident declaration with preliminary scope and clock-start timestamp recorded.

Phase 2: Hours 4-24 — containment and scope confirmation

• Containment actions: isolate affected hosts, revoke credentials, block indicators
• Forensic preservation begins: affected system images, memory captures, log exports
• Scope refinement: which CDI systems were reachable, which were actually touched, which are still unknown
• External IR firm engaged if internal capacity is insufficient (most tier-2 contractors engage within 8 hours)
• CDI impact assessment: which categories of CUI, which contracts, which government program offices
• Initial legal review by internal counsel; determination of 7012 applicability
• Draft DIBNet report begins

Deliverable by hour 24: containment complete or in progress; scope of CDI impact characterized with defensible confidence; draft DIBNet report prepared.

Phase 3: Hours 24-72 — submission and continued response

• Final review of DIBNet report by security leadership and counsel
• Medium assurance certificate (PKI) retrieved and validated - this is the #1 operational failure point
• DIBNet submission via the portal
• Copy of submission preserved in incident record
• Internal stakeholders notified of submission: contracting officer notification per contract terms, leadership, board notification if material
• Response operations continue: eradication, recovery, lessons learned

Deliverable by hour 72: DIBNet report submitted with confirmation; incident response continues beyond this milestone until resolved.

Phase 4: Post-submission (days 3-90)

• Preservation of affected system images for 90 days per 7012(d)
• Response to any DoD follow-up questions or damage assessment requests
• Supplemental reports if scope changes materially
• Coordination with DC3/DCSA if invoked
• Internal lessons learned; update to IR playbook

The tabletop

The only way to know if the runbook works is to execute it under pressure. A credible DFARS tabletop:

• Involves the SOC, IR team, security director, CIO, general counsel, CFO, contracts administrator, FSO, and a senior executive
• Uses a realistic injected scenario: a known-good malware family hitting an engineering workstation during non-business hours, with plausible lateral movement to a file server holding technical drawings
• Runs on a compressed but realistic timeline (compressing 72 hours into 3-4 hours of tabletop with explicit time-jumps)
• Includes at least one curveball: the medium assurance certificate has expired, the SOC analyst who first detected is on vacation, or the DIBNet portal is slow
• Produces a written after-action report identifying every delay, gap, or decision point that failed

The first tabletop almost always fails the 72-hour deadline. Common failure points observed across tabletops:

• Medium assurance certificate not retrievable or expired (60%+ of first tabletops)
• Legal review consumes 12+ hours because counsel has never reviewed a DIBNet report before
• Clock-start timestamp not captured at detection, leading to confusion about deadline
• Scope of CUI impact unclear because data flow diagrams are absent or stale
• Internal approval chain for submission requires a C-suite signature that cannot be obtained during the window

The tabletop exists to surface these failures before the live incident. Every one of them is cheap to fix before, expensive to fix during.

Reporting content: required fields

The DIBNet report requires specific fields. Prepare a template with these fields and pre-filled organizational data:

• Contractor name, DUNS/UEI, CAGE code
• Contract number(s) affected
• Contracting officer name and contact
• Reporter name, role, contact
• Affected system identification (system name, OS, role, location)
• Date and time of incident discovery
• Date and time of incident occurrence (if known)
• Description of the incident (factual, no speculation)
• Impacted covered defense information (categories, approximate volume)
• Remediation actions taken to date
• Anticipated next steps

Operational posture

Operationalizing 7012 reporting requires:

• Named IR lead with authority to declare incidents and start the clock
• Standing medium assurance certificate held by an identified individual (and a backup)
• Pre-built DIBNet report template with pre-filled organizational data
• Legal review workflow that can execute in under 8 hours
• Data flow diagrams current enough to support scope determination within the 24-hour mark
• Quarterly tabletop exercises with structured after-action reports

Techvera runs DFARS 7012 tabletops and operational readiness programs for DIB contractors. See our government and defense practice or schedule an IR readiness session to stress-test your current runbook.