Incident Response Incident Log · 72-Hour Clock · Chain of Custody

Incident Lifecycle and 72-Hour Reporting

Each incident record moves through defined phases: Detection, Analysis, Containment, Eradication, Recovery, and Closure. At each phase you document actions taken, personnel involved, systems affected, and evidence collected. The structured lifecycle ensures nothing is skipped between phases and creates the comprehensive incident record that supports both internal review and external reporting.

DFARS 252.204-7012 requires reporting cyber incidents to DoD via DIBNet within 72 hours of discovery. The module tracks the discovery timestamp, calculates the reporting deadline automatically, and records when the DIBNet submission was made and by whom. The 72-hour clock is visible on open incidents from the moment a record is created. removing any ambiguity about whether the reporting window has been met.

Dashboard Requirements Evidence POA&M Reports

Incident Log and History

The incident log maintains a complete history of all incidents. open, closed, and archived. Each closed incident record includes the full lifecycle documentation: what was detected, how it was analyzed, what containment actions were taken, what systems were affected, and how the incident was resolved. This history is the evidence that your IR capability is operational, not aspirational.

Assessors reviewing IR.L2-3.6.2 look for documentation that incidents were tracked and reported to designated officials. The incident log provides that documentation directly. a timestamped record of every incident, every response action, and every reporting event, stored on the appliance where no external access is required to produce it during an assessment.

What You See Inside

• *Incident record with detection timestamp, severity classification, affected systems, and initial description
• *Phase-by-phase lifecycle: Detection → Analysis → Containment → Eradication → Recovery → Closure
• *72-hour reporting clock. calculated from discovery timestamp, visible on all open incidents
• *DIBNet submission tracking. records submission date, submitting user, and report reference number
• *Personnel assignment. incident commander and responding personnel named per incident
• *Evidence attachment. artifacts collected during response linked directly to the incident record
• *Chain-of-custody log. every action on the incident record is timestamped and attributed to a named user
• *Closure documentation. root cause, lessons learned, and follow-on POA&M items if applicable
• *Full incident history exportable for assessor review or post-incident analysis

Incident Lifecycle Phases

What this replaces

• *An IR plan that exists as a document but has never been used to handle an actual or simulated incident
• *Email threads used as de facto incident tracking. no structured record, no timeline, no way to produce a complete incident report on demand
• *72-hour DFARS reporting deadline managed manually. discovery timestamp not formally recorded, deadline calculated informally, no submission record
• *No chain of custody on incident artifacts. evidence collected during response not formally linked to the incident record
• *No incident history to present to assessors. the organization has never had an incident, or if they have, no record exists to demonstrate how it was handled

Practices Satisfied

Related Modules