An incident evidence log your team can complete under pressure
Share
Published
An incident evidence log records what was observed, when it was observed and where the supporting material is held. It should help the response team separate a confirmed fact from a report, an assumption or an unanswered question.
Use this template during the 45-minute privacy tabletop or adapt it to the organisation’s approved incident process. A working log does not replace specialist forensic handling or the requirements that may apply to a particular investigation.
Give the incident one reference
Create a unique reference and name the incident lead and recorder. Use that reference in status updates and evidence locations. A shared label reduces the chance that a second team starts a conflicting record for the same event.
Record the time zone. A message timestamp, server log and staff account of events may otherwise appear inconsistent simply because they use different time settings.
| Field | What belongs there |
|---|---|
| Entry time and zone | When the log entry was made |
| Event time | When the reported activity occurred, if known |
| Source | Person, system or record providing the information |
| Observation | What the source actually shows or reports |
| Evidence reference | Controlled location of the original or relevant copy |
| Assessment | Interpretation, clearly marked as such |
| Action | What was authorised and done, by whom |
| Open question | What still needs verification and its owner |
Use precise wording
“The sender reports attaching dispatch-test.csv” is different from “the attachment contained every customer address.” The second statement needs an inspection or another reliable source.
Similarly, a recipient failing to reply is not proof that the file was opened, copied or misused. Record the absence of a response as a fact and keep the other possibilities as questions.
Preserve the source and limit copies
Follow the organisation’s approved evidence-handling process. Record where the original is held and who has access. Avoid repeatedly forwarding a sensitive file through group chats to demonstrate the problem.
If a screenshot supports an observation, check whether a smaller or redacted copy is sufficient for the people receiving the update. Preserve the controlled original where required. The PDF redaction guide explains why covering text visually may not remove the underlying information.
Record actions without rewriting the past
When an earlier assessment changes, add the new finding and explain what changed. Keep the sequence understandable. A reviewer should be able to see why a decision was reasonable on the information available at the time.
NIST’s incident-response guidance includes tracking incident status and relevant actions. The fields here are an original simplified log for that practical need.
Control who can see the log
An evidence log may itself contain personal information, security details and sensitive business decisions. Restrict access to the people who need it. Use a smaller approved status update for a broader audience.
The first-update template helps turn the log into a clear message without copying every technical detail. Do not include credentials, unnecessary identifiers or unverified allegations in that message.
What should happen after closure?
Record the closure decision, outstanding actions and evidence of the relevant fixes. Apply the organisation’s retention and access rules, including any required hold. Preserve enough context for a later review without leaving uncontrolled copies of the incident material on personal devices.
Featured image: AI-generated conceptual illustration.
