How to use Annex A in ISO27001

In a previous article Why you should ignore Annex A and a follow up article How to ignore Annex A I explained why and how I think that you should ignore Annex A when implementing ISO27001.

However, I was also asked “How do I use Annex A”? I recommend that you don’t do this but if you really feel that you have to use Annex A here goes anyway…

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. When you get to the statement that says “determine all controls that are necessary to implement the information security risk treatment option(s) chosen;” you simply look at each risk and then look at Annex A and select the controls in Annex A for each risk that are necessary to manage the risk.

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

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

This approach is fully compliant with and meets the requirements of ISO27001.

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 ISO27000 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”.

Look at each risk in turn and then look at Annex A and select the controls that look as though they are necessary to help you manage the risk. Add this to your risk assessment against each risk.

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 is “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.

As part of this you should also be thinking about any controls you think are necessary controls to manage your risks but are not in Annex A. If you have any of these you should add them into the risk assessment and word them as a control that makes sense to you. In the jargon these are “custom controls”. I.e. you have selected your controls from Annex A but are now supplementing this with some additional “custom controls” that you have decided are necessary to manage your 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.

There is some more detail about determining controls in this article. https://www.dhirubhai.net/pulse/iso27001-how-you-should-choose-controls-needed-manage-chris-hall/

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 – 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 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 in the 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 look at the risks and see if something to do with patching is a necessary control to help manage one or more risks. If not then do not add it. If it is then add in the Annex A control about patching to the appropriate risks or add in an appropriately worded custom control.

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 may 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 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 (at a detail level), cloud security alliance, NIST, ISO27017, ISO27701, PCI DSS, COBIT.

There is more detail about how to do this comparison in this article https://www.dhirubhai.net/pulse/how-do-iso27001-comparison-annex-clause-613-c-chris-hall/

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

It is all very well doing the comparison with Annex A but how do you prove to the auditor that you did it? Because you are using Annex A as your control set this is normally fairly easy as you are going to list all the Annex A controls in your SOA anyway. See the next section.

Step 7 – What about the Statement of Applicability (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;”

If you are using Annex A then I suggest you keep it simple and simply list all the Annex A controls in a table in your SOA and then against each one say:

If it is implemented or not (Y/N)

? If it is applicable/justified or not (Y/N)

? Put in some sort of explanation as to why it is applicable or not applicable.

Strictly speaking the only reason a control is applicable or not is because it is referred to in your risk assessment – or not. If it is then it is applicable, if not then it is not applicable. So in principle all you need to put against the control is either:-

? “This control is justified because it is necessary to modify the likelihood or impact of one of more of the risks identified in the information risk assessment.”, or

? “This control is not justified because it is not necessary to modify the likelihood or impact of one of more of the risks identified in the information risk assessment.”

However, there are lots of certification auditors who feel very strongly that you are supposed to say more than this. They are wrong but if you want to avoid an argument with your auditor then can put in some sort of reason as to why the control is applicable or why it is not. Waffly nonsense is usually sufficient to keep the auditor happy.

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 information risk assessment.

Don’t forget that if you have any custom controls they also need to be added to the SOA.

There is more detail about creating the SOA in this article. https://www.dhirubhai.net/pulse/how-create-iso27001-statement-applicability-clause-613-chris-hall/

Summary

This article gives a process for how to undertake a risk assessment that uses Annex A controls.

Keep it simple!

Chris

www.btrp.co.uk