ISO 27001 & ISO 22301 Blog

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

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.

To learn how to become compliant with every clause and control from Annex A and get all the required policies and procedures for controls and clauses, sign up for a 14-day free trial of Conformio, the leading ISO 27001 compliance software.

Advisera Dejan Kosutic
Dejan Kosutic
Leading expert on cybersecurity/information security and author of several books, articles, webinars, and courses. As a premier expert, Dejan founded Advisera to help small and medium businesses obtain the resources they need to become certified against ISO 27001 and other ISO standards. He believes that making ISO standards easy-to-understand and simple-to-use creates a competitive advantage for Advisera's clients.

As an ISO 27001 expert, Dejan is sought out to help companies find the best way to obtain certification by eliminating overhead and adapting the implementation to the specifics of their size and industry.
Connect with Dejan: