Knowledge Base

Building an Incident Timeline

Reconstruct sequence and uncertainty without presenting imperfect logs as an exact story.

Why timelines matter

A timeline makes event order, confidence, gaps, and decisions reviewable. It can connect identity, endpoint, network, application, cloud, and vendor events, but it rarely proves every event occurred exactly when a log says it did. Event time, ingestion time, first observed time, and first occurred time are different fields.

Timeline entry template

  • Normalized timestamp and original timestamp, including time zone.
  • Source system, event identifier, entity, and collector or ingestion time.
  • Observed fact, confidence label, supporting artifact, and analyst note.
  • Known gap, alternative explanation, and next pivot or owner request.

Construction workflow

  1. Preserve source timestamps before normalizing them to a shared zone such as UTC.
  2. Record clock drift, delayed ingestion, batching, and missing retention where known.
  3. Place high-confidence facts first, then attach hypotheses and lower-confidence correlations separately.
  4. Pivot by identity, host, IP, process, application, and time window; expand only when an evidence link supports it.
  5. Mark gaps explicitly. A gap can be a retention limit, inaccessible system, clock mismatch, or unreviewed data source.

Fictional example

A cloud sign-in is observed at 09:05 UTC, an endpoint event is written at 09:03 local time, and SIEM ingestion occurs at 09:11 UTC. The timeline records the separate clocks and does not assume the endpoint action preceded the sign-in until time-zone and drift checks are complete.

Common errors

Do not sort by ingestion time alone, silently convert time zones, merge similarly named accounts, or treat first observed as first occurred. A plausible sequence is still a hypothesis until source timestamps and evidence support it.