How to write, deploy and implement ISO27001 policies

Home / ISO 27001 Tutorials / How to write, deploy and implement ISO27001 policies

In this article I lay bare how to write, deploy and implement ISO27001 Policies. A beginners guide, exposing the insider trade secrets, giving you the templates that will save you hours of your life and showing you exactly what you need to do to satisfy it for ISO27001 certification. We show you exactly what changed in the ISO27001:2022 update. I am Stuart Barker the ISO27001 Ninja and this is how to implement ISO27001 Policies.

Introduction

This document is to act as a guide when deploying the ISO27001 policies. It is not a substitute for real world experience. The guide is based on need and the need is based on your business. If you understand your business, you are in a great position. 

When developing ISO27001 policies, we would in the normal course of events produce them as part of a structured process. The first step being to develop the Context of Business. This is not covered in this document, but it is assumed, that to a greater or lesser or extent, you have completed that step.

ISO27001 Clause 5.2 Policies

The ISO27001 requirement policies comes from Clause 5.2 and this is a great introduction to the wider requirements of the ISO27001 policies.

ISO27001 Policy Templates

All of the required information security policies for ISO27001 are included in the ISO27001 Policy Template Toolkit. They are already written and ready to go. If you want to fast track then get a copy of the toolkit.

ISO 27001 Policy Template Toolkit

What are ISO27001 Policies?

Policies are statements of what you do. They are not how you do it. How you do it is covered in the process documents of the business. We would advise maintaining this logical separation.

Confusing policies and processes into one document will add complexity such as when asked to share your policies with third parties. Sharing documents that contain potentially staff contact details or propriety process steps is not advised if it can be avoided. Keep them logically separate.

ISO27001 Policies Implementation Guide

This video on on the ISO27001 YouTube channel shows you exactly what you need to do, step-by-step.

First write your ISO27001 policies

These policies are what good looks like. There is nothing in here that you should not be able to do as a business. Remember it is not saying how you do it. This is best practice based on industry standard and ISO27001. 

They are your starting point. You are going to review each policy for what is says that you do and check that you either can or will do it. If you cannot or will not, then you have work to do to understand the changes required to the policy. It is not unreasonable to change them. That is the art of the implementation. 

Build your policy pack

Creating a folder on your file storage drive called policies is a great place to start. We would advocate at this stage a sub folder for each version and iteration of signed off policies. For now, create your base folder and copy the templates to there. You will always have the foundation and something to come back to. 

The folder structure should support your complete Information Security Management System and your mandatory ISO27001 documents.

Brand your policies

Brand the policies to your business brand.

Assign Owners to your Policies

Policies should be assigned to the people that are ultimately accountable for the area that the topic that the policy covers. 

If you have the ISO27001 Toolkit, then complete the Document Tracker and record the owner in there.

In each Policy set the [Document Owner] to the assigned document owner. 

Review the Policies

Either assigning to the Policy owner or working with the policy owner review each policy, updating the variables (see section below) as required. The policies are statements of what you do not how you do it. You are reviewing whether the policy statement of what you do is accurate in terms of you do do it, or you will be able to do it. You will tackle how you do it in the process documents. For now, concentrate on what you do. There should not be anything in here you do not or cannot do but use your judgement to update the policy as required. 

Update Version Control, Document Markup and Make Live

If this is the first build, then once the review stage is complete and the policies reflect your reality then now is the time to set the version control. Update the version control table. It is good practice to set all documents in your first build and deployment to version 1.

You are going to take these policies to the next Management Review Team meeting for sign off. To do that you will share them with the Management Review Team before hand and at the meeting formally approve them. You will record this, with the list of policies in your meeting minutes. Then you are going to publish the policies and communicate to the business that they exist and where they are. Tip: When you set your version 1 to reduce the amount of admin it is good practice in the Document Changes to record the fact that the policy was reviewed and signed off at the management review team meeting. 

Which ISO27001 Policies Do I Actually Need?

Potentially all of them. Remembering that these are information security policies. They rely on other company policies to satisfy the requirements of an effective ISMS. Most notably would be your HR policies and documents such as Company Handbook, Grievance Policy and more. 

If you have a GDPR or Data Protection implementation already you are not going to need the Data Protection Policy and Data Retention Policy

The policies are modular to meet the requirements of many standards. To meet those standards, you may need tweaks. They fully satisfy ISO 27001 and the foundation of any good ISMS.

As discussed, the policies are based on the Context of Organisation. Specifically, the statement of applicability will be a guide. If you do not have one, have not completed a context of organisation or this concept is alien to you then the simple approach is to look at each policy and ask your self – does this look like it applies here?

Let us take Secure Development Policy as an example. If you do not do Secure Development, then it is unlikely this policy is needed for you. 

How to implement ISO27001 policies step by step

Time needed: 1 day, 4 hours and 15 minutes

How to implement policies

  1. Tweak your policies to meet the needs of the business.

    Understand the context of your own business and what you do and want to do. Write your policies to meet this.

  2. Share them for review and update as needed.

    Share the policies with those that understand the areas that are covered to provide input and changes that are appropriate

  3. Set the version control for a stable version.

    For the first implementation set the version of all documents to version 1.

  4. Hold a Management Review Team Meeting and record in the minutes that you reviewed and approved the Policies with a list of the policies and versions in the minutes.

    The oversight body that you have should review the policies and sign them off with the meeting documented and minuted.

  5. Make the policies available.

    Put the policies on an area accessible internally by all staff. This could be a share point or a shared drive.

  6. Communicate that the new version of policies is available, where they are and direct people to read them.

    Communicate using different means where the policies are and that people should read them.

  7. Include them in your communication plan and training plan for the year.

    Create a communication plan and follow it so that polices are communicated and also that they are signed up to by staff.

  8. Review them annually or after a significant change and repeat the process.

    Policies are not static so be sure to review them as things change and / or at least annually.

How often should ISO27001 policies be updated, reviewed and reissued?

At least annually within a 12-month period. Or when a significant change occurs.

How ISO27001 policies fail audits – shooting fish in a barrel

The first thing any auditor is going to do is look at the document mark up. 99 times out of 100 hundred this is wrong in some way. It is an easy win.

What is the Version number of the document? Is it the same in the header and footer and document version control?

When was the document last signed off? Was it within the last year?

Does the document have an owner, and do they still work here if a named person?