---
{
  "title": "Incident timelines",
  "summary": "Reconstruct events without treating proximity as proof of causation.",
  "topic": "forensics",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Integrating Forensic Techniques into Incident Response",
      "url": "https://csrc.nist.gov/pubs/sp/800/86/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

A timeline orders relevant events with evidence references and a common time basis. Preserve original timestamps and document conversions, clock differences, and uncertainty. Identify whether each record reflects an action, observation, or ingestion time. Distinguish directly confirmed events from inferred relationships. A good timeline helps identify gaps and guide further collection rather than presenting a polished but unsupported story.

## In practice

An account sign-in, mailbox change, and file download are placed in UTC with source IDs. The analyst notes that one system’s time is estimated because its clock drift is unknown.

## A common misunderstanding

Events close together are not necessarily caused by the same actor, and the first observed event may not be the first actual event.

## Check your understanding

What makes a timeline useful for another investigator?

**Think it through:** Traceable evidence, explicit time handling, clear confidence, and documented gaps.


## Normalize time without erasing uncertainty

A timeline brings events from different sources into a common view. Record the original timestamp, its timezone or offset, the source, and any normalization performed. A device clock may be wrong or corrected during the incident, while an application may record processing time rather than the moment a user initiated an action. Apparent precision is not the same as accuracy.

Separate observed facts from interpretation. A login followed by file access may support a hypothesis, but sequence alone does not prove that a particular person performed both actions. Shared accounts, background processes, delayed logging, and missing events can change the explanation. Preserve the link from each timeline entry back to the original evidence.

## A fictional cross-system sequence

An academy investigates an unusual account session and a later data export. Identity logs use UTC, application logs use local time, and a workstation clock is several minutes slow. The analyst records those differences before ordering events. Without normalization, the export could appear to precede the login that enabled it.

The resulting timeline includes confidence and gaps. It distinguishes an event's recorded time from the analyst's inferred interval where exact timing is uncertain. New evidence may revise the sequence, so keep a reproducible method rather than manually editing an attractive chart with no trace of its inputs.

## Reconcile three clocks

Create three fictional events with different timezones and one known clock offset. Convert them to a common basis while retaining the originals. Then add a delayed log entry and explain why its storage time may differ from the event time. Write a short narrative that uses cautious language where the ordering is uncertain. A useful timeline makes uncertainty visible instead of hiding it behind a neat horizontal line.

## Keep exploring

- [[network-time]]
- [[log-correlation]]
- [[forensic-reporting]]