How Do You Write a Security Incident Report That Holds Up?

How to write a security incident report that survives legal review: the 6 elements, a template, weak vs. strong examples. Learn the method.

Joe Juarez — Co-founder & CEO

Published July 12, 2026 Updated July 22, 2026 8 min read

I've reviewed incident reports at Ranger Guard for years across four markets — Houston, Corpus Christi, Las Vegas, and Florida — and I've seen what happens when one of them ends up in front of an attorney. Here's the method we train, and the mistakes that cost companies money. (One note up front: this is operational guidance from a security operator, not legal advice — have your counsel review your report policies.)

Why do security incident reports end up in front of attorneys?

Because incidents become claims. A slip-and-fall becomes a premises-liability suit; a detained shoplifter becomes a false-imprisonment allegation; a parking-lot assault becomes a negligent-security case. Personal-injury statutes of limitation commonly run 2–4 years depending on the state (2 years in Texas and Nevada), which means the report an officer writes at 3 a.m. may be the only reliable record when an insurance adjuster or plaintiff's attorney examines the event years later. The officer may have quit — annual turnover in the guard industry is commonly cited at 100%+ — so the document has to stand entirely on its own.

That's the standard: write every report as if it will be read aloud, sentence by sentence, in a deposition, with you under oath explaining each word. A report that meets that bar also happens to be exactly what your client and your insurance carrier want. The same discipline applies to the routine log around it — see our daily activity report template.

What are the six elements of a security incident report?

Six, not seven. The seventh — why — is the cardinal sin.

1. Who — everyone: subjects, victims, witnesses, responding officers (with unit numbers), your own name and badge/license number. Full names where obtainable; physical descriptions where not.
2. What — the event itself, in observable terms. What you saw and heard, in sequence.
3. When — exact times for each stage: when it started, when you observed it, when you called it in, when police arrived, when it ended. Times, not "shortly after."
4. Where — precise location: "northeast corner of the east parking lot, near light pole 7," not "outside."
5. How — the mechanics you observed: how entry was made, how the injury occurred, how the subject left.
6. Response — what you did, in order, with times: notifications made, aid rendered, area secured, reports filed.

Never why. "He was trying to steal a car" is a conclusion — you observed a man pulling on door handles of four vehicles. "She slipped because the floor was wet" bundles causation you can't prove — you observed a person on the floor and a liquid nearby. The moment a report speculates about motive or cause, an attorney owns it: every guess becomes evidence of what your company "believed" and can be turned against you. Report the observations; let investigators draw conclusions.

What does an incident report template look like?

SECURITY INCIDENT REPORT — #______

Narrative (first person, chronological, timestamped, facts only)

Actions taken (numbered, with times)

Photos / video attached: ☐ Yes (count: ___) ☐ No Officer signature / date-time: ____________ Supervisor review / date-time: ____________

What's the difference between a weak and a strong incident report?

Same fictional incident, written twice.

Weak:

"Around midnight a drunk guy was causing problems at the garage entrance. He was obviously homeless and looking for trouble. I told him to leave and he got aggressive so I handled the situation. He probably comes around because of the new bar next door. No further issues."

Why it fails: no exact time ("around midnight"), conclusory labels ("drunk," "obviously homeless"), speculation about motive ("looking for trouble," "probably comes around because"), and a black box where the response should be ("I handled the situation" — a deposition gift). No description, no names, no notifications.

Strong:

"At 0007 on 07/19/2026, while posted at the Level 1 garage entrance of Building A, I observed a male subject — approx. 50s, 5'10", heavyset, gray beard, blue jacket — seated against the roll-gate. I detected an odor of alcohol and observed unsteady gait when he stood. At 0009 I identified myself and informed him the garage was closed to the public. Subject raised his voice and stated, 'You can't make me leave.' I maintained a distance of approximately 10 feet and did not make physical contact. At 0012 I notified dispatch, per post orders. Subject walked north on Commerce St at 0016. I notified the property manager by email at 0025 and resumed post. No injuries, no property damage observed."

Same event. Every clause is something the officer directly perceived, every stage has a time, the subject's words are quoted rather than characterized, and the officer's response is specific and policy-anchored.

What are the rules for photos and video in incident reports?

• Timestamp everything. Use a camera or app that embeds date, time, and ideally GPS in the image metadata. A photo without a verifiable timestamp is easy to challenge.
• Wide, then close. First establish context (the whole scene from a fixed point), then move in on details — the spill, the damage, the point of entry. A close-up with no establishing shot can't be located in space.
• Never stage. Don't move objects, don't re-create the scene, don't "improve" the framing by adjusting anything. Photograph what exists, where it exists. A staged photo discovered later poisons the entire report.
• Shoot before you fix. Photograph the hazard before cones go up, then again after — both states matter to a claim.
• Attach, don't describe. "See attached photos 1–6" beats a paragraph guessing at dimensions.

How should supervisors review incident reports?

Every incident report gets a second set of eyes before it reaches the client — same shift or next morning, not next week. The reviewer checks the six elements, hunts banned words (table below), verifies times against the DAR and any GPS or checkpoint data, and sends factual gaps back to the officer to complete while memory is fresh — never edits the narrative themselves, since the report must remain the officer's own account. At Ranger Guard, supervisor review inside SNTNL happens on-screen with the officer's original notes and edit history preserved, so the reviewed report and the field account can always be reconciled. Reviewed reports then go to the client with a delivery log — which matters when a client claims they were never told; that chain is half of defending an invoice or service dispute.

Which words should never appear in a security incident report?

This article is operational guidance, not legal advice. Have an attorney review your report templates and retention policies for your state.

If your incident reports currently live in texts, emails, and paper carbons: SNTNL captures the officer's original notes, enforces supervisor review, preserves edit history, and delivers the finished report to the client with a log — the workflow we run daily at Ranger Guard. Book a demo and we'll walk you through a real report's path from field note to client file.