A service organization may have a number of vendors and subservice organizations engaged to assist it in meeting its objectives or achieving the service commitments to its user entities, along with the system requirements necessary to do so. This article will explain the difference between a vendor and a subservice organization and provide some tips on how the service organization should consider assessing and managing the risks associated with them. Additionally, this article will touch upon the system and organization controls (SOC) reporting methods for disclosures related to a subservice organization, as well as complementary subservice organization controls (CSOCs).
What Is a Vendor?
A vendor provides goods and/or services to another organization. For a vendor not to be further distinguished as a subservice organization, the controls at the vendor would not be relied upon by the service organization to meet its SOC 1 objectives or achieve its SOC 2 trust services criteria covering the service commitments and system requirements with its user entities.
For example, many times a vendor may provide personnel to help carry out duties for the service organization where they may be understaffed or not have the resources or skills necessary to meet demand. In this manner, the service organization internally manages the activities performed by the vendor’s individuals and does not rely upon the vendor to do so. The service organization may require the vendor’s individuals to sign a non-disclosure agreement and to complete security awareness training prior to granting access to the service organization’s system.
For this example, the service organization is not relying on the controls at the vendor to meet its SOC 1 objectives or achieve its SOC 2 trust services criteria covering its service commitments and system requirements with its user entities. The service organization is relying upon its own system of internal controls to directly manage the vendor’s personnel performing assigned work, and does not rely on any of the vendor’s controls individuals performing work assigned, and none of the vendor’s controls are relied upon. Therefore, this type of vendor would not be considered a subservice organization.
What Is a Subservice Organization?
A subservice organization performs outsourced services under its own system of internal control necessary to assist a service organization in fulfilling its customer service agreement and achieving its compliance requirements. In many cases, it is not feasible for the service organization to perform all the controls necessary to meet its SOC 1 objectives or achieve its SOC 2 trust services criteria covering its service commitments and system requirements with its user entities. When this occurs, certain functions of the overall system of internal control are outsourced to a third party, and those activities performed are not directly managed by the service organization. However, those activities are relevant to the achievement of its compliance requirements. Here, the service organization is relying upon the controls at the subservice organization because the functions executed by the subservice organization, along with its own control activities, impact the service organization’s service delivery to its user entities. Subservice organizations are critical to the success of the service organization and to achieving the service organization’s compliance requirements.
A typical example of the use of a subservice organization is for the utilization of cloud-based hosting services. Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) are typical service providers for this type of outsourced service used by many software-as-a-service (SaaS) organizations. With this outsourced service, the service organization is relying upon the controls operated by the subservice organization to perform certain functions in conjunction with its own control activities that support its services provided to its user entities and to achieve its compliance requirements. For this, the service organization should be reviewing the control reports when they are made available, such as the subservice organization’s SOC report. The SOC report should be reviewed for the control design and operating effectiveness of the controls in place at the subservice organization to determine that the subservice organization’s controls can be relied upon to support its overall system of controls in place to provide its services to user entities.
When reviewing the SOC report from the subservice organization, the three main areas of the report to focus on are the opinion, what (if any) deficiencies were identified in the testing performed, and what complementary user entity controls (CUECs) are needed to be in place by the service organization in order for the overall system of controls to be functioning effectively.
If the opinion is unqualified, then it is a clean opinion with no material deficiencies. If the opinion is qualified, then the reasons for the qualification will need to be investigated and evaluated by the service organization to determine the potential impact on its service delivery to its user entities or compliance requirements.
If there are any deficiencies identified in the SOC report, the service organization will need to evaluate the significance of the deficiency to its service delivery or compliance requirements. The service organization will also need to determine whether it has any mitigating controls to reduce the risk of the deficiency to its service delivery to user entities or its compliance requirements.
If the subservice organization has identified any CUECs in its SOC report, then the service organization will need to determine whether those controls are in place internally in order for the overall system of controls to operate effectively. A typical CUEC requires that the user entity grant access to only those individuals who require such access to perform its job responsibilities.
Key Points for a Vendor Management Policy
When engaging third-party vendors, an organization should maintain a vendor management policy to describe the expectations for the selection, monitoring, and management throughout the life cycle of vendor relationships. Some factors to consider for inclusion within the policy include the following:
- Roles and responsibilities should be defined and cover who owns the vendor relationship, who is responsible for vendor onboarding and contract management, and who is responsible for vendor due diligence and ongoing risk assessments.
- Vendor onboarding should be described to properly vet vendors, require security questionnaires to be completed as applicable, and to make sure critical clauses are incorporated within agreements, such as confidentiality, data handling, audit rights, termination, and security incident reporting, prior to vendor approval and onboarding.
- Vendor monitoring should be covered to set expectations around the performance and frequency of the vendor review and vendor risk assessment.
- Vendor termination procedures should be documented around steps to take when ending the vendor relationship, handling data to be either returned or destroyed, and revoking system access.
- Documentation and reporting should also be considered to make sure that processes are auditable and that documentation is retained for the necessary length of time to meet compliance requirements.
Considerations for Vendor Risk Management
Service organizations should perform a vendor risk assessment at least annually to assess and manage risks associated with their vendors. The initial step in performing a vendor risk assessment is to obtain a list of vendors utilized and categorize them according to the products or services provided. An evaluation of the products or services provided should be assessed to determine the likelihood and impact on the organization if the quality of the products or delivery of services were not acceptable.
Doing this should help to determine which vendors are non-critical and those that are critical to the service organization for meeting their SOC 1 objectives or achieving their SOC 2 trust services criteria covering their service commitments and system requirements. Vendors who are deemed critical to the organization should undergo a due diligence process before they are onboarded to make sure the quality of their products or service delivery and data security adequately meets the service organization’s needs. Thereafter, the vendor should be evaluated at least annually to make sure that the quality of the products or services delivered and data security continue to be satisfactory.
The manner in which a service organization performs a review of its critical vendors to address the risks posed in the vendor relationship varies based on the nature or risk of the products or services provided. For example, the service organization may directly monitor the activities of the vendor, review monthly service level agreement reports, monitor customer reviews, or review controls reports that are made available. In any case, the service organization should be sure to establish specific requirements for the product specifications or scope of services provided, roles and responsibilities, compliance requirements, and service levels.
What Are Reporting Methods for Subservice Organizations?
It may not be feasible for the control objectives or the SOC 2 trust services criteria to be covered solely by the service organization. As a result, the controls of the service organization for the services provided may cover only a portion of the overall controls to meet its compliance requirements. Each subservice organization’s complementary subservice organization controls (CSOCs), as well as each user entity’s complementary user entity controls (CUECs), must be evaluated in conjunction with the operating effectiveness of the service organization’s controls.
The service organization takes into account the related CSOCs expected to be implemented at the subservice organization. It also reports on them using either the Inclusive or the Carve-Out reporting method. In addition, the service organization identifies the CUECs expected to be implemented by the user entity. The service organization controls, CSOCs, and CUECs cover off the overall system of controls for the services being provided.
Inclusive Reporting Method
When the inclusive reporting method is used for subservice organizations, the service organization discloses the specific controls at the subservice organization in combination with its own controls. These combined controls provide reasonable assurance for meeting the SOC 1 objectives or the SOC 2 trust services criteria covering the service commitments and system requirements for their delivery of services. An inclusive reporting method is most useful when the subservice organization does not already have a controls report (e.g., SOC report) of their own readily available, or when the services relied upon by the service organization are extensive. For this method of reporting, the service auditor will include the controls at the subservice organization as being in scope for the examination and test them for their design and operating effectiveness.
Carve-Out Reporting Method
When the carve-out reporting method is used for subservice organizations, the service organization does not disclose the specific controls at the subservice organization. Instead, it discloses the types of controls assumed to be implemented by the subservice organization that are necessary in combination with the controls at the service organization. These combined controls provide reasonable assurance for meeting the SOC 1 objectives or the SOC 2 trust services criteria covering the service commitments and system requirements for their delivery of services. A carve-out reporting method is useful when the subservice organization has its own controls report (e.g., SOC report). The controls at the subservice organization are not in scope for the service auditor’s examination when the carve-out reporting method is used.
CSOC Considerations
When the service organization chooses the carve-out method of reporting for its subservice organization, the types of complementary subservice organization controls (CSOCs) assumed to be implemented by the subservice organization are disclosed within their own SOC report. A couple of typical CSOCs for a subservice organization providing cloud-based hosting services, for example, are responsibility for providing physical security as well as environmental protection over the production servers.
Key Takeaways: Differentiating Subservice Organizations & Vendors Successfully
A service organization may engage various types of vendors to assist them in meeting their SOC 1 objectives or SOC 2 trust services criteria covering their service commitments and system requirements. When business functions are outsourced and controls are relied upon as with a subservice organization, the vendor relationship is critical to the success of the service organization in meeting its SOC 1 objectives or SOC 2 trust services criteria covering its service commitments and system requirements. In contrast, a regular vendor’s controls are not relied upon in the service organization’s control environment to meet its service delivery and compliance requirements.
Subservice organizations are integral to the service organization’s overall system of controls for its service delivery to its user entities, and their performance should be assessed at least annually. As such, the nature of the services provided by the subservice organization must be disclosed in the service organization’s own SOC report through either the Inclusive reporting method or Carve-out reporting method, along with the CSOCs that are being relied upon.
Linford and Company performs SOC 1, SOC 2, HIPAA, HITRUST, ISO/IEC 27001:2022, and FedRAMP audit and compliance services, among others. Please contact us if you would like to learn more about any of the services that we provide.
This article was originally published on 6/16/2020 and was updated on 10/29/2025.
Becky McCarty has extensive experience in internal controls, audit, and advisory services. She specializes in SOC, HIPAA, and ISO/IEC 27001:2022 examinations for Linford & Co., LLP. Becky completed a Bachelor’s degree in Business Administration (Accounting) and a Master of Science degree in Management Information Systems. She worked 6 years with KPMG LLP commencing in 1999, worked many years in the energy industry, and joined Linford & Co., LLP in 2018. Becky also served 9 years on the Board of Directors for a home healthcare nonprofit. She works closely with clients so that the examinations are performed efficiently and with minimal disruption while ensuring performance in accordance with professional guidance. She enjoys helping clients successfully achieve the requirements for their security compliance reporting needs.