Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How to build an incident timeline
Updated
Build a defensible incident timeline in UTC: one row per event, source, evidence ID, and notes. Normalize timezones and clock skew before correlating logs. Mark first access, dwell, discovery, and containment as practitioner metrics, not SLAs. Cite evidence. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against NIST SP 800-61r2 (Computer Security Incident Handling Guide — guidance, not a statute; document a chronology of what happened and when), NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response — guidance, not a statute; correlate sources and record how timestamps were interpreted), the SANS Incident Handler's Handbook (practitioner PICERL checklist, not a standard), and SANS 'Mastering the Super Timeline With log2timeline' (Kristinn Gudjonsson, 2010 — a practitioner method for combining filesystem, log, and artifact timestamps, not a statute). This page does not rank DFIR firms, does not start a notification clock, and is not a substitute for counsel, your insurer, or a retained DFIR firm. The root-cause-analysis page on this site is the blameless RCA template. Not legal advice.
A chronology you can defend — this is not a statute
Audience: the incident commander keeping the log, the examiner correlating sources, and counsel who will later have to reconstruct what happened and when. The we've-been-breached page on this site is the first-moves hub. The first-15-minutes page on this site starts the contemporaneous UTC log. The first-hour page on this site turns that log into a timeline other people can use. The preserve-evidence page on this site is the capture list those rows must cite. The never-delete-after-breach page on this site is the do-not-destroy list that keeps the sources. This page is the method: how to write the timeline, how to put every timestamp into UTC, how to record clock skew, which markers (first access, dwell, discovery, containment) are practitioner metrics and not SLAs, and how every row cites evidence. It does not rank DFIR firms, does not name any, and does not start a notification clock.
NIST SP 800-61r2 is a guide to handling computer security incidents — guidance, not a statute. It asks responders to document a chronology: what was detected, what was done, who authorised it, and when. NIST SP 800-86 is a guide to integrating forensic techniques into incident response — guidance, not a statute. It treats examination as reconstructing what the evidence supports, including how timestamps from different sources were read. The SANS Incident Handler's Handbook treats contemporaneous notes as part of identification — a practitioner checklist, not a standard. SANS super-timeline teaching (the 2010 log2timeline paper; FOR508-class timeline analysis) is a method for combining filesystem, log, and artifact times so a single-source filesystem MAC timeline is not the whole story. Last verified 7 September 2026. Not legal advice.
- UTC on every row. Local time plus 'I think' is how two logs disagree. Keep the original timestamp and timezone on the row as well as the UTC conversion.
- One row per event. Detections, actions, decisions, and unknowns are events. Corrections are new rows, not silent edits.
- Cite evidence. A row without a source and an evidence ID is a recollection, not a timeline entry.
- Mark first access, discovery, and containment when the evidence supports them. Dwell and mean-time figures derived from those marks are practitioner metrics, not SLAs and not a regulator clock.
- This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
Timeline template
Copy the columns. Fill a row when something is observed, decided, or done — not when you have a complete story. Unknowns belong on the list. This product does not ship a downloadable template file; the table is the template. Last verified 7 September 2026. Not legal advice.
| Event | UTC time | Source | Evidence ID | Notes |
|---|---|---|---|---|
| What happened, in one clause (detection, action, decision, or unknown). Mark the row if it is first access, discovery, or containment. | ISO-8601 UTC (YYYY-MM-DDTHH:MM:SSZ). If the source was not UTC, convert here and keep the original in Notes. | The system, log, person, or ticket the event comes from (IdP, EDR, firewall, commander log, counsel email). | The chain-of-custody ID, hash, ticket, or export name that a later reader can pull. Empty ID means the row is recollection until you attach one. | Original timezone, observed clock skew, who recorded the row, limits (sampled flow, rotated log, estimated time). Corrections point at the earlier row; they do not overwrite it. |
Timezone and clock-skew normalization
Two logs that disagree by hours are often in different timezones. Two logs that disagree by seconds are often unsynchronised clocks. Normalize before you correlate, and write the conversion on the row so a later reader can undo it. NIST SP 800-86: document the method and the limit. SANS timeline analysis: a super timeline is only as honest as the timestamps you fed it. This is practitioner method, not a statute. Last verified 7 September 2026. Not legal advice.
- Record the original. Store the source timestamp as written (including offset or timezone name if the source has one) plus the UTC conversion. Do not overwrite the original with UTC.
- Name the zone. 'Evening' and 'PDT' and 'UTC-7' are different claims. DST transitions are how a local timestamp maps to two UTC instants or none. Write the zone the source was configured for, not the zone the analyst sits in.
- Measure clock skew. Compare the source to NTP or to a log you trust (IdP and cloud control-plane logs are often NTP-backed; a laptop often is not). Record skew as 'source ahead of NTP by Ns at collection' — a signed offset, not a vibe. Apply it as a noted adjustment; do not silently rewrite the source.
- Do not assume the SIEM already did this. Ingest pipelines translate, drop offsets, or store 'local' as naive UTC. The raw export is the evidence; the SIEM view is a rendering.
- A gap is a gap. If the source has no timezone, write 'timezone unknown — not converted.' A guessed zone is a new claim. NIST SP 800-86: the method and the limit go with the conclusion.
| Step | What you record | Limit |
|---|---|---|
| Original timestamp | The value the source stored, copied exactly, with its zone or offset if present. | A screenshot of a dashboard that already converted to the analyst's laptop zone is not the original. |
| Timezone | IANA name or offset the source was configured for (UTC, America/Los_Angeles, +0000). | Host local time without a zone is incomplete. DST around the window is a documented risk, not a silent assumption. |
| Clock skew | Signed offset versus NTP or a trusted log, measured at collection (e.g. host 6s ahead of NTP). | Skew drifts. A measurement at imaging time is not proof of skew on the day of the event. Write when you measured it. |
| UTC time (timeline column) | The converted instant used to sort rows. Notes hold original + zone + skew so the conversion is reversible. | Sorting mixed zones without conversion fabricates order. SANS super-timeline work exists because a single-source MAC times table is not the incident. |
First access, dwell, discovery, containment — practitioner metrics, not SLAs
Mark the rows the evidence supports. Derive dwell and mean-time figures from those marks. They are practitioner reconstruction metrics for investigators, counsel, and the post-incident write-up. They are not service-level agreements, not contractual targets, not a regulator clock, and not DORA software-delivery MTTR. Last verified 7 September 2026. Not legal advice.
| Marker / metric | From | To | What this page is not saying |
|---|---|---|---|
| First access | The earliest evidence of unauthorised presence or use (successful auth, execution, or control-plane action the incident is about). | A single UTC instant on a cited row. | Not 'when the vulnerability was introduced.' Not a finding first-seen date from a scanner. If the earliest evidence is later than actual entry, say so — the mark is first evidenced access, not first possible access. |
| Discovery | When YOUR organization first recognized the incident (alert, human report, or commander declaration — pick one definition and keep it). | A single UTC instant on a cited row. | Not when a vendor blogged it. Not when a scanner first listed a CVE. Write which definition you used. |
| Dwell time | First access (or first evidenced presence). | Discovery. | A practitioner interval, not an SLA, not a mean across the industry, and not a notification deadline. If either end is unknown, dwell is unknown. Do not invent an end so the interval looks complete. |
| Containment | Discovery (or the decision to contain, if that is later). | When isolation or equivalent control was in force for the scoped systems. | Isolation is not eradication. A contain-versus-observe decision to keep watching is not containment. Record the decision as its own row. |
| Time to contain | Discovery. | Containment in force. | Practitioner metric, not a contractual SLA and not a regulator 24/72/14-day ladder. Those ladders, when they apply, are counsel's statutes. |
| Time to recover (IR) | Containment or eradication start — pick one and keep it. | Service restored and believed clean. | Not DORA mean time to restore. DORA MTTR is a software-delivery metric for failed production changes at the org score. Do not mix the two. |
Worked example (fictional)
Fictional. Not a real incident, not customer data, not a named CVE, not an org on this product. The names, hosts, and times are invented so the columns are visible. Do not treat the intervals as typical. Last verified 7 September 2026. Not legal advice.
| Event | UTC time | Source | Evidence ID | Notes |
|---|---|---|---|---|
| First access (mark): IdP sign-in for j.reed@northpine.example from ASN not in the usual set, MFA succeeded. | 2026-08-12T03:11:22Z | IdP audit export (UTC) | EVD-0142-001 (sha256 on export) | Original timestamp already UTC. IdP clock NTP-backed; skew not measured. Access is not exfiltration. |
| VPN session opens to vpn-gw-01 for the same identity. | 2026-08-12T03:12:04Z | VPN concentrator session log | EVD-0142-002 | Source stored as UTC. Correlated to EVD-0142-001 by identity and 42s delta. |
| RDP to app-web-03 as local admin. | 2026-08-12T03:18:51Z | Windows Security log on app-web-03 | EVD-0142-003 (memory image + event-log export) | Original 2026-08-11 20:18:57 PDT. Host zone America/Los_Angeles (UTC-7 in August). Host 6s ahead of NTP at imaging (2026-08-19T16:40Z); UTC column subtracts 6s. Skew measured at imaging, not at the event. |
| Discovery (mark): EDR alert 'unusual RDP then scheduled-task create' paged the on-call; commander declared incident INC-FIC-0142. | 2026-08-19T14:02:00Z | EDR console + commander UTC log | EVD-0142-004 (EDR alert export), LOG-CMD-0142 | Discovery defined here as commander declaration, not the earlier unpaged alert noise. Dwell (first access → discovery) = 7 days 10 hours 50 minutes. Practitioner interval, not an SLA. |
| Containment (mark): app-web-03 and the IdP session isolated; VPN account disabled after export. | 2026-08-19T14:28:00Z | Commander UTC log + IdP admin audit | LOG-CMD-0142, EVD-0142-001 (same export, later rows) | Time to contain (discovery → containment) = 26 minutes. Isolation, not reimage. Preserve-evidence list still open for memory on app-web-03. |
Evidence-citation discipline
A timeline row is a claim about the world. The evidence ID is how a later reader checks it. NIST SP 800-86: the chain of custody tracks movement through collection, safeguarding, and analysis. The preserve-evidence page on this site is the field list. This page is the rule that the timeline points at that list. Last verified 7 September 2026. Not legal advice.
- Every row names a source and an evidence ID (hash, export name, ticket, or chain-of-custody ID). Recollection without an ID is labelled recollection.
- Do not cite a slide. Cite the export the slide was made from.
- When two sources disagree, keep both rows. The disagreement is the fact. Resolving it is a later analysis note, not a delete.
- When a source is missing (rotated, never collected, timezone unknown), write a row for the gap. Missing egress logs do not prove no theft; the was-data-stolen page on this site is that map.
- Counsel-directed collection is common practice so working papers can sit under attorney-client privilege and work-product. That is practice, not a ruling that privilege will attach.
Where this shows up in ShipReady Metrics
The signed-in app does not build a forensic incident timeline, does not normalize clock skew across log sources, and does not compute dwell time for an incident. Finding detail (signed-in app → Security → Findings → a finding) shows the three timestamps the feed keeps: first seen, last seen open, and resolved — not per-sync history, not first access, not discovery, not containment. Delivery Health at the org score reports DORA software-delivery metrics (deployment frequency, lead time for changes, change-failure rate, time to restore). Those are not incident dwell and not IR time-to-recover. The signed-in app keeps an append-only audit log of platform actions (login, connector, org-switch, and similar); that log is not a forensic incident timeline and does not ingest YOUR IdP, EDR, or firewall timestamps into one chronology. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a forensic timeline, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. None of those surfaces replaces the commander's UTC log.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012) this cluster cites for documenting a chronology of detections, actions, and decisions — guidance, not a statute, last verified still final on 7 September 2026. NIST SP 800-86 (August 2006), Guide to Integrating Forensic Techniques into Incident Response, remains the current final guide this page cites for examination that states what the evidence supports, correlating multiple sources, and documenting how timestamps were interpreted — guidance, not a statute. The SANS Incident Handler's Handbook (Patrick Kral) is a practitioner PICERL checklist, not a standard; this cluster cites it for contemporaneous notes as part of identification. SANS 'Mastering the Super Timeline With log2timeline' (Kristinn Gudjonsson, 25 August 2010) is a practitioner paper on combining filesystem, log, and artifact timestamps; it is not a statute and not a requirement to use that tool. SANS FOR508-class timeline analysis is training, not a regulator document. Dwell time and mean-time-to-contain as used here are practitioner reconstruction metrics, not SLAs and not DORA delivery metrics.
Frequently asked questions
How do you build an incident timeline?
Write one UTC row per event with the source, an evidence ID, and notes. Keep original timestamps and timezones on the row; convert to UTC in the time column. Record clock skew as a signed offset, do not silently rewrite the source. Mark first access, discovery, and containment when the evidence supports them. Corrections are new rows. NIST SP 800-61r2 and NIST SP 800-86 are guidance, not statutes. Not legal advice.
Why normalize timezones and clock skew before correlating logs?
Two sources in different zones will sort into the wrong order if you treat naive local time as UTC. Two sources whose clocks differ by seconds will fabricate sequence around a login-then-RDP pair. Record original time, zone, and skew versus NTP, then convert. SANS super-timeline work exists because a single-source filesystem times table misses log and artifact context. The conversion must be reversible. Not legal advice.
What is dwell time, and is it an SLA?
Dwell time on this page is the practitioner interval from first evidenced unauthorised access to discovery. Time to contain is discovery to containment-in-force. They are reconstruction metrics for investigators and counsel, not service-level agreements, not contractual targets, and not a GDPR or CRA clock. If either end is unknown, the interval is unknown. They are not DORA mean time to restore. Not legal advice.
Does ShipReady Metrics build a forensic incident timeline?
No. The signed-in app does not build a forensic incident timeline, does not normalize clock skew, and does not compute dwell time for an incident. Finding detail shows first-seen, last-seen-open, and resolved timestamps the feed keeps. Delivery Health at the org score reports DORA delivery metrics, not incident dwell. The platform audit log records signed-in actions. Compliance → CRA reporting is a ladder from recorded awareness, not a chronology of the breach. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from NIST SP 800-61r2, NIST SP 800-86, the SANS Incident Handler's Handbook, and SANS super-timeline practitioner writing. Whether a chronology is admissible, whether privilege attaches, whether a notification duty applies, and which firm to retain are questions for counsel on YOUR facts. This page does not rank DFIR firms and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.