An expert blog by Ken Holmes CISSP, CIPP/E; CertiKit’s managing director and principal consultant. Ken is a qualified ISO/IEC 27001 Lead Auditor and an active member of ISACA and a BSI-published author on IT service management. Ken is the lead author of the CertiKit ISO 27001 toolkit.
One of the areas we’re often asked about is that of policies. In this article I’ll cover some of the dos and don’ts of creating policies for ISO27001 certification.
But first of all, what do we mean by a policy? One common definition of a policy is:
“a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party”.
In information security terms, we would probably say it’s a set of rules to follow.
So how many policies do you need to comply with the ISO27001 standard? Well, a simple search of the term within the standard document comes up with about ten discrete instances where the need for a policy is mentioned:
But in terms of how many documents that actually translates into is largely up to you and your organization. You could for example have one single information security policy that covers everything, and some people do that. The main advantage of this approach is simplicity.
However, in some circumstances a number of issues occur with this approach. Firstly, there’s the question of the audience. Not all policies are aimed at the same people; you may have some that are intended for users, some for technicians and again some for a specific department such as HR.
Secondly, it depends on who approves your policies and how often they change. It’s common for an information security policy to be approved at board level and if you need to make frequent revisions to the document because it covers areas that change rapidly then approval could become a problem.
So there’s no single right answer to the question of how many policies is appropriate; it depends on your organization.
What we provide in the toolkit is a high-level information security policy that references a set of lower-level policies that may change more often and have specific audiences. We also provide many more than the number mentioned in the standard as we believe that having clear rules in each area of information security is a good idea. But you could decide to merge some of these together into a smaller set – remember the approach you take is up to you.
So how should you create your policies from the template documents we provide in the toolkit? The mantra we often suggest when it comes to creating policies suitable for audit is to under-promise and overdeliver, rather than the other way round. Make sure that the policy reflects what you actually do now, rather than what you aspire to at some time in the future. The ISO27001 standard just says you should have a policy; it isn’t prescriptive about what is in it. If a statement in a template policy doesn’t reflect your current practices then simply remove it. You can always put it back in when your ISMS is more mature. An easy way to get a nonconformity at audit time is to state you do something in a policy that isn’t the case. The only caveat I put on that is that the policy still needs to be appropriate to the level of risk you perceive in that area.
Because it’s a set of rules, the language used in your policies should be sufficiently imperative – use verbs like “must” and “will” rather than “should” or “may”, unless you genuinely want to allow something to be optional.
Once you’ve created your policy, the ISO27001 standard expects it to be formally approved and communicated. Failing to do either of these actions would be an audit issue. Approval doesn’t have to be a wet signature on a piece of paper; most electronic forms of signifying approval by an appropriate person are accepted.
Communication means that the people who are expected to abide by the policy are aware of it and its contents. This normally means as part of new starter induction and via a suitable mechanism to publish new policies and changes to existing ones. Clear version control is essential in this.
It’s also important to communicate the consequences of non-compliance with your policies. This is often done as part of regular awareness training.
Lastly, things do change, and it’s important that your policies change with them. Put in place a regular review of all of your policies and make sure you record the fact that this has happened.
Policies are a great tool as part of your ISMS and following these basic rules should help to avoid the most common pitfalls.
Title image credits: Computer vector created by freepik – www.freepik.com