Cybersecurity & Information Security

How to Build a Timeline for a Cyber Incident Investigation

6 min readPublished: August 5, 2026

Professional visual illustration on building a Timeline for an incident investigation in the field of SOC and operations

Quick answer

An incident investigation timeline is a chronological table that unifies events from various sources to a consistent time, linking them via users, workstations, IP addresses, processes, and sessions. Proper construction includes preserving the original time, converting to UTC, noting source and reliability, identifying gaps, and distinguishing between fact, interpretation, and hypothesis.

A cyber incident almost never appears in a single log. The login is in the identity system, the process execution in EDR or Windows, the domain request in DNS, and the outbound connection in the Firewall. Each source describes a different part, in a different time format and with different identifiers. Without a Timeline, an investigator sees a collection of symptoms; with a Timeline, they can see a possible causal chain.

A timeline is not just about ordering by time. It is a process of normalization, linking, and reliability assessment. A clock that has drifted, an incorrect time zone, or an ingestion delay can reverse the order and lead to a wrong conclusion. NIST defines log management as a process that includes generation, transmission, storage, and access; each stage affects the ability to reconstruct an event.

In this article, we will build a Timeline from a scenario involving Windows, DNS, Firewall, and EDR. The examples are not product-dependent and can be implemented in a spreadsheet, SIEM, Notebook, or DFIR tool.

Why the Timeline is the Heart of the Investigation

A timeline answers questions that cannot be solved with a single event: What was the Initial Access, which process created the connection, did the login precede the execution, what happened after isolation, and did the same user act on other assets?

It also reveals gaps. If EDR shows file execution but there is no process creation event in Windows, it could be that Auditing is not enabled, the log was deleted, the event was filtered out, or time identifiers are not aligned. The gap itself is a finding.

In a complex investigation, it is advisable to maintain two timelines: a Master Timeline containing the central events, and a detailed Timeline for each asset or source. This keeps the report readable without losing data.

Time and Source Normalization

Always retain two fields: Original Timestamp as it appeared in the source, and Normalized Timestamp in UTC. Indicate the original time zone, known clock skew, and ingestion time in the SIEM. Do not overwrite the original time, as it is required for auditing and resolving contradictions.

Distinguish between event time and ingestion time. A Firewall may send a log late, an Agent may be offline and upload data later, and a cloud product may calculate detection after the event. Ordering by ingestion time alone can be inaccurate.

Check NTP synchronization, Daylight Saving settings, formats with/without Offset, milliseconds, and fields that contain creation time versus update time. When changing system time, document the deviation and do not try to “fix” it silently.

Linking Users, Hosts, IP, and Processes

Events from different sources are connected using Pivot Keys. Identity: UPN, SID, Object ID, Session ID. Workstation: hostname, Device ID, Agent ID, MAC address. Network: IP, NAT translation, port, protocol. Process: PID, Parent PID, Process GUID, hash, and command line.

PID alone is not a stable identifier over time because the operating system can recycle it. In Windows, Sysmon's Process GUID or a combination of Host + PID + time are more helpful. An internal IP address can move between workstations via DHCP, so it must be cross-referenced with a Lease or additional telemetry.

In each row, add an “Entity Link” field: why the event is related to the previous one. For example: “DNS query created by PID 4120, which is a child of powershell.exe from the previous line.” An explicit link prevents the reader from assuming an unproven connection.

Separating Fact, Interpretation, and Hypothesis

Fact: “At 10:14:22 EDR recorded powershell.exe with Parent winword.exe.” Interpretation: “The sequence aligns with the possibility of code execution from a document.” Hypothesis: “The user may have opened a Phishing file.” The distinction is critical so that the report does not present an assumption as if it were evidence.

You can add a Confidence column: high when several independent sources support; medium when one quality source supports; low when the data is partial or dependent on a hypothesis. The confidence level is not a binding mathematical score, but a way to communicate uncertainty.

MITRE ATT&CK can be added after understanding the event to describe techniques, but mapping should not be used to fill gaps. The mere existence of PowerShell does not prove Initial Access or Persistence.

Identifying Gaps and Contradictions

Look for time gaps, events that appear in only one source, addresses that do not match NAT, users in different formats, and contradictory results. A five-minute gap before the first connection could contain the most important action.

When two sources present different times, check Clock Skew, Time Zone, write time versus ingestion time, rounding, and cache. Keep both versions and indicate which one was used for ordering and why.

Build a “missing list”: Proxy logs were not saved, Process Creation was not enabled, the EDR was offline, or there is no access to Mailbox Audit. The list helps understand the limitations of the conclusion and improve Logging in the future.

Presenting the Timeline in a Report

A timeline in an executive report should only include events that change the understanding of the incident: initial access, execution, persistence, lateral movement, data access, containment, and recovery. A technical appendix can include the full records.

For each row, it is recommended to display: UTC, original time, source, entity, event, evidence/identifier, interpretation, and confidence level. Use consistent language and precise verbs: “created,” “blocked,” “failed,” “observed” — not “breached” without proof.

Attach a summarized Timeline also to the Ticket so that the next analyst can continue without reading all the notes.

Scenario: Windows, DNS, Firewall, and EDR

UTC	Source	Entity	Event	Link and Interpretation
08:41:03	Windows Security	WS-17 / user1	Successful interactive login	Start of session; verify source and Logon ID
08:43:18	EDR	WINWORD.EXE	Creation of powershell.exe	Process tree indicates execution from a document
08:43:20	EDR	powershell.exe	Encoded command line	Requires decoding in a safe environment and preserving source
08:43:22	DNS	WS-17	Query for new-example-domain.tld	Same Host, two seconds after execution
08:43:23	Firewall	10.0.4.17	TLS connection to external IP	IP matches DNS response; NAT verified
08:44:01	EDR	powershell.exe	File creation in Temp folder	Hash saved; not yet determined if malicious
08:47:55	Microsoft Sentinel	user1 / WS-17	Incident created	Detection time is later than event times
09:02:11	EDR	WS-17	Workstation isolation successful	Containment point; check connections afterward

Practical Checklist

I preserved original time and UTC time.
I distinguished between Event Time and Ingestion Time.
I documented source and identifying field.
I linked entities using reliable identifiers.
I separated fact from interpretation.
I noted gaps and contradictions.
I added Confidence.
I created a summarized Timeline and a detailed appendix.

Common Mistakes

Sorting by ingestion time only.
Converting time without preserving the original value.
Linking events based solely on dynamic IP.
Writing a hypothesis as if it were a fact.
Overloading thousands of events on a Master Timeline without filtering.

Summary and CTA

Take one lab scenario and manually build a Timeline from four sources. Then compare it to the investigation process in the first article and examine which fields should be added to the team's Playbook. In HPI's Cybersecurity & AI course, logging, networking, and SIEM skills are learned as part of practical incident investigation exercises.

FAQ

Should UTC always be used?

It is recommended to normalize to UTC to unify sources, but also to preserve the original time and Offset and display local time as needed for business purposes.

What to do when there is no clock synchronization?

Estimate Clock Skew using a common event or reliable source, document the difference, and preserve the original times. Do not alter evidence without documentation.

What tool is used to build a Timeline?

You can start with a spreadsheet or SIEM. For large investigations, DFIR tools or Notebooks are used. The tool is less important than the fields, normalization, and linking.

How many events should be included?

For the Master Timeline, essential events are included. All records are kept in an appendix or evidence repository.

Does a Timeline prove causality?

Not necessarily. Proximity in time strengthens the possibility of a link, but an identifier or additional evidence is required to determine that one process caused another.