---

Jump to my interactive ISO 27001 Policy Selection tool to help you determine which policies you need.

---

Purpose and Objective

Information security policies are a fundamental requirement for establishing security governance, supporting compliance, and guiding employee behaviour. Every ISMS needs policies; just how many, where, and why are down to you, as an organisation, to determine. I rarely see it implemented in the same way twice.

In plain terms, Clause 5.1 of ISO 27001 requires you to have a high-level policy. I usually refer to this as the ‘parent policy’, with all others as child policies signposted to from the parent.

Unless you stuff that main policy full to bursting with detail (and I do not recommend it), it needs to be backed up by more detailed policies on specific topics, and the whole lot needs to be reviewed and kept in step with the business as it grows and changes.

By implementing ISO 27001 Control 5.1, you create a clear framework that helps people know what good looks like and when they have deviated from the path. Without policies, anyone could do anything and claim they didn’t know. For example, the policy in my house is for the kids to wash their hands before eating, without that they could make themselves quite sick, and then claim ‘nobody told me..’

So, the main purpose of Control 5.1 is to ensure your organisation has a robust policy framework that provides clear direction, so that all relevant personnel and interested parties know exactly what is expected of them in protecting information.

The objective is to embed information security into your organisation’s culture and daily operations, supporting the effectiveness of your information security management system (ISMS).

---

What the control actually wants

ISO 27001 Control 5.1 (Policies for information security): requires that information security policies are defined, approved by management, published to everyone, communicated to relevant stakeholders (both internal and external) and reviewed at planned intervals or when significant changes occur.

Policy documents should be formal documents (within reason), approved by top management, and tailored to the organisation’s context. I say ‘within reason’ because I don’t know any business that benefits from having an internally facing policy (or externally, come to that matter) that’s written in complex, boring legal language, which nobody can understand and therefore cannot comply with.

What we are looking for is to change behaviours, and this can only come from understanding something. So, my key advice with policies is always to make sure they are in plain language, short, sharp, and easy to comply with.

So auditors will look for four things:

1. The policies are defined – there is a documented information security policy (and, ideally, supporting topic-specific policies).
2. The policies are approved – senior management has signed it off (name, role, date, version).
3. Policies are communicated – people who need to follow it, as well as relevant interested parties, have actually seen it.
4. Policies are Reviewed – policies are reviewed regularly, and you can show the review cycle has happened.

If you cover those four, you are most of the way there.

It is essential to ensure that employees understand their responsibilities under these policies for effective implementation and ongoing compliance.

---

Policy hierarchy (what you actually need)

A simple, workable structure for SMEs is:

1. Information Security Policy (top-level, strategic), which everyone needs to read.
2. Topic-specific/supporting policies (operational details), e.g., a development policy that is only needed by the engineering team.

You do not need 30 separate policies on day one, but you do need to show that you can create them, keep them consistent, and update them.

---

The foundation: Information Security Policy

So, let’s look at the highest-level statement of how your organisation manages information security and the Information Security Policy.

I’ve written more about creating one here if you need further guidance.

How to Write an Information Security Policy (ISO 27001)

The policy articulates the organisation’s approach to information security, providing a framework for all related activities.

Purpose

• Set direction and expectations across the organisation and with external parties
• Links security to objectives
• Shows leadership commitment through key statements
• Point to the other policies
• Provide management direction and management’s direction for information security

What to include

• Scope – what parts of the business or ISMS this policy applies to
• Objectives / principles – confidentiality, integrity, availability; “support business operations”; “protect customer data”
• Commitment – to meet legal, regulatory and contractual requirements
• Commitment to continual improvement – required by ISO 27001 under clause 5.2
• Roles and responsibilities – who owns information security, who approves policies
• Requirement to create topic-specific policies – access control, acceptable use, incident management, etc.
• Detailed requirements – specify detailed requirements for compliance and implementation of security controls
• Review – how often it will be reviewed (normally annually or on major change)
• Approval – name, role, date

For example, a paragraph you can drop in to show that the management commitment highlighted above could be something like…

“Top management is committed to protecting the confidentiality, integrity and availability of information. We will define, implement and maintain information security policies and supporting procedures, comply with applicable legal, regulatory and contractual requirements, and continually improve the effectiveness of our information security controls.”

Job done. That hits the ISO 27001 intention.

---

Supporting framework: topic-specific policies

The topic-specific policies “operationalise” the top policy. They tell people what to do in more specific scenarios, such as when working from home or using your own device for work.

The following is a list of such supporting topic-specific policies I’d expect to see in an ISMS. It’s not intended as a definitive list, so don’t rush off and create each one; it’s just a list of typical policies, and it’s fine to absorb some of these into others to combine them for simplicity.

ISO 27001 Policy List

Policy Name	Purpose	Annex A Controls
Sets out the top management’s commitment to information security and provides the overarching framework for the ISMS.	Sets out top management’s commitment to information security and provides the overarching framework for the ISMS.	5.1 Policies for information security
Acceptable Use Policy	Defines how employees and contractors may use company information assets, systems, and devices.	5.10 Acceptable use of information and other associated assets
Access Control Policy	Establishes the rules for granting, reviewing, and revoking access to information and systems based on business need.	5.15 Access control
Asset Management Policy	Governs the identification, ownership, classification, and handling of information assets throughout their lifecycle.	5.9 Inventory of information and other associated assets
Information Classification and Handling Policy	Defines classification levels and the corresponding handling, labelling, and protection requirements for information.	5.12 Classification of information; 5.13 Labelling of information
Cryptography Policy	Specifies when and how cryptographic controls (encryption, key management, digital signatures) are applied.	8.24 Use of cryptography
Physical and Environmental Security Policy	Sets requirements for protecting offices, equipment, and facilities from unauthorised access and environmental threats.	7.1 Physical security perimeters; 7.2 Physical entry
Human Resources Security Policy	Covers security responsibilities before, during, and after employment, including screening, training, and offboarding.	6.1 Screening; 6.2 Terms and conditions of employment; 6.5 Responsibilities after termination or change of employment
Supplier and Third Party Security Policy	Defines how supplier risks are assessed and managed, and what security requirements must be included in contracts.	5.19 Information security in supplier relationships; 5.20 Addressing information security within supplier agreements
Operations Security Policy	Establishes operational procedures, change management, capacity management, and protection from malware.	5.37 Documented operating procedures; 8.6 Capacity management; 8.7 Protection against malware
Communications Security Policy	Governs the security of network services, information transfer, and electronic messaging.	8.20 Networks security; 8.21 Security of network services; 5.14 Information transfer
Secure Development Policy	Defines secure coding, testing, and deployment requirements for systems developed in-house or via third parties.	8.25 Secure development life cycle
Incident Management Policy	Sets out how security events and incidents are reported, assessed, responded to, and learned from.	5.24 Information security incident management planning and preparation; 5.25 Assessment and decision on information security events
Business Continuity Policy	Establishes requirements for maintaining information security during disruption and ensuring recovery of critical services.	5.29 Information security during disruption; 5.30 ICT readiness for business continuity
Backup Policy	Defines backup frequency, retention, storage, and testing requirements to ensure information availability.	8.13 Information backup
Logging and Monitoring Policy	Specifies what events must be logged, how logs are protected, and how they are reviewed for security purposes.	8.15 Logging; 8.16 Monitoring activities
Vulnerability and Patch Management Policy	Governs the identification, assessment, and remediation of technical vulnerabilities.	8.8 Management of technical vulnerabilities
Mobile Device and Teleworking Policy	Sets requirements for securing mobile devices and remote working arrangements.	6.7 Remote working; 8.1 User endpoint devices
Data Protection and Privacy Policy	Aligns the ISMS with GDPR/UK GDPR obligations and defines how personal data is handled.	5.34 Privacy and protection of personal identifiable information (PII)
Compliance Policy	Establishes how legal, regulatory, and contractual obligations are identified and met.	5.31 Legal, statutory, regulatory and contractual requirements
Risk Management Policy	Defines the methodology for identifying, assessing, treating, and reviewing information security risks.	(Supports clauses 6.1, 8.2, 8.3)
Internal Audit Policy	Sets out how the ISMS is independently audited to verify conformance and effectiveness.	(Supports clause 9.2)
Management Review Policy	Defines the inputs, frequency, and outputs of management review of the ISMS.	(Supports clause 9.3)
Document and Records Control Policy	Governs how ISMS documentation and records are created, approved, distributed, and retained.	(Supports clause 7.5)
Change Management Policy	Establishes how changes to systems, processes, and the ISMS itself are controlled.	8.32 Change management
Acceptable Encryption and Key Management Policy	Defines specific algorithms, key lengths, and lifecycle controls.	8.24 Use of cryptography
Clear Desk and Clear Screen Policy	Reduces the risk of unauthorised access to information left visible in workspaces.	7.7 Clear desk and clear screen
Bring Your Own Device (BYOD) Policy	Sets conditions and controls under which personal devices may access company information.	8.1 User endpoint devices; 6.7 Remote working
AI Usage Policy	Governs acceptable use of generative AI tools and protection of information shared with them.	5.10 Acceptable use of information and other associated assets; 5.34 Privacy and protection of PII

Per my earlier comment, combining policies is fine. So, I might move the classification policy into the main information security policy, because everyone needs to know about it, but you don’t have to. Do what’s right for you

You don’t have to publish all of these externally. Some can stay internal if they contain sensitive details (e.g. configuration standards).

Good practice for these policies

• State the purpose (why this exists)
• State who it applies to (employees, contractors, partners)
• State controls / rules (e.g. “admin accounts must be named and assigned to individuals”)
• State responsibilities (IT, HR, line managers, users)
• State references (to the main information security policy)
• Add review period (usually 12 or 24 months)
• Provide implementation guidance to help teams develop, communicate, and maintain effective policies in line with standards such as ISO 27001 and ISO 27002.

Regular policy review is essential to ensure topic-specific policies remain current, effective, and aligned with organisational and regulatory changes.

Information Security Policy vs Topic-Specific Policies

The topic-specific policies support slightly different aspects than the main policy, for example;

Feature	Information Security Policy	Topic-Specific Policies
Level of detail	High-level, strategic	Detailed, operational
Audience	Whole organisation, external interested parties	Specific teams / roles
Approval authority	Top management	Process / functional owner
Purpose	Set direction, show commitment	Tell people exactly what to do
Review	At least annually / on major change	On change in technology/process, or annually
Examples	Information Security Policy	Access Control, Information Classification, Incident Management, Backup, Secure Development

---

Build Your Own Policy Pack Tool

Use my tool to define your own policy pack, identifying the policies you need, right-sized for your organisation.

---

Managing the policy lifecycle

ISO 27001 Control 5.1 isn’t just “write a policy”. It’s “write it, approve it, communicate it, review it”. This means it will slot in with Clause 7.5.3 “Control of Documented Information”. You must ensure that you can evidence the following;

Creation & approval

Ensure that you have a standardised approach to managing the policies in terms of;

• Draft the policy (security lead, IT manager, consultant, etc.)
• Check it aligns with business objectives and risks, using risk assessments to identify and address vulnerabilities
• Get senior management to approve it (CEO/MD/Director)
• Ensure the who/when of creation and approval are captured somewhere, either in a document header or automatically in an approval cycle tool

Communication

Auditors will ask: “How do staff know about this policy?”

Options:

• Publish on intranet / SharePoint / Google Drive with controlled access
• Include in onboarding/induction, for example, your employee handbook is common
• Ask staff to acknowledge key policies annually through something like an HR system with “read & accept” functionality and record keeping (my personal favourite)
• Add to the LMS/e-learning platform if you have one.
• Include in contracts for contractors / third parties (high-level version)

Review

Show this in your document:

• “This policy will be reviewed at least annually or sooner if there is a significant change in business, technology, legislation or risk.”
• Incorporate lessons learned from audits, security incidents, and ongoing improvement efforts into policy updates.
• Keep a document control table: version, date, change, author, approver.

When you update one policy (e.g. classification), check related ones (e.g. data transfer, backup) so they don’t contradict each other.

---

What auditors will want to see

One of the key things I tell my clients when we are taking them through their ISMS creation and defining their policies is this;

The auditor doesn’t evaluate if your policy is written well or badly; they evaluate against the key measures already outlined above in the ‘What the control actually wants’ section.

So, good evidence of the control would be having the following;

1. Current Information Security Policy – the main policy exists, with version, date, approver, and coverage of relevant laws and regulations
2. List of topic-specific policies – even a simple register in Excel/Sheets is enough
3. Communication evidence – show how you communicated it to stakeholders, e.g. induction pack, email announcement, LMS record, signed employee handbook
4. Review records – demonstrate how / when it was reviewed through meeting minutes, management review, change log, etc.
5. Link to objectives and risks – policy references the ISMS/risk assessment and specifies detailed requirements for compliance
6. External sharing rules – Ensuring you determine how you share policies with customers/auditors without exposing confidential content. Typically, this would come down to defining the policy’s classification (public or otherwise).

---

Common Issues with Security Policies

Here’s a quick list of ‘gotchas’ for you that might trip you up in an audit;

• The policy has no approval from top management. It’s fine if topic-level policies are approved by the department head or team lead if they are the subject expert and owner.
• The policy is out of date. There’s really no excuse for this. If you have a register of policies, ensure you include the date of last and next reviews.
• No evidence it was communicated to staff. “We put it on SharePoint” is not communication. Auditors want to see acknowledgement records, induction materials, or training logs that prove people actually saw it.
• Policies still written for ISO 27001:2013. I still see this occasionally. If your policies reference the old 14 control domains, the old A.5 to A.18 numbering, or the 2013 control names, you have a clear gap to close before audit. The 2022 structure (4 themes, 93 controls) needs to be reflected in your documentation.
• Sensitive configuration details are buried within the policy itself. Policies are statements of what you do; procedures and standards are how you do it. If your firewall rules, password complexity settings, or admin account naming conventions are part of a policy shared with customers, you have both a confidentiality and a maintenance issue. Keep policies high-level; push the details into supporting procedures.
• Inconsistent formatting and version control across the policy pack. Different headers, different review cycles, different approver names, different version numbers. An auditor will spot this in the first ten minutes, and it tells them your ISMS is being managed by individuals rather than as a system.

---

ISO 27001 Control 5.1 FAQs

---

Conclusion

Control 5.1 is one of the simplest controls to satisfy, but it underpins the rest of ISO 27001.

Get a single, business-aligned information security policy approved by management, back it up with topic-specific policies for the main risk areas, publish them to staff, and review them on a schedule. If you can also show evidence of communication and version control, your auditor will have very little to challenge.

If you’d like to see what a complete SME policy pack looks like in practice, the Iseo Blue ISO 27001 Toolkit includes editable templates for every policy on this page, written in plain English and pre-mapped to the 2022 controls.

Or if you’d rather talk through your situation before committing to anything, the free 30-minute consultation is genuinely free and genuinely 30 minutes; no follow-up sales cycle, no obligation. Either way, you’ll leave with a clearer view of what your policy pack should look like.

---