Policies vs Standards vs Procedures vs Guidelines: What's the Difference?
When your IT partner asks you to "write a policy", do they mean a one-page statement or a 20-page manual? The confusion between these four document types is one of the most common stumbling blocks in cybersecurity documentation — and getting it wrong wastes a lot of effort.
The four document types form a hierarchy. Each builds on the one above it. Understanding which type you're writing determines who owns it, how often it changes, and how specific it needs to be.
The Four-Tier Hierarchy
Policy
The "what" and "why"
A policy is a high-level statement of intent. It says what the organisation wants to achieve and why it matters — but not how. Policies are owned by management, approved at board level, and rarely change. They typically fit on one or two pages.
Example
"The organisation will maintain regular backups of all critical data to ensure business continuity in the event of a system failure or cyber incident."
- Written for management and auditors
- Technology-agnostic (doesn't name specific tools)
- Reviewed annually or when the business changes significantly
- Violation has formal consequences
Standard
The "how much"
A standard defines the specific, measurable requirements that implement a policy. It answers "how much", "how often", "what level". Standards are more technical than policies and can reference specific configurations or thresholds. They are mandatory, like policies.
Example
"Critical data must be backed up daily. Backups must follow the 3-2-1 rule: 3 copies, on 2 different media types, with 1 copy offsite. Recovery must be tested quarterly."
- Specific and measurable
- May reference technology or vendor products
- Mandatory — not optional
- Updated when technology or risk landscape changes
Procedure
The "how to"
A procedure is a step-by-step description of how to perform a specific task to meet a standard. Procedures are operational documents — they're used by the people actually doing the work. They change frequently as tools and processes evolve.
Example
"Step 1: Log into the backup management console at [URL]. Step 2: Verify last night's backup job completed successfully. Step 3: If the job failed, escalate to the IT partner within 2 hours..."
- Written for the person doing the task
- Tool-specific and detailed
- Updated whenever processes or tools change
- Often includes screenshots or checklists
Guideline
The "recommended approach"
Guidelines are non-mandatory recommendations. They offer best practices, suggested approaches, or helpful context — but following them is optional. They're useful for situations where rigid rules don't make sense because context varies.
Example
"When selecting a cloud backup provider, consider vendors with ISO 27001 certification and data centres located within the EU. Avoid providers that store data in jurisdictions with weak privacy laws."
- Voluntary — not mandatory
- Useful where judgment is needed
- Provides context and rationale
- Updated as best practices evolve
Why the Distinction Matters
Mixing up these types creates two common problems:
Policies written like procedures
A 30-page "policy" that describes every technical step becomes unmanageable. When tools change, the entire policy must be rewritten and re-approved. Keep policies short and technology-agnostic — the procedures are where the detail lives.
Procedures without a policy foundation
If you have step-by-step instructions but no underlying policy, you have no framework for decisions. When an exception arises, nobody knows what the intent is. Policies give procedures their authority.
How This Maps to CyFun and NIS2
CyberFundamentals (CyFun) controls typically require evidence across all four document types:
| Control | Policy | Standard | Procedure | Guideline |
|---|---|---|---|---|
| Access Control | Access Control Policy | Password length, MFA requirements | How to provision/revoke user accounts | Recommended password manager tools |
| Backup & Recovery | Business Continuity Policy | 3-2-1 rule, RTO/RPO targets | Daily backup verification steps | Suggested backup software options |
| Incident Response | Incident Response Policy | Response time requirements, reporting thresholds | Step-by-step incident handling playbook | Communication templates for incidents |
During a CyFun or NIS2 audit, auditors check for all four layers. A procedure without a backing policy is a gap. A policy without any implementing procedures is also a gap.
Where to Start
The right order is top-down: write policies first, derive standards from them, then procedures.
Identify your scope
Which areas need documentation? For CyFun Basic, the minimum set includes: access control, backup, incident response, acceptable use, and patch management.
Write one-page policies first
Each policy should answer: What are we protecting? Why does it matter? What is the overall approach? Who is responsible? Keep it under two pages.
Derive standards from each policy
For each policy, list the specific measurable requirements. What exactly must happen? How often? To what threshold? These become your standards.
Write procedures for operational tasks
Identify which standards require recurring human action. Write step-by-step procedures for those tasks. Assign an owner.
Add guidelines where judgment is needed
For decisions where context varies (e.g. vendor selection, tool choice), document your recommended approach as a guideline rather than a rule.
Frequently Asked Questions
Do small SMEs really need all four document types?
For NIS2 and CyFun compliance, yes — auditors expect to see policies and at least some standards and procedures. Guidelines are optional. But "all four types" doesn't mean a huge amount of paperwork. A 10-person SME might have 5 one-page policies, 5 standards documents, and 10 short procedures. That's manageable.
Who should own each document type?
Policies are owned by management (CEO, COO, or board). Standards are typically owned by IT or the IT partner. Procedures are owned by the team doing the work. Guidelines are often owned by IT or the MSP.
How often should we review these documents?
Policies: annually or when the business changes significantly. Standards: when technology changes or new risks emerge. Procedures: whenever the underlying process or tool changes. Guidelines: as best practices evolve. For NIS2, you need to be able to show that documents are reviewed regularly — so date them and keep a revision history.
Our IT partner gave us a 50-page "policy" document. Is that normal?
It's common but not ideal. What's usually happening is that a policy, standard, and procedure have been merged into one document. That's not wrong, but it makes updates harder. As you mature your compliance programme, consider splitting them. For a first audit, a consolidated document is usually acceptable.
Does Easy Cyber Protection help with these documents?
Yes. The platform stores your policies, standards, and procedures as wiki pages linked to specific CyFun controls. You can generate policy drafts from templates, track which controls have documentation, and export documents for audits.
Related Articles
Last updated: April 2026