ISO 27001 Policy Guide for Beginners in 2026

ISO/IEC 27001:2022 directly mandates only the Information Security Policy, which is set out in Clause 5.2, stating management’s intent to protect information and the baseline objectives for the ISMS. 

Annex A 5.1 puts that policy into practice, outlining controls and topic-specific policies to support the expectations set out in Clause 5.2. Since almost no organization excludes A.5.1 from its Statement of Applicability(SoA), it makes supporting policies a working obligation rather than a nice-to-have. 

This guide covers the list of necessary ISO 27001 policies, policy templates, and guidelines on writing your own policies. 

What are ISO 27001 policies?

ISO 27001 policies are foundational documents that define the organization’s protocols and information management practices on which your ISMS is built. And so, every policy undergoes meticulous definition, rigorous management reviews, approvals, and revisions to keep the ISMS up to date. An organization’s policies are largely driven by business requirements, legal and legislative mandates, and regulatory requirements.  

ISO 27001 mandates that organizations maintain transparency and communicate with stakeholders, customers, and senior management about their policies. Organizations are often requested to have their policies furbished as a part of their contract requirements. 

List of ISO 27001 policies

ISO 27001 mandates one policy; the rest of your set is an output of your SoA and who owns each control, which is why the count runs anywhere from a dozen to thirty. The list below groups the policies most organizations need by family, mapped to their 2022 controls.

1. ISMS & governance policies

Top management owns this layer, and it consolidates the most: small teams fold roles, risk, and improvement into the Information Security Policy.

Policy	Status	Primary 2022 control	What it governs
Information Security Policy	Mandatory	Clause 5.2; A.5.1; A.5.2; A.5.4	Top-level intent, objectives, and the framework for all other policies
Risk Management Policy	Almost always	Clause 6.1; A.5.1	Risk assessment and treatment methodology
Continual Improvement Policy	Almost always	Clause 10; A.5.1	Handling nonconformities and improving the ISMS
Document and Record Policy	Almost always	Clause 7.5; A.5.37; A.5.33	Version control, approval, and protection of records

2. Asset and information handling policies

These govern what you hold and how it moves; classification is the spine the rest hang off.

Policy	Status	Primary 2022 control	What it governs
Asset Management Policy	Almost always	A.5.9; A.5.11	Inventory, ownership, return of assets
Acceptable Use Policy	Almost always	A.5.10	Acceptable use of information and assets
Information Classification and Handling Policy	Almost always	A.5.12; A.5.13	Classification and labelling of information
Information Transfer Policy	Almost always	A.5.14	Secure transfer of information internally and externally
Data Protection Policy	Almost always	A.5.34; A.8.11; A.8.12	Privacy and protection of PII, aligned to GDPR and similar law
Data Retention Policy	Almost always	A.5.33; A.8.10	Retention periods and secure deletion

3. Access and identity policies

The most-tested area in any ISO 27001 audit; most teams keep one document unless different owners run access rights and the identity provider.

Policy	Status	Primary 2022 control	What it governs
Access Control Policy	Almost always	A.5.3; A.5.15; A.5.16; A.5.17; A.5.18; A.8.2; A.8.3; A.8.5; A.8.18	Access rights, privileged access, authentication, restriction

4. People security policies

Owned by HR, not security, which is exactly why auditors probe the handoffs.

Policy	Status	Primary 2022 control	What it governs
Human Resources Security Policy	Almost always	A.6.1; A.6.2; A.6.4; A.6.5; A.6.6	Screening, terms, disciplinary process, post-employment
Information Security Awareness and Training Policy	Almost always	A.6.3; Clause 7.3	Awareness, competence, and training (also satisfies Clause 7.3)
Remote Working Policy	Almost always	A.6.6; A.6.7	Remote and mobile working, plus confidentiality

5. Physical security policies

The one family a fully remote company can exclude, provided the SoA justifies it.

Policy	Status	Primary 2022 control	What it governs
Physical and Environmental Security Policy	Conditional (sites in scope)	A.7.1–A.7.14	Secure areas, entry, equipment siting
Clear Desk and Clear Screen Policy	Conditional (sites in scope)	A.7.7	Workspace expectations; often a section, not standalone

6. Technology operations policies

The largest family, and the one most worth splitting by owner since each policy produces its own continuous evidence.

Policy	Status	Primary 2022 control	What it governs
Secure Configuration Policy	Almost always	A.8.9; A.8.19; A.5.37; A.8.6	Baseline configuration and installation of software on systems
Change Management Policy	Almost always	A.8.32	Controlled change to information systems
Backup Policy	Almost always	A.8.13	Backup and restoration
Logging and Monitoring Policy	Almost always	A.8.15; A.8.16; A.8.17; A.8.34	Logging, monitoring, clock synchronisation
Malware and Antivirus Policy	Almost always	A.8.7	Protection against malware
Network Security Management Policy	Almost always	A.8.20–A.8.23	Network controls, services, segregation, web filtering
Technical Vulnerability Management Policy	Almost always	A.8.8	Identification and patching of vulnerabilities
Endpoint and Mobile Device Policy	Almost always	A.8.1	Secure configuration and handling of user endpoints

7. Cryptography policies

Split into two because key management and encryption use are often owned and reviewed separately.

Policy	Status	Primary 2022 control	What it governs
Cryptography Policy	Almost always	A.8.24	Key management, and where and how encryption is applied

8. Secure development policies

Applicable only if you build software, and easy to over-scope; one document usually covers the lifecycle.

Policy	Status	Primary 2022 control	What it governs
Secure Development Policy	Conditional (dev in scope)	A.5.8; A.8.25–A.8.31; A.8.33; A.8.4	Secure SDLC, environment separation, code review, testing

9. Supplier and cloud policies

Increasingly where auditors spend the most time, since most of your risk now lives in someone else’s infrastructure.

Policy	Status	Primary 2022 control	What it governs
Third-Party Supplier Security Policy	Almost always	A.5.19–A.5.23	Supplier onboarding, agreements, supply chain, cloud services

10. Incident management policies

Keep the policy short and testable; the operational detail belongs in a separate response plan and procedure.

Policy	Status	Primary 2022 control	What it governs
Information Security Incident Management Policy	Almost always	A.5.5; A.5.24–A.5.28; A.6.8	Event reporting, response, evidence, lessons learned

Here is a sample incident management policy you can download:

11. Continuity and resilience policies

The controls expect recovery objectives and testing, so commit to an RTO, an RPO, and a test cadence you can evidence.

Policy	Status	Primary 2022 control	What it governs
Business Continuity Policy	Almost always	A.5.29; A.5.30; A.8.14	Continuity, ICT readiness, disaster recovery, redundancy

12. Threat and compliance policies

The layer that keeps the ISMS honest and current; threat intelligence and compliance often answer to different owners.

Policy	Status	Primary 2022 control	What it governs
Threat Intelligence Policy	Almost always	A.5.6; A.5.7	Collection and use of threat intelligence
Compliance and Independent Review Policy	Almost always	A.5.31; A.5.32; A.5.35; A.5.36	Legal and regulatory obligations, IP, independent review

What should every ISO 27001 policy contain?

Every ISO 27001 policy is built from the same eight parts: purpose, scope, roles and responsibilities, rules, exceptions, evidence, review cadence, and approval and version history. And even though ISO 27001 guidelines focus more on rules, the rest of the seven sections of the policy make it defensible during an audit. 

So let’s look at the anatomy of an ISO 27001 policy in detail:

• Purpose: In this section, you explain why the policy exists and what risk it addresses, connecting back to your risk assessments.
• Scope: The scope lists the systems, people, locations, and data the policy covers, and what it deliberately excludes. While templates help here, you’d still need to customize them so the scope of your policies reflects your business reality. 
• Roles and responsibilities: In this section, you need to map the policy, controls, and responsibilities to the right owners, covering details like the person responsible for review, execution, approval, and maintenance of rules. 
• The rules: This section details what must happen, what must not, and under what conditions. Write them so compliance is observable. And ensure that these rules are testable. 
• Exceptions: Cover how someone requests a deviation, who can grant it, how long it lasts, and where the record lives. 
• Evidence: You need hard evidence, artifacts to prove that your ISMS operated as intended, and that any drifts were timely detected and rectified. So the policy needs to outline what artifact maps to which rule or control and parameters of upkeep of that evidence.
• Review cadence and triggers: This typically covers how often the policy is reviewed, plus the events that trigger an out-of-cycle review. 
• Approval and version history: Maintain a version history of all the changes and the approvals behind them, confirming that each change had an owner and was executed as intended. 

How do you write and implement the ISO 27001 policies?

To write and implement a policy set for ISO 27001, start by defining your ISMS scope and run the risk assessment that selects your controls. Then decide which of those controls need their own document, draft them, and route each to an approver with the authority to sign, communicate, and collect acknowledgments. 

Here’s a step-by-step guide on writing and implementing your policy set for ISO 27001:

Step 1: Scoping and assessing risk

ISO/IEC 27003 treats scope as the activity everything else rests on. So to start, you need to define a boundary under which your ISMS gets evaluated. Which business units, which locations, which systems, and which data are inside it, and by omission, what sits outside, all need to be listed out 

Once the scope is finalized, you need to identify the risks that are applicable to the assets in scope and rank them based on the likelihood of their occurrence and impact. 

Step 2: Selecting the set

Your policy set directly depends on the controls mentioned in your SoA, as the controls need to be tied to specific policies. Typically, a policy register lists each document, its owner, and the controls it covers. 

So to build your set, take the list of controls your SoA marked as applicable and group them by who runs the work. 

Step 3: Drafting

Every policy needs three things Clause 7.5.2 asks for. Identification and description, meaning a title, date, author, and reference number. A defined format and medium. Review and approval before it goes out.

So write each document to the same template, and give every rule a frequency, an owner, and a record it produces. 

Step 4: review and approval

Route each policy to its owner and capture the approval as a record naming the approver, the version, and the date. Here, a signature, a GRC workflow, or a ticket approval all work as evidence. 

Step 5: Communication and acknowledgment

A.5.1 expects that policies are published, communicated, and acknowledged. All 3 of these criteria need to be fulfilled. So publish versions where people can access them, trigger update notifications to concerned employees for each policy, and collect acknowledgement receipts against every version number. 

Step 6: Operate, review and update

Annex A 5.1 requires review at planned intervals and when significant changes occur. 

So put a review date on each policy, name the triggers that force an early review, and log every review, including the ones that change nothing. Some triggers worth naming can be an incident, an internal audit finding, a control change, an infrastructure migration, a new regulation, or a restructure that moves a policy owner out of the business.

Automate ISO 27001 policies with Sprinto

Managing ISO 27001 policies can quickly become a manual, time-consuming process, especially as organizations scale.

Sprinto simplifies policy management by automatically mapping policies to relevant controls, identifying gaps, generating summaries, and suggesting improvements for clarity and audit readiness.

Its AI capabilities also include a policy approval assistant to streamline reviews and sign-offs, policy improvement suggestions to strengthen policy language, and 15+ pre-built AI actions covering common compliance workflows, with the ability to create custom actions without coding.

Combined with support for 200+ compliance frameworks, 300+ integrations, and 4,000+ customers using Sprinto, these capabilities help teams keep their ISO 27001 policies aligned, actionable, and continuously connected to their broader compliance program.