What should you document during a cybersecurity incident?

Why it matters

During an incident, documentation is not administration — it is the shared version of the truth that legal counsel, insurers, technical responders, regulators, and leadership will all rely on. Reconstructing it afterwards from memory and message threads is slow, expensive, and frequently incomplete.

This guidance is general and educational. It is not legal advice. Involve legal counsel early; they may direct that certain records be created under privilege, and their instructions take precedence over anything here.

What to document

1. Chronology

A single running timeline: what happened, when it happened, when it was detected, when it was learned, and the source of each entry. Distinguish the time an event occurred from the time you found out about it. Use one time zone, stated explicitly, for every entry.

2. Decision log

• The decision made and the options considered.
• Who made it and who was consulted.
• What information was available at the time.
• The time it was made and when it took effect.

3. Action log

Every change made to any system during response: isolation, account changes, credential resets, blocks, restores, patches, and configuration changes — with who performed them and when. This is what allows you to separate attacker activity from responder activity later.

4. Evidence and custody

What was collected, by whom, when, from which system, how it was stored, and who has accessed it since. Where regulated or litigable matters may be involved, qualified forensic practitioners should direct collection.

5. Notifications

Who was notified and when: legal counsel, insurer or broker, executive leadership, board, regulators, affected customers, partners, and law enforcement where applicable. Notification timing frequently carries legal and contractual consequence.

6. Communications

Retain copies of internal and external statements issued, with approval trail. Inconsistent statements create their own problems.

What not to do

• Do not speculate in the written record. Label uncertainty as uncertainty.
• Do not maintain the record only in a chat channel that can be edited or lost.
• Do not keep the incident record exclusively on systems that may be affected.
• Do not delete or edit earlier entries; append corrections instead.
• Do not attribute the incident to a named individual or party in early documentation.

Questions to ask

• Who is the single scribe, and who covers when they are off shift?
• Where does the record live, and is that location trustworthy right now?
• Has counsel given direction on privilege and record-keeping?
• Can we state the current facts, the current assumptions, and the current unknowns separately?

When internal teams can handle it

Organizations with a practiced incident process, a defined scribe role, and counsel engaged early can maintain this internally.

When outside help may be appropriate

When several vendors and internal teams are working in parallel, when leadership needs a single authoritative account, or when the internal team is fully occupied with technical containment and has no capacity to maintain the record.