A report arrives after a confrontation at a venue entrance. It says the individual was aggressive, staff dealt with it, and the matter was resolved.

That may satisfy a reporting requirement, but it tells a manager almost nothing useful. Was there a credible threat? Did staff recognise the right indicators? Was the response proportionate? Is there a safeguarding, security or operational issue that could recur?

Security incident reporting is not an administrative task that begins after the risk has passed. Done properly, it is how an organisation turns an event, concern or near miss into a better decision the next time.

Done badly, it creates a false sense of control: plenty of records, little learning and no clear picture of risk.

What a useful report actually does

The purpose of a report is not to prove that somebody completed a form.

Its purpose is to preserve an accurate account, support proportionate escalation and give leaders enough information to decide what happens next.

That requires more than a narrative. A useful report separates what was directly observed from what was assumed, heard from another person or discovered later. This distinction matters. A staff member may observe someone repeatedly testing a restricted door. They may reasonably feel concerned. They should not record an untested motive as fact.

Good reporting also captures the operational context. Time, location, people involved, actions taken, who was notified and whether the issue remains active all affect the response. A brief report can still do this well. Length is not quality. Clarity is.

The uncomfortable reality is that many reporting systems reward completion rather than judgement. Staff learn which boxes must be ticked, but not how to identify material information. Supervisors accept vague language because they are busy. Patterns disappear into separate reports because nobody has responsibility for reviewing them.

A policy exists, yet organisational awareness remains poor.

Security incident reporting starts before an incident

The quality of reporting is usually decided before anything happens.

If people do not know what deserves reporting, who receives it or what an urgent escalation looks like, they will improvise under pressure. Some will report everything to avoid criticism. Others will stay silent because they do not want to create work, appear foolish or be blamed for getting it wrong.

Neither response is helpful. The aim is informed reporting, not indiscriminate reporting.

Organisations should define clear reporting thresholds in language that fits the working environment. A shopping centre, construction project, corporate office and transport hub will not face the same risks or operate in the same way. Their people still need to understand the difference between routine service issues, security concerns, significant incidents and immediate threats to life or safety.

This is especially relevant where organisations are strengthening protective security arrangements in preparation for Martyn’s Law. A plan that identifies reporting routes is necessary, but it does not prove that staff can recognise concerning behaviour, record it accurately or make a sound decision when normal routines break down.

Capability has to be tested and practised.

Facts first, interpretation second

A report should answer a basic question, what would a person who was not present need to know to make the next decision?

Start with the facts. Record the date, time and precise location. Identify those involved where appropriate and lawful. Describe actions, words and behaviour plainly. Note what staff did, who they contacted and the outcome at the point the report was made.

Then make room for professional judgement. If an employee believes an event is unusual or concerning, that view should be recorded as an assessment, not disguised as fact. The person appeared to be checking staff access arrangements is different from the person was planning an intrusion.

The first may be a reasonable observation based on behaviour.

The second makes a claim the reporter cannot support.

This is not pedantry. Inflated language can trigger unnecessary action, damage confidence in reporting and make later analysis less reliable. Understated reporting creates the opposite problem, warning signs are missed because the written account failed to convey what happened.

Managers should coach staff to be specific. Replace suspicious individual with the behaviour that caused concern. Replace security issue resolved with the action taken and the reason it was judged sufficient.

The report should allow another competent person to understand the decision without needing to guess.

Escalation must be proportionate and timely

Not every incident needs the same response. A damaged fence panel, an abandoned item, a persistent attempt to access a staff only area and an allegation of threatening behaviour may all require reporting, but their urgency, ownership and external notification requirements will differ.

This is where rigid reporting processes can fail. If staff must complete a detailed form before they can alert a supervisor, control room or emergency service, the process has been designed around administration rather than safety. Urgent information should be passed through the quickest reliable route first.

The written report follows as soon as it is practical and safe to complete.

Equally, not every concern should be pushed immediately to the most senior person available. Over escalation can overwhelm control functions and encourage leaders to dismiss future alerts as noise. The answer is not to discourage reporting.

It is to give people scenarios, decision cues and feedback so they can judge urgency with greater confidence.

A strong escalation model sets out who needs to know, how quickly they need to know and what information they need first. It also gives staff permission to act on reasonable concern. People should not need certainty before they raise a credible issue.

They do, however, need discipline in how they describe it.

The report is only useful if somebody learns from it

A well written report that is filed and forgotten has limited value.

The real return comes from review. Leaders need to look beyond individual events and ask what the reporting is showing them about the environment, systems and people.

Repeated reports about unsecured doors may indicate a maintenance problem, poor access control design, weak supervision or a local culture that treats security as somebody else’s job. A cluster of verbal confrontations may reveal a queue management problem, unclear staff authority or inadequate support for people dealing with difficult behaviour.

The event is rarely the whole story.

Review should happen at two levels. The first is immediate: was the incident handled appropriately, does anyone need support and are there actions that cannot wait? The second is periodic: what patterns, recurring vulnerabilities or capability gaps are emerging over weeks and months?

Data can assist, but it should not replace experienced review. A dashboard may count incidents by location or category. It cannot always explain why staff in one area report concerns early while another team reports only after matters have escalated.

That often comes down to leadership, confidence and local working practice.

Build reporting confidence through feedback

Staff quickly learn whether reporting is valued.

If reports vanish without acknowledgement, if minor errors attract disproportionate criticism, or if managers ask why a concern was raised rather than what can be learned, reporting quality will decline.

Feedback does not need to be elaborate. A supervisor can explain that a report was useful because it allowed an early check of a vulnerable area. They can also explain, constructively, what information was missing. This closes the loop between action and outcome.

Exercises are valuable here, particularly for teams with public facing, security or incident management responsibilities. Use realistic but safe scenarios to test whether people can spot relevant behaviour, communicate concise facts and select an appropriate escalation route.

Assessment should examine judgement, not merely whether someone knows the wording of a procedure.

Mildot Group’s approach to capability evaluation reflects this distinction. The issue is not whether a person has seen the policy.

It is whether they can apply it when information is incomplete, time is limited and the consequence of poor judgement is real.

Questions leaders should ask now

A reporting process is worth testing against practical questions. Can a new member of staff explain what requires urgent escalation? Can a manager tell the difference between an observation and an assumption in a report? Is there a clear owner for reviewing repeated concerns? Do staff receive feedback that improves their next decision?

If the answer to any of these is unclear, the organisation may have a reporting system but not reporting capability. The gap matters because incidents do not arrive in neat categories. They arrive as fragments of information, uncertain behaviour and decisions made by people who may be busy, tired or under pressure.

The best security incident reporting process makes those decisions easier. It gives people a common language, preserves the facts and creates a route from concern to action.

More importantly, it shows an organisation where its assumptions are failing before those failures become something more serious.

.

Useful Links:

.