How to audit the ISO27001 Statement of Applicability

This article is aimed at ISO27001 auditors. I have written it because I continue to meet auditors who want to raise non conformities about the Statement of Applicability (SOA) that are not valid. Specifically, they do not seem to appreciate the different ways that the SOA is used by organisations to both:

? Conform to the requirements of ISO27001, and

? Help them manage their information security risks.

6.1.3 d) What does ISO27001 say about the SOA

It says:

“Produce a Statement of Applicability that contains the necessary controls (see 6.1.3 b) and c)) and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A;”

That is it. That is all there is too it. Not much really.

Different Interpretations

This article cannot cover all the different interpretations of how the SOA is used but will cover some of the more common ones. The two main variations I see are:

Extra controls in the SOA

Organisations sometimes have controls listed in the SOA as applicable/justified/applicable/included that are not named in the risk assessment as being necessary to manage any of the risks. This is usually as a result of doing the comparison with Annex A but it might be that the organisation just says “We don’t care what the risk assessment says, we are also going to also do control X” – perhaps for legal, regulatory or contractual reasons or because they think it is “good practice”. The standard does not preclude organisations doing this. However, my view (and that in ISO27005:2022) is that given that ISO27001 is based around the principle of using an information security risk assessment to determine what controls you need to manage it is not clear why anyone should consider it OK to have controls that are not referred to in the information security risk assessment.

As I say, my view (and that of ISO27005:2022) is that it is not quite right to do this but it is not for you (or me) as the auditor to dictate your view of this given that this interpretation of ISO27001 could be considered valid. I.e. it is OK and reasonable to have “extra” controls in the SOA.

Extra information in the SOA

Lots of organisations add all sorts of extra information/attributes into their SOA that are not required by the standard. For example, “control owners”, “links to evidence”. I don’t recommend that you do this for a number of reasons but there is nothing to stop you doing so. I prefer to have a separate document – a “controls catalogue” with all this other information.

The other common addition to the SOA is to somehow show the results of the comparison with Annex A. This is sometimes shown as a mapping between the controls listed in the SOA and Annex A. The standard does not require the organisation to do this in the SOA and my own view is that it seems a bit odd to be documenting this comparison in the SOA given that the SOA is supposed to be a “statement of the applicable” controls but I know lots of people do it that way.

Another very common extra is detailed information for each control about why the control is included or excluded. Often quoting “business reasons” or “legal, regulatory, contractual reasons”. None of this is required by ISO27001 given that it is sufficient to simply say that all the controls are included/excluded on the basis of if they are named in the risk assessment or not. But if the organisation wants this detail in their SOA then OK.

From an auditor’s perspective if an organisation has included extra information in the SOA then the auditor is justified in auditing this extra information?as it represents what the organisation has decided they need to operate their ISMS. However, if the organisation has clearly identified that some of this information is not part of the ISMS then the auditor may not audit it. This is sometimes done by marking this extra information as “Not part of the ISMS” – for example in a column header.

It is not for you (or me) as the auditor to dictate your view of this as long as these various extra things in the SOA do not represent a non conformity against the requirements of the SOA. What you can’t do of course is insist on any of these “extra” things just because you think they should be there.

You should raise a non conformity if:

? The risk assessment defines a control as a necessary control but the control is not listed in the SOA as included. All the controls named anywhere in the risk assessment must be listed in the SOA as being included.

? If, as a result of the comparison with Annex A there is a separate list of controls that are not named in the risk assessment and one or more of them are not marked as included.

? There is no justification for the inclusion of any of the controls. Note that the only justification needed for the inclusion of a control is that it is named in the risk assessment as being necessary to manage one or more risks.

? There is no justification for the exclusion of any of the Annex A controls. Note that the only justification needed for the exclusion of a control is that it is not named in the risk assessment as being necessary to manage one or more risks.

? There is no indication of which of the controls are implemented. This could be covered by a blanket statement at the top which says “All the controls are implemented”. Note that contrary to popular belief and within reason, it is OK for not all the controls to be implemented for an organisation to conform to the requirements of ISO27001.

? There is a control that is marked as “Implemented” but when you audit the controls you find out that it is not implemented. I.e. the SOA is wrong.

You should not raise a non conformity if:

? There is a control “missing” (i.e. not marked as included) from the SOA that you think should be but see the next section for more detail about this.

? The SOA does not list out all of the Annex A controls.

? The SOA does not list out or name any of the Annex A controls.

? The SOA does not include a mapping of the controls to Annex A.

? The SOA does not document the result of the comparison with Annex A.

? The SOA does not have any Annex A controls marked as included.

? All the controls marked as included in the SOA are custom controls.

? The SOA does not have any custom controls marked as included.

? The SOA marks as included some controls from other controls sets (e.g. CSA, NIST).

? The SOA does not give a separate individual justification for the inclusion or exclusion of each control. I.e. it gives blanket reasons that apply to all or groups of the controls.

? The only reason given for the inclusion of a control is solely based on “the control is named as a necessary control in the risk assessment”. I.e. it helps manage one or more risk. No further justification is needed.

? The only reason given for the exclusion of a control is solely based on “the control is not named as a necessary control in the risk assessment”. I.e. The control is not managing one or more risks. No further justification for exclusion is needed.

? A single blanket justification is given for the inclusion/exclusion of all the controls that is based on whether the control is defined in the risk assessment as a necessary control or not.

? It does not include the phrase “Annex A” somewhere. Odd thought it may seem it is entirely possible to have an SOA that does not anywhere in it include the phrase “Annex A” and does not include or name any of the Annex A controls. Think about it. ??

You cannot say “you have a control missing from your SOA”

This is a very important point that many auditors do not adhere to. See this article for more details about this. https://www.dhirubhai.net/pulse/iso27001-auditor-should-never-say-control-statement-marked-chris-hall/ The following is an extract from this article:

“An auditor may have this idea in their head from somewhere that your organisation should be operating a control that is not currently identified as applicable/justified in the SOA. However, they can only make the case for this if they can convince you that it is a necessary control to help manage one or more risks in the risk assessment. Specifically, that the control is needed to help ensure that one or more specifically named risks meet the risk criteria (i.e risk appetite). In order to do this they must be able to point out exactly which risks in the risk assessment they think this applies to. Or, it might be that they think that you may have a risk missing from the risk assessment which would need this control. You might disagree with them about any of this. But they could be right. Be open about this but also be prepared to argue your case.”

There are only two exceptions to this:

? It is a control that is named in the risk assessment as being necessary to manage one or more risks and the organisation has accidentally forgotten to mark it as included in the SOA.

? The organisation has created a list of "extra" controls (i.e. that are not named anywhere in the risk assessment) as described earlier in this article. However, the organisation has accidentally forgotten to mark some of them as included in the SOA. As an example, the organisation has decided that "Cryptography Policy" should be a control to be managed by the organisation even though it is not named anywhere in the risk assessment. However, "Cryptography Policy" is not named in the SOA.

They key point being that you can’t just say “I think you should be doing control X” when auditing the SOA.

You should make such points when auditing the risk assessment and not when auditing the SOA.

Summary

The main principle is to recognise that there are many different interpretations of the SOA requirement and as long as they meet the formal requirement in 6.1.3 d) then all is well. An auditor must not impose their interpretation of this requirement on the organisation.

A minimal SOA approach is shown in this article ?https://www.dhirubhai.net/pulse/iso27001-what-purpose-statement-applicability-soa-should-chris-hall/ but as I have said, many organisations put a lot more into their SOA than this.

Chris Hall

www.btrp.co.uk