Get in touch

Get in touch

  • This field is for validation purposes and should be left unchanged.

Privacy Notice

X

When you request to download our free implementation guide, we use your name, company name (which is optional) and your email address to email you a link to download the requested document. We may also email you after your download in order to follow up on your interest in our products and services. We will do this based on our legitimate interest in marketing to prospects for our products and services. Your name and email address are stored on our website which is hosted with Digital Ocean. Your personal data is stored for one year after you requested your download, after which it is deleted.

Reveal Menu

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.

Ken team member on green background

 

How many policies?

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:

  1. Information security policy
  2. Mobile device policy
  3. Teleworking policy
  4. Access control policy
  5. Cryptographic policy
  6. Clear desk and screen policy
  7. Backup policy
  8. Information transfer policies
  9. Secure development policy
  10. Supplier relationships policy

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.

The CertiKit approach

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.

What should your policies say?

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.

Policy language, approval and communication

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.

Final thoughts

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

Over 3000 businesses have purchased our toolkits

Testimonials

Compared to competing toolkits, your V9 document structure (title page, history, ToC, content organization) was very good. The provided "Introduction" of each was useful (I have moved those out of the core documents and into a more comprehensive manual) for the general audience vs security staff. The inclusion of references to 27017 and 27018 were appreciated. You provided more "ISMS-C" oriented artefacts than competitors.

Security Strategist
Trusted By Design Inc

View all Testimonials