Most incident runbooks are written once, filed in a wiki, and ignored at 3 a.m. when an alert fires. Physical security solved a version of this problem long ago with post orders, the site-specific instructions that tell a guard what to do, when to do it, and who to call. Studying how written post orders define what a guard does at each site gives cyber and IT teams a practical template for writing playbooks that survive real pressure. This post applies that template to runbooks, escalation paths, and alert handling.
Key Takeaways
- A runbook that cannot be followed by a tired person in under two minutes is a document, not a procedure.
- Strong post orders are specific to one location, one role, and one set of risks. Strong runbooks should be too.
- Every instruction needs an owner, a trigger, an action, and an escalation contact.
- Instructions only stay reliable if you verify they were followed and review them after every real incident.
Why It Matters
Incident response rarely fails because a team lacks skill. It fails because the right instruction was missing, outdated, or buried at the moment someone needed it. Under stress, people do not read long documents. They act on habit, and habit comes from short, clear, rehearsed instructions.
Security guards work under the same pressure. A guard alone at a site at night cannot call a committee to decide what a fire alarm or an unlocked door means. The post orders already answered that question, which is why the best ones are short, concrete, and tied to a single post.
Cyber teams face the same reality with alert fatigue, shift changes, and thin overnight coverage. The gap between “we have a playbook” and “someone followed it” is where breaches grow from minor events into major ones. Post orders are a mature model for closing that gap.
Key Insight: A procedure is only as good as the worst moment it will be used in. Write for the tired, interrupted reader, not the calm author.
What Post Orders Actually Contain
Post orders are a written set of site-specific duties, procedures, and escalation rules that tell a guard exactly how to operate at one post. They are not a general policy manual. They answer practical questions about a single location and a single shift.
A well-built set of post orders typically covers a handful of elements:
- Purpose of the post: what the guard is there to protect and why.
- Routine duties: patrols, access checks, logs, and reporting requirements.
- Special instructions: known risks, restricted areas, or client preferences.
- Emergency procedures: what to do for fire, medical events, intrusions, and threats.
- Contacts and escalation: who to call, in what order, and within what timeframe.
Notice what is absent: background theory, long justifications, and vague guidance such as “use good judgment.” Judgment is trained separately. The post orders supply the decision framework so judgment has something to stand on.
Why specificity beats coverage
A single generic policy applied to ten sites produces ten gaps. A set of orders tailored to each site closes those gaps because it names the actual door, the actual contact, and the actual threshold for escalation. The same logic applies to runbooks. A “ransomware response” document that applies to every system is less useful than a one-page procedure for the file server that holds payroll data.
Where Runbooks Break Down
Runbooks usually fail for four reasons: they are too long, too generic, unowned, and unverified. Each of these has a direct equivalent in poorly written post orders, and each has a known fix.
Too long to use
A forty-page incident response plan is a reference document. During an incident, nobody reads page 23. Post orders solve this by keeping the operational core short and pushing background material into appendices.
Too generic to act on
Phrases like “investigate the alert” or “escalate as appropriate” leave the decision to the person least equipped to make it at that hour. Good orders replace them with triggers and thresholds, such as “if three failed logins come from a new country within ten minutes, lock the account and page the on-call lead.”
Nobody owns it
Guard post orders are tied to a site supervisor who maintains them. Many runbooks have no named owner, so they decay quietly as systems change. An unowned procedure is already out of date; you just have not found out yet.
Nobody checks that it was followed
In guard operations, execution is verified through patrol logs, check-ins, and incident reports. Most cyber runbooks have no equivalent. If you cannot show that a step was performed, you cannot tell whether the procedure works or whether people are quietly skipping it.
| Failure point | Weak runbook | Post-order style fix |
| Length | 40 pages, one document | One-page core, appendices for detail |
| Triggers | “Investigate suspicious activity” | Named conditions with thresholds |
| Ownership | Shared wiki, no author | Single named owner and review date |
| Escalation | “Contact management” | Ordered contact list with time limits |
| Verification | None | Logged steps and post-incident review |
Rewriting a Runbook Using Post-Order Structure
You can convert any runbook into a post-order style procedure in six steps. The goal is a document a new team member could follow on their first overnight shift.
- Define the post. Name the single system, service, or alert type the procedure covers. If it covers more than one, split it.
- State the purpose in one sentence. Explain what is being protected and what a bad outcome looks like.
- List triggers. Write each condition that activates the procedure as a concrete, observable event.
- Write actions as short imperatives. “Isolate the host.” “Reset the credential.” “Record the time and ticket number.”
- Add an escalation ladder. Name roles and backups, with a time limit before moving up a level.
- Define the record. Specify what must be logged so the response can be reviewed later.
Pro Tip: Test each procedure by handing it to someone outside the team and timing how long it takes them to reach the first correct action. If it takes more than two minutes, cut text until it does not.
Keep judgment and instruction separate
Post orders work because they do not try to replace training. They assume the reader is competent and supply the site-specific facts that competence cannot invent: who to call, which door is restricted, what the client expects. Runbooks should follow the same split. Training builds skill; the procedure supplies local detail and decision thresholds.
Write for the handoff
Shift changes are where information leaks. Guard operations rely on shift reports and handover notes so the next person inherits context, not just a post. A runbook should include a short handoff section: open incidents, active exceptions, and anything the next analyst should watch.
Keeping Instructions Alive
A procedure stays reliable only if you review it on a schedule and after every real event. Post orders are updated when a site changes, a client’s requirements shift, or an incident exposes a gap. The same cadence works for runbooks.
Three review triggers cover most cases:
- Scheduled review: a fixed interval, such as quarterly, with the owner signing off.
- Change-driven review: any major system, vendor, or staffing change that affects the procedure.
- Incident-driven review: a short debrief after each real incident asking which instruction helped, which was missing, and which was ignored.
The third trigger is the most valuable. Every real incident is a free test of your documentation, and the debrief converts that test into a better procedure.
Verify, do not assume
Patrol records exist because a written instruction proves nothing about what happened. Logged checkpoints, timestamps, and incident reports show what was actually done. For cyber teams, ticket notes, timestamps on containment actions, and structured incident records serve the same function. Without them, post-incident reviews rely on memory, and memory favors a tidy story.
A Concrete Example: The After-Hours Phishing Alert
Consider a mid-sized company whose overnight IT coverage is a single analyst. The existing runbook for suspected phishing is six pages long and begins with a definition of phishing. At 2 a.m., an alert shows that one employee clicked a credential-harvesting link and entered a password.
The analyst skims the document, cannot find a clear first step, and waits until morning to message the security lead. By then the credential has been used to access a shared mailbox for six hours.
The team rewrites the procedure in post-order style. The new one-page version has a single purpose line, a trigger (“user submitted credentials to a flagged domain”), and four imperative steps: disable the account, revoke active sessions, record the time, and page the on-call lead within ten minutes. A named owner and a quarterly review date sit at the top.
Three months later, a similar alert fires. The analyst completes the containment steps in under five minutes, pages the lead, and logs each action. The debrief adds one line about checking forwarding rules, and the owner updates the page the same day.
Actionable Takeaways
- Pick your three highest-risk alert types and rewrite each as a one-page procedure with a trigger, actions, and an escalation ladder.
- Assign a named owner and a review date to every runbook, and remove any that nobody will claim.
- Replace vague verbs such as “investigate” and “assess” with specific, observable actions.
- Add a logging requirement to each procedure so every response leaves a reviewable record.
- Run a timed test with someone outside the team to confirm the first action is clear in under two minutes.
- Hold a short debrief after every real incident and update the procedure within a week.
Conclusion
Post orders endure in guard operations because they respect how people actually behave at 3 a.m. They are short, specific, owned, and checked. Cyber and IT teams can adopt the same discipline without new tools: shorter documents, sharper triggers, named owners, and a habit of reviewing what happened. The result is a procedure people follow instead of one they merely have.
FAQ
What are post orders in security?
Post orders are written, site-specific instructions that define a guard’s duties, procedures, and escalation contacts for one post. They cover routine tasks, emergency responses, and special requirements so a guard can act consistently without needing to ask for direction.
How are post orders different from a general security policy?
A security policy sets broad rules for an organization, while post orders apply those rules to one specific location and role. The difference is specificity: post orders name the actual doors, contacts, and thresholds that a general policy leaves out.
Why do incident response runbooks fail in practice?
Runbooks usually fail because they are too long, too generic, unowned, or unverified. Under stress, people cannot find the relevant step, and nobody checks whether the procedure was followed, so gaps stay hidden until a real incident exposes them.
How long should an incident runbook be?
The operational core of a runbook should fit on one page, with supporting detail placed in appendices. A new team member should be able to reach the first correct action in under two minutes, and that goal should drive how much text you keep.
How often should runbooks be reviewed?
Review each runbook on a fixed schedule, such as quarterly, and again after any major system change or real incident. The post-incident review is the most useful because it shows exactly which instructions helped and which were missing or ignored.
