“Dear vendor, your Service Provider’s SOC report doesn’t cover the services you’re providing us. Thank you for providing Amazon’s/Google’s/Microsoft’s SOC 2 report, but can you please provide a SOC 2 report that covers your services for the most recent period?…”
That’s the beginning of what is becoming a very commonly sent email from the risk management departments at several of our clients during their third-party application risk assessment activities.
Part of a good Third-Party risk management process includes obtaining and reviewing SOC reports for vendor candidates ideally prior to procuring their services. (As the saying goes though, better late than never.) Many organizations’ technology risk management departments know to perform a couple important steps in this process.
- First, they know to request the SOC report and review it to make sure it’s presented with an unqualified opinion from the auditor. An “Unqualified Opinion” is like getting an A+. This means controls are described fairly and accurately and are operating effectively for the period covered. Basically, it means the controls meet all of the standards. Further due diligence would encourage the review of the detailed results of testing within controls, not always trusting that a lack of major exceptions led to an unqualified opinion.
- Another important activity that effective risk management departments perform during the SOC report review is determining if their organization has accounted for the CUECs (Complementary User Entity Controls) and has either implemented or plans to implement those controls. A user entity is an organization that utilizes the services of a service organization, and CUECs are controls that reside at the user entity. For example, for a cloud application like Google Drive, a user entity must make sure they remove terminated employees’ access to the application. If a terminated employee retained that access and accessed sensitive information post termination, that’d be a failure of control on the user entity’s behalf, as that control responsibility is not owned by Google.
Fig 1. – Common SOC 2 visualization.
Each of those bullet points could be explored in much more detail, but those explanations should suffice for the purposes of this article. And… it gets more complicated. In the instance we’re discussing where a Service Organization is providing SAAS (Software as a Service), a SOC 2 report is necessary. For a SOC 2, the control areas are categorized using what are called Trust Services Categories. The available Trust Services Categories (TSCs) as defined by the American Institute of Certified Public Accountants (AICPA) that can be included in a SOC 2 are the following:
- Security (also known as common criteria). Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives;
- Availability. Information and systems are available for operation and use to meet the entity’s objectives;
- Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives;
- Confidentiality. Information designated as confidential is protected to meet the entity’s objectives; and
- Privacy. Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s objectives.
With the exception of Security, which must be included in all SOC 2 reports, not all of the TSCs have to be included. It’s the job of the issuing SOC 2 auditor to perform that scoping.
To this point we should have painted the picture that for a business process that is supported by a service organization, control responsibility is divided into categories and shared between at least two entities – the service organization and the user entity.
So what about instances where a company providing SAAS is using another Service Organization for their server infrastructure? (e.g. Imaginary Software provides a subscription accounting application that is hosted on Amazon Web Services’ servers)? In this instance there are 3 entities involved.
Fig 2. – This is what some SAAS providers without a SOC 2 are trying to pass off as acceptable. It isn’t.
This is where things get more complicated, and in the confusion we see Services Organizations that do not have a valid SOC 2 report try to pass off the SOC 2 report of their Service Provider (of which they are a User Entity) as covering all of the risks that they introduce to the process, and therefore introduce to their User Entities.
This is a problem for multiple reasons. First, you get no indication of their CUECs and whether they are in place and operating effectively. More importantly though, the controls (categorized into TSCs) for the additional services they are providing you aren’t covered by that SOC report. In the example we mention, Imaginary Software’s storage/DB and application servers would be hosted on Amazon infrastructure, and assuming Imaginary Software held up their end of the bargain with the related CUECs (which you wouldn’t know without testing), the controls Amazon provides for availability would likely benefit the end User Entity. However, the end User Entity would have no guarantee of the processing integrity for their data. Imaginary Software’s processing could be totally inaccurate, and the user entity would never know b/c the provided SOC report was for Amazon, not Imaginary Software, and Imaginary Software is the one doing that processing.
Ok, so we know that’s not how this works, then how should it really work? What does an IT Auditor or Risk Management professional have to do to gain assurance of risk mitigation?
Would they have to:
- Get the SOC 2 for Amazon and verify it’s unqualified;
- Test the CUECs at Imaginary Software;
- Obtain the SOC 2 report for Imaginary Software and verify that it is also unqualified, and;
- Test the CUECs for that SOC 2 report at the user entity?
Phew, that’s a lot of work! And what if there’s a 4th service organization, or worse yet a 5th!?
Fortunately, it doesn’t work this way. Instead, the service organization and user entity in this situation, Imaginary Software’s SOC 2 should have been properly scoped so that the issuing audit firm performed the work of reviewing their Service Organization, Amazon’s, SOC 2. They would have also tested Imaginary Software’s CUECs related to Amazon’s services prior to issuing the SOC 2 covering Imaginary Software’s services.
Fig 3. Thank goodness it doesn’t work this way.
So, the result would once again look like figure 1.
So what does this all mean to you if you’re an IT Auditor or Risk Management professional? Well, if during your procedures you have a Service Organization hand you the SOC 2 report for another Service Organization for which they are a User Entity, you can kindly send them this article and request that they provide you a valid SOC 2 report that covers their services.
If they can’t provide it, then that’s a finding, and you know what to do when you have this type of finding during a review of your third-party service providers, right? Well, that’s a topic for another article.
Need more insightful guidance for your audit, GRC, or technology risk management programs? Contact Cential today.