Security Incident Report Template for India (2026): Recording What Happened, Fairly

Every security operation needs one plain form that anyone on duty can fill in the moment something happens: an intrusion, a theft, a trespass, an alarm activation, a footage or data breach, or a safety event. That form is the security incident report template — the standard record of what happened, written factually enough that it can be acted on, learned from and, where the law requires, escalated. This page explains the fields, shows a worked example, and gives you a blank copy-ready version to adapt.

It sits in the operate phase of a security programme (brief -> design -> procurement -> install -> commission -> handover -> operate). A guard, control-room operator or facility manager completes it whenever an incident occurs; management, insurers, the police (where lawful) and any investigation read it later. Done well, it drives the right response, supports a fair claim, feeds honest learning, and never becomes a tool to shame or accuse.

Scope & how to read this. This is a ready-to-adapt professional template, not authoritative, legal or contractual wording. A security incident report can hold personal data and may support serious decisions, so get professional and legal review before you standardise it, and defer specifics to your site, your organisation and the authorities. It records facts; it does not decide guilt.

What it is, and when it is used

An incident report is the single source of truth for one event. It is written at the time, by the person who responded, while memory is fresh and evidence is intact. It answers who, what, when, where and what-was-done — and deliberately stops short of why-and-who-is-to-blame, because that is for a proper investigation or due process, not for a form filled in the dark by a guard.

Use it for the whole range of security events, not just crimes:

• Intrusion, theft, trespass, vandalism — someone or something crossed a line.
• Alarm activation — genuine or false; log both, because patterns of false alarms matter.
• A data or footage breach — CCTV clips shared wrongly, a lost drive, an unauthorised login. This also triggers your data-breach response process.
• A safety event or near miss — a fall, a blocked fire exit, a fault that could have hurt someone. Near misses are the cheapest lessons you will ever get; capture them.

The report is where your incident response plan turns from intention into evidence. One completed form should let a reader who was not there understand exactly what occurred and what still needs doing.

The fields the form should capture

Keep it to fields anyone can complete under pressure. Group them so the form reads top to bottom in the order an incident unfolds.

Facts, not verdicts. The description and the people fields are where reports go wrong. Write what was observed and when. A person captured on camera near a stolen item is "a person seen near the cycle stand at 21:40", not "the thief". Presumption of innocence is not a nicety; a report that brands someone guilty can defame them, be challenged, and see an unfair action taken against the wrong person.

A worked example

Illustrative only, to show the shape. The values below are a neutral, made-up example.

Example only — adapt to your project. Names, times and references here are placeholders, not real data.

Notice what the example does not do: it names no one as guilty, offers no theory of motive, and hands the escalation decision to management rather than the guard. The footage is referenced, not attached or forwarded.

The blank template

Copy this into your own sheet, print it as a pad for the gate, or paste it into your operations system. Keep the field order; add site-specific rows if you must.

This report holds personal data. Descriptions, names and CCTV references identify people, so the form is personal data under the Digital Personal Data Protection (DPDP) Act, 2023. Store it securely, restrict who can read it, share it only on a lawful basis, and keep it only as long as you genuinely need it. For sharing footage referenced here, follow the CCTV footage sharing rules.

Field guide: how to complete it well

• Be factual and objective. Record what you saw, heard and did, with times. If you are inferring something, label it clearly as an inference, or leave it out.
• Never accuse or defame. No one is guilty until due process says so. "A person seen ..." is your default phrasing for anyone not clearly identified and confirmed.
• Protect personal data. Reference evidence rather than pasting faces and footage into a widely shared document. Access to the report itself should be limited to those who need it.
• Escalate correctly. Management owns the response and the decision to escalate. Reporting a crime to the police goes through due process, not through a guard branding a suspect — see responding to police requests. A data or footage breach goes to your Data Protection Officer and the data-breach response process.
• Keep it secure. A stack of incident reports on a shared desk is a privacy leak. Lock them, digital or physical.
• Close the loop. An open follow-up with no owner is how the same incident happens again. Use the report to learn and prevent recurrence, then log the fix.

Common mistakes to avoid

How it connects to the rest of your operation

The incident report is one document in a small family that a professional security operation keeps together:

• Your incident response plan defines who does what when something happens; the report is the evidence that they did it, and the raw material for the debrief.
• A data-breach response is triggered when the incident is a footage or data breach; the report starts that clock and hands it to the DPO.
• The CCTV footage sharing rules govern any clip you reference here — reference, do not forward.
• When an incident becomes a police matter, responding to police requests keeps escalation on a lawful footing.
• Routine faults and tests belong in the security maintenance log, not the incident report — keep the two distinct so real incidents stand out.

For the full toolkit and how these fit together, see the professional security resources guide in the security resources hub.

Completion checklist

• [ ] Every field completed, or marked "not known" — no blanks left ambiguous.
• [ ] Description is factual; no opinion, no accusation, no "the thief".
• [ ] People described with dignity; suspects written as "a person seen ...".
• [ ] Evidence referenced, not pasted or forwarded; access restricted per DPDP.
• [ ] Notifications logged with times; escalation routed to the right owner.
• [ ] Follow-up has an owner and a status; the lesson is captured.
• [ ] Report stored securely, retained only as long as needed.
• [ ] Completed and reviewed, both signed and dated.

Key takeaways

• One standard form, filled every time. Consistency is what makes a report usable months later.
• Facts, not verdicts. Record what was observed and done; leave guilt to due process and protect the presumption of innocence.
• The report is personal data. Handle, store, share and retain it under the DPDP Act, 2023 — never let it become a register of accusations.
• Escalate correctly. Management, police and the DPO each have their route; the form routes to the right one, it does not decide.
• Close the loop to learn. An owned follow-up is how one incident stops the next.

References

• Digital Personal Data Protection (DPDP) Act, 2023 — incident reports and referenced footage that identify people are personal data; keep access controlled, sharing lawful and retention limited.
• Your organisation's incident response and escalation procedures — the authoritative source for who is notified and when; this template records, it does not override them.
• Bureau of Indian Standards catalogue for any life-safety or system standard referenced in an incident; verify the current edition at https://www.services.bis.gov.in/

This is an educational, ready-to-adapt template, not legal advice. A security incident report can hold personal data and support serious decisions — get professional and legal review before you standardise it, and defer specifics to your site, your organisation and the authorities.