What should a useful security incident report contain? A facilities manager’s buyer guide

A useful security incident report gives a facilities manager a reliable account of what was observed, what was done, who was told and what remains unresolved. It separates facts from opinion, records times and handover, protects personal data and supports a proportionate review. Set these expectations in writing before deployment, with clear escalation thresholds and named ownership.

Start with the management question, not the form

First decide what the report must enable you to manage: an immediate decision, handover, client update, investigation, insurance notification or review of a site procedure. The record must be clear, attributable and proportionate.

Agree what counts as an incident, suspicious activity, near miss or routine observation. State who owns decisions at each level, when the provider notifies the facilities team and which matters require a client-led process. ProtectUK advises organisations to make reporting routes known, identify ownership and retain reports of suspicious activity with the responsible manager. Its guidance also covers escalation to management, security and, where appropriate, police.¹

Require a factual record that can be checked

Ask for a chronological account in plain, neutral language. The writer should distinguish direct observation, information reported by another person, and any assessment or decision. Where an opinion is included, identify it as opinion and state its basis. The ICO says records of opinion should make that distinction and include enough context for a reader to interpret them correctly.²

Useful does not mean lengthy. This is a compact starting point for an agreed report standard, to be tailored to the site and incident type.

Reference evidence rather than circulating unnecessary copies. If material may be important, follow the site procedure, protect people and preserve it appropriately. College of Policing guidance identifies establishing what happened, managing risk, securing and preserving evidence, and proper recording as core early considerations in a police investigation.³ A security report should not present itself as a police investigation or go beyond the available facts.

Make escalation thresholds usable during a shift

An escalation matrix is more useful than an instruction to “report anything serious”. For each category, agree the trigger, recipient, contact route, minimum information and who records the decision. Include an out-of-hours client contact and fallback route. State when the provider informs the client even if an agreed procedure is in use.

The process must not delay an emergency response. Police.uk says to call 999 when a serious offence is in progress or has just happened, someone is in immediate danger, property is in danger of damage, or serious public disruption is likely. For a minor crime, incident or non-urgent information, it directs people to report online or call 101.⁴ Site instructions should reflect the risk assessment and emergency-service direction where given.

Expect the record to show the escalation path: time, recipient, decision and reason. Do not assume that a provider will make legal, regulatory or client-policy decisions unless responsibility has been expressly agreed.

Treat handover and closure as operational controls

A saved report is not necessarily closed. Handover should identify what remains unresolved, such as a damaged access point, welfare concern, police reference, evidence-preservation step or client decision. The incoming team needs the current risk, last action and next owner.

Set a simple closure rule. It can distinguish between an officer completing the report, a supervisor checking that required actions are recorded, and the client closing a site-level action. ProtectUK recommends end-of-shift debriefs so suspicious activity is recorded and investigated, and says governance should identify ownership, record keeping and how effectiveness is assured.⁵

Review proportionately and protect personal data

Agree review triggers in advance: a serious matter, repeated event, failed control, unresolved welfare issue or possible personal-data breach. The review should test whether the right people received the right information and identify a specific action, owner and review point. ProtectUK recommends regular review and exercising of incident-response arrangements to keep them accurate, workable and current.⁶

Security reports may contain personal data about staff, visitors, witnesses or subjects of concern. The ICO requires personal data to be adequate, relevant and limited to what is necessary for the stated purpose.⁷ Agree access, retention, correction and attachment controls before deployment. Do not collect sensitive detail “just in case”.

The agreement should also set out how a possible personal-data breach is raised and assessed. The ICO says all personal-data breaches must be documented and that a controller must notify the ICO without undue delay and, where feasible, within 72 hours when a breach is likely to risk people’s rights and freedoms.⁸ If police request personal data, sharing must be justifiable as necessary and proportionate; record the request, decision and material disclosed.⁹

Ask providers to demonstrate the workflow, not a dashboard

Technology can help organise agreed records, manage access and retrieve reports. It does not decide what happened, determine severity or remove the need for trained people to follow the escalation plan. Ask a prospective provider to demonstrate how a report is created, amended, approved, shared, handed over and retrieved against a genuine site scenario.

For SSS clients, the SSS Application can support agreed incident records alongside site instructions, attendance, patrol logs and facilities-management tracking. Client access can be arranged for agreed rotas, vetting and licence details, and incident reports. These tools support record keeping and transparency; operational judgement, escalation and follow-up remain with the people responsible for the site.

What to prepare before speaking to a security provider

Prepare each site’s operating hours, access points, existing instructions and priority incidents or near misses. Identify facilities, operations, health and safety, data-protection and out-of-hours contacts. State the information, timing and communication channels required. Also bring retention rules, restrictions on sharing CCTV or personal information, and the authority the security team has while awaiting a client decision.

Discuss a site-specific reporting arrangement with SSS

SSS Official can discuss how agreed reporting expectations can be reflected in site instructions, patrol and mobile logs, incident records and client access within the SSS Application. To discuss a London security requirement, contact SSS Official.

This article is general information for facilities and security procurement. It is not legal advice, does not determine regulatory reporting duties, and should be considered alongside your organisation’s own legal, data-protection, health and safety and emergency procedures.

Sources and further reading

1. ProtectUK: reporting suspicious activity
2. ICO: data minimisation
3. College of Policing: investigation process
4. Police.uk: how to report
5. ProtectUK: incident roles and responsibilities
6. ProtectUK: review incident-response plans
7. ICO: data-minimisation principle
8. ICO: personal data breaches guide
9. ICO: sharing data with law-enforcement authorities

Published: 21 October 2026
Reviewed: 21 October 2026