Overview
The timeline is the chronological account of an incident — a sequenced record of what happened and when, from initial compromise through detection and response, forming the factual backbone of the report.
Learning objectives
- Explain the purpose of an incident timeline.
- Describe how a timeline is constructed from evidence.
- Identify what makes a timeline accurate and useful.
Core concept
The timeline is an ordered, timestamped sequence of the incident's key events: when the attacker gained access, what they did and when (persistence, lateral movement, actions on objectives), when the activity was detected, and each response action (identification, containment, eradication, recovery) with its time. It is the report's factual backbone — the shared, chronological understanding that the analysis, impact, and root-cause sections all reference. Building an accurate timeline depends on the telemetry and logs from across the path (module 4 timestamps, SIEM, EDR process trees, network and auth logs) and on the evidence gathered during response. Because events come from many sources in different time zones/formats, normalized, consistent timestamps (module 4/5) are essential — a timeline is only as trustworthy as its time data. A good timeline lets any reader follow exactly how the incident unfolded and how quickly the SOC responded.
How it works
The SOC constructs the timeline by correlating events from all relevant telemetry and evidence into a single chronological sequence. From logs and EDR data it establishes: initial access (when and how), subsequent attacker actions (persistence, lateral movement, data access) each with timestamps, the moment of detection (which alert/hunt, when), and every response milestone (declared, contained, eradicated, recovered) with times. Crucially, all timestamps are normalized to a consistent time zone/format (module 5) so events from different sources line up correctly — a misaligned clock can make cause appear to follow effect. Each timeline entry is tied to its supporting evidence (the next lesson), so the sequence is verifiable, not asserted. The finished timeline also yields useful metrics — dwell time (access to detection) and response times — that inform lessons learned. Where gaps exist (missing telemetry), the timeline notes them honestly rather than guessing.
Practical example
For the intrusion, the SOC builds the timeline by correlating evidence: exploitation of the unpatched vulnerability at 02:47 (from the affected host's logs); scheduled-task persistence created at 03:01 (endpoint telemetry — the anomaly the hunt found); lateral movement to two more hosts between 03:10 and 03:40 (authentication and network logs); the connection to attacker infrastructure at 03:05 onward (network flow); detection via the threat hunt at 10:15; incident declared 10:40; all hosts contained (isolated) by 11:05; eradicated and recovered over the next two days. All timestamps are normalized to one time zone so the sequence is coherent. The timeline makes the dwell time (~7.5 hours from access to detection) explicit and ties each entry to its log/EDR evidence, giving every reader the same verifiable account of how the incident unfolded.
Cybersecurity relevance
The timeline is the factual foundation the rest of the report rests on: impact, root-cause, and lessons-learned analysis all reference the sequence of events, and metrics like dwell time and response speed come directly from it. Its accuracy depends on the logging and timestamp-normalization skills from earlier modules — a timeline with inconsistent time data can misrepresent cause and effect and undermine the whole investigation. By correlating multi-source telemetry into one verifiable, evidence-backed chronology, the timeline turns scattered logs into a clear story of the incident, essential for understanding, communication, and improvement.
Common mistakes
- Inconsistent or un-normalized timestamps, so events from different sources don't align and cause/effect is distorted.
- Asserting events without linking evidence, making the timeline unverifiable.
- Papering over gaps with guesses instead of noting where telemetry was missing.
Key takeaways
- The timeline is the chronological, timestamped account of the incident from initial access through detection and response.
- It is built by correlating multi-source telemetry and evidence, with normalized timestamps so events align correctly.
- Each entry ties to supporting evidence; the timeline yields metrics like dwell time and underpins the report's other sections.
Check your understanding
- Why are normalized, consistent timestamps essential to a trustworthy timeline?
- How is a timeline constructed, and why should each entry link to supporting evidence?