ISO 27001 Policies Required: A Practical Guide with Steps & Examples (2026)

ISO 27001 Clause 5.2 requires exactly one named policy: the information security policy, formally approved by top management. Beyond that, there's no fixed number of required policies — your risk assessment and the Annex A controls you select determine which topic-specific policies you actually need. Most procurement teams now ask for evidence of these policies before signing a deal, and sellers who think their documentation is ready often find risk questionnaires and audits reveal real gaps.

This guide draws on Konfirmity's work across 6,000+ security audits to explain why policies matter, exactly what the standard demands, and how a security-driven approach to writing and rolling them out improves outcomes for companies selling into regulated sectors.

Key Takeaways: ISO 27001 Policies Required

ISO 27001 Clause 5.2 requires one overarching Information Security Policy, formally approved by top management. Beyond that, there's no fixed number of required policies — your risk assessment and the Annex A controls you select determine which topic-specific policies you need, with common examples including access control, asset management, and incident response. A policy states what you do and why; procedures describe how to do it step by step.

Why Policies Matter in ISO/IEC 27001 and Enterprise Sales

ISO/IEC 27001 is the world's best-known framework for information security management, providing guidance for establishing, implementing, maintaining, and continually improving an ISMS. Conformity means an organization has a real system for managing data-security risk, following the standard's own best practices.

The standard takes a holistic view — people, policies, and technology together — which matters most when selling to large customers. Procurement teams operate under obligations from HIPAA, GDPR, SOC 2, or emerging AI security frameworks, and send questionnaires covering risk assessment, access control, business continuity, and vendor security. Without documented policies answering those areas, deals stall.

Policies provide broad direction: what you do and why, leaving procedures to explain how. For enterprise buyers, policies demonstrate management commitment, risk appetite, and ISMS scope, and give assurance you understand confidentiality, integrity, and availability — the three pillars of information security.

Understanding "ISO 27001 Policies Required"

Mandatory vs. De-Facto Required Policies

ISO 27001 explicitly names one policy in Clause 5.2: the information security policy. Top management must document, approve, communicate, and periodically update it, setting out management's commitment to protecting information, the assets that need protection, the threats faced, and the controls used to mitigate them. Without this document, you will not pass an ISO 27001 certification audit.

Beyond that one policy, other documents become effectively required once you implement specific Annex A controls or address particular risks. Annex A lists 93 controls across organizational, people, physical, and technological categories, and during certification you produce a Statement of Applicability explaining which controls apply and why. Apply an access control measure, and auditors expect an Access Control Policy. Classify information, and you need an Asset Management Policy. Policies emerge from your risk assessment and the controls you actually choose — not from a fixed checklist.

Policies vs. Procedures

The information security policy vs. procedure distinction is the one teams blur most often. HighTable's framing is the clearest version: policies describe what you do and why, procedures describe how. Policies should avoid detailed process steps, which often contain proprietary or operational specifics you don't want to share externally — a broad policy sets principles and objectives, leaving the "how" to separate procedures. Keeping the two separate is also what lets you hand a policy to a client without exposing internal detail.

Policies as the Spine of the ISMS

ISO 27001's mandatory clauses — defining scope, demonstrating leadership commitment, setting objectives, allocating resources, planning operations, measuring performance, and managing non-conformities — each depend on a policy underneath them. A Risk Management Policy supports the risk assessment and treatment plans in Clauses 4 and 6. An Access Control Policy supports Annex A's identity and least-privilege controls. A Business Continuity and Incident Response Policy supports Clause 8 operations and Clause 9 performance evaluation. Document Control, Audit, and Compliance policies show auditors you have a real cycle for monitoring, review, and improvement — and enterprise clients expect to see exactly these documents because they map directly onto their own vendor risk questionnaires.

Why Enterprise Buyers Care

Why enterprise buyers care comes down to rising stakes: the global average cost of a data breach reached a record $4.99 million in 2026, up 12% year over year according to IBM's 2026 Cost of a Data Breach Report, driven largely by AI-enabled attacks and rising detection and business-disruption costs. Healthcare breaches remain the most expensive category by sector, and third-party and vendor-related incidents continue to be one of the most common initial attack vectors. Enterprise buyers need evidence that you manage these risks, and a documented policy is the first signal that you do — which is exactly why questionnaires ask for vendor security documentation, incident response plans, and training evidence up front.

Core Policies Every ISO 27001 Programme Needs

The list below covers the main policies most organizations selling into regulated sectors actually need, each with a simple example illustrating intent.

1. Information Security Policy — management's commitment to confidentiality, integrity, and availability, the ISMS scope, objectives, and roles. Example: leadership commits to protecting all company and client information, sets risk-reduction objectives, and mandates annual review. Satisfies Clause 5.2 and underpins every other control.
2. Risk Management and Assessment Policy — how you identify, assess, treat, and report risk, including risk appetite and register maintenance. Example: risks evaluated quarterly, a maintained register with likelihood/impact ratings, treatment plans approved by the CISO. Supports Clauses 4 and 6.
3. Asset Management Policy — how you inventory, classify, and manage assets through their lifecycle. Example: every asset recorded with an owner, classification reviewed annually. Supports Annex A asset management controls.
4. Access Control Policy — how privileges are granted, modified, and revoked, including least privilege and segregation of duties. Example: role-based access enforced, MFA required for privileged accounts, quarterly access review. Corresponds to Annex A identity and authentication controls.
5. Cryptography and Encryption Policy — how encryption protects data in transit and at rest, and how keys are managed. Example: AES-256 for sensitive customer data, annual key rotation, a documented compromised-key process. Ties to Annex A cryptography controls.
6. Incident Response and Business Continuity Policy — detection, reporting, and response to incidents, plus how operations continue through disruption. Example: a defined incident response team, time-bound escalation, per-function recovery time objectives. Satisfies Clause 8 and 9 requirements.
7. Vendor and Third-Party Security Policy — how you select, onboard, and monitor vendors, including required risk assessments and contract clauses. Example: vendors handling sensitive data complete a risk assessment, provide SOC 2/ISO 27001 evidence, and agree to 24-hour incident notification. Addresses one of the largest sources of breaches directly.
8. Training and Awareness Policy — regular security training and phishing awareness for employees and contractors. Example: annual awareness training, twice-yearly phishing simulations, security briefing at onboarding. Responds to the human element in breaches.
9. Compliance, Audit and Review Policy — how you monitor and audit the ISMS, manage non-conformities, and track legal requirements. Example: annual internal audits, quarterly management review, a maintained register of applicable laws. Supports Clauses 9 and 10.
10. Document and Record Control Policy — how policies and ISMS documents are created, approved, versioned, retained, and disposed of. Example: a central repository with version history, records retained three years, owner approval required for changes. Protects documentation integrity itself.

Additional Topic-Specific Policies

Small organizations don't need dozens of stand-alone documents, but enterprise buyers often expect them anyway. Additional policies commonly include Acceptable Use, Clear Desk/Screen, Remote Working, Network Security, Change Management, Data Retention, Malware and Antivirus, Backup, Logging and Monitoring, Secure Development, Physical and Environmental Security, and Information Transfer — each tied to a specific set of Annex A controls. A Remote Working Policy might require personal devices to register with an endpoint management system and mandate VPN use; a Change Management Policy might define how changes are requested, assessed, approved, and recorded. Rather than writing a separate document per control, busy teams can group related topics into modular sections attached to a core policy.

Mapping Policies to ISO 27001 Controls

Building Your Policy Framework: A Practical Step-by-Step Guide

A structured, nine-step approach — drawn from Konfirmity's delivery work and Clauses 4–10 — keeps this from becoming overwhelming for a busy team.

1. Secure Management Commitment and Define Scope

Get explicit senior leadership support first. Clause 4 requires defining ISMS scope — the business units, processes, locations, and information assets covered. Involve engineering, product, legal, and sales to understand client expectations, draft a scope statement that explicitly excludes what's irrelevant (an internal marketing site, say) and why, and get management to approve the scope and commit resources.

2. Conduct Risk Assessment and Asset Inventory

Identify and classify your information assets (confidential, restricted, public), map them to business processes and client obligations, and run a risk assessment covering threats, vulnerabilities, and potential impact. Record everything in a risk register with treatment plans, often prioritized using CVSS, and tie this work directly to your Risk Management Policy and Clauses 4 and 6.

3. Assign Policy Ownership

Appoint an owner per policy — typically the CISO for the information security policy, technical leads for access control or cryptography. Clarify who drafts, approves, communicates, and reviews each one, set a review cycle (commonly annual), and record version history in your Document Control Policy so accountability doesn't evaporate when someone leaves.

4. Draft the Core Policy

Use a template to build the information security policy: purpose, scope, definitions, roles, commitment to continual improvement, broad objectives, and references to supporting documents, addressing Clause 5.2's requirement that it fit your organizational context. Get senior management sign-off and make it accessible to employees, contractors, and — where relevant — clients.

5. Draft Supporting Policies

Use the core list above as your checklist, prioritized by risk and client demand. Processing healthcare data pushes Business Continuity and Vendor Security policies to the front, given healthcare's breach-cost premium and how often third-party incidents originate there. Hosting customer data on public cloud pushes Cryptography and Network Security policies forward. Write in clear language, keep process steps out, and group related topics into modular sections rather than letting documents multiply.

6. Communicate, Train and Roll Out

A policy nobody knows about is dead weight. Clause 7 requires competence and awareness — run training across formats (e-learning, live sessions, phishing simulations), require attestations that employees actually read and understood each policy, fold security orientation into onboarding and vendor induction, and keep policies accessible through an intranet or knowledge base.

7. Implement Controls and Monitor Enforcement

Deploy the technical and organizational controls that back each policy: SSO and MFA for access control, inventory tooling for asset management, monitoring and ticketing for incident response. Document these as procedures linked back to their policy, and make sure internal audits check both that the policy exists and that there's evidence it's enforced — this is exactly what Clause 9 is checking for.

8. Measure, Review and Improve

Clauses 9 and 10 require evaluating performance and managing non-conformities: run internal audits and management reviews on a schedule, track metrics like incident count, mean time to detect and remediate, training completion, and policy exceptions, and document non-conformities with their corrective actions. Update policies when the business or the threat landscape changes — auditors specifically look for evidence that findings actually get acted on.

9. Certification and Client Assurance

If you're pursuing certification, an accredited certification body runs Stage 1 (document review) and Stage 2 (evidence of implementation), followed by ongoing surveillance audits. Without certification, you can still provide client assurance by sharing your policy framework, audit reports, and enforcement evidence directly — in Konfirmity's experience, this alone shortens procurement cycles. With a fully managed service, customers typically reach SOC 2 and ISO 27001 readiness in 4–5 months versus 9–12 months self-managed, spending under 70 hours a year instead of 550+.

Templates, Examples and Practical Tips

Structure of a Policy Document

A concise, consistent structure makes every policy easier to write and easier for an auditor to sample: Purpose/Objectives (why it exists), Scope (units, locations, systems, data covered), Definitions, Roles and Responsibilities, Policy Statements (broad rules, e.g. "all users must use MFA when accessing production systems"), Compliance/Enforcement (consequences and exceptions process), Review/Revision History, and Approval (senior management sign-off, recorded in minutes or an e-signature system).

Sample Snippets

These sample snippets show the level of specificity a real policy statement needs, adapted from language already in use:

• Access Control Policy: "User access to systems must be authorized by the asset owner. Access rights are removed within 48 hours of employee exit. Privileges are reviewed quarterly by the system owner."
• Incident Response Policy: "Any employee who becomes aware of a security incident must report it immediately to the incident response team via the designated channel. The team classifies incidents within one hour and initiates the appropriate response plan. Lessons learned are documented and feed into process improvements."
• Vendor Security Policy: "Before onboarding a third-party service provider, the vendor risk management team must conduct a risk assessment, obtain assurance reports such as SOC 2 or ISO 27001 certificates, and include security obligations in the contract. Vendors processing sensitive data must notify the company of any security incident within 24 hours."

Building these from scratch takes time. Our ISO 27001 Policy Templates Pack covers the core information security policy plus the topic-specific policies above, ready to adapt.

Practical Tips for Busy Teams

• Use a policy library instead of a blank page. Many teams burn months writing from scratch when a vetted template, customized to context, gets you 80% of the way there.
• Prioritize by risk. You don't need a dozen documents on day one — start with the policies addressing your highest risks and the topics clients ask about most, then expand as the program matures.
• Make policies living documents. Version-controlled, scheduled for review, updated after audit findings and incident post-mortems — not written once and forgotten.
• Record evidence of enforcement. A policy alone satisfies nobody. Keep training completions, access reviews, risk assessments, and vendor questionnaires on file, automated where possible.
• Fit policies to your actual regulatory context. Healthcare pulls in HIPAA, EU personal data pulls in GDPR, SaaS often needs SOC 2 — map policies to what actually applies rather than duplicating generic coverage.
• Bring in dedicated expertise where it counts. A managed service that embeds into your team and does the implementation and evidence-collection work directly can cut a team's ongoing effort from 550+ hours a year to around 75.

Common Pitfalls and How to Avoid Them

The common pitfalls here, and how to avoid them, recur across nearly every audit Konfirmity supports:

• Policies exist on paper but aren't enforced. Auditors look for evidence a policy is actually applied — back every statement with a procedure, a control, and monitoring.
• Using a generic template without adapting it. An unmodified download signals a lack of ownership; adjust content to your actual business, processes, and risk appetite.
• Outdated policies. A policy untouched for three years reads as neglect to an auditor — schedule real reviews tied to threat and regulatory changes.
• Over-documenting without risk context. A control deployed because a template said so, with no link to an actual risk, invites the question "why does this exist?" — document the connection explicitly.
• Neglecting vendor risk. Third-party breaches cost millions industry-wide. Make vendor assessment a formal, enforced part of the ISMS, not an afterthought.

How a Strong Policy Framework Helps You Win Enterprise Clients

Documented policies signal maturity. When responding to a due-diligence questionnaire, handing over your Information Security, Access Control, Vendor Security, and Incident Response policies — instead of writing ad hoc answers each time — reduces friction and builds trust immediately. It also satisfies real obligations: healthcare clients under HIPAA need assurance their business associates protect ePHI, and sharing your Business Continuity and Incident Response Policy plus training records addresses that directly. GDPR, SOC 2, and emerging AI security frameworks all expect documented governance, and a thorough policy set shows you take it seriously rather than treating it as paperwork.

Konfirmity is built around "start with security and arrive at compliance." Run it self-serve, or add the fully managed service and a dedicated team implements controls inside your stack, monitors them continuously, and maintains audit readiness year-round — rather than a platform that only collects artifacts, or a consultant who leaves after the report. Clients report roughly 75% fewer audit findings and readiness months sooner, with evidence already in hand when procurement asks for it.

See what your policy framework is missing

Book a demo and we'll map your current policies against what ISO 27001 auditors and enterprise buyers actually check.

Book a demo

Frequently Asked Questions

Conclusion

Policies are the backbone of an ISO 27001 programme and a critical signal to enterprise buyers. Only the information security policy is explicitly named in the standard, but implementing Annex A controls and addressing your actual risks means producing a real suite of supporting policies — documents that define what your organization stands for in information security, guide behavior, and demonstrate governance. Building this takes management commitment, a real risk assessment, clear ownership, thoughtful drafting, training, control implementation, monitoring, and continuous review, and using templates or dedicated expertise makes the task genuinely manageable rather than a scramble.

For cloud vendors selling into regulated sectors, strong policies are a differentiator: they shorten procurement, prove you understand client obligations, and form the foundation for SOC 2, HIPAA, GDPR, and AI security compliance alike. Start with the information security policy, build out the supporting documents, and treat all of it as living guidance — combined with continuous monitoring and evidence collection, that's what satisfies auditors and protects the business at the same time.