An ISO 27001 policy set is the audit-ready collection of governance documents, procedures, and records that prove your information security management system (ISMS) actually works. Most mid-sized organizations typically need a set of core policies sized to their scope and treatment decisions, generally including a substantial number of policies. Start by picking a template pack with genuine Annex A mapping, then customize each document against your own risk treatment plan rather than publishing generic boilerplate.
TL;DR:
- Most mid-sized organizations need around 18 core policies covering risk management, access control, incident response, and physical security, tailored to their scope.
- Validating templates involves checking for proper Annex A mapping, implementation notes, document-control fields, and sample evidence artifacts, not just generic boilerplates.
- Policies must be clear, organized around purpose, scope, responsibilities, rules, exceptions, compliance, and document control to effectively demonstrate adherence during audits.
- Evidence such as risk registers, audit reports, training logs, and incident logs are crucial, organized into stages for proof of policy implementation over at least one operational cycle.
- Building a certification-ready policy set depends on organization size and scope, with tools like ISMS Calculator helping estimate effort, duration, and budgeting through tailored project plans.
Table of Contents
- What Policies Does an ISO 27001 Policy Set Actually Require?
- Where Can You Find Audit-Ready ISO 27001 Policy Templates?
- How Should You Write and Structure Each Security Policy?
- How Do Policies Map to ISO 27001 Clauses and Annex A Controls?
- What Records and Evidence Do Auditors Actually Ask to See?
- How Do You Customize a Template Pack to Your Organization?
- How Long Does It Take to Build and Certify a Policy Set?
- Why Fewer, Clearer Policies Beat a Longer Policy Set
- How ISMS Calculator Helps You Size and Plan Your Policy Set
- Sources
What Policies Does an ISO 27001 Policy Set Actually Require?
Every ISMS policy set starts with the same anchor document: the top-level Information Security Policy, paired with a clearly written ISMS scope statement. Everything else branches from there, built around your risk assessment and treatment methodology and the Statement of Applicability (SoA) that records which of the 93 Annex A controls apply to you and why.
Beyond that anchor, the working inventory most compliance teams assemble looks fairly consistent across industries. Advisera’s mandatory documents list confirms the ISMS scope, risk assessment and treatment documentation, SoA, internal audit reports, and management review records as the non-negotiable core. Practical guides built on top of that baseline typically land around 18 core policies once you add the operational documents auditors actually sample.
Here is the inventory that shows up in nearly every ISO 27001 policy list:
- Information Security Policy — the charter document; sets tone and management commitment.
- Risk Assessment and Treatment Methodology — defines how you identify, score, and treat risk.
- Statement of Applicability — the master map of which Annex A controls apply and why.
- Access Control Policy — governs identity, authentication, and privilege management.
- Asset Management Policy — tracks hardware, software, and data ownership across their lifecycle.
- Cryptography Policy — sets rules for encryption use, key management, and algorithm standards.
- Incident Response Policy — defines detection, escalation, and reporting timelines.
- Supplier Security Policy — covers vendor risk assessment and contractual security clauses.
- Business Continuity Policy — documents recovery objectives and continuity testing.
- Acceptable Use Policy — sets employee-facing rules for systems and data handling.
- Data Classification Policy — defines sensitivity tiers and handling rules per tier.
- Change Management Policy — controls how changes to systems and infrastructure get approved.
- Secure Development Policy — applies to organizations that build or customize software.
- Physical Security Policy — covers facility access, equipment, and environmental controls.
Auditors sample the Information Security Policy, Access Control Policy, and Incident Response Policy more than any others, because those three tend to expose gaps between what’s written and what’s practiced. Assign clear owners early. Access control usually belongs to IT operations, incident response to a security lead, and supplier security to procurement or legal. Splitting ownership this way keeps each ISMS policy tied to someone who can actually produce evidence when an auditor asks for it.
Where Can You Find Audit-Ready ISO 27001 Policy Templates?
A template pack that isn’t mapped to Annex A controls is just a generic Word document with a security-sounding title. Before you adopt any ISO 27001 policy templates, check for four things: clause and control mapping, implementation notes explaining what auditors actually look for, document-control fields built into the template itself, and example evidence artifacts showing what “done” looks like.
A few real options fit different budgets and timelines:
- Open-source starter kits. The CenedrilTeam starter kit on GitHub covers all 93 Annex A controls and the ISMS clauses with 21 policy documents, registers, and mapping tables, released under a CC BY 4.0 license. It costs nothing but requires careful review of default risk matrices and categorization schemes before you adopt them as your own.
- Community and consultant-built policy suites. Projects like the enterprise-grade policy suite on GitHub map more than ten policies directly to Annex A controls, which is useful as a second reference point when you’re checking your own coverage.
- Commercial template packs. AuditFront’s ISO 27001 policy pack bundles implementation notes explaining common pitfalls alongside the DOCX templates, which tends to shave hours off the “what does the auditor actually want here” guesswork.
Pro Tip: Open any candidate template and search for the words “insert” or “TBD.” If you find more than a handful, the pack still needs real customization work, not a light edit.
Validate audit-readiness fast by checking whether the template already references your SoA controls by number, includes a version history table, and states who approves changes. If those three things are missing, you’re looking at a boilerplate document, not an audit-ready one.
How Should You Write and Structure Each Security Policy?
A policy that reads like a legal contract usually fails for the same reason a policy with no version history fails: nobody can prove it’s actually being followed. CertPro’s documentation guidance is blunt about this: auditors want organization-specific content, formal approval, a defined review cycle, and evidence that the policy was communicated, not just written.
Structure every policy around the same seven fields, every time:
- Purpose — one or two sentences on why the policy exists.
- Scope — who and what it applies to (departments, systems, third parties).
- Responsibilities — named roles, not just “IT” or “management.”
- Policy statements — the actual rules, written in plain language and cross-referenced to specific SoA control numbers.
- Exceptions — how deviations get requested and approved.
- Compliance — consequences for non-adherence and how compliance gets monitored.
- Document control — owner, approver, version number, effective date, and next review date.
Plain language wins over legalistic phrasing almost every time. A sentence like “Passwords must be a minimum of 12 characters and rotated every 90 days for privileged accounts” gets followed. A sentence buried in three subordinate clauses about “reasonable and appropriate measures” does not.
Pro Tip: Keep a single shared document-control table across all policies, so the version number, review date, and approver format stay identical everywhere. Auditors notice inconsistency in these fields faster than almost anything else.
For communication evidence, a signed acknowledgment in your HR or LMS platform, meeting minutes showing the policy was walked through with a team, or an email confirmation trail all count. What doesn’t count: assuming people read it because it’s on a shared drive.
How Do Policies Map to ISO 27001 Clauses and Annex A Controls?
The 2022 revision reorganized Annex A into four themes: organizational, people, physical, and technological controls, spanning 93 total controls. Each theme maps cleanly to a handful of policies, which makes the mapping exercise far less painful than it sounds once you see it laid out.
| Clause or control theme | Typical covering policy | Example controls |
|---|---|---|
| Clauses 4-7 (management system) | Information Security Policy, Management Review Procedure | Leadership commitment, internal audit, corrective action |
| Organizational controls (A.5) | Risk Management Policy, Supplier Security Policy | Roles, supplier relationships, incident management |
| People controls (A.6) | Acceptable Use Policy, HR Security Policy | Screening, remote working, disciplinary process |
| Physical controls (A.7) | Physical Security Policy | Secure areas, equipment siting, clear desk |
| Technological controls (A.12) | Access Control Policy, Cryptography Policy, Secure Development Policy | Authentication, encryption, threat intelligence, cloud services |
The new 2022 controls, like threat intelligence, cloud service security, and secure coding, don’t need brand-new standalone policies in most cases. They usually fit inside existing documents: threat intelligence inside your Incident Response Policy, cloud services inside Supplier Security, and secure coding inside a Secure Development Policy. For a deeper walk-through of individual controls, the Annex A controls breakdown is worth bookmarking alongside your SoA.
What Records and Evidence Do Auditors Actually Ask to See?
Documentation deficiencies, not badly written policies, cause most initial audit nonconformities. Auditors want proof a policy is followed, not proof it exists.
The records that come up in nearly every audit conversation:
- Risk register with current treatment status for each identified risk.
- Statement of Applicability, current version, with rationale for excluded controls.
- Internal audit reports and evidence that findings were closed out.
- Management review minutes showing the ISMS was actually discussed at leadership level.
- Security awareness training logs, ideally tied to completion dates and content covered.
- Incident logs, including near-misses, with response timelines documented.
- Backup and recovery test results, dated and showing pass or fail outcomes.
Organize evidence into two folders from day one: a Stage 1 package (policies, scope, SoA, risk methodology) and a Stage 2 package (operational records proving those policies were followed for at least one full cycle). Retention of 3 years is a common baseline for most evidence types, though your risk register and audit trail should stay accessible for the life of the certification cycle. Restrict write access to evidence folders, since an auditor asking “who can edit this log” is a common follow-up question. For a fuller breakdown of what auditors expect to see by category, the evidence types guide covers specific artifact examples worth reviewing before your audit window opens.
How Do You Customize a Template Pack to Your Organization?
Downloading a starter kit is the easy part. Turning it into something an auditor will accept as yours takes a short, repeatable process.
- Confirm your ISMS scope. Write down exactly which business units, locations, and systems are in scope before touching a single template.
- Map Annex A against your risk assessment. Decide which controls apply and record justification for exclusions in your SoA.
- Pick your template source. Choose an open-source kit, a commercial pack, or a blend of both based on your budget and timeline.
- Customize policy statements. Replace every placeholder with your actual thresholds, tools, and named roles.
- Assign document owners. Every policy needs one accountable person, not a department.
- Route for approval. Formal sign-off, dated and recorded, not an email that says “looks good.”
- Publish and communicate. Distribute through a tracked channel and capture acknowledgment.
The most common pitfall is leaving default risk matrices or classification tiers untouched, which auditors spot instantly because the language doesn’t match how the organization actually talks about risk. Template customization guidance suggests roughly 2 to 4 hours per policy for a small organization, more for mid-sized and large scopes where multiple business units need separate input.
Pro Tip: Run a five-minute internal review with someone outside the security team before submission. If they can’t summarize a policy’s main rule in one sentence, it needs simpler language.
How Long Does It Take to Build and Certify a Policy Set?
Once you know roughly how many policies you need, the real question becomes how much time and budget the whole project eats up, and that depends heavily on organization size, existing documentation, and how many business units are in scope.
A phased plan usually breaks into five stages: scoping and gap analysis, policy documentation, evidence collection over at least one operating cycle, internal audit, and management review before the certification body ever shows up. ISMS Calculator turns those stages into a tailored Gantt-style timeline once you enter your company size, industry, and current security maturity, rather than forcing you to guess at generic project templates.
- A small organization with under 50 employees and a narrow scope often completes documentation and evidence collection inside a few months.
- A mid-sized organization spanning multiple departments or a SaaS product typically needs longer for supplier assessments and evidence maturity, especially around access reviews and incident logs.
- A large or multi-site organization usually spends the most time on scope negotiation and change management before policies even get drafted.
The tool’s maturity assessment scores your organization across 14 ISO domains, which is often the fastest way to see which policy areas are actually behind, rather than assuming every domain needs equal attention. Combined with industry benchmarks, that scoring turns a vague “we need policies” project into a prioritized list of what to build first. Running the free 2-minute readiness check gives you a baseline estimate before you commit budget or a certification date to anyone.
Why Fewer, Clearer Policies Beat a Longer Policy Set
Most organizations don’t fail audits because they’re missing a policy. They fail because the policies they have don’t match what people actually do, and nobody kept the evidence to prove otherwise. I’ve seen teams add a fifth backup policy variant while their incident log sits three months out of date. That’s backwards.
Plain-language policies that employees can actually summarize get followed, and followed policies generate their own evidence trail. Dense, legalistic ones get filed and forgotten. If you’re staring at a 25-policy checklist wondering where to start, stop optimizing the document count and start closing evidence gaps. A short readiness check and a benchmark against similar organizations will tell you faster than another round of policy drafting where the real risk sits.
— Martin
How ISMS Calculator Helps You Size and Plan Your Policy Set
Every option this article covered, open-source starter kits, commercial template packs, and mandatory-document checklists, gets you the documents themselves. None of them tell you how long the whole project will take or what it will cost your team in hours and budget. That’s the piece ISMS Calculator fills in.
Enter your company size, industry, and current security maturity, and the platform builds a tailored cost and effort estimate instead of a generic industry average. You get a maturity score across 14 ISO domains, a benchmark against similar organizations, and a customizable Gantt chart that turns your policy set into a phased project plan with actual dates attached. Export the results as a PDF or a shareable link when you need to bring budget numbers to leadership.
Start with the free 2-minute readiness check to get a baseline estimate at no cost, then save and compare a few scenarios once you know how scope changes affect the timeline. If you want a deeper, guided estimate before committing to a certification date, the ISO 27001 readiness assessment walks through the same variables with more granularity.
Sources
- Free ISO 27001:2022 Starter Kit — policies, registers, plans and other templates (GitHub)
- ISO 27001 Policies and Procedures: What You Need and How to Document Them | CertPro