Table of contents
- What are ISO 27001 Policies?
- First write your ISO 27001 policies
- Build your policy pack
- Brand your policies
- Assign Owners to your Policies
- Review the Policies
- Update Version Control, Document Markup and Make Live
- Which Policies Do I Actually Need?
- How to implement policies step by step
- How often should policies be updated, reviewed and reissued?
- How policies fail audits – shooting fish in a barrel
This document is to act as a guide when deploying the ISO 27001 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 ISO 27001 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.
What are ISO 27001 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.
First write your ISO 27001 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 ISO 27001.
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 ISO 27001 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 ISO 27001 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 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.
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 policies step by step
Time needed: 1 day, 4 hours and 15 minutes.
How to implement policies
- 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.
- 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
- Set the version control for a stable version.
For the first implementation set the version of all documents to version 1.
- 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.
- 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.
- 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.
- 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.
- 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 policies be updated, reviewed and reissued?
At least annually within a 12-month period. Or when a significant change occurs.
How 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?