A useful security incident report lets someone who was not at the scene understand what happened, what the officer observed, what action was taken and what still needs attention. It should preserve evidence and uncertainty, not turn either into a confident story.
The strongest reports are chronological, specific and easy to review. They separate direct observation from what another person said, identify the people and locations involved, and make every operational handoff visible.
Start with the facts another reviewer needs
Record the date, time and precise location first. Identify the reporting officer and the people involved using the organisation's approved identifiers. State the incident type and immediate risk without trying to diagnose motives or assign blame.
Use exact descriptions where they are useful. “A broken lower hinge on the east loading-bay gate” is actionable; “the gate was bad” is not. If a time is approximate, label it as approximate rather than silently presenting it as exact.
- Who was involved, present or notified
- What the officer directly saw, heard or received
- When each important event and response occurred
- Where the incident occurred, including the area within the site
- What action was taken and by whom
- What evidence exists and where it is attached
Write in chronological order
A timeline is easier to verify than a narrative that jumps between causes, reactions and outcomes. Begin with how the officer became aware of the event, then record observations and actions in sequence. End with the condition of the scene and any open follow-up at handover.
When two events happened at the same time, say so. When the order is uncertain, do not invent precision. A reviewer can work with a clearly marked gap; they cannot safely rely on a false sequence.
Separate observation, statement and inference
Direct observations can be written plainly: “I saw water flowing from beneath the plant-room door.” A witness account needs attribution: “The cleaner stated that the leak began at approximately 21:10.” An inference needs an explicit boundary: “The source had not been confirmed when the area was handed over.”
This separation protects the credibility of the record. It also makes later investigation easier because reviewers can trace each fact to its source.
Attach evidence without overstating it
Photos, audio and video should support the record, but an attachment does not explain itself. Note what the evidence shows, when it was captured and who captured it. Preserve the original file where policy allows and avoid edits that could obscure provenance.
Location data can show where a device reported from; it does not by itself prove why an event occurred. An AI-generated draft can organise supplied material; it does not turn an uncertain fact into a verified one.
Record notifications and handover
List every person or authority contacted, the time, the channel and any instruction received. If operations, a client representative or emergency services took ownership, record when that transfer happened and what remained outstanding.
A report is not complete merely because the form is full. It is complete when the next responsible person can see the current state and the decisions already made.
Review before signing
Digital review should preserve the original field account, the reviewed version and the identity and time of each approval. That history is often as important as the final prose.
- Check names, timestamps, site details and incident classification
- Remove assumptions and emotive language
- Confirm every attachment belongs to the correct incident
- Verify the notified-party list and open actions
- Sign only the version you actually reviewed