SOC 2 - Vendors vs. Subservice Orgs

In #soc2 (and also #soc1), determining?if your #vendor is a #subservice organization is kind of a big deal.?The 2022 AICPA SOC 2 guide describes a subservice organization as:

“A vendor used by a service organization that performs controls that are necessary, in combination with controls at the service organization, to provide reasonable assurance that the service organization's service commitments and system requirements were achieved.”

English please??Go with me on this.

To clarify the AICPA quote, let’s use an example.?In a previous article, I discussed the importance of commitments and system requirements in SOC 2 (and the flow down of commitments>categories>criteria>controls).?When using the AICPA SOC 2 criteria for security, one of those criteria (CC6.4) is the physical and environmental protection of customer data.?

For our example, let's say a SaaS-based organization is committing to “protection of customer data from misuse, unauthorized access, or loss”. They are ultimately responsible for having a complete control environment that meets the commitment. During the audit, they are evaluated for meeting the commitment by the auditor using the SOC 2 security criteria.

Part of example SaaS company's control environment includes using a co-location hosting provider (e.g., AWS, Azure, GCP) to host the application. Because example SaaS has effectively outsourced meeting the CC6.4 criterion to the hosting provider, the hosting provider is considered a subservice organization to meet the commitment of protection of data.

Another way to look at it is: SaaS company cannot meet CC6.4 (and, in turn, their commitment to protection of data) without the hosting provider, so the hosting provider is a subservice organization.?

Still with me??Good.?

Let’s get a little more detailed on how to draw the line between vendor and subservice. Now, understanding there are exceptions and outliers in any situation (I’m looking at you CPAs ??), for the most part tools/software being used are not going to cause the vendor to rise to the level of a subservice organization. It depends on how management uses those tools and what controls they have around the tool.

To expand: if SaaS’ monitoring controls of the vendor's tool are enough to provide reasonable assurance that SaaS’ commitment was achieved, the vendor is likely to stay a vendor.?

Example: an infrastructure availability tool is being used by example SaaS’ for the IaaS environment in AWS. Example SaaS has security personnel that monitor the data from the tool to make sure the environment is available to meet a 99.99% availability commitment. Those personnel are using a tool for their monitoring purposes, and they have controls in-house for using the information provided by the tool. Thus, even though the tool provides valuable information for availability, the tool vendor remains a vendor and is not a subservice organization.

STILL with me??Fair enough.

But what about more service-based vendors? (Think MSPs or specialists like pen testers or vulnerability assessment firms). This is also going to depend on the level and type of service provided.

Say an MSP is acting on behalf of example SaaS' security department. The MSP regularly (yes, frequency also plays a role in determining vendor vs. subservice) helps with things like access permissions, security events, vulnerabilities, etc.?The MSP services include controls that would be a necessary part of the example SaaS control environment when measuring against the SOC 2 security criteria (then, in turn, determines if commitments were achieved). So, our example MSP here would be considered a subservice organization.

Another? Sure. Example SaaS uses a pen test vendor to perform their annual pen test. Example SaaS management gets the pen test report and reviews it, discusses, then acts within their own controls based on the pen test results. Because this is infrequent, and management has their own controls to just use the pen test info, this vendor would not be a subservice organization.

Other things to note once you have determined that you do have a subservice organization:

• Inclusive or carve-out method of reporting?(The majority of SOC 2 subservice orgs are reported under the carve-out method, if you want to know more or have questions, contact me!)
• They are mentioned in engagement letters, management’s assertion, auditor’s report, and rep letters
• You have to figure out what Complementary Subservice Organization Controls (CSOC) are to be disclosed in the system description

The #vendormanagement program of the client/service organization needs to be a bit more in-depth by reviewing the subservice org reports to determine if the CSOCs are designed and working correctly

OK, clear as mud??YOU ARE NOT ALONE!?Vendor vs. subservice org is one of the most difficult areas of getting a SOC engagement executed. It is probably the biggest area that needs to be looked at on a case-by-case basis and where everyone’s favorite answer of “it depends” pops up the most. Make sure that both client and auditor have in-depth discussions to plan accordingly.

For example, vendors that may be a subservice org in company A may not be in company B because of how they are used. Or, after having up front planning discussions, during control testing a previously thought vendor is determined to be a subservice org. These things happen, just know it’s OK and you’ll get through it!

Need more information on vendors vs subservice orgs? Inclusive vs carve-out? Requirements in SOC 2 once you have a subservice org? Or just want to chat? Feel free to reach out to me in a message and we can talk! ?As always, let me know in the comments if there are any topics within here where you would like more detail!

If you need any help with peer review, establishing a SOC program, or other SOC-related info, give me a shout!?I’m happy to help service orgs, CPAs, firms, or anyone that needs additional information and guidance for the SOC space.