CALL US +44 1502 449001

The ISO 27001 & ISO 22301 Blog

Dejan Kosutic

How to structure the documents for ISO 27001 Annex A controls

Once you’ve finished your risk assessment and treatment, it is time for you to start writing documents that describe your security controls according to ISO 27001 Annex A. But, which documents should you write? How do you structure them? Which one do you begin with?

Here’s what I found to be the best way to do it.

How to choose which documents to write

blogpost-banner-22301-en

ISO 27001 says that you cannot simply start to select the controls and/or write the documents that you like the most – the point is that selection of controls must be a direct consequence of the risk assessment and risk treatment process. See also: ISO 27001 risk assessment & treatment – 6 basic steps.

Secondly, you must know which documents are mandatory and which are not – see this list here: List of mandatory documents required by ISO 27001 (2013 revision).

Finally, once you know which controls must be applied and which documents are mandatory, you must decide how extensive your documentation will be:

  • Smaller companies will tend to have a smaller number of documents: (1) they won’t document each control, and (2) they will include several controls in a single document.
  • Larger companies will tend to have more documents, and the documents will be more detailed.

However, these are not the only criteria to decide which documents to write – see also 8 criteria to decide which ISO 27001 policies and procedures to write.

Which documents should cover which controls?

Since Annex A has 114 controls, the truth is that it is not very easy to decide how to group policies and procedures to cover them (see also: Overview of ISO 27001:2013 Annex A). And the fact that ISO 27001 does not prescribe which controls must be allocated to which policies and/or procedures might initially seem like a problem, but once you realize that such an approach gives you big freedom to adapt the documentation to your real company needs, you will actually become grateful that ISO 27001 is so flexible.

Again, there are two approaches to group the documents:

Smaller companies will normally have policies and/or procedures that cover several controls with one document only – for instance, you might use:

  • Access Control Policy to cover all the 14 controls from section A.9 (without writing detailed procedures),
  • BYOD (Bring Your Own Device) Policy to cover not only A.6.2.1 (Mobile device policy) and A.6.2.2 (Teleworking), but also A.13.2.1 (Information transfer policies and procedures),
  • with Acceptable Use Policy, you might get even more ambitious and cover controls from various sections of Annex A, since this document could serve as a security baseline for all employees: A.6.2.1, A.6.2.2, A.8.1.2, A.8.1.3, A.8.1.4, A.9.3.1, A.11.2.5, A.11.2.6, A.11.2.8, A.11.2.9, A.12.2.1, A.12.3.1, A.12.5.1, A.12.6.2, A.13.2.3, and A.18.1.2.

Bigger companies usually structure the documentation in a different way:

  • each section from Annex A will be covered with a policy – e.g., Organization of Information Security Policy (A.6), Human Resources Security Policy (A.7), Asset Management Policy (A.8), etc.
  • each policy will have detailed procedures and/or working instructions that cover single controls – for example, Information classification procedure (for control A.8.2.1), Information labeling procedure (control A.8.2.2), Information handling procedure (control A.8.2.3), etc.

The sequence of writing the documents

Once you have an idea of how to structure the documents, how do you decide where to start, and where to end?

For smaller companies, you can use a couple of criteria to decide which documents to start with:

  • Areas where you can get quick wins – this means you can select an area where you know you will finish your document quickly, and this way you show your management, your peers (and yourself) that you are capable of doing this job effectively.
  • Areas where you have largest risks – this way you start resolving the biggest problems first –you may not finish this quickly, but sometimes this approach is necessary if your risk assessment has shown you have some very big gaps to fill in.
  • Areas that are compatible with other running projects in your company – for example, if your company is currently implementing help desk software, you might want to start writing incident management procedure, because this will regulate how that software will be used in the context of ISO 27001.

For documents that are to be written at the end, my personal preference is documents that cover larger number of controls (for example, the Acceptable Use Policy). This way you will know which controls you covered with other documents, and those that haven’t been described in other policies and procedures can be described in an all-inclusive document at the very end.

Again, bigger companies will have a different approach – they will write the policies first, and related procedures/working instructions second, while for the decision on which policies to start first they can use the same criteria as described above.

So, to conclude, make sure you use this flexibility that ISO 27001 offers you to adapt the documentation to your specific needs – because the idea is that the documentation serves you, not the other way around.

If you want to learn more about security controls, this eBook ISO 27001 Annex A Controls in Plain English can help you.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 27001/ISO 22301 standards.

You may unsubscribe at any time.

For more information on what personal data we collect, why we need it, what we do with it, how long we keep it, and what are your rights, see this Privacy Notice.

2 responses to “How to structure the documents for ISO 27001 Annex A controls”

  1. Wondering Jo says:

    Can you please elaborate more that picture within your article or point to a page describing it more? My main interst focuses on the cybersecurity part and what are you including in it. I see it solely as an IT (scada, automation etc) related issue.

Leave a Reply

Your email address will not be published. Required fields are marked *

OUR CLIENTS

OUR PARTNERS

  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM, TL and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.