Your controls have to be perfect for SOC 2 (sort of) but not for ISO27001 (sort of)

One concept that is not always fully understood is that for SOC 2 all your controls have to perfect. Or rather all the samples that the auditor choose must show the control to be operating perfectly. If not they will raise an exception. Bad. See the section below “So what?” for an idea that might help a bit with this.

With ISO27001 this is not the case. Because ISO27001 is about how you manage your information security risks there are two important concepts:

Concept 1: A control need not be working perfectly all the time or even fully implemented

As long as you know about it and have a clear plan to fix it you can have some controls that are not working perfectly and/or have not been implemented. Of course it does not make sense to have none of your controls implemented or working and still expect to be certified but you can certainly have some controls that need to be implemented and/or have faults or needs work and all is well. A simple example illustrates this.

On Friday you review your risk assessment and identify the need for a new risk. When you analyse it you see it is outside your risk criteria (notably your risk appetite). You realise that in order to get it within the risk criteria you need 2 new controls and changes to 3 existing controls. You update your risk treatment plan accordingly. Notably you now have 2 new controls listed in the SOA as not implemented. You also have 3 controls that are “not working how you want them to be”. This is the ISMS in action. All is well. This is what is supposed to happen. On Monday the certification auditor arrives for a certification audit. The auditor cannot raise a nonconformity for any of this even though you have 2 controls not implemented and 3 controls not working quite how you want them to be. Of course you do have to update the 3 controls and implement the 2 new controls in a timely manner so that the new risk you added can be brought to a state where it meets the risk criteria.

As another example, you have a policy that says “All laptops must have hard disk encryption”. Great policy and control. However, one day it comes to light that one laptop does not have hard disk encryption. Bad. You document this as a non conformity and go through the non conformity process – i.e. ?What is the correction? (encrypt it now). Could it happen anywhere else? (check all the laptops for this). What is the cause? (the laptop was bought urgently for the CEO and the set up process was not followed). What is the corrective action? (put in place a technical control to check every laptop automatically when it connects to the network). This is your ISMS in action. All is well. But let us say the auditor arrives on site to do a surveillance audit part way through you applying this non conformity process – notably before you have even had a chance to encrypt the rogue laptop. You have a laptop that is not encrypted. This is a control not working. But the auditor cannot raise a non conformity for this because you know about this and are correctly managing your ISMS by going through your non conformity process. All is well provided of course you deal fully with the non conformity by following the non conformity process and in a reasonably timely manner.

Concept 2: Your controls can have ongoing and permanent “weaknesses”

Most people operate on the basis that all controls in ISO27001 must be operating at 100% effectiveness all the time. Not true. They only need to be operating at sufficient effectiveness to ensure that all the risks that all the controls are managing are within the risk criteria – notably the risk appetite or risk acceptance criteria.

As an example, we may have a control “Information security awareness”. A popular control and usually a necessary control to help manage one or more risks. In practice we are likely to have several risks that this control is helping to manage and it is also likely that each of those risks is being managed by lots of other controls of which “Information security awareness” is just one. It might be that even if “Information security awareness” as a control is not working very well, all the other controls for each risk would be sufficient to keep the risks within their risk criteria. I.e. even though we have said “Information security awareness” is a necessary control it is not that important compared to some other controls. I.e. it can have weaknesses and problems and all is still well with the ISMS but more importantly all is well with how we are managing our information security risks. To be fair most people do not understand this and most certification auditors are unlikely to accept or even understand this principle. It is also tricky to document this but can be done and I do it sometimes. But the principle is certainly sound.

There are some things that you could not reasonably apply this principle to. After all, you do not really want your firewall to be only operating at 95% effectiveness. It needs to be 100%. Similarly, if as part of your recruitment practices you do criminal records checks you really need to do it on everyone. And so on.

Advanced thinking (optional and skip if you want to!) is below:

If you want to get sophisticated about this then against each control for each risk you put some indication of how important each control is for each risk. As an example we have a risk “We are subject to a successful ransomware attack”. Against this risk we might have a number of controls and against each one we put a % which represents how important that control is contributing to the management of the risk. These %’s of course add up to 100 but represent the relative importance of those controls. As an abbreviated example, for the risk “We are subject to a successful ransomware attack” you might put “Secure air gapped backups” as contributing 80% towards managing the risk and “Phishing exercises” as contributing 5% with several other controls contributing together the remaining 15%.

An even more sophisticated approach would be to then aggregate this across all the risks so you can get a picture of the relative importance of each control across the whole organisation. The “key” controls. It is important to do this as a control may be very unimportant for some risks but very important for other risks. An even more level of sophistication would be to take into account the other attributes of the risks when doing this – notably the likelihood and impact.

I only very very rarely do this for organisations as it is too sophisticated for most of them to implement and understand.

So what?

Some of the above is too much for many organisations to full get to grips with. Most organisations just keep it simple and say that:

? “all the controls are of equal importance” and

? “all controls must all be working at 100% effectiveness at all times”.

It is a simplification but will do most of the time for most organisations.

But there is something that can be done that might help a bit with this.

If you can, what you can do for both SOC 2 and ISO27001 is to “hard code” into the control description how well the control needs to be working for your organisation to “be happy with it”. A few examples:

? “Within 24 hours of the new definitions being released malware definitions are updated on 95% of all devices connected to the corporate network”

? “90% of all staff undertaking active work for the organisation will complete annual information security training within one month of it being available”

? “On at least 19 days out of every 20 a security guard walks around the outside of the building every night at 3am to check that all the windows are shut”

? “We hold 48 CAB meetings in each calendar year". (I.e. not “every week”).

? “IT morning check lists are completed for at least 240 days each year”. (I.e. not every day).

? “A documented acceptable use policy and is reviewed at least annually. Within 2 weeks of commencing work all new starters formally agree their agreement to adhering to it. 95% of all staff agree to this annually within one month of being asked to do so.”.

Also, if you do this you are also helping define “criteria” for your processes which is one of the new requirements in ISO27001:2022.

This is not going to work for all your controls but for some it is a viable option and can give you a bit of “wriggle” room.

For both SOC 2 and ISO27001 you may need to convince the auditor that your “qualification/criteria/tolerance” for the control is reasonable and does not compromise the ability to meet the organisation’s objectives. But the principle behind this approach is sound.

If you want to find out a bit more about this see this article: https://www.dhirubhai.net/pulse/when-using-iso27001-controls-do-need-100-effective-chris-hall/

?Chris

An index of all my articles is here?https://btrp.co.uk/Articles2

?