Write a policy to state what the organization intends, a standard to set a measurable rule, a guideline to advise, a runbook to give steps under pressure, and an FAQ to answer one repeated question. Mixing them in one page is why most security documents get ignored.
The five document types side by side
| Type | Purpose | Reader | Changes | Length |
|---|---|---|---|---|
| Policy | Intent and accountability | Everyone, auditors | Rarely | One to three pages |
| Standard | A measurable rule that supports the policy | Engineers, reviewers | A few times a year | One to two pages per topic |
| Guideline | Advice where judgment is allowed | Engineers | As needed | Short |
| Runbook | Ordered steps for a known situation | The person on call | After every use | One page, often a list |
| FAQ | A direct answer to a repeated question | Anyone | When answers change | A few lines per question |
A worked example
Take access to production data.
- The policy says production data is accessed by people with a business need, and that access is reviewed.
- The standard says access is granted through the identity provider, expires after a fixed period, and is reviewed quarterly.
- The guideline suggests how to request the narrowest role.
- The runbook lists the steps to revoke access when someone leaves or a laptop is lost.
- The FAQ answers "Can I borrow a colleague's login to debug?" with a clear no and what to do instead.
Each one answers a different question. None of them repeats the others.
How to choose in three questions
- Is this a statement of intent that leadership signs? Write a policy.
- Can someone check compliance with a yes or no? Write a standard.
- Will someone follow it during an incident with a clock running? Write a runbook, and keep each step an action.
If none fits and you keep answering the same chat question, write an FAQ entry. If the answer needs judgment, write a guideline.
Common mistakes
- A policy full of commands. It will be out of date the day tooling changes. Move commands into a runbook.
- A runbook full of rationale. Link to the decision record instead. See architecture decision records for security choices.
- A standard nobody can test. If you cannot say how to verify it, it is a guideline.
- An FAQ that is really a policy. If the answer is "it depends on 12 factors", write the guideline and link it.
Layering and ownership
Link downward: policy to standard to runbook. Link sideways from the FAQ to whichever page holds the full answer. Give each document a named owner and a review date, and list both at the top of the page.
For the incident side of this split, policy vs plan vs playbook covers the same idea in more depth.
Where Safeguard fits
Standards are easier to keep honest when a tool enforces them. Safeguard policies, gates and guardrails can turn a written dependency rule into a check on pull requests, so the document describes what the system actually does.
Quick check
Is a standard the same as a policy?
No. A policy states intent in general terms. A standard is a specific, testable rule that supports it, such as a maximum age for an access grant.
How long should a runbook be?
As short as the task allows, usually one page. If it needs more, split it into a main runbook and linked sub procedures.
Last reviewed: 19 October 2026.
