How to write a security incident report that holds up

How-to Published 9 March 2026 · 7 min read

Most security incident reports are written badly, and it costs money. A vague report cannot support an insurance claim, cannot be forwarded to a client without editing, and falls apart if a solicitor reads it eighteen months later. The fix is not more writing — it is a consistent structure and a few habits.

The structure

Every report should answer six things, in this order:

1. When — exact date and time the incident occurred, not when it was written up.
2. Where — the site and the specific location within it. "North gate, pedestrian entrance", not "outside".
3. Who — the reporting officer, plus anyone involved or present, described factually.
4. What happened — a chronological account of what was observed.
5. What was done — the actions taken, in order, including who was contacted and at what time.
6. What is outstanding — anything requiring follow-up, and by whom.

Facts, not conclusions

This is the single biggest improvement available to most reports.

The pattern is the same each time: replace the conclusion with the observation that led to it. If the conclusion is right, the reader will reach it themselves — and the report survives being challenged.

Photographs: three, not one

Insurers and clients consistently ask for the same three shots, and officers consistently take only the middle one.

• Wide — shows where this is on the site, with a recognisable landmark in frame.
• Mid — shows what happened in context.
• Close — shows the detail: the damage, the mark, the item.

Take them on the app rather than on the camera roll. Photographs captured in the reporting app carry their own time and location metadata and are attached to the record, which removes any argument about whether the image is from this incident or an earlier one.

Time is evidence

A handwritten report is time-stamped by whoever wrote the time on it. A digital report submitted from a phone is time-stamped by the system, along with a GPS position. Those two facts turn a description into evidence.

This is also why "write it up at the end of shift" is a bad habit even when the words are identical. Report at the scene, and the time stamp does work for you that the prose cannot.

Log the boring things too

The daily occurrence book is not just for incidents. A delivery at an unusual hour, a door found unlocked, a contractor without a permit, a light out over the yard, a gate left open by a subcontractor — none of these are incidents on the night, and any of them can turn out to be the crucial entry six weeks later.

A digital occurrence log is searchable, which is what makes those entries worth making. Nobody has ever found anything useful by leafing through a hardback notebook.

What good looks like

Under two hundred words, entirely factual, chronological, with times and photographs. That report can be forwarded to the client unedited, supports a claim, and still makes sense in two years.

How to get your officers writing like this

• Give them a template, not a blank box. Structured fields produce structured reports.
• Use incident types so the right questions are asked for the right kind of event.
• Make it fast. If filing takes five minutes, it gets done at the scene. If it takes fifteen, it gets done from memory or not at all.
• Feed back. Show officers a report that was used successfully — to win an argument with a client, or to support a claim. It changes how the next one is written.

See how incident reporting works in SMS-Patrol, or book a demo and we will show you a real report end to end.