ISO 27001 vs SOC 2 - Part 2

‍

What are the key implementation stages with ISO 27001 and SOC 2?

LD – Okay, let’s try and keep this at a high level.  Step one, make sure you've got management commitment, make sure you've got leadership on board.  You need the leadership to do what they say, not just say what they expect everybody else to do.  And it is about having the right resources, the right roles in place. You absolutely need top management commitment to it.  So, number one, get that management engagement in place.

Step two, define your scope.  Unlike SOC, which is very much about a particular service you are delivering, ISO 27001 can apply to a service, a series of locations, your central group of functions, the entire organisation.  Define your scope, and by that, you need to think about, does the scope meet the objectives of the organisation? So, what are your company objectives?

If you are offering Cloud services and see that as your expansion model, there's no point in having a scope that doesn't have anything concerned with the Cloud services model.  

LG – So, the scope doesn’t have to cover the whole organisation for ISO 27001?  It can be a bit more specific.

LD – You are absolutely right, but it must be meaningful.  So, if you think about it, when you write your scope down in a paragraph, a few sentences, that’s what will be on your certificate.

Think, why am I doing ISO 27001? And then consider if a key client or prospect looks at your certification scope, is it going to be relevant to them?  As an example, if you are regulated, by the Gambling Commission, does your scope include the regulated services? Or, if a client is asking for ISO 27001, is the service you are delivering to them included within your statement.   And finally, does your scope align with your business objectives?

So, define your scope.  And, as we've already mentioned, next is risk assessment. Undertake your risk assessment, and once you've done that, your risk assessment will help determine whether the controls you have in place are appropriate.  If not, do the existing controls need improving or do you need to consider additional controls to appropriately mitigate your risk? And which controls should you prioritise?  It then that becomes an ongoing activity throughout your implementation, in terms of treating risks and reviewing those risks on a regular basis.  Alongside that, implement your management system and all the various facets to it.  It’s called an ISMS and, as we addressed in the first of this series, it’s your approach to managing information security.  Once established, it is wise to start auditing early and establishing your audit cycle.  When you invite an external assessor in to verify whether you have successfully implemented your ISMS and you’re going to get that certificate, you want to have been living it for at least three months and audit evidence supports that.

The assessor doesn’t want to see that it is all brand new and shiny and a case of ‘what you intend to do’, but that you actually are already living and breathing information security management.  So, think management commitment, scope, risk assessment, implementing your ISMS and getting into continual improvement.

LG – Chris, are you able to tell us a little bit more about the SOC 2 implementation stages?

CH – It's not going to surprise anybody, but because the two standards cover broadly similar areas, the implementation requirements are also broadly similar.  With SOC 2 though, it's very important, at the earliest stage possible, to gain a clear understanding of what you need to achieve and why you're actually doing it.  

As I said earlier, SOC 2 is based around service.  So, you need to be absolutely clear on what the scope of your SOC 2 report is going to be.  If you deliver a range of services, but you are only delivering a couple to American customers, the likelihood is that you're only going to want to include those two services within your scope.  So, understand exactly what services require a SOC 2 report.  

Once you've identified that, this will help you to decide which of the trust service criteria are applicable to your service.  We haven't really touched on criteria yet, but essentially within SOC 2 there are 5 trust service criteria; there is security, which is mandatory and is by far the biggest one that all audits have to include.  Then there are four other optional criteria, and they are availability, processing integrity, confidentiality and privacy.

Depending on the type of service that you're delivering and depending on the requirements of your customers, you need to make a decision on which of the optional trust service criteria to include as well. So, for example, if you're delivering software as a service, it's quite likely that availability is going to be an applicable trust service criteria and that you're going to need to include it as it’s going to be important to your customers.

Whereas, if you're delivering a service where you are processing financial data, then processing integrity i.e., checking what's going in, what's coming out of your system, may well be applicable.  And then what you really need to do at that point is some sort of gap analysis to determine what you've already got in place and what you believe is fit for purpose for the services you’re delivering, and which meets the points of focus of your selected trust service criteria, and what is missing and then, obviously, you need to look to resolve those gaps.

Lisa has mentioned that in 27001, risk is very much the kicking-off point for a lot of the work.  Risk is also applicable to the SOC 2 as well, but it's not as central in terms of the mechanisms of determining which controls are applicable and your structure.

It's a component. It's a point of focus within the standard but it's not such a driver of the process.

‍

‍

‍

‍

Are ISO 27001 and SOC 2 standards applicable to particular organisations or market/industry sectors?

LD – So this is where the gloves come off in terms of the context of ISO versus SOC.   SOC is very much a client supply-chain driven standard.  You're highly unlikely to go through the whole SOC audit process and assessment process unless somebody is asking you to do it, whereas with ISO 27001, you're more likely to do it from an internal assurance perspective.

So, ISO 27001 applies to any organisation in any sector.  As I said at the start, it's about best practice information security management.  I cannot think of any organisation that shouldn't be asking itself ‘do we do information security management well?’  ‘Have we got a positive approach to information security management?’

I’ll defer to Chris, but you’re less likely to have a manufacturing plant, doing SOC 2.  Whereas for ISO 27001, there's probably a really good reason to do it when you're considering security of that plant, the vetting of staff, and all aspects of information security management.  So, is ISO 27001 applicable to particular organisations/sectors?  My answer is everyone!

CH – In fairness, when I talk to customers about ISO 27001, that’s pretty much what I say as well. It's obviously a generic standard.  It can be applied to organisations of any size and in any business setting.  With SOC 2, I've never come across an organisation that has decided to obtain a SOC 2 report just because of internal drivers.

It's absolutely driven by the fact that you've already got clients that have made a request for a SOC 2 report, or you are looking to expand your client base into the American market where you believe it is likely that clients are going to be asking for SOC2 reports. Now, there is another aspect to this as well.

Everything Lisa says about ISO 27001 is correct. But essentially, if a client asked you about your ISO 27001 status, really all you can share is your certificate and your statement of applicability and what controls are being managed by your ISMS.  However, if you've got a SOC 2 report, that report, in great detail, specifies the service that you deliver.

It's specifying the environment that you operate in, in terms of your wider organisation and the governance of your wider organisation, along with the key tool sets you use, the key third parties you use, down through the trust service criteria and the points of focus.  The auditor will be specifying what they found and how they assured that you have got an effective response, an effective set of controls and processes associated with a particular point of focus.

So, if you're a customer of a particular supplier, and if that supplier gives you a SOC 2 report, you're going to get an awful lot more information.  And I guess it might be unfair to say an awful lot more assurance, because obviously ISO 27001 is an international standard with all sorts of requirements around auditing standards etc.

But essentially, you are providing a lot more information.

LD – Can I just add the other really important consideration, and this is what we see generally, ISO 27001 is an international standard adopted across the globe.  You are just as likely to be asked for it, whether you're in Japan, Australia, or the UK,

SOC 2, as Chris has said a few times, is very much an American standard.  So, unless you are delivering to the American market or have an American client and you're in that supply chain, you're highly unlikely to be asked about SOC.  It is very US focused. Having said that, here’s a slight curved ball.  We, at URM, have seen more requests for SOC post Brexit.  Whether that’s a change in market or something else, it’s a bit early to say.  

But you could be asked by anybody across the globe whether you're ISO certified and there are certain parts of the globe that have adopted it more than others.  You're only going to be asked about SOC if you're selling into the American market or you're in the American supply chain.

CH – It is worth saying that there’s nothing within a SOC 2 report which is American focused and only applicable to the USA.  So, if you've got a SOC 2 report, you could use it as a method of assurance to a UK-based client for a European-based client.  There’s nothing in there which prevents that.

But Lisa is absolutely spot on.  Essentially, it is developed as an American standard.  As I mentioned at the start, the AICPA, the key American accounting organisation developed it.  Therefore, you can see that fundamentally its roots are in a perceived gap within the American marketplace for an assurance methodology.

LG – A question I have been asked is ‘Can ISO 27001 and SOC 2 be used as a substitute for the other? Can someone offer their SOC 2 report if someone said we need to be ISO 27001 certified and vice versa?

LD – You can try if you're being asked for it.  You can go to your client, or whoever is asking and say, I don’t have a SOC 2 report, but I am ISO 27001 certified, will you accept that?  In our experience, if you're being asked for a SOC 2 report and you offer something else, it's likely to be rejected because of the level of assurance that a SOC report provides.  If you are asked for ISO 27001 and you say, I've got a SOC 2 report and that report, and this is the key part, covers the exact same scope or a wider scope than you would have for ISO 27001, then it's likely to be accepted.  But generally speaking, ISO 27001 covers a broader scope. So, it depends on the needs of the requestor and it's down to what they will accept.

CH – That’s absolutely right.  If your client comes to you and says I need you to have a SOC 2 report, and if you say we haven't got SOC 2 report, but we've got ISO 27001, in my experience, they may accept that as a starting point, but they will absolutely expect you to be getting that SOC 2 report.  I guess it’s just the nature of how SOC 2 is developed and its use within the marketplace.  And again, I come back to my supply chain example, if you're an organisation which is sitting in the middle of a supply chain, and your client is asking you for a SOC 2 report, the sensible thing to do is to ask your key suppliers for SOC 2 reports as well  This will then enable you to show not only that your service is assured, but that the subcontractors or sub organisations which are assisting in the delivery of your service, are equally well assured.

‍

‍

‍

‍

‍

‍

‍

‍

What are some of the key similarities and differences between ISO 27001 and SOC 2?

LG – Just to recap from what we have heard so far on some of the key similarities and differences between the two standards.  I've taken that both information security standards have requirements for controls, processes and policies to be in place.  There are risk management elements in both standards, although ISO 27001 is more risk focused and is a risk based standard and both standards do rely on auditors to deliver external assurance. Chris, are there any differences, which we haven't discussed so far, that people should be aware of?

CH – Yes there are some key differences.  One key area of difference is around the actual auditing process.  For ISO 27001, it's fair to say that fundamentally the auditing process is a ‘point in time’ audit.  When the auditor comes in, they're going to be looking at the documentation, the policies, the processes. They're going to want to see examples of effective operation of those policies and processes. And they may do a little bit of sampling.  In my experience, typically they will sample things like your procedures for managing joiners and leavers over a period of time, or they might want to look at a sample of your change requests.  With SOC 2, and I need to caveat this with a specific point, the auditors are looking at the effectiveness of your policies and processes over a period of time.  But I did say I need to raise a caveat as there two different types of SOC 2 audit  you can undertake, a Type 1 and a Type 2 audit.

A Type 1 audit is very much along the lines of an ISO 27001 audit in that it’s a point in time audit. When the auditor comes in, they’ll be looking at your documentation, your policies, your processes and the auditor will want to see some examples to show that your processes and policies are being effectively implemented.  A type 2 audit, however, is an audit where the auditor is looking for demonstration of the effective operation of the policies and processes over a specified time period.  So, for example, the auditor will want to validate that processes such as change management, incident management and access management have been operating effectively over the entire reporting period.  If they find that there are gaps in the operation of these processes this is when they are likely to raise exceptions in the report.  An exception is likely to have wording along the lines of ‘the change management process was seen to be operating effectively in 8 out of 10 sampled changes, but for 2 changes there was no evidence of a test report.’

LG – What is that specified time period?

CH – It depends. Typically, once you're in the cycle, you've done your first SOC 2 report, then there is a twelve-month reporting cycle, and essentially you get a new report each year, and obviously you have to go through an audit each year.

Initially, the audit bodies will give you a little bit of flexibility.  I've not really experienced any initial SOC 2 audits that have covered a period of any less than six months.  Once you get much below six months, you start to get to the point where it's really almost a ‘point in time’ audit.  A SOC 2 Type 2 audit, where you're covering a full reporting period, is the de-facto standard. That's the expectation that your clients are going to have, that is a Type 2 of SOC 2 report. There are only  specific circumstances where you would do a Type 1 report, a point in time report, and that is typically when you either have a very specific deadline for when you need to produce a SOC 2 report; and that deadline will mean that you're not going to be able to demonstrate that you've been operating your controls effectively for a period of any longer than a few months. That's absolutely a key difference between ISO 27001 and SOC 2.

Another key difference between ISO 27001 and SOC 2 is one that quite often can catch an organisation out.  Although we've talked about the fact that they broadly cover the same areas, SOC 2 is slightly wider, in that SOC 2 is also looking at aspects of the governance of your organisation.

The auditors want to understand that you are operating your information security management system and your processes and controls in a well-governed organisation. ISO 27001 really limits its scope to the ISMS and its relevant controls.  

It's things like how senior management works and how business objectives are set.  How do you communicate to clients, internally and to suppliers?  How do you manage your staff?  How do you recruit?  How do you train?  How do you performance manage your staff?

The third key difference to be aware of is that SOC 2 auditors are likely to dive into much more technical detail on the implementation of your controls than an ISO auditor.  For example, a SOC 2 auditor will want to review your firewall rule lists, the alerting configurations of your monitoring tools and your access control configurations in Active Directory.  In that respect, a SOC 2 audit is more similar to a PCI DSS or Sarbanes Oxley audit than an ISO 27001 audit.

We will also talk in our 3rd instalment about another difference, which is that SOC 2 audits tend to drill down into more detail on the technology that is used to manage controls.

‍

Next Instalment

In our final instalment, Lisa and Chris will be addressing the following questions:

• How are the 2 standards assessed and audited?
• How long does each certificate last?
• How much time and effort is required to implement each?
• How much does it cost?  
• Who can carry out ISO 27001 and SOC 2 audits?
• Are the requirements for SOC 2 type 1 and type 2 different?

‍

Read Previous Instalment

ISO 27001 vs SOC 2 Blog - Part 1

‍