Cybersecurity Engineering Handbook / Chapter 65

Incident Timeline Template

Build an incident timeline that preserves events, observations, evidence, uncertainty, actions, and the reasons behind changing decisions.

Book contents

Audio edition 7:36 narrated chapter

Continuous listening Opus

0:00 7:36

Playback speed

Preparing audio…

All three do. They answer different questions: when the system behaved incorrectly, when the organization learned of it, and when the evidence changed the response. Collapse them into one timestamp and a later reader may conclude that responders waited nine minutes to act, or that they knew at 09:09 what was only established at 09:16.

An incident timeline is therefore more than a transcript. It is the durable account of changing system state and changing human knowledge. It should allow a responder joining late to see what is known, what remains uncertain, which actions changed the system, and why an authorized decision made sense at the time.

Incident timeline evidence ledger showing detected, triaged, contained, eradicated, recovered, and reviewed stages, each with fact, evidence, and open question fields, plus a reminder to separate facts from hypotheses. — A timeline protects incident quality by preserving facts, evidence, and open questions at each phase instead of letting memory and assumptions overwrite the record.

Keep one chronology without pretending there is one clock

Use the timeline for suspected or confirmed security incidents, active exploitation, credential compromise, data exposure, abuse, malware, supply-chain compromise, insider misuse, and exercises that rehearse the same decisions. Assign a scribe or commander delegate early. The record should be visible to the response team, but its access and contents must match the sensitivity of the incident.

For each entry, distinguish three times when they differ:

event time: when the activity occurred in the source system;
observation time: when a person or control surfaced it to the response;
record time: when the entry was added or corrected.

Use UTC unless the response plan specifies another common time base. Preserve the source timestamp, timezone or offset, known clock error, ingestion delay, and query window with the evidence. A neat sequence built from incomparable clocks is not a reliable chronology.

The response bridge carries conversation. The timeline carries durable state. The evidence repository holds original or defensible copies of artifacts. Link the three, but do not paste secrets, personal data, malware, tokens, or restricted evidence into a broadly visible record.

The working record

This form keeps the current operating picture near the chronology. Repeat the entry block for each material observation, hypothesis, decision, or action. Links should identify preserved artifacts or immutable snapshots rather than a mutable dashboard view alone.

# Incident Timeline: <incident ID and short name>

## Identity and command
- Incident ID, severity, status, and declaration time:
- Incident commander and alternate:
- Technical lead, scribe, and evidence owner:
- Communications lead and legal/privacy contact, if required:
- Systems, environments, tenants, identities, and data in scope:
- Current operating objective:
- Timeline access classification and evidence repository:
- Source-of-truth time base and known clock limitations:

## Current operating picture
### Confirmed facts
- <fact> — evidence <reference>; confidence and boundary <statement>

### Live hypotheses
- <hypothesis> — supports <evidence>; conflicts <evidence>; owner <person>;
  next test <action>; state open | weakened | superseded

### Impact
- Confirmed customer, data, identity, service, safety, financial, legal,
  regulatory, or contractual impact:
- Plausible but unconfirmed impact:
- Unexamined scope and evidence needed:

### Active decisions and actions
- Decision or action; authority or owner; state; deadline; reversal or stop
  condition; evidence expected:

## Chronology
### <entry ID>: <type — fact | hypothesis | decision | action | impact | communication>
- Event time, if known:
- Observation time:
- Record time and recorder:
- Actor or source:
- Statement:
- Evidence reference and preservation state:
- Confidence, limits, or conflicting evidence:
- Consequence for severity, scope, containment, recovery, or communication:
- Owner and next question, action, or review time:
- Correction or superseding entry, if any:

## Containment, eradication, and recovery
### <work item>
- Phase and objective:
- Owner, authority, start time, and state:
- System change made or proposed:
- Evidence at risk and preservation decision:
- Expected result, stop condition, and actual result:
- Validation evidence and completion time:

## Communications
### <audience and update ID>
- Sent time, owner, reviewer, and audience:
- Facts and bounded impact communicated:
- Uncertainty deliberately retained:
- Message or approved-record reference:
- Next update commitment:

## Handoff and closeout
- Current objective, severity, and commander:
- Confirmed facts, live hypotheses, and urgent open questions:
- Active containment or recovery actions and stop conditions:
- Evidence gaps, source-health concerns, and expiring retention:
- Next decisions, owners, and deadlines:
- Follow-up control work, verification, owner, and due date:
- Closure authority, evidence, residual risk, and time:

Give every entry a claim it can support

A fact reports an observation and its source. “Audit event A-88912 records role billing-admin assumed by subject user-481 at 02:14 UTC” is a fact; “the attacker logged in” adds an identity and intent the event may not prove.

A hypothesis is a testable explanation. Name the evidence for and against it, its owner, and the next test. If it influenced the response and later failed, do not delete it. Mark it superseded and link the evidence that changed the team’s understanding.

A decision names the authority, facts relied upon, uncertainty accepted, options rejected, expected reduction in harm, and reversal condition. “Remain at severity 2” says almost nothing. “The commander retains severity 2 because cross-tenant execution remains plausible; downgrade after complete archive and object-access queries exclude it” preserves a reviewable judgment.

An action records a change to the world: a session revoked, queue paused, workload isolated, image preserved, customer update sent, or service restored. Name the owner, start and completion times, result, and evidence. An assigned action is not a completed action, and a command issued is not proof that the system changed.

An impact statement bounds a conclusion. State what population, data, service, identity, or period was examined; which evidence supports the claim; what remains outside the query; and the confidence justified now. “No evidence of export in the searched worker and object-access records from 08:45–09:20 UTC” is honest. “No data was exposed” may not be.

Corrections should be additive. Link the mistaken entry to the correction and retain who changed it and why. Silent rewriting makes the final story cleaner by destroying the record of what responders actually knew.

Follow a failed probe through changing knowledge

Suppose the duplicate-job probe from the preceding release review is accepted instead of rejected. The identifiers and times below are illustrative. Notice that the timeline does not wait for certainty before recording action, and it does not let early language harden into a conclusion.

### TL-001: fact
- Event time: 2026-07-18 09:07:11 UTC, production API clock
- Observation time: 09:09:03 UTC; record time: 09:10:18 UTC by the scribe
- Actor or source: alert DET-JOB-REPLAY-004
- Statement: duplicate probe job `canary-184-2` returned an accepted decision;
  the release stop threshold requires rejection before data read.
- Evidence: preserved alert `AL-551` and API audit event `API-9011`.
- Limit: worker execution and customer-data access are not yet known.
- Consequence: stop condition met; pause export creation and consumption.
- Owner and next action: Export SRE to pause both paths and attach control-plane
  evidence; incident commander review at 09:15.

### TL-002: action
- Event time: 09:11:02–09:11:39 UTC; observed and recorded by 09:12:10 UTC
- Actor: Export SRE
- Statement: export creation and worker consumption paused for all tenants.
- Evidence: configuration revisions `CFG-190` and `QUEUE-77`; negative health
  probe `HP-412`. No queued work was discarded.
- Result: new export work is blocked; in-flight execution remains under review.
- Next action: preserve the accepted envelope, worker events, replay store, and
  object-access records before changing worker state.

### TL-003: hypothesis
- Observation time: 09:12:44 UTC; record time: 09:13:20 UTC
- Statement: worker revision 184 may fail to make the replay-store write
  durable before acknowledging the first delivery, allowing a duplicate.
- Supports: API accepted the duplicate job ID. Conflicts: no worker execution
  event has yet arrived; worker telemetry is delayed by about seven minutes.
- Owner and test: Runtime lead will compare preserved acknowledgements, replay
  records, and worker traces. State: open.

### TL-004: decision
- Decision time: 09:14:07 UTC; record time: 09:15:01 UTC
- Authority: incident commander
- Statement: declare severity 2 and keep exports paused. Preserve the two
  affected workers for a bounded ten-minute collection before termination.
- Facts used: duplicate accepted; customer-data access unconfirmed; queue and
  API paused; worker telemetry delayed. Continuing risk is bounded by the pause.
- Rejected option: immediate worker termination, because it would remove
  volatile state while current controls prevent new work.
- Reversal condition: terminate immediately on evidence of continuing access;
  reconsider severity after object and archive access are bounded.

### TL-005: fact
- Event time: 09:07:12 UTC, worker clock; observation time: 09:16:31 UTC;
  record time: 09:17:09 UTC
- Source: preserved worker trace `WT-184-992`
- Statement: the worker rejected `canary-184-2` as a duplicate before source
  data read. The API response reported an intermediate admission decision,
  not the final worker decision.
- Evidence: trace joined to the same tenant, export record, and job ID; object
  access query `OBJ-331` has no matching read.
- Limit: `OBJ-331` covers the canary tenant only; ordinary jobs in the release
  window remain under review.
- Consequence: TL-003 is weakened, but the misleading API decision and failed
  stop-condition contract remain release incidents.

### TL-006: hypothesis update
- Observation and record time: 09:20:12 UTC
- Statement: TL-003 superseded. Evidence does not show a replay-store failure.
  Current hypothesis: the canary evaluator treated API admission as completed
  execution and emitted the wrong result.
- Owner and test: Release owner will replay the evaluator against preserved API
  and worker decisions; Detection Engineering will inspect alert semantics.

### TL-007: impact update
- Observation time: 09:27:40 UTC; record time: 09:29:02 UTC
- Statement: no duplicate worker execution, archive creation, or object read is
  present for any job admitted between 09:00 and the 09:11 pause.
- Evidence: immutable query exports `JOB-201`, `OBJ-332`, and `ARCH-91`, joined
  by job ID and tenant; source health and ingestion watermark verified through
  09:20 UTC.
- Limit: the claim covers the named production region and interval. Network
  egress corroboration is pending and is not required to establish whether a
  worker read source data.
- Consequence: commander may reduce customer-data impact confidence from
  plausible to not observed within the bounded scope; service outage continues.

### TL-008: recovery decision
- Decision time: 09:41:16 UTC; recorded at 09:42:03 UTC
- Authority: incident commander and release owner
- Statement: enable export workers and then export creation after the corrected
  evaluator proves final worker decisions, duplicate rejection, alert routing,
  and the same no-data canary in production.
- Evidence required: evaluator test `EVAL-19`, negative probe `CANARY-185`,
  route acknowledgement `AL-558`, and joined production trace `TRACE-185`.
- Stop condition: any accepted duplicate, missing join identifier, source-data
  read, or absent alert acknowledgement restores the pause.
- Residual work: review why an intermediate state could satisfy the release
  probe; owner Release Engineering, due 2026-07-25.

At 09:14, keeping the workers briefly available for collection was reasonable because the pause bounded new work and the record still showed a possible execution defect. The 09:17 trace changes the hypothesis; it does not make the earlier decision foolish. A useful timeline preserves both truths.

Let the record govern handoff and recovery

At a handoff, the incoming responder should not have to replay the bridge. Read back the current objective, confirmed impact, live hypotheses, containment state, expiring evidence, next decision, and every action whose owner or stop condition is changing. Record acceptance of command and any disputed point.

Track communications as decisions made for distinct audiences. Preserve the facts and uncertainty approved for each message, its reviewer, send time, and next-update promise. Do not copy speculative internal discussion into a customer update, and do not let a concise executive message replace the technical record from which it was derived.

Recovery deserves the same precision as containment. Record the trusted state being restored, the validation that permits it, who may authorize the change, and the signal that will stop it. Close the timeline only when containment, eradication, recovery, impact, communications, evidence gaps, and follow-up work have explicit owners and dispositions. Silence from the alert is not evidence of recovery.

Before closeout, give the record to a responder who was absent. They should be able to reconstruct when the system changed, when the team learned, what was believed at each decision, which evidence corrected the story, what harm was bounded, and why recovery was authorized. Any answer that still lives only in chat belongs in the timeline before the incident closes.

Find what you need.