The audit that stopped at document one
Denholm Freight Solutions had been preparing for ISO 27001 certification for eleven months when the Stage 1 auditor asked a question that stopped the room cold: "Which of these thirty-eight documents is your information security policy?"
Priya Nandekar, the newly appointed IT and security manager at the 260-employee logistics company, had inherited a SharePoint library that had grown the way most policy libraries grow — organically, unsupervised, and over a decade. There was a 2014 "IT Security Policy" written by a departed sysadmin. There was a 2019 "Data Protection Policy" drafted by an outside law firm for a GDPR engagement that referenced a data processor Denholm hadn't used since 2021. There was a "Password Policy," a "Password Standard," and a "Password Guideline," each with different minimum-length requirements. There was an "Acceptable Use Policy" that banned personal email on company laptops, sitting three folders away from a "Remote Working Policy" that assumed employees would use personal email to forward files home. Nobody could say who had approved any of them. Nobody could say when they had last been reviewed. And when the auditor asked a warehouse supervisor and a dispatch coordinator, at random, whether they had read the acceptable use policy, both said they had never heard of it.
Priya counted afterward: forty-one separate policy-like documents, no version control, no approval trail, no acknowledgement records, and at least six pairs of documents that contradicted each other outright. The Stage 1 auditor didn't fail the audit outright — Stage 1 is a readiness check, not a certification decision — but issued a major nonconformity against control 5.1 and told Denholm's leadership, bluntly, that Stage 2 would not proceed until the policy framework was rebuilt from the ground up. The knock-on cost was real: a four-month certification delay, a renegotiated Stage 2 date, roughly $38,000 in extended consultant fees and re-audit costs, and — the part that actually got the board's attention — a mid-six-figure logistics contract with a European retailer that had made ISO 27001 certification a hard contractual deadline. Denholm missed it.
Control 5.1 looks, on paper, like the easiest control in Annex A. Write a policy, get it signed, tell people about it. In practice, it is the control I see organizations get wrong more often than almost any other, because "we have a policy" and "we have a policy that satisfies 5.1" are very different claims. This article exists to close that gap: what 5.1 actually requires, how the top-level policy relates to your topic-specific policies, how to run approval, communication, acknowledgement, and review so an auditor can trace every step, and what a right-sized policy architecture looks like whether you're 40 people or 4,000.
Who this is for and what you'll walk away with
This is for the person who owns the policy library — a CISO, information security manager, compliance lead, or the "accidental ISMS owner" handed the job alongside three other titles — heading into an ISO 27001 implementation or gap remediation. You'll walk away with a clear model for what belongs in a top-level information security policy versus a topic-specific policy, a ready-to-adapt table mapping the topic-specific policies I recommend to the Annex A controls they support, the exact evidence trail (approval, publication, communication, acknowledgement, review) an auditor will ask to see, and architecture patterns sized for a 40-person company, a 400-person company, and a multinational. If you finish this article and can point to a document that names your policy owner, your review cadence, and your last acknowledgement campaign, you are in materially better shape than Denholm was on the day their auditor walked in.
What Annex A control 5.1 actually requires
Control 5.1, "Policies for information security," sits at the top of the Organizational controls theme (A.5, controls 5.1–5.37) in ISO/IEC 27001:2022's Annex A. Stripped to its operative language, the control requires that:
An information security policy and a set of topic-specific policies are defined — meaning written down, with defined scope and content, not implied by practice.
Both are approved by management — a named, authorized decision, not silent tolerance.
Both are published and communicated to relevant personnel and relevant interested parties — internal staff, but also, where applicable, contractors, suppliers, and other external parties whose actions the policy governs.
Both are acknowledged by the people they apply to — a positive, recorded act, not an assumption that publication equals awareness.
Both are reviewed at planned intervals and whenever significant changes occur — a scheduled cadence plus an event-triggered mechanism, not a "we'll get to it" approach.
ISO/IEC 27002:2022, the companion guidance standard, adds context rather than new obligations: it classifies control 5.1 with its five attributes — control type (preventive), the information security properties it supports (confidentiality, integrity, and availability), the cybersecurity concept it maps to (Identify), the operational capability (governance), and the security domain (governance and ecosystem). None of that changes what you have to do, but it's a useful reminder that this is fundamentally a governance control, not a technical one — its job is to make every other control's expectations explicit, approved, and known, which is exactly why it sits first in Annex A's numbering.
Every one of those verbs — define, approve, publish, communicate, acknowledge, review — is something an auditor can ask you to evidence independently. That's the trap in Denholm's story: they had documents (defined, arguably), but nothing to show for approval, nothing for communication, and nothing for acknowledgement. A control that looks like a single line item in Annex A is actually five separate obligations, each with its own paper trail.
Table 1: Control 5.1 — the five obligations and what auditors ask for
Obligation | What it means in practice | Typical audit evidence request |
|---|---|---|
Defined | Policy content exists, is version-controlled, and has clear scope | Current policy document with version number and effective date |
Approved by management | A named executive or governance body signed off | Approval record — signature, meeting minutes, or workflow log |
Published | The policy is accessible to everyone it applies to | Location/URL, publication date, access logs if available |
Communicated | Relevant personnel and interested parties were actively told | Email/training records, induction materials, supplier notices |
Acknowledged | Individuals confirmed they read and will comply | Signed/e-signed acknowledgement records, LMS completion reports |
Reviewed | Checked on a planned schedule and after significant change | Review log with dates, reviewer names, and change triggers |
Crucial distinction: Control 5.1 is not Clause 5.2, and neither is Clause 5 in general
This is the single most common confusion I see in first-time implementations, and it's worth being precise about, because auditors will test whether you understand it.
Clause 5 ("Leadership") in the main body of ISO/IEC 27001:2022 is a management-system requirement. It obligates top management to demonstrate leadership and commitment to the ISMS — ensuring policy and objectives are established and compatible with strategic direction, ensuring resources are available, communicating the importance of effective information security management, and so on. You can read the full requirement in our companion piece on ISO 27001 Clause 5 leadership and management commitment requirements.
Clause 5.2 ("Policy"), a sub-clause of Clause 5, is the specific management-system requirement that top management establish an information security policy — one with defined characteristics (appropriate to the organization's purpose, includes objectives or a framework for setting them, includes a commitment to satisfy applicable requirements, includes a commitment to continual improvement). Clause 5.2 tells you the top-level policy must exist and what it must contain as a management-system artifact.
Annex A control 5.1 ("Policies for information security"), the subject of this article, is different in kind. It's an operational control that requires the policy framework — the top-level policy that Clause 5.2 mandates, plus the full set of topic-specific policies underneath it — to be defined, approved, published, communicated, acknowledged, and reviewed on a lifecycle. Clause 5.2 asks "does a top policy exist and does it say the right things?" Control 5.1 asks "is your entire policy architecture — top-level and topic-specific — being actively governed as a living set of documents?"
In practice, most organizations satisfy both with the same top-level document and program: the policy Clause 5.2 requires becomes the top-level policy that control 5.1 governs, and the topic-specific policies extend it. But don't conflate them in your documentation or your Statement of Applicability — an auditor testing Clause 5.2 will look at policy content and top-management ownership; an auditor testing control 5.1 will look at your entire policy library and its lifecycle evidence, including topic-specific documents that have nothing to do with Clause 5.2's specific content requirements. If you want the full walkthrough of how Clause 5.2 fits inside the broader Clause 5 leadership requirements, see the related article; if you want the complete map of how all 37 Organizational controls (5.1–5.37) relate to each other, our Annex A organizational controls overview is the reference point.
Table 2: Clause 5, Clause 5.2, and Control 5.1 side by side
Clause 5 (Leadership) | Clause 5.2 (Policy) | Annex A Control 5.1 (Policies for information security) | |
|---|---|---|---|
Type | Management-system clause | Management-system sub-clause | Annex A control |
What it governs | Top management's demonstrated commitment overall | Existence and content of the top-level policy | Lifecycle of the entire policy set (top-level + topic-specific) |
Owner in practice | CEO / executive team | CEO / executive team | CISO or information security manager, with management approval |
Evidence focus | Leadership actions, resource allocation, communication | Signed top-level policy document with required content | Approval logs, publication records, acknowledgement records, review history across all policies |
Mandatory document? | No standalone document; evidenced through actions | Yes — the information security policy itself | Yes — the policy plus every topic-specific policy in scope |
"I've sat through audits where the client proudly hands over a beautiful top-level policy and nothing else, thinking that's Clause 5.2 and control 5.1 handled. It's not. Control 5.1 wants the whole tree — trunk and branches — with a growth ring for every review." — Marcus Whitfield, Lead Auditor, Halborn Assurance Group
Top-level policy vs. topic-specific policies
The information security policy (singular, top-level) is your constitution. It states management's commitment to information security, sets the objectives or the framework for setting them, states the organization's risk appetite in broad terms, and assigns overall accountability. It is short — typically two to four pages — because its job is to be durable. A well-written top-level policy should survive a reorganization, a new CISO, and a couple of technology refreshes without needing a rewrite.
Topic-specific policies are where the operational detail lives. Each one governs a defined area — access control, acceptable use, cryptography, supplier relationships, backup — and each one should map cleanly to the Annex A controls it operationalizes. Topic-specific policies change more often than the top-level policy, because they track technology, tooling, and threat landscape. They are also where most of your acknowledgement and training activity concentrates, because different roles need different topic-specific policies: a warehouse worker needs the acceptable use and physical security policies; a developer needs secure development and access control; a finance clerk needs information transfer and classification.
Getting this split right solves two problems at once. First, it keeps the top-level policy stable, which protects your governance credibility — a document that gets rewritten every quarter looks like it was never taken seriously in the first place. Second, it lets you scope acknowledgement and training by role instead of forcing every employee to sign off on documents irrelevant to their job, which is exactly the kind of "signature fatigue" that produces box-ticking instead of genuine awareness.
Table 3: Top-level policy vs. topic-specific policy at a glance
Attribute | Top-level information security policy | Topic-specific policies |
|---|---|---|
Count | One | Typically 12–25 depending on organization size and scope |
Length | 2–4 pages | 2–6 pages each |
Content | Commitment, objectives/framework, risk appetite, accountability | Operational rules, roles, standards for one specific domain |
Change frequency | Reviewed annually, rarely rewritten | Reviewed annually, revised more often as tools/threats change |
Approver | CEO / top management (satisfies Clause 5.2) | Policy owner + management approval (may be delegated per a documented authority matrix) |
Audience | All personnel and, in summary form, relevant interested parties | Role-specific subsets of personnel and relevant third parties |
Primary control | Anchors Clause 5.2 and control 5.1 | Operationalizes control 5.1 plus the specific control(s) each policy supports |
The recommended topic-specific policy set, mapped to the controls it supports
ISO/IEC 27002:2022's guidance for control 5.1 lists topic-specific policy areas as examples, not a mandatory checklist — you select and scope your set based on your risk assessment and your Statement of Applicability. That said, after building policy frameworks for organizations from 40-person startups to 4,000-person enterprises, the following set covers the vast majority of real-world scopes. Use it as a starting checklist, then trim or add based on what your Statement of Applicability actually declares applicable.
Table 4: Recommended topic-specific policies mapped to Annex A controls
Topic-specific policy | Primary Annex A control(s) it operationalizes | Typical audience |
|---|---|---|
Access Control Policy | 5.15 Access control, 5.16 Identity management, 5.18 Access rights | All personnel, IT/identity administrators |
Acceptable Use Policy | 5.10 Acceptable use of information and other associated assets | All personnel |
Asset Management Policy | 5.9 Inventory of information and other associated assets, 5.11 Return of assets | All personnel, asset owners |
Information Classification & Handling Policy | 5.12 Classification of information, 5.13 Labelling of information | All personnel handling sensitive data |
Information Transfer Policy | 5.14 Information transfer | All personnel, especially those exchanging data externally |
Cryptography & Key Management Policy | 8.24 Use of cryptography | IT, developers, security engineering |
Supplier Relationships Policy | 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 ICT supply chain, 5.22 Monitoring/review of supplier services | Procurement, vendor managers |
Cloud Services Security Policy | 5.23 Information security for use of cloud services | IT, DevOps, cloud administrators |
Incident Management Policy | 5.24–5.28 Incident management planning through evidence collection | Security team, IT helpdesk, all personnel (reporting duty) |
Business Continuity & ICT Readiness Policy | 5.29 Information security during disruption, 5.30 ICT readiness for business continuity | IT operations, business continuity team |
Legal & Regulatory Compliance Policy | 5.31 Legal, statutory, regulatory and contractual requirements | Legal, compliance, management |
Records Retention & Protection Policy | 5.33 Protection of records | Records owners, legal, all personnel |
Privacy / PII Protection Policy | 5.34 Privacy and protection of personally identifiable information | HR, marketing, customer-facing teams, all personnel |
Screening & Employment Policy | 6.1 Screening, 6.2 Terms and conditions of employment | HR |
Security Awareness & Training Policy | 6.3 Information security awareness, education and training | All personnel |
Disciplinary Process Policy | 6.4 Disciplinary process | HR, all personnel |
Remote Working Policy | 6.7 Remote working | All personnel with remote access |
Event Reporting Policy | 6.8 Information security event reporting | All personnel |
Physical & Environmental Security Policy | 7.1–7.14 Physical security perimeters through secure disposal | Facilities, all personnel with office access |
Clear Desk & Clear Screen Policy | 7.7 Clear desk and clear screen | All personnel |
Endpoint & Mobile Device Policy | 8.1 User endpoint devices | All personnel with company devices |
Malware Protection Policy | 8.7 Protection against malware | IT, all personnel |
Vulnerability & Patch Management Policy | 8.8 Management of technical vulnerabilities, 8.9 Configuration management | IT operations, security team |
Backup Policy | 8.13 Information backup | IT operations |
Network Security Policy | 8.20 Networks security, 8.21 Security of network services, 8.22 Segregation of networks | IT/network engineering |
Secure Development Policy | 8.25 Secure development life cycle, 8.26 Application security requirements, 8.28 Secure coding | Development, engineering |
Change Management Policy | 8.32 Change management | IT operations, development |
Not every organization needs all twenty-six. A 40-person SaaS company with no physical warehouse or manufacturing floor might fold physical security into a lighter "office security" section rather than a standalone policy; an organization with no in-house development drops secure development entirely. The test is always the same one your risk assessment and SoA already apply: is this an area where you have applicable controls, and does a dedicated policy add clarity that a shorter combined document wouldn't? When in doubt, fewer well-maintained policies beat a large stack that nobody keeps current — that stack is exactly what buried Denholm.
Anatomy of a topic-specific policy: what belongs inside
A common failure mode I haven't mentioned yet is the topic-specific policy that reads like a philosophy essay — three pages of aspirational language with no operational content an employee could actually follow. A topic-specific policy earns its place in your Annex A evidence trail by containing a consistent, minimal set of sections, so that reviewers, new policy owners, and auditors can navigate any document in the set without relearning its structure each time. I standardize every topic-specific policy on the same skeleton across every client engagement, regardless of company size, because consistency here is what makes review and audit sampling fast rather than painful.
Table 12: Recommended structure for every topic-specific policy
Section | Purpose | Example (Access Control Policy) |
|---|---|---|
Purpose and scope | States why the policy exists and what it covers | "Governs provisioning, review, and revocation of access to Denholm information systems" |
Related Annex A control(s) | Ties the document to the control(s) it operationalizes | References control 5.15, 5.16, 5.18 |
Roles and responsibilities | Names who does what — owner, approver, enforcer | IT Manager (owner), department heads (access requests), CISO (approval) |
Policy statements | The actual rules, written as testable requirements | "Access is granted on least-privilege basis and reviewed quarterly" |
Exceptions process | How deviations are requested, approved, and time-boxed | Reference to the exceptions register described below |
Related documents | Links to supporting procedures and standards | Joiner-Mover-Leaver procedure, MFA configuration standard |
Version history | Every revision with date, author, and summary of change | v1.0 initial issue; v1.1 added MFA requirement for admin accounts |
Review record | Date, reviewer, outcome of the most recent review | Reviewed 2026-01-14 by CISO — no change required |
Keeping every topic-specific policy to this skeleton also makes onboarding new policy owners dramatically faster — a new IT manager inheriting the Access Control Policy from a predecessor can find the roles section, the exceptions process, and the review history in the same place every time, rather than hunting through a differently organized document.
Exceptions and waivers: handling "we can't comply yet"
No policy survives contact with real operations without the occasional exception, and control 5.1 doesn't expect zero deviations — it expects deviations to be governed, not silent. A supplier who can't yet meet your encryption-in-transit requirement, a legacy application that can't support MFA, a regional office that needs a temporarily different physical access procedure — these are normal. What auditors look for is a documented exceptions process: a register of every deviation, who approved it, the compensating control in place, and an expiry date that forces a re-decision rather than letting the exception become permanent by default.
I've seen organizations undermine an otherwise strong policy framework by having no formal exceptions process at all — which pushes people to quietly ignore the policy rather than request a sanctioned, time-boxed deviation. A visible exceptions register, reviewed at the same cadence as the policies themselves, turns "we're not following the policy" from a hidden risk into a managed one.
Table 13: Exception/waiver register — fields auditors expect to see
Field | Purpose |
|---|---|
Policy and clause affected | Identifies exactly what's being deviated from |
Business justification | Why full compliance isn't currently feasible |
Compensating control | What's in place instead, to manage the residual risk |
Approver | Named individual with authority to accept the risk |
Expiry / review date | Forces a re-decision rather than a permanent silent gap |
Status | Open, closed, or converted into a permanent policy change |
Policy hierarchy: how the pieces fit together
flowchart TD
A["Clause 5.2 Policy\n(management-system requirement)"] --> B["Top-Level Information\nSecurity Policy"]
B --> C["Topic-Specific Policy:\nAccess Control"]
B --> D["Topic-Specific Policy:\nAcceptable Use"]
B --> E["Topic-Specific Policy:\nSupplier Relationships"]
B --> F["Topic-Specific Policy:\nCryptography & Key Mgmt"]
B --> G["... additional topic-specific\npolicies per Table 4"]
C --> C1["Procedure: Joiner-Mover-Leaver\naccess provisioning"]
C --> C2["Standard: Password &\nMFA configuration"]
D --> D1["Procedure: Device\nenrollment checklist"]
E --> E1["Procedure: Vendor security\nassessment questionnaire"]
F --> F1["Standard: Approved\nalgorithms & key lengths"]
B -.governed by.-> H["Control 5.1 lifecycle:\napprove, publish, communicate,\nacknowledge, review"]The top-level policy inherits its mandate from Clause 5.2. Everything beneath it — topic-specific policies, and the procedures and standards that support them — exists to make that mandate operational. Control 5.1 is the governance wrapper that runs around the whole structure, from the top-level policy down through every topic-specific policy, ensuring each layer goes through the same approve-publish-communicate-acknowledge-review lifecycle rather than being drafted once and forgotten.
Approval: making the decision traceable
Every policy needs a named, dated, recorded approval — and it needs to come from someone with the actual authority to bind the organization to the commitments the policy makes. For the top-level policy, that's top management, which is what makes it satisfy Clause 5.2 as well as control 5.1. For topic-specific policies, approval can be delegated — a CISO approving the Cryptography Policy, an IT director approving the Backup Policy — but the delegation itself needs to be documented, ideally in a RACI or authority matrix referenced by your policy governance procedure, so an auditor can trace "who was allowed to approve this" back to a decision, not an assumption.
The mechanism matters less than the traceability. I've seen this work equally well as a signed PDF cover sheet, a Confluence page with an approval workflow plugin, or a GRC platform with electronic sign-off — what auditors actually check is whether the approval record includes a name, a role, a date, and the specific version of the document being approved.
Table 5: Approval — evidence auditors expect to see
Evidence item | Where it typically lives | Common failure mode |
|---|---|---|
Named approver with authority | Document metadata or approval log | Approver title doesn't match the delegation matrix |
Approval date | Document header/footer or workflow system | Approval date predates the content it's approving (copy-paste error) |
Version number tied to the approval | Version control table inside the document | Multiple "final" versions with no version numbers |
Delegation record (for topic-specific policies not approved by top management) | Authority matrix or governance procedure | No documented delegation — approver's authority is assumed, not evidenced |
Re-approval after material revision | Version history log | Only the original version was ever approved; later edits went live unapproved |
A simple RACI for policy governance
Approval traceability, discussed above, depends on a clear governance model that names who is Responsible, Accountable, Consulted, and Informed for each stage of a policy's lifecycle. Without this, approval authority tends to default to "whoever's available," which is exactly the gap Table 5 flags as a common failure. I recommend documenting a single RACI that covers the whole lifecycle — draft, approve, publish, communicate, acknowledge, review — rather than scattering the accountability across separate, disconnected documents.
Table 14: Sample RACI for the policy lifecycle
Lifecycle stage | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Draft | Policy owner (domain lead) | CISO | Legal, HR, affected department heads | — |
Approve | CISO (topic-specific) / CEO (top-level) | CEO / top management | Policy owner, Legal | All personnel (once approved) |
Publish | Document controller | Policy owner | IT (for platform/access) | All personnel |
Communicate | Policy owner / HR | CISO | Comms/Internal communications team | All personnel, relevant third parties |
Acknowledge | Individual employees/contractors | Line manager / HR | — | CISO (via completion report) |
Review | Policy owner | CISO | Internal audit, risk owner | Top management (via management review) |
This kind of table costs almost nothing to produce and answers, in one place, the question every auditor eventually asks in some form: "who is accountable for this policy staying current?"
Publication and communication: closing the "nobody knew" gap
Publication is necessary but not sufficient — Denholm's forty-one documents were all technically "published" on a SharePoint site nobody could navigate. Control 5.1 requires active communication: relevant personnel and relevant interested parties need to be told the policy exists, told what changed, and told where to find the current version. For internal personnel, that typically means induction packs for new hires, an intranet or LMS notification when a policy is issued or revised, and a periodic reminder as part of security awareness activities (which also supports control 6.3, information security awareness, education and training). For external interested parties — contractors, key suppliers, sometimes customers under contract — communication usually rides on onboarding documentation, contractual references, or a supplier portal.
The distinction between publication and communication is where I see the most gap between "we think we're compliant" and what an audit interview reveals. Publishing a policy to an intranet that requires three clicks past a page nobody visits is not communication. Communication has to be measurable: an email with an open/read receipt, an LMS module with a completion log, a signed induction checklist, a supplier notice with a delivery confirmation.
Table 6: Communication — evidence auditors expect to see
Interested party | Communication mechanism | Evidence to retain |
|---|---|---|
New employees | Induction/onboarding session referencing the policy set | Induction checklist with policy sign-off, dated |
Existing employees (new/revised policy) | Email or LMS notification, intranet banner | Send/open logs, LMS completion report |
Contractors and temporary staff | Contractor onboarding pack | Signed contractor acknowledgement, dated |
Key suppliers with data access | Supplier onboarding or contract addendum | Supplier acknowledgement or contractual clause reference |
All personnel (annual refresh) | Security awareness campaign | Campaign completion report, attendance log |
Acknowledgement: the record that closes the loop
Acknowledgement is the step organizations most often skip, because it requires a positive action from every individual rather than a broadcast from the policy owner. It's also the step auditors probe hardest, because it's the cheapest way to test whether "communicated" was real: pick three employees at random, in different roles, and ask to see their signed acknowledgement of the specific policies relevant to their job.
A workable acknowledgement program has three properties. First, it's role-scoped — a warehouse supervisor shouldn't need to acknowledge the Secure Development Policy, and a developer shouldn't be stuck acknowledging a Physical Security Policy written for a facility they never visit. Second, it's re-triggered on material revision, not just at hire — if the Access Control Policy changes its MFA requirement, everyone affected needs a fresh acknowledgement, not just new hires going forward. Third, it produces a report you can hand an auditor without a scramble: a percentage-complete figure per policy, a list of outstanding names, and an escalation record for anyone who doesn't complete it within a set window (commonly 14–30 days).
Table 7: Acknowledgement — evidence auditors expect to see
Evidence item | Good practice | Common failure mode |
|---|---|---|
Individual, named acknowledgement record | E-signature or LMS completion tied to employee ID | "We assume everyone read it" with no record at all |
Role-scoping | Acknowledgement assignments mapped to job role/department | Everyone assigned every policy regardless of relevance (signature fatigue) |
Re-acknowledgement on revision | New acknowledgement request triggered automatically on policy version change | Acknowledgement only captured once, at hire, never refreshed |
Completion tracking and escalation | Dashboard/report with completion percentage and overdue list | No visibility into who has and hasn't acknowledged |
Third-party acknowledgement | Signed clause in contract or supplier onboarding form | No acknowledgement mechanism for contractors/suppliers at all |
"The acknowledgement report is the single fastest thing I pull in a Stage 2 audit. If you can show me completion percentage, an overdue list, and what happened to the overdue names, I already trust the rest of your ISMS more." — Renata Oduya, Principal Auditor, Northbridge Certification Services
Review: planned intervals and significant-change triggers
Control 5.1 requires two distinct review mechanisms, and conflating them is a common gap. The first is a planned interval — most organizations I work with land on annual review for the full policy set, sometimes with a lighter-touch semi-annual check for high-change areas like cryptography or cloud services. The interval itself should be documented (in the policy governance procedure or in each policy's metadata) so an auditor can confirm the review actually happened on schedule, not just that it happened at some point.
The second is event-triggered review: a review that happens because something significant changed, independent of the calendar. Significant changes include a new regulatory obligation (a new GDPR guidance note, a new sector-specific requirement), a material technology change (migrating to a new cloud provider, adopting a new identity platform), an organizational change (a merger, a new business unit, a major restructuring), or a security incident that reveals the existing policy was inadequate. A mature ISMS treats incident post-mortems and risk assessment updates as standing inputs to the review trigger list — if your Clause 6 risk assessment surfaces a new risk that an existing policy doesn't address, that's a trigger, not a coincidence to note for next year's cycle.
Table 8: Review — evidence auditors expect to see
Review type | Trigger | Evidence to retain |
|---|---|---|
Planned interval review | Calendar date reached (commonly annual) | Review log: date, reviewer, outcome (no change / minor update / major revision) |
Significant-change review | Regulatory change, technology change, organizational change, incident finding | Change trigger record linking the event to the specific policy reviewed |
Risk-assessment-driven review | New or materially changed risk identified in the risk register | Cross-reference from risk register entry to policy review record |
Post-incident review | Security incident or near-miss reveals policy gap | Incident report action item tracked through to policy update and re-approval |
Review sign-off | Any review, regardless of trigger | Confirmation of "no change needed" is itself documented — silence is not evidence |
Policy architecture by company size
The right number of policies and the right level of formality scale with headcount, complexity, and regulatory exposure — a 35-person startup running one AWS account does not need the same architecture as a 3,000-person financial services group with twelve business units. Over-engineering the policy set for a small company is almost as damaging as under-engineering it for a large one: it creates a maintenance burden nobody can sustain, which is exactly how organizations end up with Denholm's forty-one stale documents in the first place.
Table 9: Policy architecture models by organization size
Small (under ~75 employees) | Mid-market (~75–750 employees) | Enterprise (750+ employees, multiple business units) | |
|---|---|---|---|
Top-level policy | One, 2–3 pages | One, 3–4 pages | One, 3–4 pages, may reference regional addenda |
Topic-specific policy count | 8–12, several combined (e.g., physical + clear desk in one document) | 15–22, following Table 4 closely | 22–30+, often with business-unit or regional supplements |
Approval body | Founder/CEO or single accountable executive | CISO with executive sign-off; steering committee for major revisions | Formal ISMS governance/steering committee with charter |
Review cadence | Annual, single batch review | Annual, staggered by risk tier | Annual for stable policies, semi-annual for high-change domains |
Acknowledgement tooling | Shared drive + signed PDF or simple e-signature tool | LMS or GRC platform with role-based assignment | Enterprise GRC platform integrated with HRIS for automatic role-scoping |
Ownership model | One person owns the whole library | Policy owner per domain (IT, HR, Legal) reporting to CISO | Named accountable owner per policy, tracked in a formal RACI |
Choosing tooling: spreadsheets, LMS, or a GRC platform
I get asked constantly whether a specific tool is "required" for control 5.1 compliance — it isn't. The standard is tool-agnostic; what matters is whether your chosen mechanism can produce the evidence in Tables 5 through 8 on demand. That said, the right tool changes the cost of running the program honestly, and picking one that doesn't fit your size tends to produce exactly the kind of stale, unmaintained library Denholm had.
Table 15: Tooling options for policy governance, by fit
Approach | Best fit | Strengths | Limitations |
|---|---|---|---|
Shared drive + manual sign-off (email or scanned signature) | Very small teams (under ~30 people) | Zero cost, fast to start | Doesn't scale, easy to lose track of acknowledgement completion |
Spreadsheet register + e-signature tool | Small to mid-market | Low cost, flexible, easy to audit manually | Manual upkeep, no automated reminders or role-scoping |
LMS (learning management system) | Mid-market to enterprise with existing training infrastructure | Automated completion tracking, integrates with onboarding | Not purpose-built for policy version control or approval workflow |
Dedicated GRC platform | Mid-market to enterprise, especially multi-framework programs | Automated role-scoping, audit-ready reporting, links policies to controls/SoA directly | Cost and implementation time; overkill for very small teams |
Whichever you choose, the test at audit time is the same: can you produce, in minutes rather than days, a list of who has acknowledged a specific policy version, and when the policy was last reviewed. If the answer requires reconstructing history from memory or email search, the tool — or the discipline around it — isn't doing its job yet.
Metrics that show your policy program is actually working
A policy program that only gets attention once a year, right before the audit, tends to look fine on paper and fall apart under questioning. The organizations that sail through both certification and surveillance audits track a small set of leading indicators year-round, not just a pass/fail status at audit time.
Table 16: Suggested KPIs for an ongoing policy program
Metric | Healthy target | Why it matters |
|---|---|---|
Acknowledgement completion rate (current policy versions) | 95%+ within 30 days of assignment | Directly evidences the "acknowledged" obligation in control 5.1 |
Percentage of policies reviewed within their planned interval | 100% | Directly evidences the "reviewed at planned intervals" obligation |
Average time from significant change to policy update | Under 60 days | Shows the significant-change trigger mechanism is real, not theoretical |
Number of policies with no named owner | Zero | A policy without an owner is the first sign of the drift that produced Denholm's forty-one documents |
Exceptions open beyond their expiry date | Zero | Shows the exceptions process (Table 13) isn't being used to quietly ignore expired waivers |
Employees with overdue acknowledgements after escalation | Trending to zero, tracked monthly | Confirms the escalation path in Table 7 is functioning, not just documented |
Common mistakes I see in the field
Even organizations that take control 5.1 seriously tend to trip on the same handful of failure modes. Naming them explicitly saves you the audit finding.
Table 10: Common mistakes and how they surface in audit
Mistake | Why it happens | How it surfaces in audit |
|---|---|---|
Confusing Clause 5.2 with control 5.1 | Teams treat the top-level policy as the whole deliverable | Auditor asks for the topic-specific policy set and evidence trail; nothing exists |
Policy sprawl with no single source of truth | Documents accumulate across departments over years with no owner | Duplicate/contradictory policies found on different systems (Denholm's forty-one documents) |
Publication without communication | Assuming an intranet upload equals awareness | Interviewed staff have never heard of the policy that applies to them |
No acknowledgement records | Treating acknowledgement as a formality not worth tracking | Random staff interviews can't produce a signed acknowledgement |
Review "happens" but isn't documented | Someone reads the policy annually but never logs it | No date, no reviewer name, no outcome recorded — looks identical to "never reviewed" |
Approval by someone without delegated authority | Convenience — whoever's available signs it | Delegation matrix doesn't list the approver, or no matrix exists at all |
Topic-specific policies not mapped to controls or SoA | Policies written generically, disconnected from the risk assessment | Auditor can't trace a policy back to the control(s) it's meant to operationalize |
One-size-fits-all acknowledgement | Assigning every policy to every employee regardless of role | Low completion rates, staff fatigue, box-ticking instead of genuine reading |
Maintenance cadence: keeping the framework alive after certification
Certification is a snapshot; control 5.1 is a continuous obligation. The maintenance model that holds up best over multiple surveillance audit cycles treats the policy set as a living calendar of activity rather than a project that ends at Stage 2.
Table 11: Recommended annual maintenance cadence for the policy framework
Activity | Frequency | Owner |
|---|---|---|
Full policy set review (planned interval) | Annually | Policy owner(s), coordinated by CISO |
High-change domain review (cryptography, cloud services, supplier relationships) | Semi-annually | Domain policy owner |
New-hire acknowledgement capture | Continuous, triggered by onboarding | HR + policy owner |
Acknowledgement completion audit | Quarterly | CISO or internal audit function |
Significant-change trigger scan (regulatory, technology, organizational, incident) | Ongoing, reviewed monthly at security steering meeting | CISO |
Version control and document register audit | Annually, ahead of internal audit | Document controller |
Alignment check against Statement of Applicability | Annually, or when SoA is revised | ISMS owner |
Internal audit sampling of policy 5.1 evidence | Per internal audit schedule (commonly annual) | Internal auditor |
Budgeting for the policy program
Leadership teams sizing an ISO 27001 implementation for the first time consistently underestimate control 5.1's ongoing cost, because the writing phase is a one-time project but the governance phase is permanent. Rough figures below are illustrative, drawn from typical engagement sizing across the companies I've worked with, not a vendor price list — treat them as planning inputs, not quotes.
Table 17: Illustrative first-year and ongoing cost ranges for the policy program
Company size | Initial build (writing + approval workflow setup) | Ongoing annual maintenance (tooling + review time) |
|---|---|---|
Small (under ~75 employees) | $4,000–$12,000 (largely internal time plus a consultant review pass) | $2,000–$6,000 |
Mid-market (~75–750 employees) | $15,000–$45,000 (consultant support, LMS setup, role-scoping design) | $10,000–$30,000 |
Enterprise (750+ employees) | $50,000–$150,000+ (GRC platform licensing, multi-business-unit rollout) | $40,000–$120,000+ |
The ongoing column is the one boards tend to underfund, because it's easy to mistake "we passed certification" for "the program is now free to run." It isn't — Table 11's maintenance cadence and Table 16's KPIs both require standing time from a named owner, and that time has a real cost whether or not it shows up as a separate line item.
Integrating control 5.1 with internal audit and management review
Control 5.1 doesn't operate in isolation from the rest of your management system — it's one of the standing inputs your internal audit program and management review should test every cycle. A well-run internal audit samples policy 5.1 evidence the same way an external auditor would: pulling a handful of policies at random, checking approval dates against the version history, and interviewing a cross-section of staff about acknowledgement and awareness, rather than simply confirming a document exists. Feeding those internal audit findings into management review closes the loop that Clause 5 leadership ultimately owns — if internal audit flags that acknowledgement completion has slipped to 80%, that's a management review agenda item, not just a note for the policy owner's to-do list.
The organizations that treat control 5.1 as genuinely embedded, rather than a certification artifact, are the ones where an internal audit finding about a stale policy triggers a corrective action under Clause 10 within weeks, not the ones where it sits in a spreadsheet until the next external audit surfaces the same gap a second time.
A first-90-days plan for building control 5.1 from scratch
If you're starting close to where Denholm started — a messy or nonexistent policy library and an audit date on the calendar — the sequencing below is the order I run engagements in, compressed to roughly ninety days for a mid-market organization. Smaller organizations can compress it further; larger, multi-business-unit organizations should expect to extend each phase.
Table 18: Illustrative 90-day build sequence
Weeks | Focus | Key output |
|---|---|---|
1–2 | Inventory every existing policy-like document; map each to an owner and, where possible, an Annex A control | Consolidated document register (Denholm's "forty-one documents" exercise) |
3–4 | Draft or revise the top-level information security policy; confirm it satisfies Clause 5.2's content requirements | Approved top-level policy |
5–8 | Draft topic-specific policies against Table 4, prioritizing the ones tied to your highest-risk SoA entries first | First wave of topic-specific policies in review |
9–10 | Build or confirm the approval workflow and authority/delegation matrix | Signed authority matrix; approval records for all drafted policies |
11–12 | Roll out communication and acknowledgement campaign, role-scoped per Table 6 and Table 7 | Acknowledgement completion report |
13 | Set the planned review calendar and significant-change trigger process; brief internal audit | Documented review schedule feeding into Table 11's maintenance cadence |
This isn't a one-time checklist to file away once Stage 2 passes — it's the template your annual maintenance cadence (Table 11) repeats, at a smaller scale, every year the ISMS operates.
Documented information, retention, and cross-framework reuse
Every artifact this article has described — the policy itself, approval records, communication logs, acknowledgement reports, review memos — is "documented information" in ISO/IEC 27001 terms, and it needs to be controlled the way Clause 7 requires: version-identified, protected from unauthorized change, and retained for a defined period. If you haven't yet nailed down how your organization handles documented information generally — retention periods, access permissions, version control discipline — our guide to Clause 7 support requirements for resources, competence, and awareness covers the mechanics that control 5.1's evidence trail depends on. If you're still unclear on how Annex A controls like 5.1 relate to the ISO 27002 guidance that expands on them, the distinction is covered in depth in our piece on ISO 27001 vs ISO 27002.
It's also worth knowing that a well-built policy framework isn't single-use. The topic-specific policies you build for control 5.1 — access control, incident response, supplier management — map closely onto policy expectations in other frameworks: SOC 2's common criteria expect a comparable information security policy set, HIPAA's Security Rule expects documented policies and procedures for safeguarding ePHI, and organizations under the EU's DORA regulation need equivalent ICT risk management policies for financial-sector ICT resilience. Building your ISO 27001 policy set with those overlaps in mind — consistent terminology, compatible review cadences — turns one compliance program into reusable groundwork for several.
If you want a narrower, template-driven walkthrough of drafting the top-level policy document itself line by line, our dedicated guide on writing an effective information security policy covers exactly that.
Case study one: rebuilding from forty-one documents to nineteen
After Denholm Freight Solutions' Stage 1 nonconformity, Priya Nandekar led a four-month remediation. The team's first move was a full inventory: every document that looked like a policy, standard, or guideline went into a single register with owner, last-modified date, and a note on which Annex A control it was meant to support (or, in most cases, no clear mapping at all). Of the forty-one original documents, nineteen survived consolidation — several near-duplicates were merged, a handful of genuinely obsolete documents (including the 2019 GDPR policy referencing a defunct processor) were retired, and the rest were reorganized under a single top-level policy with eighteen topic-specific policies mapped directly to Table 4's structure. Denholm stood up a lightweight GRC tool for approval workflow and acknowledgement tracking, ran a role-scoped acknowledgement campaign that reached 96% completion within three weeks, and documented an annual review cadence with named owners per policy. Stage 2 passed on the rescheduled date with zero nonconformities against control 5.1. The European retailer's contract was ultimately renegotiated rather than lost outright, but Denholm's leadership pointed to the four-month delay and the near-loss of the contract as the reason the policy program now gets a standing budget line rather than being treated as a one-time project cost.
Case study two: the acknowledgement gap that surfaced in a supplier audit
A 220-person healthcare SaaS vendor I advised — I'll call it Kestrel Health Analytics, since the client asked that its real name stay out of print — had a genuinely well-written policy set: a tight top-level policy, sixteen topic-specific policies, all approved and reviewed on schedule. Where it fell down was communication to a specific interested party class the team had overlooked: contracted clinical data reviewers, a group of about thirty part-time contractors who accessed de-identified patient data under a separate services agreement. The internal policy library was communicated thoroughly to employees but had never been extended to this contractor population, because they sat outside the standard HR onboarding process. A customer's own security team, conducting a supplier due-diligence review ahead of a contract renewal, asked specifically whether Kestrel's data classification and information transfer policies had been communicated to and acknowledged by everyone with data access — including contractors. Kestrel could not produce the records. The customer paused the renewal pending remediation, a six-week delay on a contract worth roughly $410,000 annually. Kestrel fixed the gap by extending its LMS-based acknowledgement workflow to contractor accounts and building a standing contractor-onboarding checklist tied to system access provisioning, closing the loop before the next audit cycle and before the customer's revised deadline.
Case study three: turning annual review into a genuine control, not a formality
A 90-person fintech startup had passed its first ISO 27001 certification with a lean, well-scoped policy set, but its internal auditor flagged in year two that "annual review" for every policy meant one person skimming all fourteen documents in a single afternoon each January, with no evidence that anything beyond a read-through had actually happened. The finding wasn't a nonconformity — the review had technically occurred — but the internal auditor noted it as an opportunity for improvement, correctly anticipating that a external auditor might view a single unstructured afternoon as inadequate rigor for higher-risk domains like cryptography and access control. The company restructured its review calendar: high-change policies (cryptography, cloud services, access control) moved to a semi-annual cadence with the relevant domain owner (engineering lead, IT lead) doing the technical review before the CISO's final sign-off; lower-change policies (clear desk, physical security) stayed annual. Each review now produces a one-page outcome memo — reviewed by whom, on what date, with what outcome — filed in the document register. The following surveillance audit cited the revised review structure as a strength, and the company has since used the same one-page outcome memo template as evidence across other lifecycle-based controls beyond 5.1.
"A policy that's never been through a documented review is functionally the same as a policy that was never reviewed at all, from where I'm sitting as an auditor. Show me the memo, not just the good intentions." — Devon Ashwood, ISMS Consultant, Ashwood Governance Partners
"The mistake I made early in my career was writing beautiful topic-specific policies and forgetting that nobody outside the security team would ever read a 20-page document. Shorter policies, read by more people, beat comprehensive policies read by nobody." — Lian Cho, CISO, Fenwright Analytics
"Control 5.1 is deceptively named. It sounds like a documentation control. It's actually a governance control — it's testing whether your organization can run a lifecycle, not whether you can write a paragraph." — Marcus Whitfield, Lead Auditor, Halborn Assurance Group
"We stopped treating acknowledgement as an HR chore the day I realized it was the fastest way for me to prove, in about four minutes, that our security culture was real and not just documented." — Priya Nandekar, IT & Security Manager, Denholm Freight Solutions
"Don't build a policy architecture you can't afford to maintain. I'd rather see twelve policies reviewed properly every year than thirty policies nobody's touched since the certification audit." — Renata Oduya, Principal Auditor, Northbridge Certification Services
The strategic close: policy governance as a trust asset, not paperwork
It's tempting to treat control 5.1 as a compliance tax — a stack of documents that exists to satisfy an auditor once a year. That view costs organizations money in ways that are easy to underestimate, as Denholm and Kestrel both learned: delayed certification, renegotiated contracts, and stalled supplier due-diligence reviews are the visible costs. The less visible cost is slower, worse decision-making, because a policy set nobody trusts or reads doesn't actually change behavior — it just creates the appearance of governance while the real rules of the road get decided informally, department by department, the way Denholm's forty-one documents accumulated in the first place.
Done well, control 5.1 is the opposite: a compact, current, genuinely-read set of documents that every new hire, every supplier, and every auditor can use to understand exactly how your organization protects information — and a defensible answer, backed by dated records, to "how do you know people know the rules?" That's not paperwork. That's a trust asset you can point to in a sales cycle, a due-diligence questionnaire, or a board conversation about risk appetite, months before it's ever tested in a certification audit.
If you're building or rebuilding your policy framework and want a structured starting point rather than a blank page, PentesterWorld's Information Security Policy Template gives you the top-level policy structure Clause 5.2 requires, and our ISO 27001 Mandatory Documents Checklist will help you confirm which topic-specific policies your scope actually needs before you write a single page. Pair both with our Certification Readiness Checklist as you head toward Stage 1, so you never find yourself, like Priya Nandekar did, explaining forty-one uncontrolled documents to an auditor who's already decided what they think of your ISMS.
For teams building the wider governance layer around 5.1 — who owns which policy, who signs off, who's accountable when a review lapses — our article on roles and responsibilities under controls 5.2–5.4 is the natural next read, and the Annex A organizational controls overview will show you how control 5.1 sits alongside the other 36 organizational controls it underwrites. And if any term in this article — topic-specific policy, interested party, documented information — needs a plain-language definition for a colleague new to the standard, point them to our ISO 27001 glossary of terms or the standalone ISO 27001 Glossary resource before they sit through their first policy review meeting.
For a broader view of how a mature policy program pays for itself beyond the audit — in sales cycles, insurance renewals, and board reporting — our Complete ISO 27001 Implementation Guide eBook walks through the full program end to end, and the ISO 27001 Clause 5 leadership and management commitment requirements article is the right companion piece for getting executive sponsorship behind the policy program before you write a single topic-specific document.