ISO27001 and its unrealistic requirements about selecting controls

My view is that ISO27001 has a number of requirements that are not very useful or practical in helping an organisation manage its information security risks. In this article I am looking at what I think is perhaps the most unrealistic requirement of ISO27001. This is the requirement that the only controls you should manage using your Information Security Management System (ISMS) are ones that are necessary to manage your identified information security risks.

In practice this is completely unrealistic and does not take any proper account of the practical realities of organisations and their approach to information security.

Forget about ISO27001 for the moment and consider some of the possible reasons why organisations might implement information security controls:

General reasons

? It is good practice.

? It is best practice.

? It is commonly used.

? It is in Annex A of ISO27001.

? It is in a framework – e.g. CSA, CIS, NIST CSF, etc.

? Lots of other companies do this.

? Other companies in our sector all do it.

? We are already doing this – i.e. it is an existing control.

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

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

? Self imposed policy – “We will adhere to NIST CSF”.

? A salesman convinced you 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 you look good.

? One or more of our stakeholders/interested parties expect you to implement it.

Compliance reasons

? One or more of our customers has specified that we must do these controls in a contract – i.e. a contractual requirement. A good example of this is compliance with PCI DSS which if you deal with credit cards will be mandated by your acquirer.

? You have a regulator that insists you must implement it. As an example, most regulators for legal firms insist on controls on the confidentiality of client data.

? There is a legal requirement for you to implement it. As an example, many organisations are in jurisdictions that mandate controls on the management of personal data (e.g. GDPR).

Despite what many training courses and consultants will tell you there is nothing in ISO27001 that allows for or supports the principle of determining controls based on any of the above criteria. ISO27001 is very clear about this. The only controls that you should implement and operate in your ISMS are ones determined as necessary in the information security risk assessment. It is of course the case that there will be overlap between the above possible reasons and the controls identified as necessary in your risk assessment but there is nothing in ISO27001 that takes account of this.

The idea that an organisation would not take into account any of the above factors in determining what controls to implement and operate is completely ridiculous. ISO27001 does not reflect the reality of how organisations work and this causes all sorts of confusion about how to manage information security controls and what and how ISO27001 is used in practice.

There are a number of different ways of dealing with this problem but there are two main solutions that organisations usually adopt.

Option 1 - Integrate the controls into the ISMS

You have done your ISO27001 risk assessment and determined the necessary controls but you now want to add in/integrate some other controls into the ISMS that are not, according to your risk assessment “necessary”. I.e. some of the controls you have or are going to implement are based on one or more of the above list of possible reasons. Perhaps the boss thinks you should do control X. Or you have some budget to spend on controls, etc.

This approach is very common but does not work very well in practice. There are two main approaches that are typically used to do this:

1) You artificially modify the information security risk assessment by either adding in some new risks that you say need these 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. This will clutter up and add complexity and unnecessary detail to your risk assessment. It is also not compliant with the requirement 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.

2) You leave the risk assessment as it is and add these additional controls into the Statement of Applicability (SOA). This is also a popular solution and does at least leave you with a risk assessment that reasonably represents the information security risks. However, this is not 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.

3) A better solution is to keep the risk assessment and the SOA “pure” so that it only has the “necessary” controls that fully match to the risk assessment but then have a separate “controls list” that lists all the controls in the SOA plus all these other “unnecessary” controls. In this controls list you should clearly indicate that the “unnecessary” controls are not taken from the risk assessment and why you have included them.

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 is not properly compliant with 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 even though it is!

? 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.

Option 2 - Manage the controls separately from the ISMS

The second possible approach is to keep the ISMS “clean” and manage these controls outside the ISMS. This is a very common solution and one often used by accident rather than design as such. As an example, if an organisation needs to comply with PCI DSS then it makes some sense to manage the compliance with PCI DSS separately from running your ISMS. Similarly, although they can be combined, if you need to produce a SOC 2 report then this is often done separately from running the ISMS. Some organisations also have a Compliance Management System which can be used to manage the controls that the organisation needs to be compliant with some reason – e.g. contractual, legal, regulatory, etc.

In practice organisations often have a number of information security controls in place that are not part of the ISMS and are just managed on an ad hoc basis outside the ISMS.

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 you 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.

Summary

Which of these should you do? It depends. My suggestion is that when you are first implementing your ISMS that you keep the ISMS and especially the risk assessment as simple as possible. As such just focus on fairly strictly applying the requirements of ISO27001 and only include in your ISMS those controls that you determine as necessary to manage the information security risks. Your ISMS fully complies with the requirements of ISO27001 when you do this. Similarly, keep your SOA pure and only list in it those controls identified as necessary in the risk assessment. At the same time, you also acknowledge to yourself and others in the organisation that there are other controls in place that are not part of or being managed by the ISMS. This helps keep your ISMS as simple as possible and improves the likelihood of getting certified. People have enough trouble managing their information security risks and adding extra complication and complexity into the ISMS is not a good idea.

After the ISMS has been in place for a while you could consider approaches to bring some of these other controls into the ISMS because this helps you manage them. If you do this you are then changing the ISMS to be not properly compliant with ISO27001 but if this works for you then you can do it this way. If you do this, I suggest that you annotate those extra controls as being clearly there for another reason – e.g. legal, contractual, “business”, “audit finding”, etc. I recommend that you always keep your SOA clean and only lists the “necessary” controls identified in the risk assessment. If you are careful with this you may also be able to convince a certification auditor that they should not audit those “extra” “unnecessary” controls because whilst you are using the ISMS to help manage them they are not strictly part of the ISMS and should be excluded from the audit.

At present ISO27001 is somewhat academic and unrealistic about the selection of controls. and I do wonder if ISO27001 should be changed to be more realistic about how organisations actually choose the controls to implement.

Chris

www.btrp.co.uk