How to ignore Annex A in ISO27001

In a previous article Why you should Ignore Annex A I explained why I think that you should ignore Annex A when implementing ISO27001 but the article did not fully explain how to do this. This article gives some guidance on this although in practice much of this article applies even if you are using Annex A as your control set.

Simplistically the answer to this question is to read and do what the standard says in the order it says it. You should do this very carefully without reading ahead and trying as best as you can to pretend that you have never heard of Annex A and have never heard of or done ISO27001 before. Easier said than done.

That is all there is to it really. Honestly that is it. You don’t need to read the rest of this article.

Still reading? Not convinced? OK I will explain a bit more below.

This approach is fully compliant with and meets the requirements of ISO27001. Not only that it gets you a risk assessment and approach that is meaningful to your organisation and easy to use and get benefit from. Specifically, it can help you make good decisions about the management of your information risks.

Step 1 - Identify your risks

Whatever technique you use your starting point is to get a list of risks. I usually run risk workshops with groups of people around the organisation. As part of this you will also need to identify likelihoods and impacts, risk owners, etc, etc. Remember that you are looking for “business risks that if they happened would lead to loss of confidentiality, availability or integrity of information in the scope of your ISMS”. I.e. bad things that may or may not happen to information.

I have a separate article with my views about what a risk assessment could contain. What a risk assessment could contain

Step 2 - Identify the controls

Remember that a control is by definition (in ISO27001 and ISO31000) something that helps manage a risk. Sometimes this is described as something that “mitigates” or “modifies” the risk but I prefer the term “manage”.

Identify the list of controls necessary to manage each of the risks. For each risk talk to the risk owner and others around the organisation to ask “What is it that you have in place to help manage this risk?”, “What do you have stop this bad thing happening?”, “What do you have to detect it has happened?”, “What do you have to deal with this bad thing if it happens?” And so on. You will probably need to facilitate and prompt a bit to come up with the list of controls for each risk.

Don’t worry about the actual wording of the controls. Just note down what people say. You can refine the wording later. You are also likely to end up with some very similar looking controls across a number of risks but again at this stage just note it all down. You can sort all this out later.

Remember that you are only looking for "necessary" controls - i.e. ones that are needed to manage the risks. For each control you can test if it “necessary” by asking the question of each risk “What effect could this control have on the likelihood or impact of this risk? What would happen if we do not operate this control?”. Only controls that can have more than a negligible effect should be deemed as “necessary” – i.e. “needed”. You do not want to use your ISMS to manage controls that have only a negligible/insignificant effect on the management of your information risks.

Where you have identified a control that perhaps does not exist or partly exists but not fully operating or implemented this is very likely to give rise to a risk treatment/action plan to “fix” the control. However, at this stage we are not really interested in this. Your objective is to create a risk register that contains a reasonable list of risks and against each risk a reasonable list of controls that are necessary to manage each risk. You are not looking for perfection.

Be careful that just because you have a control that you are already operating somehow this does not mean it is a necessary control to manage a risk and must be included somehow. It might well be a control that you should stop operating. An example I have seen many times is organisations operating internal CCTV but when you look at it you realise that internal CCTV is not really a necessary control to manage an information risk. Or it might a control that you want to continue operating because the cost of operating it is very low or it is very expensive to remove it. Removing CCTV might be expensive to do. Don’t forget that you may want to operate internal CCTV to manage fraud risk or theft of personal property. It is just that CCTV may not be necessary to help you manage any of your information risks.

I strongly recommend that you do not let anyone look at any predefined lists of controls as part of this. The obvious one people may want to look at is Annex A but could also be ISO27002 or PCI DSS or NIST, CSA, etc. If the people you are talking to have never heard of ISO27001 then this is easier since they do not come with any preconceived ideas about, for example, Annex A. You want people to think about their own business and their own environment, infrastructure, IT, etc, etc to identify their actual controls and not ones selected from a “list” somewhere. Easier said than done and you will have to facilitate and prompt about this.

Step 3 Reconcile and rationalise the risks

You should work on refining the risks and the wording of those risks. Try to make sure they are worded as risks – i.e. “bad thing X may happen” rather than just statements. A risk which says “Insider threat” is not a risk.

Don’t get too focused on this as long as people know what the risks actually are.

Step 4 Reconcile and rationalise the controls

The main challenge with the controls is usually pinning down the wording of the control to reflect either exactly what is happening now or perhaps what should be happening now but isn’t quite.

It might be that you have some controls that look very similar to each other. If you are convinced that the controls are really the same control then change the wording so that it is the same for all the references to the control. If not then leave them as separate controls. As an example, one risk may have the control “Anti-Virus is in place” and another risk may have a control “Windows defender is used to protect against virus infections”. These may be the same controls if the only operating system you use is Windows and if so then you can change the wording to be the same. However, if you also have some Linux or Macs then these might not be the same control. You would need to look carefully at the risk and give this some thought to decide if you want to leave these two controls as there are or find some other wording that can be used as the control description for both risks.

You may also have some controls where one control looks like a subset of another. As an example, one risk may have a control “All changes have detailed back out plans” and another risk may have a control “A change management procedure is in place to all changes to the live environment”. It is very likely that the requirement to have a detailed back out plan is part of the change management process and so in principle one control is included in the other. So, should you remove the control about back out plans and replace it with the change management procedure? Again, you need to look carefully at the risk to see if it makes sense to make the specific control about back out plans to be the much more general change management process. For example, if the risk is “A change is implemented that fails and cannot be backed out” then it probably makes sense to leave the back out plan control as it is. It is Ok to have controls that are subsets of other controls or that overlap with other controls if it makes sense to you from a risk perspective. Try not to over analyse this.

If you are intending to do a SOC 2 and use the same controls for both ISO27001 and the SOC 2 then you will need to put a lot of effort into the wording of the control. This is because the SOC 2 requirements for the wording are much more rigorous than for ISO27001.

The point is that your controls are there to manage the “important” – “necessary” controls and not everything.

Step 5 – Compare your controls with Annex A

The standard requires you to do a comparison of your controls with the list in Annex A.

Be very careful here. It is very important to realise that the standard requires you to do this check against Annex A before you create the Statement of Applicability (SOA). I am going to repeat this by shouting “YOU MUST DO THIS CHECK BEFORE CREATING THE SOA”.

There are lots of ISO27001 people who seem to think that you do ISO27001 based on the SOA rather than the risk assessment They think that you do this check/comparison after you have created your Statement of Applicability (SOA) and this check is somehow to add controls to your (SOA) somehow independent of your risk assessment. They think that you can have controls in your SOA that are not referred to in your risk assessment. This is complete nonsense.

The idea of this comparison is to see if you might have missed a necessary control from the risk assessment. The idea is not to see if you have missed a necessary Annex A control. The standard does not say this. It is to simply use Annex A as a checklist for you to look down your risk assessment and see if you might have missed a necessary control in your risk assessment. This does not mean you should start adding in lots of controls to your risk assessment. In my experience you may find there are a few Annex A controls where you think to yourself “That is a good point – we should probably have a control to do something like that” to manage risk X. As an example, it might be that for some reason your risk assessment did not pick up the need to have something to do with patching as a control but you realise that you should have it. You then need to go back to your risk assessment and see if something to do with patching is a necessary control to help manage one or more risks. If it is then add in a control about patching to the appropriate risks. I recommend not using the Annex A wording for patching. Create some wording that means something to you and represents how patching takes place or should be taking place in your organisation.

To repeat myself here – when you do this check you should be ruthless and not just add in lots of controls to the risk assessment. Remember that ISO27001 only requires you to identify the necessary controls to manage the risks. You are not required to identify all the controls managing your risks. When you do this you will probably realise that quite a lot of the Annex A controls are not really that helpful to you even if you might be doing some bit of some of them.

It is worth noting that this approach is also covered in ISO27005:2022 which states this;

"The purpose of this is to act as a safety check to verify that no necessary controls have been omitted from the risk assessment. This safety check is not in place to identify any omitted controls from Annex A, in the risk assessment. It is a safety check to identify any missing necessary controls from any source by comparing the controls with other standards and lists of controls. Omitted controls identified during this check can be sector specific or custom controls or from Annex A."

It is not a requirement of the standard but you might also want to repeat the above with some other possible control sets. There are lots of them, for example ISO27002, cloud security alliance, NIST, ISO27017, ISO27701, PCI DSS, COBIT.

This approach is covered in detail in https://www.dhirubhai.net/pulse/how-do-iso27001-comparison-annex-clause-613-c-chris-hall/

Step 6 – How do I convince the certification auditor that I did the Annex A check in Step 5?

It is all very well doing the comparison with Annex A but how do you prove to the auditor that you did it? Perhaps a bit tricky really but here are a few options.

When the certification auditor asks you to prove that you did the comparison you say “We did it. We have no records of the fact that we did it but please feel free to challenge/ask us about it”. In principle this is OK but the certification auditor is not likely to be happy with this and you may have trouble convincing them about this.

Or, you document the fact that you did the comparison somewhere, for example:

? put as an agenda item on a meeting “Comparison of Annex A with our controls” and then record in the minutes of the meeting that it was discussed and agreed at the meeting, or

? send someone an email that says “Hi Sue, To confirm that I have completed the comparison of our controls with Annex A”. A useful and recommended variation on this is to also add into the email “I found a few that I think we should talk about – A12.1.4, A13.2.1. What do you think?”. Whoever then gets the email can reply “Thanks Joe, When I looked at control A12.1.4 it reminded me that one necessary control we should have in risk assessment is XXX”. You now have some evidence that the comparison was done, or

? add a statement into your Statement of Applicability something like “As required by ISO27001 6.1.3 c), a comparison of these controls with Annex A of ISO27001 has been undertaken and the results of the comparison have been used to update the risk profile. The results of this comparison and update are reflected in this version of the Statement of Applicability.”, or

? You create a document that lists all the Annex A controls and against each one you add the comment “I have checked this control against our list of controls to determine if there are any missing necessary controls”. This should be sufficient but the auditor might not be convinced. A variation on this is that where you think there is one of your custom controls that is similar in some respect to the Annex A control then you add in a comment to that effect next to the Annex A control. The auditor is more likely to be happy with this approach but I think it is bit unwieldy and unnecessary and it is a pain to create it. But if you want to play safe then do this. This could also be included as an Appendix to the SOA as described below.

Any of the above techniques could be used. The “safest” option to convince a certification auditor is probably the last one but requires the most work.

Step 7 – What about the Statement of Applicability (SOA)?

Indeed – What about the SOA! It is worth quoting the actual ISO27001 requirement.

“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;”

There is a simple approach and a longer somewhat annoying approach to meeting this requirement.

Remember that by definition (in numerous sources including ISO31000) a control only exists to “modify” a risk. The idea that you can have a control without knowing what risk it is “modifying” is clearly just wrong! If you do this properly following the process in ISO27001 you will realise that you cannot have any controls your SOA that are not referred to in your risk assessment.

The simple approach to the SOA.

First, the simple approach which is also covered in another of my articles What should be in an SOA.

I will repeat it here tailored slightly as we are not using Annex A.

Put the following statements at the top of the SOA:

? “All the controls listed below are implemented”.

? “All the controls listed below are included because they are specifically named in the information risk assessment as managing one or more of the risks identified in the information risk assessment”.

? “Any control not listed below (e.g. as in Annex A) is excluded because it has not been identified as managing one or more risks identified in the information risk assessment”.

A table containing a list of the controls. This should have two columns:

? The first is an identifier for the control. Some reference (e.g. C003) for the control. (This column is not strictly required by the standard but is strongly recommended so that each control can easily be identified).

? The statement of the control. I.e. what the control is. This is the wording for the custom control.

If not all the controls have been implemented then an additional column is needed to state “implemented” or “not implemented”.

The longer slightly annoying approach to the SOA.

Some certification auditors will not be happy with the above approach because it does not list all the Annex A controls. The standard does not require such a list in the SOA but they have never seen an SOA without a list of all the Annex A controls and now they have one in front of them. They could go into shock or faint in front of you. If you are concerned about the health and well being of your certification auditors then I suggest you add an Appendix to your SOA which lists all the Annex A controls. Against each of the Annex A controls you add the phrase “Excluded because this control has not been identified as managing one or more of risks identified in the information risk assessment”. If you are feeling especially kind then against each of the Annex A controls that have some vague similarity to one of more of your custom controls you could put in a reference to the appropriate custom controls (e.g. C003). This is now a sort of mapping between Annex A controls and your custom controls. Creating this Appendix is a real pain and difficult to get right so I try to avoid doing this. There is no intrinsic value as such in this Appendix but it can also be used to prove you did the comparison with Annex A.

Summary

This article gives a process for how to undertake a risk assessment that does not use any Annex A controls. In practice much of the above article applies even if you are using Annex A and is very focused on complying with ISO27001 as well as following the spirit of ISO27001 in using the risk assessment to drive the decision making to help manage the organisation's information risks.

Keep it simple!

Chris

www.btrp.co.uk