Policy vs standard vs procedure vs guideline

Most organisations write everything as a "policy", then discover the problem at audit: they are held to every sentence in it. The four document types exist to separate what you commit to from how you happen to do it today - and that separation is what keeps you from manufacturing your own nonconformities.

The four types

Policy - what and why

A short statement of intent and principle, approved at a senior level. It says what must be achieved and who is accountable, not how. It should change rarely - a policy that changes quarterly is doing a standard's job.

Example: "Access to information systems shall be granted on the principle of least privilege and reviewed periodically."

Standard - the mandatory specifics

Measurable, mandatory requirements that implement the policy. Standards specify the thresholds - lengths, versions, frequencies, algorithms. They change as technology changes, without touching the policy.

Example: "Privileged access shall be reviewed quarterly. Multi-factor authentication is required for all external access."

Procedure - the steps

How a specific task is performed, step by step, by a named role. Procedures are operational and change often. They are also what produces your evidence.

Example: "To perform the quarterly access review: 1. Export the user list from the identity provider. 2. Send to system owner. 3. Record decisions..."

Guideline - recommended practice

Advisory, not mandatory. Helps people make good decisions where flexibility is appropriate. The word "should" belongs here, and only here.

Example: "Where practical, prefer passkeys over one-time codes."

Why the distinction matters at audit

Auditors test you against your own documents. If your policy states access is reviewed quarterly and you review annually, that is a nonconformity you created yourself - not a security failure but a documentation one.

Put commitments where they belong. A policy saying "access shall be reviewed periodically" plus a standard saying "quarterly for privileged accounts" lets you adjust the cadence by amending a standard, rather than reopening a board-approved policy.

Approval and change

• Policies - approved by top management or the board. Reviewed annually. Changed rarely.
• Standards - approved by the security or risk function. Reviewed at least annually, changed as technology moves.
• Procedures - approved by the process owner. Changed whenever the process changes.
• Guidelines - lightweight ownership, updated freely.

Matching approval authority to change frequency is the practical reason the hierarchy exists. If every change needs board sign-off, documents go stale; if nothing needs it, nothing is governed.

Language discipline

• Shall / must - mandatory. Use in policies and standards, and be certain you can evidence it.
• Should - recommended. Guidelines only. Using "should" in a policy creates ambiguity an auditor will probe.
• May - permitted. Use sparingly and define the boundaries.

Keeping the set maintainable

1. Fewer, better documents. Twelve policies nobody reads is worse than five that are followed.
2. One owner per document, named, with a review date.
3. Version control with superseded versions retained - assessments were made against them.
4. Evidence of communication and acknowledgement, not just approval.
5. Cross-reference downward - policy names the standards beneath it, standard names the procedures.
6. Write what you do, then raise commitments deliberately as you implement them.

Key takeaways

• Policy = what and why; standard = mandatory specifics; procedure = steps; guideline = advice.
• You are audited against your own documents - do not overcommit.
• Put thresholds in standards so they can change without board approval.
• Reserve "should" for guidelines; "shall" means evidenced.