- An incident or exercise with an identifier assigned under the incident response plan (ATL-021)
- A designated scribe, named before the response gets busy
- Access to the alert consoles and logs from which facts will be cited
ATL-022RECORDEDITORIAL REVIEW COMPLETE
Incident Timeline Worksheet
A contemporaneous, timezone-consistent record of what happened, what was observed, and what was decided during an incident — the factual backbone for severity calls, containment choices, and the 72-hour reporting decision.
Using this artifact
Purpose, inputs, and completion
Purpose. Every consequential incident question — how bad, how fast, who knew what when — is answered from the timeline, or it is answered from memory under stress. This worksheet gives the scribe a disciplined format: timestamped entries, cited sources, actions with actors, and decisions with the context they were made in. It is the record the 72-hour reporting decision worksheet (ATL-023) draws its facts from.
When to use it. Open one timeline per incident the moment the incident response plan activates, name a scribe, and declare the timezone at the top. Entries go in as events happen; a gap in the record is more honest than a paragraph reconstructed later. When the incident closes, the timeline is reviewed at the close-out and filed with the incident record — it is the one document from the incident that gets read for years.
- Write entries as things happen, not at the end of the day — a contemporaneous line at 09:42 outweighs a reconstructed paragraph at midnight.
- Record facts and label interpretations: 'server unreachable' is a fact; 'we think it spread from the file server' is an interpretation and is marked as one.
- Keep one timeline per incident, declare one timezone at the top, and stamp every entry in it.
- Log decisions with their context — what was known at the time — because the 72-hour reporting decision (ATL-023) will be judged against exactly this record.
Keeping it honest
Evidence, validation, and failure modes
- A contemporaneous, timezone-consistent account of the incident
- The factual basis behind severity, containment, and reporting decisions
- An entry-by-entry record of who acted and who decided
- Pick any decision from the last incident or exercise and trace it to timeline entries showing what was known when it was made.
- Check five entries at random: each cites a source — an alert, a log, a named person — rather than unattributed memory.
What looks done but is not
- The timeline is reconstructed after the fact and presented as contemporaneous; the first discrepancy with log timestamps destroys its credibility entirely.
- Facts and guesses interleave unlabeled, so early wrong theories read later like established findings.
- Fragments accumulate in chat threads and notebooks, never merge, and the 72-hour decision gets made against whichever fragment was open.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain each incident's timeline with the incident record for as long as contracts, insurers, and counsel direct — years, not months; it is the primary account of what happened when.
Full document
Preview — exactly what prints
RECORD · INCIDENT RESPONSEv1.0 · REVIEWED 2026-08-06
Incident Timeline Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Every consequential incident question — how bad, how fast, who knew what when — is answered from the timeline, or it is answered from memory under stress. This worksheet gives the scribe a disciplined format: timestamped entries, cited sources, actions with actors, and decisions with the context they were made in. It is the record the 72-hour reporting decision worksheet (ATL-023) draws its facts from.
How to use it
Open one timeline per incident the moment the incident response plan activates, name a scribe, and declare the timezone at the top. Entries go in as events happen; a gap in the record is more honest than a paragraph reconstructed later. When the incident closes, the timeline is reviewed at the close-out and filed with the incident record — it is the one document from the incident that gets read for years.
How to keep the timeline
The four disciplines
- Contemporaneous entries
- Write it when it happens. A short entry now beats a polished one later; the timestamps are the value.
- Facts separated from interpretations
- State what was observed and its source. Mark theories as interpretations — early guesses are useful, but only when labeled.
- One timeline, one timezone
- A single document per incident, a single declared timezone, every entry stamped in it. Merging fragments after the fact loses order and credibility.
- Decisions carry their context
- Record what was known when each decision was made. Days later, the 72-hour reporting question is answered from these entries — not from what everyone knows by then.
Why this matters at hour 72
Reporting decisions under contract clauses turn on when the incident was discovered and what was known as facts developed. A contemporaneous timeline makes that account defensible; a reconstructed one invites the question of what else was reconstructed.
OT incidents: record the production state, never delay the safety action
When an incident touches production, the scribe also records production and safety state changes — line stopped, safe state reached, manual fallback engaged, vendor called — alongside the security entries, with the process owner as the cited source. Timeline-keeping never delays a safety action or a controlled shutdown: act first, write the entry immediately after, and note the actual action time.
Incident identification
Identification
| Incident identifier | Incident name | Timezone used for all entries | Scribe (named person) | Opened (date and time) |
|---|---|---|---|---|
Timeline
One row per event, observation, action, or decision. The source column is what separates a record from a recollection.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Timestamp (with timezone) | Event or observation | Source of the fact | Action taken | By whom | Decision context |
|---|---|---|---|---|---|
| EXAMPLE: 2026-08-06 09:42 EDT | Endpoint alert: credential-dumping tool blocked on ENG-07 | EDR console, alert #4821 | ENG-07 isolated via EDR | M. Okafor (MSP) | Contain first; severity SEV-2 pending analysis |
| EXAMPLE: 2026-08-06 10:15 EDT | ENG-07 user reports opening a phishing attachment around 08:50 | Interview with the user | Message searched for and pulled from all mailboxes | IT admin | Fact recorded; 'phishing was initial access' logged as interpretation, not finding |
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | Incident response lead |
| Approval authority | IT leader or incident response lead |
| Review frequency | Reviewed at every incident close-out, and exercised in at least one tabletop a year |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain each incident's timeline with the incident record for as long as contracts, insurers, and counsel direct — years, not months; it is the primary account of what happened when. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.