Most security disappointments trace back to the same root cause: nobody wrote down exactly what the guard is supposed to do. The provider showed up, a guard stood at a post, and everyone assumed the details would sort themselves out. They don’t. Clear, specific security post orders are the instruction manual for your site — and getting them right, in writing, is the highest-leverage thing a buyer can do to turn “we have a guard” into “our site is covered the way we need.”
Here’s how to build them with your provider, and how to make sure every guard actually follows them.
What post orders really are
Post orders are the site-specific playbook: what to do, when, in what order, and how to handle the situations that come up. They’re not a job description (“provide security”). They’re a set of concrete, followable instructions (“at 22:00, lock the east gate, log it, and confirm the loading dock camera is functioning”).
Good security post orders answer, for your site:
- The routine — patrol routes, timing, checkpoints, and what to inspect at each.
- Access rules — who gets in where, visitor procedures, after-hours access.
- Scenario responses — trespasser, medical, fire alarm, suspicious package, altercation, break-in.
- Escalation — who to call, in what order, and when to involve law enforcement.
- Reporting — what to log, and how.
If your provider hands you a generic template with your name pasted on top, that’s a warning. Post orders that aren’t specific to your building aren’t post orders — they’re a formality.
When post orders are structured as concrete duties, you can see them being completed — not just assume they were.
Write them to be enforceable, not aspirational
The test of a good instruction is whether you could tell, later, if it was followed. “Keep the premises secure” fails that test. “Patrol the perimeter every hour, scanning checkpoints A through F, and log any unlocked door” passes it — because there’s a record either way.
So write post orders in terms of observable actions:
- Tie routines to times and checkpoints, not vague frequency.
- Make each scenario response a numbered sequence, so there’s no improvising under pressure.
- Specify what gets logged for each action, so the record exists.
- Name the escalation contacts explicitly, in order.
Build these with your provider — they know the operational realities — but insist on this level of specificity. It’s the difference between instructions you can enforce and hopes you can’t.
Get them into the software, not a binder
Here’s the step most buyers miss. A binder of post orders in the guard shack is read once and forgotten. A new guard covering a shift never opens it. The whole point — that every guard follows the same playbook — quietly fails.
The fix is getting your post orders into the provider’s system, so they appear in the guard’s app as the shift’s actual tasks and checkpoints. Now the routine isn’t something a guard has to remember; it’s what the app walks them through.
Post orders loaded into the guard’s app become the shift itself — the same routine for every guard, every time.
When the routine lives in software, a guard tour system with QR checkpoints turns “patrol the perimeter” into scans you can verify, and the shift produces a daily activity report showing which instructions were carried out. A replacement guard on a Saturday follows the identical playbook as your regular team, because the app hands it to them. Ask your provider whether they can load your post orders this way. If everything runs on a paper binder, consistency is a coin flip.
Keep them alive
Post orders are not a one-time document. Your site changes — a new entrance, a recurring problem, a lesson from an incident. Every time something changes or something goes wrong, the post orders should be updated, and the update should reach every guard immediately. That’s another reason to keep them in the system rather than a binder: an update pushes to everyone at once, instead of relying on a note taped to the shack wall.
Set a rhythm: review the post orders together with your provider periodically, and after any significant incident. This keeps the playbook matched to reality.
A quick note on scope
Some instructions touch on what a guard is legally permitted to do — detainment, use of force, searches — and those limits vary by jurisdiction and change over time. Frame those responses conservatively and confirm the specifics with your provider and your own legal advisor; this isn’t legal advice. Post orders should keep guards within their authority, not push them past it.
What to require before you sign
- Post orders written specifically for your site, not a template.
- Instructions phrased as observable, enforceable actions.
- Scenario responses as numbered sequences with named escalation contacts.
- The orders loaded into the provider’s software so every guard follows them.
- A process to update them after changes and incidents, pushed to all guards.
Clear post orders are how you get the security you actually meant to buy. Write them tight, get them into the system, and keep them current — and every guard on your site works from the same playbook.
To see how post orders, checkpoints, and reporting come together for the client, take a look at the client portal built for security companies.