I’ve sat in rooms where a security incident report format got picked apart by a lawyer, line by line. That’s when you learn how a badly written report stops being paperwork and starts being the thing that sinks your case.
A security incident report format isn’t something you scribble out at the end of a shift to check a box. It’s the document that decides whether your company looks sharp or careless the moment something goes wrong. A vague security incident report format — missing timestamps, no real sequence of events, no record of who was told — protects nobody. It hands the other side more questions than answers.
“Suspicious person near loading dock, resolved.” Three weeks later, when a client asks what happened, that tells you nothing. Who was this person? And “resolved” how? Who got called, and when?
That last question sinks a security incident report format most often. The report says “management informed” — not which manager, at what time, or whether they responded — and the guard who wrote it has since left.
Why It Matters
Most guards never think about this until it’s too late: a security incident report format isn’t just internal record-keeping. It’s what your company hands over when a client, an insurer, or a lawyer asks “prove it.” The system side of that is covered in our security incident report software guide; this piece is about the fields themselves.
a report that cannot answer basic questions doesn’t just look sloppy — it creates legal exposure. If it can’t establish what happened, who was involved, and who was notified, you’re not defending your company in a dispute. You’re handing the other side ammunition.
The notification chain quietly makes or breaks an otherwise solid report. A detailed timeline means little if “management was informed” replaces a named person and a timestamp. The hardest question — did anyone respond in time — stays unanswered.
Step-by-Step: Filing a Report the Right Way
Here’s how this works in AVES, field by field.
Step 1: File the report from the app, on site
Case title is the only required field, so a guard can start the record while the incident is live and fill in the rest as facts settle. Date, time, place, description, and location/department are optional at capture.
Step 2: Record the people involved as structured fields, not prose
Victim name, age, gender, witness and affiliation, and a casualties flag sit in named fields rather than a paragraph, which is what makes the record searchable later — you can answer “how many incidents involved casualties this quarter” without reading fifty reports.
Step 3: Fill in the notification chain
This section earns its place in any incident report: person in charge, whether notified, department head, and duty manager, all by name. “Who was told, and when” is the first thing disputed after a serious incident, and here it’s filled in while it’s happening, not reconstructed weeks later.
Step 4: Attach evidence to the report itself
An incident accepts photos from six named angles — front, back, left, right, top, bottom — up to five images each, plus three videos and three audio files, at 50 MB per file. Accepted formats are JPEG, PNG, GIF, MP4, MOV, MP3, WAV, and OGG.
Six named angles instead of a random photo pile makes two reports of the same incident type comparable months later. Files can be attached during submission or uploaded first and referenced afterward.
Step 5: Close the loop with findings and recommendations
Beyond what happened, a complete report carries findings, action taken, recommendation, estimated value, and whether the item was insured — the difference between a log entry and a document you can hand to a client.
Step 6: Let supervisors see it the moment it’s filed
New incidents and edits broadcast to the dashboard in real time, carrying case number and status. The dashboard tracks open incidents and folds them into an “action required” count.
The incident list filters by case title, number, location, date range, and open/closed status, sorted newest-first. Guards also get a dedicated view of reports they filed themselves.
Step 7: Export as PDF — one case or a filtered batch
Any incident generates a PDF titled with its case number, carrying the full field set and status. A filtered set — a date range, one location, all open cases — exports as a batch report in a single action. Images embedded in the PDF resolve without the reader needing a login, so a report you send a client shows its photos, not broken image icons.
Step 8: The record protects itself at the edges
The report records which user filed it and in what role, automatically. Deletes are soft, so a removed record is flagged rather than destroyed.
Settings Explained
Incident permissions, split four ways. View, create, update, and delete are separate, so “can file a report” doesn’t imply “can erase one.”
“My incidents” scope. Guards see only the reports they filed, useful for completing a write-up across a shift.
Open/closed status. Status is binary — open or closed — and drives the dashboard’s open count. Formal investigation trails with severity levels belong in a separate module.
Location and department tagging. Both are free text, with dropdowns generated from values already entered. Agree on site wording up front, since “Loading Bay” and “loading bay 1” won’t group together.
Upload limits. 50 MB per file, five images per angle, three videos and three audio files per incident. On sites with poor connectivity, brief guards to submit the report first and attach video afterward.
Best Practices / Benchmarks
Fill the notification chain every time, even when it feels redundant — the person-in-charge and duty-manager fields are skipped on quiet incidents and needed most on loud ones.
Set your own time-to-close baseline for closing reports, then hold to it. Open versus closed counts establish what normal looks like across your sites, more useful than an industry figure.
Review open incidents weekly, not monthly. An incident open for six weeks is rarely still under investigation — it’s usually finished work nobody closed.
Use the six angles as a checklist for every report. A single wide photo answers one question; six answer the ones you don’t know to ask yet.
Standardise location wording per site. A short agreed vocabulary, posted where guards can see it, is what makes location filtering useful at quarter-end.
Common Mistakes That Undermine Otherwise Good Reports
Writing conclusions instead of observations. “Theft occurred” is a conclusion. “Inventory count showed three units missing from shelf B4 during the 10 PM count” is an observation. A strong report always uses the second.
Filling reports out from memory. The same failure the security guard logbook has always had. Details slip away faster than expected — which is why case title is the only required field to start the record.
Leaving the notification chain vague. “Management informed” answers nothing. Name the person in charge, department head, and duty manager, and when each was notified.
Skipping the photo angles. Patrol evidence has the same problem — see the guard tour system guide. One convenient photo tells you less than you think. Six named angles make a scene comparable months later.
Letting open incidents sit. An incident with no severity tier can quietly rot if nobody reviews the open list.
Frequently Asked Questions
What is a security incident report format? A structured record capturing incident details, the people involved, the notification chain, supporting evidence, and findings and actions taken — built so the event can be reconstructed without relying on memory.
What should a security incident report format include? Case title and details, structured fields for victim/witness/casualties, a notification chain naming who was told and when, photo/video/audio evidence, and a findings-and-recommendation section that closes the loop.
Is incident severity classified in this system? No — status is binary. Severity tiers and staged escalation live in a separate module, not a general security incident report format.
Why does the notification chain matter so much? Because “who was told, and when” is the first thing disputed after a serious incident, and it’s most often reconstructed from memory instead of recorded in the moment.
What makes a security incident report format legally usable? It sticks to observable facts, records exactly who was notified and when, attaches evidence directly to the case, and can’t be silently altered — deletes are soft, and every field is tied to the user and role that filed it.
How is a security incident report format different from a general incident report? Both share the same field set here. Formal investigation tracking, with severity levels and staged status, is handled by a separate module.
Related Features
Dashboard reporting — real-time counts for every report, filterable by location, date range, and status.
Batch PDF export — a filtered set of cases exports as a single report.
Role-based permissions — view, create, update, and delete as independently assignable permissions.
CTA
A good format tells your guards what to write down. It doesn’t guarantee that report survives getting questioned later, unless the system behind it records who was notified and protects the record from silent edits.
If you want to see how AVES turns a report into evidence you can stand behind, explore the platform and request a demo at avessecurity.com.