From the SIIRF library
The Incident Log
A simple, consistent record of every incident and near-miss, so nothing is forgotten and every incident teaches you something.
Why keep a log
- During an incident, it keeps a reliable record of what happened and what was done, when.
- Afterwards, it supports reviews, reports to funders or regulators, and any legal action.
- Over time, it shows patterns, such as the same kind of phishing getting through, so you know where to invest.
The template opens in any spreadsheet app.
What to record
| Field | What to write |
|---|---|
| Incident ID | A simple reference, such as the year and a number. |
| Date and time noticed | When it was first noticed, and when it may have started. |
| Reported by | Who reported it, and how. |
| How it was noticed | An alert, a suspicious message, a complaint, a missing device. |
| Incident type | Phishing, account takeover, lost device, malware, data breach, harassment and so on. |
| Accounts or devices affected | Which systems, accounts and devices were involved. |
| People or data affected | Whose data or safety may be at risk, and roughly how many people. |
| Severity | Low, medium, high or critical, using your plan's definitions. |
| Actions taken | Each action, with the time and who did it. |
| Escalated to | Who was informed or brought in, and when. |
| Regulator notified | Whether a report was required and made, and the date. |
| Status | Open, contained or closed. |
| Root cause | How it happened, once known. |
| Lessons learned | What you'll change as a result. |
Keeping the log safe
- The log can contain sensitive details, so store it somewhere encrypted with access limited to the response team.
- Record facts, not blame. Write what happened, not who was careless.
- Keep a copy you can reach if your main systems are down.
- Review it every few months to spot patterns.