Services
Services
SOC & Attestations
SOC & Attestations
Payment Card Assessments
Payment Card Assessments
ISO Certifications
ISO Certifications
Privacy Assessments
Privacy Assessments
Federal Assessments
Federal Assessments
Healthcare Assessments
Healthcare Assessments
Penetration Testing
Penetration Testing
Cybersecurity Assessments
Cybersecurity Assessments
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
ESG & Sustainability
ESG & Sustainability
AI Services
AI Services
Industry Solutions
Industry Solutions
Cloud Computing & Data Centers
Cloud Computing & Data Centers
Financial Services & Fintech
Financial Services & Fintech
Healthcare
Healthcare
Payment Card Processing
Payment Card Processing
US Government
US Government
Higher Education & Research Laboratories
Higher Education & Research Laboratories
About Us
About Us
Leadership Team
Leadership Team
Careers
Careers
Corporate Social Responsibility
Corporate Social Responsibility
Strategic Partnerships
Strategic Partnerships

The Difference Between Subservice Organizations and Vendors

SOC Examinations

When you consider your spice cabinet, it probably contains a lot of different things—salt, pepper, garlic powder, paprika, etc.

But what turns a simple spice in your kitchen into an ingredient you actively use in your prepared food? How much you need? Where it goes?

If you want edible food, you’ve got to use spices in the right way, and there’s a similar correlation in the differences between vendors and subservice organizations as relevant to your SOC 2 examination.

As you probably well know, many organizations often engage third-party vendors to provide services. When those services have the aim of helping that organization achieve its service commitments, that’s where the relevance to SOC assessments comes into play.

Whether they’re helping you meet SOC 1 objectives or fulfill applicable SOC 2 trust services criteria, it’s important to include the use of vendors appropriately when including them in your examination.

But therein lies the confusion—what is appropriate? Is a vendor just a vendor, or is it a subservice organization? How to know?

In this article, we will establish the differences in the definition of the two and how they’re included in SOC audits. Having done service organization audits with clients for two decades now, we’re well-versed in the distinctions and how organizations should include them in their examinations.

Read on to gain a better understanding of where your vendors and subservice organizations fit into your SOC projects.

 

What is a Vendor?

A vendor is an organization that provides you with services. 

You probably contract with several organizations for services to support your services or product, but here’s the rub: if you don’t rely on their controls to achieve your service commitments and system requirements, meet your SOC 1 objectives, or fulfill applicable SOC 2 trust services criteria, they are simply a “vendor.”

Now that’s not to say that a lack of reliance means you’re not still vulnerable because of your involvement with your vendors. To secure your environment, you should implement controls to continuously monitor vendors for compliance with your requirements. Such controls can include:

  • Performing a vendor risk assessment at least annually;
  • Assessing the performance of vendors periodically;
  • Requesting a SOC for Supply Chain report for any software product vendors
  • Establishing communication and resolution procedures for issues related to vendors; and
  • Implementing a vendor management tool with the capability to:
    • Inventory and label vendors for criticality;
    • Manage the onboarding / offboarding of vendors; and
    • Monitor the completion of vendor compliance requirements and activities. 

You might even require vendors to sign an NDA / confidentiality agreement and/or complete security and privacy awareness training, should you so choose.

We’re not just telling you to implement these controls for your security—they’re also necessary for you to meet SOC 2 Common Criteria (CC) 9.2, which says:

The entity assesses and manages risks associated with vendors and business partners.

What is a Subservice Organization?

If a vendor’s controls, in combination with your organization’s controls, are necessary to achieve your service commitments and system requirements, to meet your SOC 1 objectives, or to fulfill applicable SOC 2 trust services criteria, then the vendor is classified as a “subservice organization,” and therein lies the difference between the terms.

Say you engage someone for cloud-based hosting services. That vendor would already need to be maintaining various controls for such a service—e.g., physical security controls, environmental security controls, etc. Despite the importance of that service in meeting all your commitments or SOC obligations, it would be impractical for you to maintain such things for them, and so you would rely on them to do so.

That reliance is what would characterize them as a subservice organization rather than just a vendor.

Similar to vendor monitoring, it’s also important that you review the subservice organization’s controls as well (i.e., review their SOC report). 

Is Your Vendor a Subservice Organization?

When deciding whether a vendor would be classified as a subservice organization or not, ask the following questions:

  • Are the controls of said vendor, in combination with your controls, necessary for you to achieve your service commitments and system requirements, meet the SOC 1 objectives, or fulfill the applicable SOC 2 trust services criteria? 
  • Is the description of the vendor’s services necessary for your customers to understand your system as it relates to the applicable trust services criteria? 

If the answer to either question is yes, then that vendor is a subservice organization.

You can also think of it like this:

  • If your controls alone are sufficient to achieve your service commitments and system requirements;
  • If they’re enough to meet your SOC 1 objectives or fulfill the applicable SOC 2 trust services criteria; and
  • If you have sufficient vendor monitoring controls in place, then the vendor would not be classified as a subservice organization.  

Example of a Vendor

If an organization provides you with monitoring services, but you are responsible for reviewing the reports or alerts for unusual or suspicious activities or events, then that third party is just a vendor.

Because you’re responsible for that control activity and do not rely on the vendor, they would not be considered a subservice organization.

Common examples of vendors include:

  • Utility companies;
  • Accounts payable;
  • Sales and marketing; and
  • Other third parties used primarily for internal operations. 

Example of a Subservice Organization

If an organization provides you with data center services, they would be responsible for the related infrastructure, and therefore, they’d also be responsible for the physical and environmental security controls over said infrastructure. 

Another example would be a data, hardware, or document destruction company that is necessary to fulfill a service commitment to purge or destroy data and information. Because you would rely on them for that, they would classify as a subservice organization. 

How to Report Your Vendors and Subservice Organizations

Once you’ve classified all your third parties, the next step is figuring out how to report them in your SOC examination.

  • When it comes to vendors, it’s like we said before—you would need to define your monitoring controls in the report under CC9.2 to meet the SOC Common Criteria for that control area. 
  • With subservice organizations, your reliance on their controls makes things more complicated because you’ll also need to decide whether to carve them out of your SOC report or whether to include them. There are important considerations to make for both methods, which we outline in detail within our article here. 

That being said, in many cases, if not all, subservice organizations are essential to your delivery of services to customers. Regardless of which method you choose, you must disclose the nature of the services provided by the subservice organization in your SOC report.

If you eventually opt to carve out your subservice organizations, your SOC report should still define any controls expected to be implemented at the subservice organization—or complementary subservice organization controls. 

Next Steps for Your SOC Examination

When you’re cooking, there are factors to consider when using spices—at least, if you want your meal to be edible. The same trajectory that transforms a mere spice into an important ingredient is paralleled when it comes to your vendors and subservice organizations within your SOC report. 

To summarize, the main difference between them is that:

  • A vendor is an organization that provides you services but whose controls are not necessary for you to achieve your service commitments and system requirements, to meet your SOC 1 objectives, or to fulfill the applicable SOC 2 trust services criteria, presuming you have sufficient vendor monitoring controls in place.
  • Conversely, a vendor is instead classified as a subservice organization when the controls at the vendor are necessary, in combination with the service organization’s controls, to achieve the same. 

Categorizing your third parties is the enormous first step toward discerning their role within your SOC examination, and with this knowledge, you’re better positioned to easily do that.

But SOC audits require a lot of decision-making. So, to help further streamline your process, check out our other content on the various facets of these audits:

Of course, as you get deeper into the particulars, you may prefer to speak with someone directly to get your questions answered. If that’s the case, please feel free to reach out to us here at Schellman. Our team would be happy to set up a conversation to address any lingering concerns regarding SOC reporting that you may have.

About Erica Green

Erica Green is a Manager with Schellman. Prior to joining Schellman in September 2019, Erica worked as an IT auditor in a regional firm specializing in SOC 1 and SOC 2. As a Senior Associate with Schellman, Erica Green's focus is primarily in the SOC service line.