Turn a messy incident into a clear, filed record
When something goes wrong — an injury, a breach, an outage — the report written afterwards is what drives the fix, satisfies compliance and protects everyone involved. A vague write-up does none of that. This builder gives you a consistent structure that captures the facts, the sequence and the cause every time.
How it works
You record the reporter, incident type, severity, date/time and location, then describe the event: a summary, the affected parties or systems, an ordered timeline (one event per line), the root cause, the immediate actions you took, and the preventive measures going forward. The tool stamps the report date automatically and assembles a numbered document with each list cleanly formatted, plus a status line and signature block ready to file.
Tips and example
A strong timeline reads like a flight recorder: “14:30 — alert fired”, “14:35 — on-call engaged”, “15:10 — service restored”. For the root cause, push past the first answer — if the server ran out of memory, ask why, until you reach the change or gap that actually let it happen.
- Stick to facts and times; keep blame out of the report — focus on the system and process.
- Give every preventive measure an owner and a due date, or it won’t happen.
- For serious incidents, file the report quickly while memories are fresh and evidence exists.
Why report structure matters
An incident that leaves no paper trail is one that repeats. The structure this tool generates — summary, timeline, root cause, actions taken, preventive measures — follows the format used by most occupational health and safety regulators and ISO 45001 management systems. A consistent structure means any reviewer can scan the report quickly, compare it against past incidents, and track whether corrective actions were actually closed out.
The five sections and how to fill them
Summary. Write two or three sentences that describe what happened and when, from an outsider’s perspective. Assume the reader knows nothing: “At 14:28 on Tuesday, a gas leak was detected in the east wing. The building was evacuated and emergency services were called. No injuries were sustained.”
Affected parties. Name every person, team, system, or customer segment that experienced impact. For a data incident this might be a user segment or a specific database. For a workplace injury, it is the individual(s) involved plus any witnesses. Being explicit here determines who must be notified and who has standing to review the report.
Timeline. Use one-line entries: 14:28 — Sensor alarm fired, 14:33 — Facilities team notified, 14:40 — Building evacuated. The discipline of being specific about times forces precision about the sequence of events and often surfaces gaps in the response that become learning opportunities.
Root cause. Use the 5-Why technique to dig past the surface: the server ran out of disk (Why?) because a log rotation job failed (Why?) because the cron entry was deleted during a configuration change (Why?) because there was no change-management review gate. That third-level answer is the real root cause and points to a process fix, not just a cleanup task.
Preventive measures. Every item needs three things: a clear action, a named owner, and a target date. “Improve monitoring” is not a measure. “Add disk-usage alert at 80% — Platform team — by 2024-07-01” is.
Severity levels
| Level | Typical definition | Review required |
|---|---|---|
| Low | Minimal impact, contained quickly | Logged and noted |
| Medium | Noticeable disruption, corrective action needed | Team lead review |
| High | Significant impact on people or systems | Management and formal follow-up |
| Critical | Major injury, breach, or prolonged outage | Executive escalation and regulatory notification |
Severity drives how quickly the report must be filed, who reviews it, and whether external notification (regulator, insurer, data protection authority) is required.