How to write a security incident report: template, example and follow-up checklist

That sounds straightforward. However, incident reports can become less useful when facts, assumptions and conclusions are mixed together, important evidence is not referenced, or recommendations are recorded but never followed through. (Follow-up often takes an inordinate amount of a security manager’s time).  

This guide explains how to write a security incident report from the initial record through to follow-up and closure. It includes a practical template, a worked example and a checklist you can use to review your own reports.

Security incident report template: what should you record?

As a starting point, a security incident report should normally record:

• incident or reference number;

• name and role of the person making the report;

• date and time the report was created;

• date and time of the incident;

• exact location;

• type of incident;

• people involved;

• a factual description and chronology;

• immediate impact;

• action taken at the time;

• people or organisations notified;

• relevant evidence and where it is held;

• facts or circumstances that remain unknown;

• follow-up actions required;

• report status and, where appropriate, version.

The precise fields will vary according to your organisation and the type of incident.

Download SIRV’s free security incident report template in Word or PDF.

The template is useful on its own or can be adapted to match your organisation’s own procedures and terminology.

1. Deal with the incident before writing the full report

The first priority during an incident is the incident itself. That might mean protecting people, contacting the emergency services, following an evacuation or security procedure, restricting access to an area, calling a manager or preserving evidence.

Do not delay necessary action because you are trying to complete a formal report.

There are usually two stages to useful incident reporting.

The initial record

Capture the essential facts as soon as practical while events are still fresh. This might include:

• what has happened;

• where it happened;

• when it happened;

• who is involved;

• immediate consequences;

• what action has already been taken;

• who has been informed;

• anything requiring urgent follow-up.

The initial record may be brief. Its purpose is to make sure important information is not lost and that the people taking over the incident have enough information to act.

The fuller report

Once the immediate situation is under control, the initial record can be developed into a more complete incident report. This is the opportunity to check timings, add relevant evidence, correct errors, record outstanding uncertainties and document subsequent actions.

Do not silently rewrite the history of the incident simply because more became known later. Where it matters, distinguish what was known at the time from what was established afterwards.

2. Record what is known, not what you think probably happened

One of the most important disciplines in incident reporting is separating fact from assumption. For example, consider this statement:

“The man tried to break into the building.”

It sounds clear, but how much of it has actually been established? Perhaps a security officer saw someone pull a door handle several times. That is an observation. Whether the individual intended to break in is a conclusion about motive. A more useful report might say:

“At 22:14, I observed a male approach the east staff entrance and pull the external door handle three times. The door remained locked. I did not hear the individual speak and I do not know why he attempted to open the door.”

The second version may sound less dramatic, but it is more useful. It tells a later reviewer what the officer actually saw and what remains unknown.

Four useful categories

When writing or reviewing a report, it can help to distinguish between four types of information.

Observed: Something the reporter directly saw, heard or experienced.

At 22:14 I saw the individual pull the staff entrance door handle three times.

Reported by somebody else: Information provided by another person.

At 22:18 the receptionist told me that the same individual had approached reception approximately ten minutes earlier.

Supported by another record: Information subsequently checked against CCTV, access control, alarm records or another source.

The access-control record shows no successful credential use at the east entrance between 22:00 and 22:20.

Unknown or assessment: Something that has not yet been established.

The reason the individual attempted to open the door is not known.

This distinction becomes particularly important when an incident is later reviewed by management, HR, insurers, police, lawyers or another investigating body.

A report should help that reviewer understand the evidence. It should not require them to work out which parts were observation and which parts were speculation.

3. Build a clear chronology

Most security incidents become easier to understand when they are set out in time order (chronologically). Use precise times where they are known. For example:

22:14 Security officer observes an individual attempting to open the east staff entrance.

22:15 Officer approaches the entrance from inside the building.

22:16 Individual walks towards the visitor car park.

22:17 Control room informed by radio.

22:19 CCTV operator begins reviewing footage.

22:23 Duty manager informed.

22:31 CCTV review identifies the individual’s initial arrival at 22:09.

A chronology makes it easier to identify missing information and compare the report with other records. If the time is approximate, say so.

Writing “approximately 22:15” is better than giving a precise time that cannot be supported.

4. Record the immediate impact and response

An incident report should explain what changed as a result of the event. Depending on the incident, this could include:

• injury or concern for someone’s welfare;

• damage;

• loss;

• disruption;

• a security control being defeated or bypassed;

• an area being closed;

• a contractor being stopped;

• police or emergency-service attendance;

• additional security measures being introduced.

Then record the actions taken. For example:

The east entrance was checked at 22:20. No damage was identified and the door remained secure. The duty manager asked the control room to retain the relevant CCTV footage and requested an additional patrol of the east perimeter.

Avoid making the report look more complete by claiming an outcome that has not actually been checked.

For example, “the building was secure” is a broad conclusion.

It may be more accurate to state exactly what was checked:

The officer checked the east entrance, loading-bay door and adjacent ground-floor windows. No damage or open access point was identified.

Specific observations are usually more useful than reassuring conclusions.

5. Identify the evidence

The report does not need to contain every piece of evidence. It should, however, make clear what relevant evidence exists and where an authorised reviewer can find it. Depending on the incident, that might include:

• CCTV footage;

• access-control records;

• alarm records;

• photographs;

• witness accounts;

• Daily Occurrence Book entries;

• control-room logs;

• visitor records;

• patrol records;

• radio or telephone records;

• emails or messages;

• police reference numbers;

• maintenance records;

• related reports.

For example:

CCTV cameras E03 and E05 cover the east entrance and adjacent car park. Relevant footage has been identified between 22:05 and 22:25 and retained in accordance with the organisation’s procedure.

Or:

Access-control activity for the east entrance was checked for 22:00 to 22:30. No successful credential use was recorded during that period.

Do not claim that the absence of a record proves something did not happen. The absence of a successful access-control record, for example, does not by itself prove that nobody entered.

ProtectUK guidance on reporting suspicious activity recommends keeping records of the issues identified, decisions made and the reasoning behind those decisions. It notes that these records may later provide evidence for investigations or public inquiries.

6. Worked security incident report example

The following fictional example shows how the different elements can be brought together.

Incident

Reference: SEC-2026-0812-04
Reported by: J Smith, Security Officer
Incident date: 12 August 2026
Location: East staff entrance, Building A
Incident type: Attempted unauthorised access / suspicious activity

Incident description

At approximately 22:14, while walking from reception towards the east corridor, I observed a male outside the east staff entrance.

The individual pulled the external door handle three times. The door did not open.

I approached the door from inside the building. When I was approximately five metres from the entrance, the individual walked away towards the visitor car park.

I did not speak to the individual.

I informed the control room by radio at 22:17 and asked for the CCTV covering the entrance to be reviewed.

Description

Male, estimated 30 to 40 years old, approximately 180 cm tall. Dark jacket, blue jeans and light-coloured trainers. Carrying a black backpack.

Immediate impact

No entry to the building was observed.

No damage to the east entrance was identified during an inspection at approximately 22:20.

The reason the individual attempted to open the door is not known.

Evidence

CCTV cameras E03 and E05 cover the entrance and car park.

Control room operator A Jones reviewed footage from 22:05 onwards and identified an individual matching the description entering the visitor car park at approximately 22:09.

Access-control activity for the east entrance was checked between 22:00 and 22:30. No successful credential use was recorded during this period.

Relevant CCTV footage was retained in accordance with the site’s procedure.

Notifications and actions

22:17 – Control room informed.

22:20 – East entrance physically checked.

22:23 – Duty security manager informed.

22:25 – Additional patrol requested for east perimeter and car park.

22:31 – CCTV review completed.

Outstanding questions

The identity of the individual has not been established.

The reason for attempting to open the staff entrance is unknown.

It has not yet been established whether the individual attended any other entrance.

Follow-up

• Review available CCTV from other external cameras for the period 22:05 to 22:35.
• Check whether reception or other staff interacted with the individual.
• Duty security manager to decide whether any further reporting or escalation is required.
• Include relevant information in the next security-team briefing.
• This example deliberately leaves questions unanswered.
• A good report does not need to make uncertainty disappear. It needs to make uncertainty visible.
• 7. The incident report is not the end of the process

A common weakness in incident reporting is that considerable effort goes into recording what happened, but much less attention is given to what happens next.

A recommendation such as: “Review access arrangements.” is not yet an action. Who will review them? By when? What decision is required? How will anybody know that the action has been completed? A simple follow-up record might look like this:

Action	Owner	Due date	Status	Outcome/evidence
Review east entrance CCTV coverage	Security Manager	19 Aug	Open
Check whether similar attempts have been recorded in previous 90 days	Control Room Manager	15 Aug	Open
Inspect door and locking arrangements	Facilities Manager	14 Aug	Complete	No defect identified
Brief security team on incident	Shift Manager	13 Aug	Complete	Recorded in team briefing

The principle is straightforward:

incident > review > decision > action > owner > follow-up > outcome

In a health and safety context, HSE incident-investigation guidance recommends giving actions timescales and named owners, monitoring their implementation and considering whether similar risks exist elsewhere. The same discipline is useful in security.

The same principle is useful in security. A report creates a record. The organisation still needs to decide what the record means and what, if anything, should change.

8. Look across incidents, not just at one incident

Some incidents appear insignificant when looked at individually. The value may emerge when records are considered together. For example:

• Have there been repeated attempts to access the same entrance?

• Do incidents cluster around particular times?

• Is one location generating disproportionate numbers of reports?

• Are different officers recording similar suspicious behaviour?

• Have the same recommendations been raised previously?

• Are actions repeatedly being opened but not completed?

• Did an earlier incident reveal a weakness that has appeared again?

This is where consistent reporting becomes particularly valuable. If every report uses different terminology and important fields are regularly left blank, comparison is difficult. If information is captured consistently, teams have a better chance of spotting patterns and retaining lessons rather than repeatedly starting from the latest incident.

9. Check whether the incident needs to be reported elsewhere

Your internal security incident report may not be the only report required. Depending on what happened, your organisation may need to consider separate reporting or escalation requirements.

Examples include:

• contacting the police or emergency services;

• reporting certain work-related incidents under RIDDOR;

• following safeguarding procedures;

• notifying an insurer or client;

• following sector-specific reporting requirements;

• assessing whether a personal-data breach must be reported to the Information Commissioner’s Office.

Not every security incident falls into one of these categories. For example, RIDDOR does not apply to every incident at work. It requires reporting only for defined categories of work-related deaths, injuries, occupational diseases, dangerous occurrences and certain gas incidents.

Similarly, not every information security or physical security incident is a reportable personal data breach. Similarly, not every information security or physical security incident is a reportable personal data breach. Where a personal data breach meets the reporting threshold, it must be reported to the ICO without undue delay and, where feasible, within 72 hours of the organisation becoming aware of it.

Your organisation should have procedures for deciding which additional reporting routes apply. An internal security report should support those processes. It does not replace them.

10. Security incident report follow-up checklist

Before treating an incident record as complete, check:

• Has the incident been given a reference number?

• Are the date, time and location clear?

• Is the reporter identified?

• Is the chronology understandable?

• Are observations distinguished from information provided by other people?

• Have assumptions been removed or clearly identified?

• Are important unknowns recorded?

• Is the immediate impact clear?

• Are the actions taken at the time recorded?

• Are relevant photographs, CCTV, access control records or other evidence identified?

• Is it clear where that evidence is held?

• Have relevant internal notifications been recorded?

• Has somebody considered whether external reporting or escalation is necessary?

• Have follow-up actions been identified?

• Does each action have an owner?

• Does each action have a target date where appropriate?

• Is completion of the actions being checked?

• Has the eventual outcome been recorded?

• Have any lessons that apply elsewhere been identified?

• Has the report been retained in accordance with the organisation’s requirements?

From incident reports to retained operational learning

Good incident reporting starts with consistent information. But recording is only one part of the operational process.

Once an incident has been captured, organisations may still need to triage it, review the available evidence, identify patterns, make decisions, allocate actions, check that those actions are completed and retain useful lessons.

This is where structured reporting and controlled use of AI can work together.

SIRV Internal Reports provides structured incident and event reporting, with custom forms, audit trails and automated follow-up action emails.

SIRV AI is designed to work across the subsequent operational process, helping teams connect information to review, decisions, actions, owners, follow-up and retained learning. That does not mean asking AI to decide what happened.

An AI system should not turn an uncertain observation into a fact, establish someone’s intent, decide responsibility or replace the person accountable for reviewing the incident. The useful role is narrower.

It can help authorised teams work through information consistently, retrieve the relevant approved procedure, identify records that may need attention, find patterns across previous reports and keep actions and learning connected. The accountable judgement remains with the appropriate person.

Frequently asked questions

What is a security incident report?

A security incident report is a structured record of a security related event. It normally records what happened, when and where it occurred, who was involved, the immediate response, relevant evidence and any follow-up required.

What should I write in a security incident report?

Start with the essential facts: who, what, when and where. Then record the impact, actions taken, notifications made, available evidence, important unknowns and follow-up actions. Avoid guessing at motive or cause where this has not been established.

Should I explain why the incident happened?

Only where the reason has actually been established. If the cause or motive is unknown, record it as unknown. An investigation or later review may establish more information.

Should a security incident report include CCTV?

You can identify relevant CCTV footage and where it is retained without necessarily copying the footage into the report itself. The same principle can apply to access-control records, photographs, witness accounts and other supporting material. Follow your organisation’s requirements for handling, access and retention.

What is the difference between an incident report and a Daily Occurrence Book?

A Daily Occurrence Book is normally a chronological log of activity during a shift or at a location. An incident report provides a more detailed record of a particular event. An incident may therefore first appear in the Daily Occurrence Book and also require a separate incident report.

When should a security incident report be completed?

Record the initial facts as soon as practical, but do not delay urgent action in order to complete paperwork. A fuller report can be completed once the immediate situation is under control and relevant information can be checked.

Does writing the report complete the incident?

Not necessarily. The report may identify actions, further investigation, external reporting or lessons that need to be followed through. A useful incident-management process therefore records not only the event but also the resulting decisions, actions, owners, outcomes and learning.

Download the free security incident report template

SIRV provides a free security incident report template in Word and PDF format.

Use it as a starting point and adapt it to your organisation’s procedures, reporting requirements and operating environment. The aim is not to create a longer report.

It is to create a clearer record: what happened, what is known, what evidence supports it, what remains uncertain and what happens next.