How to use "other" control lists/”frameworks” (e.g. SOC 2, NIST, ISO27017, CSA) with ISO27001

And yes I know SOC 2 and some others are not strictly a list of controls/frameworks?but I will treat them as such for now. I.e. they are sources of possible information security controls that your organisation might use. There are lots of these around including some for specific business sectors/industries.

Since the 2013 version of ISO27001 was published it has been possible to integrate/use any lists of controls with ISO27001 although this opportunity has not been used much. Most organisations just use the list built into ISO27001 – i.e. Annex A of ISO27001 and don’t use any other such lists.

However, it is (fairly) easy to (almost):

? More or less ignore Annex A and use an alternative. - for example NIST, COBIT, CSA, etc or an internally created control list, and/or

? Use Annex A alongside and with use other controls lists, and/or

? Use my favoured approach which is to more or less ignore Annex A and not use any of other control lists and just use all “custom” controls created as necessary and specific for the organisation.

Where do these control lists/”frameworks” come from?

? There are lots of industry/sector specific ones – for example NIST, CSA, PCI DSS, ISO27017, etc. Some of these are more prescriptive and more detailed than others.

? Regulation/laws. In some industries and some countries there are regulations and laws that specify a list of information security controls that companies must operate.

? Contractual requirements. Some clients may specify a list of information security controls that a company supplying services to them must operate.

? Internally created lists of controls. Organisations rarely list out such controls as such but most organisations are likely to have some controls that they are going to do irrespective of anything ISO27001 says. More about this below.

What about ISO27002?

ISO27002 is a guidance document for implementing each of the Annex A information security controls.

However, a lot of this implementation guidance can, with a bit of slight rewording be treated as controls.

For example the control 8.20 “Networks Security” has a control description of “To protect information in networks and its supporting information processing facilities from compromise via the network.”

This then contains implementation guidance that covers 14 points each of which can easily be rewritten as a control. To pick a few of them to show this:

1)???? “b) establishing responsibilities and procedures for the management of networking equipment and devices;”

as a control could be:

“We have established responsibilities and procedures for the management of networking equipment and devices;”

2) “h) authenticating systems on the network;”

as a control could be:

“We authenticate all systems on the network”

3)???? n) disabling vulnerable network protocols.

as a control could be:

“All vulnerable network protocols are disabled”

?

And so on.

I.e. although the detailed implementation guidance in ISO27002 is not really written to be controls much of it can easily be viewed and treated as controls.

Internally created lists of controls

As noted above, most organisations are likely to have some controls that they are going to do irrespective of anything ISO27001 says. These are for many different possible reasons, for example:

? They are good practice.

? They are best practice.

? They are commonly used.

? Lots of other companies do them.

? Other companies in our sector all do it.

? We are already doing these – i.e. they are existing controls.

? We already have this control listed in our ISAE3402/SOC 2 report.

? Politics – e.g. the boss thinks we should be doing this.

? A salesman convinced us that this software tool is a worthwhile control.

? Finance – e.g. we have some budget we should spend.

? We had an incident/breach and we must implement this control to try to stop it happening again or at least to make it look as if we are doing something.

? To make us look good.

As I say, organisations do not usually list these controls out as such but they are effectively a “virtual” list of controls that the organisation wants to use and will use somehow.

Why would you want to use a control list/”framework”?

There are a two main reasons for organisations wanting to use a control list/”framework” other than or alongside Annex A with ISO27001:

1)????Mandatory - for compliance reasons

You are mandated to do so. For example in a client contract, or a regulation or a law or “head office” says so. This then becomes a compliance requirement. PCI DSS is a good example of this.

2)????It will help them

You think that the controls in the control list might be useful to you. I.e. the use of a controls list is not mandated but might contain some useful controls. I think that CSA is a good example of this.

How should you use these control lists/frameworks with ISO27001?

There are two main approaches to how to use these controls lists and other controls with ISO27001:

1) Do not try to integrate the control list with ISO27001.

I.e. your organisation uses one of these control lists but the approach and list of controls is completely separate to what you have done in your ISMS. A very popular approach especially for something like PCI DSS but also often used for SOC 2.

The advantage of managing these other controls outside the ISMS is that:

? you can keep your ISMS properly compliant with ISO27001.

? You can keep your ISMS as simple as possible.

? It helps the ISMS to focus on those activities/controls that are necessary to manage the identified information security risks.

? You decrease the likelihood of problems with the certification audit because you don’t have all those extra “unnecessary” controls to be audited.

The main disadvantages are:

? You have to deal with the often considerable overlaps between the controls in your ISMS and these other controls that are not part of the ISMS.

? You are running multiple largely separate approaches to the management of these different sets of controls.

? You are potentially missing out on all the strong disciplines and management approaches in ISO27001 to help you manage all these other controls.

2) Integrate/use other control lists with ISO27001.

I.e. ideally you want to have one single list of controls to manage across your organisation and you want to use all the disciplines of ISO27001 to help you manage those controls.

The main advantage of integrating these other “unnecessary” (from an ISMS perspective) controls into the ISMS are:

? You can then have a single set of controls to manage across the organisation.

? You can use all the disciplines and practices of ISO27001 to help to manage those controls.

The main disadvantages are:

? Your ISMS may not properly conform to the requirements of ISO27001. From a certification perspective this is less of a problem than it seems because it is very unlikely that a certification auditor would highlight this as a non conformity.

? You have added complications and complexity into your ISMS. This is not a good idea and gets in the way of you thinking properly about the management of your information security risks.

? You potentially increase the risk of problems with obtaining and keeping your ISO27001 certification because any problems with these “unnecessary” controls could lead to nonconformities.

The 4 main options

From the above there are therefore 4 main options of how to use “other” control lists/frameworks:

1) A mandatory control list kept completely separate from the ISMS.

2) A mandatory control list fully integrated into the ISMS.

3) A control list used to help manage information security risks better but done so completely separate from the ISMS.

4) A control list used to help manage information security risks better but fully integrated into the ISMS.

Below I discuss each of these in turn.

Option 1: Mandatory control list kept completely separate from the ISMS.

With this approach you just do ISO27001 using whatever approach you want and then in parallel use your other control lists. With no interaction between the two. This can be slightly annoying because you end up with two separate lists of controls to look after. I think this approach makes a bit of sense if you need to do PCI DSS for all the PCI DSS controls just because of the way PCI DSS works and the sheer number of controls.

This approach is very common for SOC 2 but it means that the list of controls in the SOC 2 report does not match the list of controls in the Statement of Applicability (SOA) although some might look a bit similar. I have always thought it was a bit odd that people do this with SOC 2 especially as you can use the same set of controls for the SOC 2 report and in ISO27001. That way you only have one set of controls to look after. Also, if you are doing ISO27001 properly it means that you are managing the SOC 2 controls on an ongoing basis.

Option 2: You want to integrate/use a mandatory control list with ISO27001.

ISO27001 does not work very well or properly take into account circumstances where there are a number of mandatory controls or even if there are a number of controls that you just want to do for some reason. This is because ISO27001 is based on the principle that the risk assessment is used to decide the controls and that you can’t add “extra” controls into the Statement of Applicability (SOA) that are not defined in the risk assessment as necessary controls. This is made clear in ISO27005:2022 (Information Security Risk Management).

There are 3 mains ways of doing this:

1) Artificially modify the information security risk assessment

You can artificially modify the information security risk assessment by either adding in some new risks that you say need these “extra” mandatory controls or you just add these controls to one or more existing risks as being necessary controls to manage the risks. You know that they are not actually necessary controls to manage the identified risks but you pretend that they are so that you can get the controls into the ISMS somehow. This will clutter up and add complexity and unnecessary detail to your risk assessment. It is also does not meet the requirements of ISO27001 in that you now have some controls in your risk assessment that are not necessary to manage your risks to the CIA of information in your scope. I don’t really recommend this as an approach but this can be and often is done. It is a bit of a fudge really but the auditor is very unlikely to challenge you about this.

2) Add these controls into the SOA.

A better approach is to leave the risk assessment as it is and add these additional controls into the Statement of Applicability (SOA) unless of course they are already there. This is a popular solution and does at least leave you with a risk assessment that reasonably represents the information security risks. However, this is not properly compliant with ISO27001 (and ISO27003, ISO27005 and ISO27007) which all make it clear that the only controls you should have listed in your SOA are ones that are referred to as necessary in the risk assessment. I.e. You end up with a list of controls in your SOA that do not fully match those in the risk assessment.

3)????Keep them separate from the risk assessment and SOA.

I think that an even better solution is to keep the risk assessment and SOA “pure” so that it only has the “necessary” controls that fully match to the risk assessment but then have a separate “controls catalogue” document that lists all the controls in the SOA plus all these other mandatory controls. In this controls catalogue you should clearly indicate that these “extra” controls are not taken from the risk assessment and why you have included them. In this way the risk assessment and SOA properly conform to the requirements of ISO27001 but you have then also included the ”extra” controls into your ISMS in a structured way. You would also then add these “extra” controls into your performance management and internal audit approach, etc. One very big advantage of this approach is that because these “extra” controls are not listed in the SOA as justified/applicable a certification auditor cannot audit them. But you have still at least to a useful extent integrated them into your ISMS.

Option 3: A control list is not mandatory but is used to help manage information security risks better but this is done so completely separate from the ISMS.

This is really the same as option 1 above although in principle because none of the controls are mandatory then you don’t have to use all the controls in the controls list.

Option 4: A control list is not mandatory but is used to help manage information security risks better and this is integrated into the ISMS.

I.e. you want to:

? use a different control list to Annex A in your Information Security Management System (ISMS). I.e. not use Annex A, or

? you want to use Annex A but supplement it with some controls from your favourite control list, or

? You want to use all custom controls. I.e. not use any control list.

But you are only doing this because you think that the control list will help you in some way – not because it is mandatory.

This is actually easier than it seems because there are really only three requirements in ISO27001 that this affects.

This first is 6.1.3 b) which says this:

“Determine all controls that are necessary to implement the information security risk treatment option(s) chosen;

NOTE 1 Organizations can design controls as required, or identify them from any source.”

This is pretty simple. You have identified your risks and you now need to identify controls that you think are the necessary controls to manage those risks. Some of these controls may already exist. Some may be ones that do not currently exist but you think should. As it says these controls can come from anywhere so feel free to use any controls from your favourite list (e.g. NIST, Annex A, ISO27017) or custom. It is your choice. It really is!

I am going to say that again – the controls you determine as necessary to manage your risks can come from anywhere.

If you already have a SOC 2 report you could try to choose controls that are already in your SOC 2 report (but you may well need others). When you do this determination of controls if you find that you have some controls in your risk assessment that are not in your SOC 2 report this may indicate that these are additional controls that should be added to the SOC 2 report (think about it).

If you don’t currently have a SOC 2 report but want one later then you should choose custom controls in your risk assessment that properly represent those necessary to manage your risks. You could use the “points of focus” in SOC 2 as a guide for this but don’t need to. You will need to be a bit more careful about the control wording because SOC 2 controls are usually more wordy than typical ISO27001 controls. If your risk assessment is sound and your selection of controls is sound then the controls you need for your SOC 2 report when you get to do it should then be a close but probably not an exact match to what will go in the SOC 2 report. In practice there is more to aligning SOC 2 and ISO27001 but that is the principle. I.e. with a bit of care you can end up with the same set of controls for your SOC 2 report and your ISO27001 implementation.

My recommendation and preference is to try not to select the necessary controls in the risk assessment from a control list (e.g. Annex A or NIST). You will end up with a much better risk assessment and set of controls if you get people to think about this rather than just pick controls from a predefined list. I.e. do the risk assessment and selection of controls without using any pre-defined lists of controls. One important advantage of this approach is that if you use a pre-defined list (like Annex A or CSA or NIST) you could easily miss some important controls because they are not in that list.

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

The second requirement in ISO27001 is 6.1.3 c) which says:

“Compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted; “

This can be quite useful as it is a way of checking that you have not missed anything important in your risk assessment. Note that any controls “omitted” do not have to come from Annex A. It might simply be that the comparison leads you to think “Hmm. Good point. Control XYZ from my control list (e.g. NIST) or custom control ABCD should be in the risk assessment to help manage risks P, Q and R.”

ISO27001 insists that you do this comparison with Annex A but you can (and should) also do this comparison of your necessary controls with the list of controls in other controls lists (e.g. NIST, CSA).

If you are also “doing” ISO27017 and/or ISO27018 you also need to the comparison with the controls lists in those documents.

This is an important quality check on the risk assessment. This point is also covered in ISO27005:2022. There is a lot more about?how to do this comparison with Annex A in this article. https://www.dhirubhai.net/pulse/how-do-iso27001-comparison-annex-clause-613-c-chris-hall/

The third requirement is 6.1.3 d) which says this:

“Produce a Statement of Applicability (SOA) that contains:

— the necessary controls (see 6.1.3 b) and c));

— justification for their inclusion;

— whether the necessary controls are implemented or not; and

— the justification for excluding any of the Annex A controls. “

This does not really have anything to do with your chosen list of controls but I have included it because you need to be careful how you cover this in the SOA. Two quick points on this:

1. The justification for inclusion can be the same for all the controls.
2. The justification for exclusion of any of the Annex A controls can be the same for all the controls.

This article shows how to create an SOA that does this. https://www.dhirubhai.net/pulse/how-create-iso27001-statement-applicability-clause-613-chris-hall/

Summary

There are few things to think about when you want to use controls from other control lists/framework but if you do this in a structured way you can then use all the governance/management bits of ISO27001 to help you manage all of it.

Chris

To see a list of all my articles click here. https://www.btrp.co.uk/Articles2