“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?”
This message has become a more and more commonly sent email from risk management departments during third-party risk assessment activities.
Part of a robust third-party risk management process includes obtaining and reviewing SOC reports for third-party vendor candidates prior to procuring their services. (Yes, better late than never, but we’re talking ideally here.)
Reviewing the report consists of several crucial steps, including evaluating the system description and checking for subservice organizations, among others. Three particular points of emphasis that we often see misunderstood by reviewers include:
- Understanding the scope and period of the report.
Understanding the scope of the report involves identifying the type of SOC 2 report, whether it is a Type I or Type II. A Type I report describes the vendor’s system and the suitability of the design of controls at a specific point in time, while a Type II report includes the same descriptions but also evaluates the operating effectiveness of those controls over a period. Speaking of the period, It is important to determine the time frame covered by the report to ensure it aligns with your organization’s assessment timeline. Additionally, review the Trust Services Criteria (TSC) included in the report, which could cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. Understanding which criteria are addressed will help you assess whether the vendor’s controls meet your specific compliance and security requirements. - Requesting and reviewing the SOC report to ensure it’s presented with an unqualified opinion from the auditor.
An “unqualified opinion” is essentially getting an A+ for their controls being described fairly and accurately, and operating effectively for the relevant period. Further due diligence would include reviewing the attestation firm’s testing procedures and the detailed results of testing within controls, not simply trusting that a lack of significant exceptions led to an unqualified opinion. - Using the SOC report to determine whether their organization has accounted for the Complementary User Entity Controls (CUECs) and has either implemented or plans to implement those controls.
Take Google Drive for example. It’s considered a “User Entity,” which utilizes a service organization, and CUECs are the controls that reside at that User Entity. For a cloud application like Google Drive, a User Entity must ensure they remove terminated employees’ access to the application. Suppose a terminated employee retained that access and accessed sensitive information post-termination. In that case, that’d be a failure of control on the User Entity’s behalf, as Google does not own that control responsibility.
Now, let’s discuss how these steps come into play when a Service Organization is providing SAAS (Software as a Service) and a SOC 2 report is necessary.
For SOC 2, the control areas are categorized using Trust Services Categories (TSCs). The available 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 to and 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.
- Privacy—Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives.
Not all TSCs must be included, except for Security, which must be included in all SOC 2 reports. The issuing SOC 2 auditor performs that scoping. To this point, for a business process 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.
If an auditor were to audit the business process, they could get assurance that the service organization has an effective control environment from reviewing the SOC 2 report; however, they would still need to test the CUECs at the user entity level to verify those are in place and operating effectively to understand the effectiveness of all the controls for the entire business process.
What about instances where a company providing SAAS uses another Service Organization for its server infrastructure?
For example, Imaginary Software provides a subscription accounting application hosted on Amazon Web Services’ servers. In this instance, three entities are involved.
Situations like these are where things get more complicated. In the confusion, we see Service Organizations try to pass off the SOC 2 report of their Service Provider (of which they are actually a User Entity) as covering all of the risks that they introduce to the process, and therefore introduce to their user entities.
This confusion is a problem for multiple reasons.
The first problem: there is no indication of their CUECs and whether they are set up and operating effectively.
The second (more important) problem: the controls (categorized into TSCs) for the additional services they are providing aren’t covered by that SOC report.
In the Imaginary Software example, storage 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 that Amazon provides for availability would likely benefit the User Entity.
However, the User Entity would have no guarantee of the processing integrity of their data. Imaginary Software’s processing could be totally inaccurate, and the User Entity would never know because the provided SOC report was for Amazon, not Imaginary Software—the one doing the processing.
So, how does this vendor risk management actually 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.
- Test the CUECs for that SOC 2 report at the User Entity.
The answer: all the above. (That’s a lot of work! And what if there’s a fourth service organization—or, worse yet, a 5th?)
Fortunately, it doesn’t work this way. Instead, the service organization will either take the inclusive or carve-out method for their subservice organizations.
In the inclusive method, the service organization reveals the specific controls used by the subservice organization along with their own controls. This combined disclosure provides reasonable assurance that they meet the SOC 1 objectives or the SOC 2 trust services criteria, ensuring their service commitments and system requirements are fulfilled.
On the other hand, the carve-out method is when the service organization does not detail the specific controls of the subservice organization but instead discloses the types of controls assumed to be implemented by the subservice organization, which, together with the service organization’s controls, provide reasonable assurance for meeting the SOC 1 objectives or the SOC 2 trust services criteria for their service commitments and system requirements.
(They also should be testing Imaginary Software’s CUECs related to Amazon’s services before issuing the SOC 2 covering Imaginary Software’s services.)
Vendors vs. Subservice Organizations
While we’ve been discussing vendor risk management at length, we feel this is an important time to dive deeper into a slightly different yet closely related topic: subservice organizations.
In times when it’s not feasible for the service organization to perform all the controls necessary to meet their SOC 1 or SOC 2 objectives, the assistance of a subservice organization to execute the necessary functions and controls for the vendor to meet the necessary compliance requirements.
In this case, a service organization would need to provide a CSOC—Complementary Subservice Organization Controls—report that assesses the controls within its organization but excludes controls managed by the subservice organization.
The provided CSOC report will demonstrate that, while certain aspects of their service are managed by a third party (the subservice organization), their own controls and processes remain effective and compliant with relevant standards. This helps clients understand the division of responsibility and the reliability of the vendor’s internal controls.
So what does this all mean to an IT Auditor or Risk Management professional?
Well, suppose a Service Organization hands you the SOC 2 report for another Service Organization for which they are actually a User Entity. In that case, you can kindly send them this article and request that they provide a valid SOC 2 report that covers their services.
If they can’t provide it, that’s a finding, and risk management leadership needs to decide how to proceed. They could ask the organization for audit rights to thoroughly audit the necessary systems themselves, look for a different service provider, or take a different approach.If your organization needs more insightful guidance for your GRC or technology risk management programs, contact Cential today.