What is the Statement of Applicability?

In short, the SoA is an extremely boring (but required) document under ISO 27001. In very simple terms (because it is, in fact, a very simple document), it explains which of the Annex A controls you have decided to implement as a part of your ISMS.

Look it up on Google and you'll see that there are as many ways to do a Statement of Applicability (SoA) as you've had hot dinners in your life! So what's the right way to do it?

In this article we'll answer that question, along with why you need a SoA and suggestions on how to turn your SoA into a really useful tool.

Why is the SoA important?

Your SoA is important for a couple of reasons:

1. It tells your auditor which controls you have implemented and that they should therefore be auditing; and

2. It tells everyone after that audit exactly which controls were audited by that auditor at that audit

...and that's about it!

That's also why your SoA has to be a versioned document - to provide clarity on what has been audited and what hasn't. So, for example, if you were a "virtual" business with all staff working remotely and therefore excluded much of the A.11 controls, but then post-audit adopted an office, it might be helpful for your interested parties to know that the physical security elements have not been audited.

We should also therefore recognise that the version only has to change if you update which controls are implemented. Changing any other detail is inconsequential, because of point 2 above!

Why do people make such a big deal out of it?

That's a good questions - and we don't really know!

Our best guess is that, because there are 114 Annex A controls in ISO 27001:2013 (current at time of writing) and 93 in the new version (coming soon...this year), it's a pretty big document, no matter how you build it.

Take that a couple of steps further and, depending on how you write/build you SoA, it can be quite overwhelming to anyone who isn't familiar with it, giving consultants everywhere a GREAT opportunity to bamboozle their clients into sticking with them because, well, it looks so darn complicated!

So what's actually required in the SoA?

Not much!

In it's purest form, the SoA should list all of the controls, along with whether you have included or excluded the control, and your justification for its inclusion/exclusion. So, for example, an entry might look like:

A.6.2.1, Included, Business reasons

The justification can be whatever you feel is appropriate, but will usually be a choice of one or more of:

• Business reason

• Best practice

• Contractual requirement

• Legal requirement

What else might be in there?

Well, you can add all sorts of stuff into your SoA. The essential bits are covered in the previous section, but after that, stick in there whatever you think will be helpful!

Here's how we do it

We only ever want to build things that help our clients. Creating a monolithic SoA that provides no value just isn't in our nature. Instead, the SoA we build for our clients acts as a cheat sheet for audits. Against each control, after the essential bits (described above), we'll include:

• A description of how the controls has been implemented

• Links to any supporting documentation

• Where to find evidence of the control's implementation

...and then we coach our clients that, in an audit, the key question to ask the auditor is:

What control are you asking us about?

They can then just look up the control in the SoA to identify where to point the auditor for evidence or documentation that demonstrates the control's implementation.

Easy eh!

Conclusion

The key take-aways from this article are:

1. Your SoA should work for you, not your consultant or the auditor!

2. You MUST list each control, whether you've implemented it within your ISMS (i.e. is the control included/excluded) and the reason why (justification)

3. The document (in whatever format) must be versioned, but the version only needs to change if you add or remove a control

4. You can add whatever you like beyond the essentials. We recommend linking/pointing to evidence and/or documentation the demonstrate the control's implementation

If you found this article helpful, please feel free to share it.