ISO 27001 Policy Templates: What to Include and How to Write Them

ISO 27001 certification requires documented policies. But "documented" does not mean lengthy, complex, or consultant-authored. The standard requires policies that are proportionate to your organisation and actually followed — not policies that exist to satisfy an auditor and are ignored in practice.

This guide covers which policies are mandatory, what each must contain, and how to structure them so they work as real operational tools.

Which policies does ISO 27001 require?

ISO 27001:2022 mandates documented policies in several places. The core requirement is in Clause 5.2: top management must establish an information security policy. Annex A adds specific policies across its 4 control categories.

Mandatory under the management system clauses:

Clause	Requirement
5.2	Information security policy (top-level, signed by top management)
6.1.2	Documented risk assessment methodology
6.2	Information security objectives

Mandatory or strongly expected under Annex A (based on typical risk assessments):

Annex A control	Policy
A.5.1	Policies for information security (top-level + topic-specific)
A.5.10	Acceptable use of information and other associated assets
A.5.12	Classification of information
A.5.14	Information transfer
A.5.15	Access control policy
A.5.29	Information security during disruption
A.6.2	Terms and conditions of employment (security obligations)
A.6.3	Information security awareness, education, and training
A.6.7	Remote working
A.7.9	Security of assets off-premises
A.8.1	User endpoint devices
A.8.9	Configuration management

The actual policies you need depend on your risk assessment and Statement of Applicability. A control you declare "not applicable" in your SoA does not require a policy. But any control you declare applicable — particularly in A.5 organisational controls — almost always requires at least a brief policy statement.

The information security policy (Clause 5.2)

This is the top-level policy — the document that signals organisational commitment to information security. Clause 5.2 requires it to:

• Be appropriate to the purpose of the organisation
• Include information security objectives or provide a framework for setting them
• Include a commitment to satisfying applicable requirements
• Include a commitment to continual improvement of the ISMS
• Be communicated within the organisation
• Be available to interested parties as appropriate

What it does not need to be: long. A one-page A4 document signed by the managing director satisfies the requirement for most SMBs. The mistake most businesses make is writing a generic policy downloaded from the internet that no employee recognises as relevant to their work.

Effective information security policy structure:

1. Purpose and scope (1 paragraph): Why information security matters for this business. Name the specific risks — client data, business systems, supplier relationships.
2. Objectives (3–5 bullet points): Specific, measurable where possible. "All staff to complete annual security awareness training by December each year." Not: "maintain a culture of security."
3. Commitments (1 paragraph): Commitment to meeting ISO 27001 requirements and continually improving the ISMS.
4. Responsibilities (1 paragraph): Who owns the ISMS. Named individual, not "the IT department."
5. Review (1 line): Annual review date and approval authority.
6. Signature and date: Managing director or equivalent.

One page. Reviewed annually. Communicated to all staff at induction and when materially updated.

Topic-specific policies

Under Annex A.5.1, you are expected to have topic-specific policies for individual control areas. Each policy is a separate document — typically 1–3 pages — covering a specific subject area in more detail than the top-level policy.

Acceptable use policy (A.5.10)

Covers: permitted and prohibited use of information assets. What staff can and cannot do with company systems, devices, email, and data. Must include:

• Permitted personal use (if any) of company systems
• Prohibited activities: installing unauthorised software, sharing credentials, accessing systems for personal gain
• Use of portable media and personal devices (BYOD)
• Consequence of policy breach (reference disciplinary procedure)
• Review: annually, or when significant changes occur

Access control policy (A.5.15)

Covers: who gets access to what, and how access is granted, reviewed, and revoked. Must include:

• Principle of least privilege — access only to what is required for the role
• How access requests are made and approved
• Joiner / mover / leaver process for access changes
• Review frequency for access rights (annually for most systems; quarterly for privileged access)
• Reference to privileged access management (A.8.2)

Clear desk and clear screen policy (A.7.7)

Often combined into one document. Must include:

• Physical clear desk requirements: no sensitive documents visible when unattended
• Screen lock requirements: automatic lock after [X] minutes; manual lock when leaving desk
• Printer and copier procedures: collect sensitive print-outs immediately
• Disposal of paper documents containing sensitive information

Remote working policy (A.6.7)

Covers: information security requirements for staff working away from the office. Must include:

• Permitted and prohibited activities when working remotely
• VPN or secure connection requirements for accessing internal systems
• Physical security requirements for home offices (screen visibility, visitors)
• Device requirements: encryption, updated OS, antivirus
• Incident reporting when working remotely

Bring your own device policy (A.6.7 / A.8.1)

If personal devices access company systems. Must include:

• Eligibility and approval process for BYOD
• Minimum security requirements for personal devices (encryption, passcode, approved app)
• Data storage restrictions: what company data can be stored on personal devices
• Right of the company to remotely wipe the device if lost, stolen, or on leaving the company
• Leaver process: verify data removal from personal device

Supplier security policy (A.5.19–A.5.22)

Covers: how third-party suppliers that access your systems or data are managed. Must include:

• Due diligence requirements before engaging suppliers
• Contractual requirements: data processing agreements, right to audit, security obligations
• Ongoing monitoring: how supplier security is reviewed during the relationship
• Termination: how access is revoked and data is recovered or destroyed at contract end

Policy writing principles

Write for the reader, not the auditor. A policy that staff cannot understand will not be followed. Avoid legal language, passive voice, and abstract commitments.

Be specific to your business. Generic downloaded templates fail because they reference systems, roles, and processes that do not match your organisation. Name your actual systems (Microsoft 365, not "email systems"). Name your actual roles (Office Manager, not "relevant personnel").

Keep them short. One to three pages per policy. An employee should be able to read and understand a policy in under five minutes.

Assign ownership. Each policy should have a named owner — the person responsible for maintaining and implementing it. Typically the IT Manager, Operations Director, or ISMS Manager.

Set a review date. Annual review is the minimum. Trigger-based reviews are also required: when a significant change occurs, after an incident, or when the policy area is identified as a risk.

Control your versions. Policies are documented information under Clause 7.5. They need version numbers, review dates, and approval signatures. A simple header block on each document handles this:

Document: Remote Working Policy | Version: 1.2
Approved by: Jane Smith (MD) | Date: 2026-03-15
Next review: 2027-03-15

How policies connect to your ISMS

Policies do not exist in isolation. Each feeds into:

• Risk assessment (Clause 6.1): policy gaps identified in the risk assessment indicate which new policies are needed
• Mandatory documents (see full list): policies form a significant portion of the ISMS documentation set

• Internal audits (Clause 9.2): auditors check whether policies are being followed in practice — not just whether they exist. See ISO 27001 Internal Audit Guide
• Awareness training (A.6.3): all staff must be aware of the security policies relevant to their role. Policy distribution and training records are evidence of this
• Management review (Clause 9.3): policy adequacy is reviewed annually as part of management review inputs

The most common finding during Stage 2 audits related to policies: the policy says one thing and the practice is something different. "Staff must use VPN when working remotely" written in the remote working policy, but 4 of 8 audited staff had never been set up with VPN access. The policy exists; the control does not. Write policies that reflect what your business actually does — or implement the controls before the audit.

This article is for general informational purposes only and does not constitute legal, regulatory, or professional compliance advice. ISO certification requirements vary by scope, sector, and certification body. Always verify requirements with your UKAS-accredited certification body or a qualified consultant before making compliance decisions.