Why use PDF instead of a guard-management app?

Because the client wants a deliverable, the insurer wants an archive, and not every site has connectivity for an app. PDF works on every site, prints to clipboard, and signs cleanly. A guard-management app is great for shift tracking; PDF is the report deliverable.

What does a usable incident report PDF look like?

A structured form: time, location, persons involved, narrative, witnesses, photos, evidence inventory, signatures. Each section labeled with a heading; each field bounded so the guard knows what to write where. Free-form text-only reports are slower to write and harder to read.

How do I keep photos credible?

Preserve EXIF — timestamp and GPS support the narrative. Note in the report each photo's capture time and the source device. If the photo is a re-shot of a printed image (rare), document that explicitly. A photo with stripped EXIF and no source documentation is weak evidence.

Tour log — how detailed?

Per checkpoint: time, location identifier, anything notable. The point is not to log every door, it is to give the post commander a reconstructable timeline if anything happens. Hourly summaries are usually enough unless the post orders specify otherwise.

Do all reports need a signature?

Yes — guard signature attests to the report; supervisor signature attests to review. Most jurisdictions require both. Sign with a stylus on a tablet PDF reader; the signed file carries the audit trail. Wet signature is acceptable as a fallback but slows archiving.

How do I deliver the shift package to the client?

Bundle the DAR, the tour log, and any incident reports into one PDF per shift, named with site-date-shift identifiers. Upload to the client portal; do not email. The audit trail starts at portal upload, not at email send.

PDF for security guards: incident…

By ScoutMyTool Editorial Team · Last updated: 2026-05-28

A site supervisor I worked with described his report problem as "the guard finishes shift, hands me a half-page narrative, and the client wants forty fields filled in by Monday." The fix is not telling guards to write more; it is giving them a structured PDF template where the fields are bounded, the photo evidence has a designated section, and signing the file closes the report. Here is the working DAR / incident / tour-log PDF kit I use on contract sites, with the metadata and signature steps that keep the deliverable defensible months later.

Vocabulary, quickly

Term	Meaning
Daily activity report (DAR)	Shift summary of routine activity and notable events
Incident report	Per-incident detailed write-up with evidence and witnesses
Post orders	Site-specific instructions for the guard on duty
Tour / patrol log	Time-stamped checkpoints walked during a shift
Use-of-force report	Mandatory document when force was applied; tightly structured
Chain of custody	Trail of evidence handling from capture to filing
After-action review	Post-incident analysis attached to the incident report

Step by step

Template the DAR. Site, date, shift, guard name, weather, notable activity grid, narrative box. Form fields, not free-text.
Template the tour log. Checkpoint identifier, time, observation. One row per scan.
Template the incident report. Time, location, persons, narrative, witnesses, photos section, evidence inventory, signatures.
Photo evidence section. Per photo, capture time and source device. EXIF preserved.
Sign on a tablet. Guard signature at end of shift; supervisor signature after review.
Bundle the shift package. DAR + tour log + incident reports into one PDF per shift.
Name and route consistently. SITE_DATE_SHIFT.pdf, upload via client portal.
Archive nightly. Shift package goes to local archive; cloud sync if the client requires.

Shift-deliverable checklist

Every report field is bounded — the guard knows what to write where.
Photo evidence has EXIF preserved and a per-photo source note.
Guard and supervisor signatures both present; audit certificates intact.
Tour log timestamps match the patrol time window; gaps explained.
Shift package uploaded to client portal, not emailed.
File name and metadata include site, date, and shift — three places, consistent.

Common pitfalls in security shift PDFs

Tour log timestamps that round to the nearest 15 minutes — patterns are obvious to a client reviewer and signal the guard was not actually walking checkpoints. Capture real times from the badge reader or the tablet clock.
Incident-report narratives without persons-involved details — names, descriptions, and roles are the difference between a useful report and a liability when the client subpoenas the report later.
Photo evidence shot at low resolution — phones default to compressed; switch to full-quality for incident photos and keep the originals.
Reports signed by the guard only — supervisor review is the second sign-off that satisfies most contract requirements; without it, the deliverable is incomplete.
Files emailed to the client portal address rather than uploaded through the portal — email is not an audit trail, the upload confirmation is.
Daily activity reports overwritten on the same filename when corrected — keep the original and add a revision letter (-A, -B), so the trail of corrections survives a client question.
Use-of-force reports filed inside the daily activity report — they need to be a standalone PDF with a separate retention policy and routing.
Long narratives where bullet points would do — a client reviewer reads bullets in seconds; paragraphs get skimmed.

FAQ

Why use PDF instead of a guard-management app?: Because the client wants a deliverable, the insurer wants an archive, and not every site has connectivity for an app. PDF works on every site, prints to clipboard, and signs cleanly. A guard-management app is great for shift tracking; PDF is the report deliverable.
What does a usable incident report PDF look like?: A structured form: time, location, persons involved, narrative, witnesses, photos, evidence inventory, signatures. Each section labeled with a heading; each field bounded so the guard knows what to write where. Free-form text-only reports are slower to write and harder to read.
How do I keep photos credible?: Preserve EXIF — timestamp and GPS support the narrative. Note in the report each photo's capture time and the source device. If the photo is a re-shot of a printed image (rare), document that explicitly. A photo with stripped EXIF and no source documentation is weak evidence.
Tour log — how detailed?: Per checkpoint: time, location identifier, anything notable. The point is not to log every door, it is to give the post commander a reconstructable timeline if anything happens. Hourly summaries are usually enough unless the post orders specify otherwise.
Do all reports need a signature?: Yes — guard signature attests to the report; supervisor signature attests to review. Most jurisdictions require both. Sign with a stylus on a tablet PDF reader; the signed file carries the audit trail. Wet signature is acceptable as a fallback but slows archiving.
How do I deliver the shift package to the client?: Bundle the DAR, the tour log, and any incident reports into one PDF per shift, named with site-date-shift identifiers. Upload to the client portal; do not email. The audit trail starts at portal upload, not at email send.

Citations

Wikipedia — “Security guard — documentation duties.” en.wikipedia.org/wiki/Security_guard
Wikipedia — “Incident report — structure and chain-of-custody.” en.wikipedia.org/wiki/Incident_report
Wikipedia — “Exif — photo metadata.” en.wikipedia.org/wiki/Exif

Build security-shift PDFs in your browser

Template DARs, tour logs, and incident reports; sign on tablet; bundle and upload — ScoutMyTool runs every step locally so client and incident data never leaves the post.

Open the PDF toolkit →