Gartner analysts said that more than 85% of organizations will embrace a cloud-first principle by 2025 and will not be able to fully execute their digital strategies without the use of cloud-native architectures and technologies. With this ever-increasing move to a cloud environment, do you know what complementary subservice organization controls are, how to distinguish between a vendor and a subservice organization, and how to monitor your subservice organizations and their related CSOCs? We will cover all of this in this week’s blog post.
What Are Complementary Subservice Organization Controls (CSOCs)?
Complementary subservice organization controls (CSOC) are controls that the management of the service organization assumes, in the design of the service organization’s system, will be implemented by the subservice organizations and are necessary to achieve the control objectives/trust services criteria stated in management’s description of the service organization’s system.
What Is an Example of a CSOC?
Let’s say that your company provides software as a service (SaaS) to its customers (your company is the service organization) and that your company’s infrastructure is hosted in a service provider’s cloud environment (e.g., Amazon Web Services or Google Cloud Platform). In this example, your cloud environment provider is the subservice organization (key vendor). Your company will likely expect the cloud environment subservice provider to have certain physical and environmental controls in place to address the risks to your company’s ability to continue to provide its software services to your customers. For example, you may expect that the subservice cloud provider has a CSOC that states that the subservice provider has a business continuity plan and will perform an annual disaster recovery test to ensure that they can continue to provide your cloud environment, in the case of a natural disaster.
As a service organization going through a SOC examination (so that you can provide a SOC report for your customers), you do not need to outline each and every vendor in your system description (section III of your SOC report). See more about carve-out vs. inclusive audit methods here. In fact, out of the multiple vendors your company may use, only a few of your vendors may actually be considered a subservice provider.
How To Distinguish A Vendor From A Subservice Organization
The key here is that all subservice organizations are a vendor, but not all vendors are subservice organizations. What sets a subservice organization apart from a vendor is that subservice organizations provide functions that affect the delivery of services that you provide to your customers, and whose controls are necessary, in combination with your company’s controls, to achieve your company’s service commitments and system requirements.
Using the cloud environment/hosting example above, if a natural disaster wiped out a data center and your cloud environment/hosting provider was unable to bring your system back up in a separate location, your SaaS would not be available for use by your customers and you may not be able to meet your service commitments. Thus, the cloud provider would be considered a subservice organization. If however, your cloud environment was available as normal, but the vendor who provides your company with instant messaging capabilities were not available, you would likely still be able to provide services to your customers, meet your services commitments, and maintain your system requirements.
Who is Responsible for CSOCs?
The short answer is that the service organization (your company) is responsible for ensuring CSOCs are in place and operating effectively. While CSOCs are controls that are designed by and operating at your subservice organization/provider, as part of your periodic risk assessment process (after you identify your subservice organizations/providers and distinguish them from vendors), you should identify the expected CSOCs that should be in place to address your company’s identified risks. Once you have determined who your subservice providers are and which CSOCs you require to be designed and operating effectively, you need to determine the monitoring activities your company will put in place to gain assurance over the identified CSOCs.
How To Monitor Subservice Organizations & CSOCs
There are multiple methods that your company can choose from in order to monitor a subservice organization.
Examples of monitoring activities from the AICPA’s AT-C 320 .A27 include:
- “Reviewing and reconciling output reports.”
- “Holding periodic discussions with the subservice organization.”
- “Making regular site visits to the subservice organization.”
- “Testing controls at the subservice organization by members of the service organization’s internal audit function.”
- “Reviewing type 1 or type 2 reports on the subservice organization’s system.”
- “Monitoring external communications, such as customer complaints relevant to the services by the subservice organization.”
Not every vendor will agree to all or some of the activities above (remember, they will likely have multiple customers, all of which will want to perform some level of monitoring activities). The monitoring activity(ies) that your company chooses to employ, will depend on multiple factors including your company’s internal resource constraints (financial resources to support travel, people resources to conduct audits, etc.), the contract that you have in place with the subservice organization (i.e., right to audit), alternative monitoring activity options, etc.
The most common practice is to obtain and review your subservice organization’s SOC report. Similar to how each and every vendor does not need to be included in your company’s SOC report, each and every CSOC in your subservice organization’s SOC report does not need to be documented in the system description section of your SOC report. In fact, if you choose the carve-out method, you only need to cover general types/broad categories of controls, but not the detailed processing or controls performed at the subservice organization. Not only do the CSOC control details not need to be included in your company’s own SOC report, but not every control listed in your subservice provider’s report may be applicable to your company’s service commitments or system requirements. The review of a SOC report should focus on the relevant services provided by the subservice provider in addition to the related CSOCs identified from your internal risk assessment.
What is a Cloud Environment SOC Report? Does One Exist?
As more and more clients’ environments migrate into the cloud, a common question we hear is, “What is a cloud environment SOC report?” The answer to this question is that there is no “cloud environment” SOC report. The AICPA has established five types of System and Organization Controls (SOC) service offerings that CPAs may provide in connection with system-level controls of a service organization:
- SOC 1® – SOC for Service Organizations
- SOC 2® – SOC for Service Organizations
- SOC 3® – SOC for Service Organizations
- SOC for Cybersecurity
- SOC for Supply Chain
If your organization is using a cloud subservice organization/vendor, the most common report that a subservice organization will have for you to review is a SOC 2 report. Check out the articles listed below to learn more about each of these SOC offerings:
- What is a SOC 1 Report? Expert Advice You Need to Know
- What is SOC 2? An Expert’s Guide to Compliance
- SOC 2 vs SOC 3 Reports: What is the Difference?
- Reporting on an Entity’s Cybersecurity Risk Management Program and Controls (SOC for Cybersecurity)
- Is There Value in Obtaining a SOC for Supply Chain Report?
Evidencing The Monitoring Activities
One key element in reviewing a subservice SOC report is documenting the process you went through in performing this review. Documentation could include the list of all CSOCs contained in the subservice provider’s report (i.e. all of the controls for relevant services) and a simple yes or no as to whether or not your company considers them as a relevant CSOC or not. For relevant CSOCs, you would want to document whether or not there were any exceptions/issues to those CSOCs with a yes or no. You would want to also tie each relevant control to the related trust services criteria so that in case there was an issue you could point to additional, related controls to meet the criteria.
While this post focused on CSOCs, similarly, when performing and documenting a review of subservice organizations and related CSOCs, you could also review and document any complementary user entity controls (CUECs) listed in your subservice organization’s SOC report at the same time.
CSOC Summary
As companies continue to expand out into the cloud environment and use other types of vendors to ultimately provide services to their customers, understanding which vendors are subservice providers and formally monitoring those service providers and their related CSOCs will be key in ensuring that they can continue to provide services to their customers, meet their services commitments, and maintain their system requirements.
If you have questions about SOC 1 services or SOC 2 services or the inclusion of CSOCs within service auditor reports, please contact us.
Linford & Co., LLP, founded in 2008, is comprised of professional and certified auditors with specialized expertise in SOC 1, SOC 2, HIPAA, HITRUST, FedRAMP and royalty/licensing audits. Our auditors hold CPA, CISA, CISSP, GSEC licenses and certifications. Learn more about our company and our leadership team.