Information security policy template

What's in the template

One Word document, seven pages, version 1.2. It has four parts:

1. The information security policy. Your top-level policy, laid out the way an ISO 27001 auditor reads it: purpose and scope, management's commitment, how the policy sets your security objectives, roles and responsibilities, the topic-specific policies that sit beneath it, and how it's approved, communicated and reviewed.
2. A getting-started guide. It shows which parts to edit first and what to leave alone.
3. Next steps. These show where the policy fits in your wider ISMS, and what to write after it.
4. A policy management checklist. It covers approval, sign-off, communication and review dates, which are the records an auditor asks to see alongside the policy.

Every placeholder is marked in square brackets, so you replace the names and dates, adjust the scope, and it's ready for management approval.

What is an information security policy?

An information security policy is the document in which your leadership states how the organisation protects information: what's in scope, who is responsible, and what everyone must do.

It doesn't hold every technical rule. Those live in topic-specific policies such as access control, acceptable use and backup.

The information security policy sets the direction they all follow.

It's usually the first document a certification auditor asks for and the first one a customer's security questionnaire requests. If it's missing, or reads like a generic download with another company's name still in it, that tells the reviewer to dig deeper.

Which standards require one

For the detail on each requirement, see the ISO 27001 A.5.1 guide and the clause 5.2 guide.

How to create your information security policy with this template

With the groundwork in place, this takes about half a day plus one management meeting. Without it, the policy is the wrong place to start, so check the groundwork first.

Before you start

Your policy has to describe an organisation that's ready for it.

Check you have:

• An ISMS scope statement. The policy's scope must match it, and clause 4.3 is where it's set. No scope statement yet? Write that first: see our guide to ISO 27001 Clause 4.3.
• A named owner, and an approver with authority. The owner keeps the policy current. The approver must be top management: someone who directs and controls the organisation.
• A view of your topic-specific policies. Know which exist today and which you'll publish before the audit. The policy will name them.
• A sense of your risks. Your commitments and objectives should reflect what you're protecting against. Our clause 6.1 guide covers this.

If none of these exist yet, the job is bigger than one policy. That's the point where most firms bring in help.

1. Name the owner and the approver (10 minutes)

• Do this: put names against the owner, approver and reviewer roles.
• The template: has those roles laid out, so you're filling in names, not designing a governance model.
• Watch for: an approver below top management. A CTO who sits on the executive team counts. An IT manager outside it doesn't, however capable they are.

2. Set the scope (30 to 60 minutes)

Next, say which teams, locations, systems and services the policy covers, in words that match your ISMS scope statement.

The template gives you the structure and placeholders. The judgement is in where you draw the line.

3. Make every statement true (about an hour)

• Do this: confirm the two commitments clause 5.2 requires (to meet applicable requirements and to improve continually), decide how objectives are set, then read every remaining line and ask: "Could we show an auditor this happens?"
• The template: has the clause 5.2 commitments written in, and every organisation-specific detail in [brackets], so nothing generic hides in the prose.
• Watch for: writing this year's objectives into the policy. It dates within twelve months. Say where objectives are set, such as the management review, and keep them in a register.

4. Link your topic-specific policies (20 minutes)

Then list the policies that sit beneath this one, such as access control, acceptable use and backup, using their exact titles.

Only list what exists, or what will be published before the audit: an auditor will ask for each one by name, and a missing policy is an easy finding.

5. Approve, publish and record acknowledgement (one management meeting, then 1 to 2 hours)

• Do this: take it to top management for approval and set the next review date, no more than a year out. Then publish it where staff can find it and ask everyone in scope to confirm they've read it.
• The template: includes a policy management checklist for the approval, review date and communication records.
• Watch for: approval that exists only as an email or a typed name, and acknowledgement no one can evidence. Both are covered in How to use it so it holds up at audit.

Do it yourself, or have us do it with you

Prefer the second column? Talk to us about ISO 27001 readiness.

What good looks like

Most information security policies pass a quick read. Fewer survive an auditor's. Here is the difference.

Weak and strong, side by side

What an auditor checks in the first five minutes

Before reading the detail, most auditors check that:

• It's current. It has a version, an approval date and a review date that hasn't passed.
• The right person approved it. The approver is top management, and there's a record of the approval.
• The scope matches. It describes the same scope as the ISMS scope statement.
• The commitments are there. It covers objectives, meeting requirements and continual improvement.
• It's genuinely yours. It has your organisation's name and specifics throughout, with no leftover template text or another firm's name.
• The named policies exist. Every topic-specific policy it lists can be produced on request.

If all six hold, the auditor moves on with confidence. If one fails, they usually look harder at everything else.

What good looks like at 25 staff and at 250

The common mistake at 25 staff is adopting a policy written for 2,500: it promises processes the firm can't run. The common mistake at 250 is the reverse, a top-level policy that has never grown up with the firm.

How to use it so it holds up at audit

The policy is only half the evidence. An auditor tests whether it operates, and these are the records they usually ask for:

• The approval record: who in top management approved this version, and when.
• Acknowledgement: evidence that staff in scope have read it, from an HR system, an e-signature or a training platform.
• The review history: the date of the last review, what changed, and the next review date.
• Alignment: the objectives and topic-specific policies it names actually exist, and are current.

The most common reasons this policy fails audit:

• It was never formally approved, or the approver isn't top management.
• It names policies, roles or tools that don't exist at the firm.
• No one can show that staff have seen it.
• It's more than a year old, and nothing shows it was reviewed.
• It was copied from a template and still carries the template's wording or another organisation's name.

Each of these is cheap to prevent and costly to explain in the audit room.

Information security policy questions

Get the template

Start from a policy that already says what an auditor expects, written for a firm your size. Download the Word template, put your names in, and take it to your next management meeting for approval.

This template is a starting point to adapt to your organisation, not legal advice.