ISO 27001 Policy vs. Procedure: What Auditors Expect

A policy says what your organization commits to and why. A procedure says how a named person carries it out, step by step. In an ISO 27001 project you need both, they must agree with each other, and an auditor will test the link between them. A policy with no procedure is a promise nobody can keep. A procedure with no policy is a habit nobody has authorized.

This guide shows where the line falls, which documents sit on each side, how they are tested in a certification audit, and how to plan the writing work so it does not swallow your timeline.

TL;DR

• Policy = what and why. Short, approved by management, and written for everyone in scope. Procedure = how. Specific steps, owners, timing and records.
• ISO 27001 asks top management to set an information security policy. Beyond that, which topic policies and procedures you need depends on your risk assessment and the controls you select.
• Auditors follow a chain: policy, then procedure, then evidence that people actually did it. A break anywhere in the chain becomes a finding.
• Keep policies stable and procedures easy to change. Mixing the two makes every small process update a management sign-off.
• Writing documents is a real share of the effort. Estimate it before you commit to a date.

Table of Contents

• The difference in one table
• Where standards and guidelines fit
• What ISO 27001 actually requires
• The documents on each side
• The maturity chain auditors implicitly test
• How a certification audit tests policy and procedure
• Seven mistakes that cause findings
• How to write them without drowning
• What this does to your timeline and budget
• Our perspective
• Plan the documentation workload
• FAQ
• Sources

The difference in one table

The definitions below follow how U.S. standards bodies use the words. NIST’s glossary describes a security policy as the set of rules and practices that regulate how an organization manages, protects and distributes sensitive information. Procedures are the operational layer that makes those rules happen.

The last row is the one to keep in mind. The policy line is true for years. The procedure line breaks the day you change ticketing tools.

Where standards and guidelines fit

People often add two more words to the mix and get tangled.

• Standard: a mandatory, specific rule that supports a policy, such as “passwords must be at least 14 characters.”
• Guideline: advice that is recommended but not mandatory.

You do not need a document of each type for every topic. Small companies usually fold standards into the policy as a short list of requirements, and fold guidelines into the procedure as tips. What matters is that every rule has a clear status: required or advisory. If an employee cannot tell which one they are reading, the document has failed.

What ISO 27001 actually requires

ISO/IEC 27001 is a requirements standard. As ISO describes it, it defines what an information security management system (ISMS) must meet, and it is open to companies of any size and sector. It does not hand you a template pile.

The practical reading:

1. One policy is explicit. The standard asks top management to establish an information security policy, communicate it and keep it available to interested parties.
2. Everything else is risk-driven. The controls in Annex A are selected through your risk assessment and recorded in your Statement of Applicability. Each selected control that needs rules usually ends up with a topic-specific policy, and many need a procedure behind them.
3. Documented information must be controlled. Whatever you write needs an owner, a version, an approval and a review date.

This is why “how many policies do I need?” has no single answer. Our own 18 core policies guide lists the set most audit-ready programs end up with, and the ISMS policy template gives you the top-level document to start from. Treat both as a starting point to tailor, not a quota to hit.

The documents on each side

Policies you will likely write

• Information security policy (the top-level one)
• Access control
• Acceptable use
• Asset management
• Incident response
• Business continuity and disaster recovery
• Supplier and third-party security
• Secure development, if you build software
• Cryptography and key management
• Remote work and mobile devices

Procedures that make them real

• User access provisioning and removal (joiners, movers, leavers)
• Incident reporting and escalation steps
• Backup and restore
• Change management
• Vulnerability and patch handling
• Supplier onboarding and review
• Log review
• Document control

The pairing is the point. Take the access control policy: it states that access is least-privilege and reviewed. The access review procedure says who pulls the account list, who signs off, how exceptions are logged, and where the record is saved. If your policy makes a promise that no procedure carries out, that is where an auditor will probe.

The maturity chain auditors implicitly test

NIST once published a program review model, PRISMA, that rates security maturity in five levels: policy, procedures, implementation, test and integration. The project page notes it was last updated in 2007 and is no longer supported, so use it as a mental model rather than a requirement. The lesson holds up well: a higher level cannot be reached if the one before it is missing. You cannot claim a working implementation when no policy defines the requirement.

ISO 27001 auditors do not use those five labels, but the questions they ask map onto them:

1. Is there a policy? Approved, current, and communicated.
2. Is there a procedure? Specific enough that a new hire could follow it.
3. Does practice match? They sample real tickets, logs and records.
4. Do you check it? Internal audits and management review.
5. Do you improve it? Corrective actions that close.

Knowing this changes how you write. Do not draft documents to look impressive. Draft them so that the next three questions have answers.

How a certification audit tests policy and procedure

Certification happens in two stages. In the Stage 1 and Stage 2 structure described by one U.S. audit firm, Stage 1 is a documentation review and Stage 2 is an operational audit. Our own walkthrough of the audit stages goes deeper on sample records.

Stage 1 looks at the paper. The auditor wants to see that the policy exists, that scope is defined, and that your documents cover the controls you said apply. Weak points here are policies that contradict each other, missing approvals, and a Statement of Applicability pointing at documents that do not exist.

Stage 2 looks at the behavior. Here the procedure is the star. The auditor picks a few people and asks them to show how they handle, for example, a leaver. If your procedure says access is removed on the last day and the ticket shows it happened three weeks later, you have a nonconformity. The policy was fine. The gap was between procedure and practice.

Before either stage, your internal audit should already have run this exercise on yourself.

Seven mistakes that cause findings

1. Procedures written inside the policy. The policy then needs board-level approval for every tool change.
2. Policies copied from a template and never read. Staff say one thing, the document says another. Auditors interview staff.
3. Procedures nobody uses. If the real process lives in someone’s head or a chat thread, document that real process, then improve it.
4. No owner. Every document needs a named role, not a department.
5. No evidence trail. A procedure that produces no record cannot be shown to work. Define the record up front: a ticket, a signed checklist, a log export.
6. Stale review dates. Set annual policy review and trigger-based procedure review, such as after an incident or a tool change.
7. Vague verbs. “Should” and “where possible” in a policy give you nothing to audit against. Use “must” for rules you will enforce.

How to write them without drowning

A workable order for a team that is starting from nothing:

1. Define scope and run the risk assessment first. It tells you which controls apply, and so which documents you need. Writing before this means rewriting after.
2. Write the top-level policy. Keep it short and get management to approve it visibly.
3. Write topic policies only where a control calls for one. Merge small topics. A ten-person company does not need twenty separate documents.
4. Document what people actually do. Interview the person who does the task, write the steps, then tighten them.
5. Link each procedure to its policy and control. A simple mapping table saves hours in the audit.
6. Pilot with real work. Run the procedure on live tasks for a few weeks so records exist before Stage 2.
7. Version and review. Put revision history on every page.

If you want the full sequence, our 80-step certification checklist places document writing within the whole project. For smaller teams, the small business guide shows how to keep the document set lean.

What this does to your timeline and budget

Documentation rarely looks expensive until it is late. One U.S. audit firm puts certification for a small-to-mid-sized organization at 6 to 12 months, covering the ISMS build, risk assessment, controls, internal audit and both audit stages. Policy and procedure writing runs through the first half of that, and it competes for the same people who run the controls: IT, HR, and engineering leads.

Three things push effort up:

• Number of in-scope processes. Each one with a real control usually needs a procedure.
• Maturity today. Teams that already have informal routines document faster than teams starting from scratch.
• Reviewer availability. Procedures need sign-off from the people who own the work, and their calendars set the pace.

The implementation timeline and the certification timeline articles show how the phases overlap.

Our perspective

We build an estimating tool for ISO 27001 projects, so we see where plans go wrong before work starts. The most common mistake is treating documentation as a one-week task done by whoever has spare time. It is a project with owners, reviewers and a calendar.

We also see teams collapse policy and procedure into one long document because it feels efficient. It is efficient for about a month. Then a tool changes, the document needs management approval to edit, and nobody edits it. Keep the layers apart: a short policy that leadership owns and a living procedure that the doers own.

Our practical advice is to scope first, estimate the documentation effort honestly by maturity level and company size, and then test your plan against model reference comparisons. If your figures look far from similar organizations, find out why before you commit to an audit date. That is the reason our calculator shows its assumptions and lets you edit them, and why the methodology is open to inspection.

— Martin

Plan the documentation workload

If you are not sure how much policy and procedure writing your project needs, start with the free 2-minute readiness check. It shows where your gaps are without requiring a signup. Then use the ISO 27001 cost calculator to turn company size, industry and security maturity into an effort and cost estimate you can edit, save and compare. For a domain-by-domain view across all 14 ISO areas, the readiness assessment is the deeper option.

FAQ

Is a procedure mandatory for every ISO 27001 policy?

No. The standard does not hand you a one-to-one rule. A procedure is needed wherever a task must be done consistently, is done rarely, or is risky if done wrong. For simple topics a few clear sentences inside the policy may be enough, as long as someone can show they are followed.

Who approves a policy, and who approves a procedure?

Top management approves the information security policy and normally the key topic policies. Procedures are usually approved by the process owner, with a security or compliance review. Record each approval with a name, role and date.

Can one document be both a policy and a procedure?

It can, but we advise against it. Policies should stay stable and procedures should change as your tools change. Combining them means every small update needs the same approval as a rule change, so updates get skipped and the document drifts out of date.

Is an ISMS the same as ISO 27001?

Not quite. An ISMS is the management system itself: the policies, procedures, roles, risk process and records you operate. ISO 27001 is the standard that sets requirements for that system, and certification checks that your ISMS meets them.

How often should we review them?

Review policies at least once a year and after major changes such as a new business line or a significant incident. Review procedures whenever the underlying tool, team or workflow changes. Keep the review date on the document itself.

Sources

• NIST CSRC glossary: security policy
• NIST PRISMA security maturity levels
• ISO/IEC 27001:2022 overview, ISO
• ISO 27001 certification in the USA, CertPro

Recommended

• Free ISO 27001 Readiness Check — 2-Minute Self-Assessment
• Logging and Monitoring for ISO 27001: What Auditors Expect
• ISO 27001 Certification Checklist: 80 Steps to Certification
• 18 Core Policies for an Audit-Ready ISO 27001 Policy Set