Policy vs standard vs SOP: getting the layer right

Before you write anything, know what you’re writing.

Four document types cover most IT operations. Each answers a different question. Confusing them — writing a policy when you needed an SOP, or promoting an SOP into a policy because it sounds more serious — produces documents nobody uses and audit findings nobody expected.

The four types, in one sentence each

• Policy — the rule. Answers what is expected, and why.
• Standard — the requirement that makes the rule measurable. Answers what must be achieved.
• Procedure (SOP) — the steps. Answers how to do the thing.
• Work instruction — the granular detail inside a step. Answers exactly how to do that one action.

They stack:

Policy → Standard → Procedure (SOP) → Work Instruction

Each layer is more specific than the one above it. Higher layers change rarely (annual review is typical); lower layers change with tooling, version upgrades, and incidents.

A worked example: SSH access

Same subject, four documents:

Policy

All access to production Linux servers must use per-human accounts with cryptographic authentication. Shared accounts, password authentication, and root logins are prohibited.

One sentence, high-level, rarely changes. It doesn’t tell you what “cryptographic authentication” means or which algorithm to use — that’s not its job.

Standard

SSH-STD-001 — SSH authentication key requirements

• Algorithm: Ed25519. RSA 4096 permitted only for compatibility with systems that pre-date OpenSSH 6.5.
• Passphrase: mandatory. Stored in the approved password manager.
• Key comment: must include the operator’s email and issue date in name@company-YYYY-MM-DD format.
• Rotation cadence: annually, or immediately on suspected compromise.

Measurable. Auditable. A key without a dated comment fails the standard. A key on a shared account fails the standard and the policy above it.

Procedure (SOP)

SOP-002 — SSH key rotation on production Linux servers

Step 1: Generate a new Ed25519 keypair on your workstation using the naming convention in SSH-STD-001.

Step 2: Deploy the public key to every in-scope server with ssh-copy-id.

Step 3: Test authentication with the new key before removing the old one.

…

Numbered steps. The operator can execute this at 2 a.m. without inventing anything.

Work instruction

WI-002.1 — Generating an Ed25519 keypair on OpenSSH

1ssh-keygen -t ed25519 -C "[email protected]$(date +%Y-%m-%d)" \
2           -f ~/.ssh/id_ed25519_prod

When prompted, enter and confirm a passphrase from your password manager. Do not accept the default empty passphrase.

The single command, with flag-level detail. In smaller teams the work instruction is usually absorbed into the SOP step; only pull it out into its own document when the step needs more than a couple of lines of explanation.

The most common mistake: writing a policy when you needed an SOP

Small teams overwhelmingly do this. The instinct is understandable — “policy” sounds more serious, more finished, more like the kind of thing an auditor wants to see.

The auditor wants both. But the auditor wants the SOP first, because that’s the evidence the policy is actually enforced. A three-page policy with no supporting SOPs reads as aspirational. An SOP with a one-paragraph policy above it reads as controlled.

Symptom: your “SSH access policy” runs to four pages, describes step-by-step how to generate keys, mentions specific package versions, and has to be revised every time OpenSSH ships a new release.

That’s an SOP with a policy header stapled to the top. Split them.

The second most common mistake: skipping standards entirely

Standards feel redundant if you’re small — the policy says “use strong authentication”, the SOP says “run ssh-keygen -t ed25519”, and you figure the middle layer is obvious.

It is, until:

• A junior operator generates an RSA-2048 key because it “worked” and nobody wrote down that Ed25519 was mandatory.
• An auditor asks why Ed25519 specifically and you have no reference document to hand them.
• You add a second SOP (backup key rotation, say) and it references a different key type because the writer had different assumptions.

The standard exists to remove those failure modes. In a very small team you can absorb it into the policy — a short “Requirements” section — but don’t just skip it.

How to decide which type you’re writing

Ask two questions:

1. Does this change more than once a year? If yes, it isn’t a policy — it’s a standard or an SOP.
2. Does it name specific commands, versions, or tools? If yes, it isn’t a policy or a standard — it’s an SOP or a work instruction.

Cross those two:

The bottom-right cell — changes often and names tooling — is where the vast majority of operational documentation lives. That’s the SOP, which is what next week’s article is about.

In practice, for a small team

You probably need:

• A handful of policies — maybe six to ten total across security, access, change management, incident response, backups, data handling. Approved by whoever owns the risk. Reviewed annually.
• A short standards register — key types, TLS baselines, patch windows, retention periods. Referenced by both policies and SOPs.
• A working SOP library — one per recurring operational task. This is the layer that grows. Aim for coverage of every task performed at least monthly.
• Work instructions on demand — pull them out of SOPs only when a step is complex enough that inlining bloats the SOP.

If you have twelve policies and one SOP, the ratio is wrong. Fix it before your next audit prep, not during it.

Get the template

A fillable Word template built on the eight-section structure Week 4 walks through:

Download: SOP-Template-StackHarden.docx (15 KB)

Fork it into your own document management system, fill in the placeholders, delete the guidance notes, and you have a v1.0 SOP that will pass a first-look audit. Weeks 3 and 4 cover the writing rules and the section-by-section detail; Week 5 walks through a production SSH-key-rotation SOP built on the same template.

Next in this series

• Week 3 — Five writing rules that make SOPs usable at 2 a.m.
• Week 4 — The eight-section SOP structure auditors expect.

Further reading

• ISO/IEC 27001:2022 §7.5 — Documented information.
• ISO 9001:2015 §7.5 — Documented information (the pattern is cross-standard).
• FDA (2022). A basic guide to writing effective standard operating procedures. Applies wider than pharma; the layer model is transferable.