Do Your Subprocessors Need Their Own SOC 2?

No. Nothing in the SOC 2 description criteria requires a vendor you rely on to hold its own SOC 2 report, and nothing in the GDPR requires a subprocessor to hold one either. What your SOC 2 does require is that you disclose the vendors whose controls your commitments depend on, and that you operate controls to monitor them. The AICPA's DC section 200 lists "Inspecting type 2 SOC 2 reports on the subservice organization's system" as one item in a list of monitoring controls that "may include a combination of the following," next to site visits, internal audit testing, reconciling output reports and evaluating performance against service levels. The contrarian version: a vendor with no report is not a gap in your SOC 2. A vendor you rely on and do not monitor is.

The question usually arrives as "our vendor has no SOC 2, what now," and the answer depends on a distinction most teams have never had to make: whether that vendor is a subprocessor, a subservice organization, both, or neither. This article draws the distinction from the texts that define the two words, sets out what the report actually needs from you when a vendor has no report, and lists the evidence each option produces.

Key takeaways

• Subprocessor is a privacy-law word and subservice organization is a SOC 2 word. A vendor can be one, both or neither, and the obligations attach to the classification rather than to the vendor.
• Under the carve-out method your description must identify the vendor, the types of controls you expect it to perform, and your own controls for monitoring it. None of those three is "the vendor holds a SOC 2 report."
• DC section 200 names a vendor's Type 2 SOC 2 report as one monitoring control among several. Internal audit testing, site visits, output reconciliation, service-level reviews and monitoring complaints are on the same list.
• Under the GDPR, a processor "shall not engage another processor without prior specific or general written authorisation of the controller," and it "shall remain fully liable to the controller" for that other processor. The mechanism is contract, not attestation.
• The failure that produces a revision cycle is not a vendor without a report. It is a description that assumes controls at a vendor and a monitoring programme that never checks whether they exist.

Two words from two regimes

Subprocessor comes from data protection law. The GDPR does not use the word itself; it describes the relationship. Article 28(2) says "The processor shall not engage another processor without prior specific or general written authorisation of the controller," and Article 28(4) says that where a processor engages another processor, "the same data protection obligations" set out in the controller's contract "shall be imposed on that other processor by way of a contract," and that "the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations." Those quotations are from the text as reproduced on gdpr-info.eu, a reference site operated by a data-protection consultancy; the authoritative text is the Regulation in the Official Journal. The subprocessor concept is about personal data, authorisation and liability, and its instrument is a contract. What is a data processing agreement covers that instrument.

Subservice organization comes from the AICPA description criteria, and the test is different. DC section 200 defines it 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." The same glossary defines a vendor as "An individual or business (and its employees) engaged to provide services to the service organization," and then says the quiet part: "Depending on the services a vendor provides ... a vendor might also be a subservice organization." Might. The test is whether the vendor performs controls your commitments cannot be met without, and our glossary carries the same definition: "a service organization used by another service organization to perform some of the services provided to user entities, where those services are likely to be relevant to user entities' internal control."

A cloud host that stores customer personal data and provides the physical and environmental controls your availability commitments depend on is usually both. An analytics tool that receives personal data but whose failure breaks nothing you promised is a subprocessor and an ordinary vendor. A hardware security module provider that touches no personal data but performs a control your confidentiality commitment relies on is a subservice organization and not a subprocessor. Deciding which of your vendors is a subservice organization, and choosing between carving it out and including it, is the ground carve-out or inclusive owns; this article starts after that decision is made.

What the report needs from you under a carve-out

The description criteria are specific about what a carve-out obliges you to write, and none of it is "the vendor has a report."

DC section 200 defines the carve-out method as one in which the subservice organization's system components "are excluded from the description of the service organization's system and from the scope of the examination. However, the description identifies (1) the nature of the services performed by the subservice organization; (2) the types of controls expected to be performed at the subservice organization 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; and (3) the controls at the service organization used to monitor the effectiveness of the subservice organization's controls."

Item (2) is the complementary subservice organization controls, which the same document defines as "Controls that service organization management assumed, in the design of the service organization's system, would be implemented by the subservice organization." The implementation guidance under DC7 adds that the description should indicate "that the related service commitments and system requirements can be achieved only if the CSOCs are suitably designed and operating effectively during the period addressed by the description." That is a disclosure about what you assumed, and it stands whether or not the vendor has a report.

Item (3) is where the vendor's report enters, and the guidance is explicit that it is one method. "Regardless of the method service organization management selects," DC7's guidance says, "the description would disclose controls designed to provide reasonable assurance that the service organization's service commitments and system requirements are achieved, which include controls that the service organization uses to monitor the services provided by the subservice organization. Such monitoring controls may include a combination of the following:" and the list that follows is:

• "Testing of controls at the subservice organization by members of the service organization's internal audit function"
• "Reviewing and reconciling output reports"
• "Holding periodic discussions with the subservice organization personnel and evaluating subservice organization performance against established service-level objectives and agreements"
• "Making site visits to the subservice organization"
• "Inspecting type 2 SOC 2 reports on the subservice organization's system"
• "Monitoring external communications, such as complaints from user entities relevant to the services performed by the subservice organization"

Read that list the way your auditor will. The vendor report is the fifth of six, it is introduced with "may include a combination," and every other item is something you do rather than something the vendor holds. The question your auditor asks is not "does the vendor have a SOC 2" but "what controls do you operate to know the CSOCs you assumed are real, and what is the evidence."

What to do when a vendor has no report

Five options, in rough order of how often they are the right answer. Each produces different evidence, and the evidence is what gets tested.

Monitor by another method on the DC 200 list. If the vendor will not or cannot produce a report, the description criteria already name the alternatives: your internal audit function tests the vendor's controls, you reconcile the vendor's output against what you expect, you hold periodic reviews against service-level agreements, you visit. Each of those is a control with an owner, a cadence and an artifact, and each is tested in your examination like any other control. For a small vendor performing a material control, a documented annual test by your own team is frequently a better monitoring control than a report would have been, because it examines the thing you rely on rather than the vendor's whole system.

Accept other independent evidence, and say what it covers. DC section 200's list does not mention any other framework's report or certificate, and we are not going to claim it does. What it does say is that the list is a "combination," and the operative test is whether your monitoring gives you a basis for the CSOCs you assumed. An independent report or certificate under another framework can be part of that basis if its scope covers the controls you rely on, and your monitoring control then has to include reading it for that scope rather than filing it. Our vendor risk management guide covers tiering vendors and matching assessment depth to the tier, and that programme is where this decision gets recorded.

Redesign so the vendor's controls are no longer necessary. If your commitments can be met by controls you operate, the vendor stops being a subservice organization and becomes a vendor, which is the DC 200 definition applied in reverse. Encrypting data before it reaches a provider so that the provider's access controls are no longer load-bearing for your confidentiality commitment is the common example. This is the option that removes the disclosure rather than satisfying it, and it is often cheaper than the monitoring it replaces.

Use the inclusive method. The vendor's controls come inside your description and your auditor's testing, which means the vendor participates, provides its own assertion and aligns to your period. DC section 200 confirms that "controls at the subservice organization are subject to the service auditor's examination procedures" under this method. It is rarely available for a large provider and occasionally right for a small one you have leverage over; the carve-out article works through when.

Replace the vendor. Sometimes the honest conclusion of the monitoring exercise is that you cannot obtain a basis for the CSOCs you assumed, by any method, and that a vendor whose controls you cannot see is performing a control your customers were promised. That is a risk decision, not a SOC 2 decision, and the report is doing its job by surfacing it.

The privacy side has its own answer and it is simpler. Under Article 28(4), what a subprocessor needs is a contract imposing "the same data protection obligations" the controller imposed on you, and you remain "fully liable" for it regardless. No report is required, and no report would discharge the liability if it were.

The mistakes that actually cost a revision cycle

A CSOC list written as a wish list. The description says you assume the vendor performs eight categories of control, and nobody in your organization has ever seen evidence of five of them. The guidance says the description is presented in accordance with the criterion only "if the CSOCs are complete, accurately described, and relevant." Assuming a control you have no basis for is not a disclosure, it is a misstatement of your own design.

A questionnaire treated as a report. A vendor's completed security questionnaire is the vendor's own description of itself, unexamined. It can be an input to your monitoring control. It is not a substitute for one, and calling it "the vendor's assurance" in the description invites the question of who examined it.

Monitoring that files and never reads. Obtaining a report annually is not a control unless someone reads it against the CSOCs you assumed, checks the period, checks the scope covers the services you use, and acts on the complementary user entity controls it expects of you. How to read a SOC 2 report is the twenty-minute version of that check, and it applies to the reports your vendors give you.

Claiming the vendor's controls as your own. The commonest description error on this subject, and the carve-out article owns it: physical security and environmental controls listed among your controls when your cloud provider performs them. In fieldwork there is no evidence, and Section 3 gets rewritten late.

Where Top Floor fits

The work on this subject is a boundary exercise followed by a monitoring programme. Deciding which vendors are subservice organizations, drafting the CSOC disclosures so they describe controls you have a basis to assume, and then building the monitoring controls the description promises is what our SOC 2 readiness and audit and assurance engagements do on this front. Where the gap is that nobody owns the vendor register between audits, so reports go stale and questionnaires stand in for evidence, that is a programme problem and compliance as a service is the purchase. We manage the examination around an independent CPA firm; we do not perform it.

Against our own interest: a normal SaaS company on one major cloud provider whose report is current does not need help with this. Read the provider's report against your CSOCs once a year, record that you did, and act on the user entity controls it lists. The vendor-without-a-report problem is real, but it is usually one vendor, and it is usually solved by a documented test rather than a consultancy.

How to decide this week

Take your vendor list and, for each vendor, answer two questions in writing: does it process personal data on our behalf, and does our description rely on a control it performs. The first answer classifies it as a subprocessor or not; the second as a subservice organization or not. Most vendors will be one, both or neither in about a minute each.

For every subservice organization without a current report, pick one item from the DC 200 monitoring list, name the owner, set the cadence, and decide what artifact the control produces. If you cannot pick one, you have found a vendor whose controls you cannot see, and that is this week's actual decision.

For every subprocessor, confirm the flow-down contract exists and that the controller authorised the engagement in the form the contract requires. That is the whole GDPR obligation on this point, and a report was never part of it.

Frequently asked questions

Does my cloud provider need a SOC 2 report for my own SOC 2?

No. Your description must identify the provider, the types of controls you assume it performs, and the controls you operate to monitor it, and DC section 200 lists inspecting the provider's Type 2 SOC 2 report as one monitoring method in a list introduced with "may include a combination of the following." In practice large providers publish reports and reading one against the controls you assumed is the cheapest monitoring control available, so use it. But the requirement is that you monitor, not that the provider holds a report.

What is the difference between a subprocessor and a subservice organization?

Subprocessor is a data-protection classification: another processor engaged by your processor, which under GDPR Article 28 needs the controller's written authorisation and a contract imposing the same data protection obligations, with you remaining fully liable. Subservice organization is a SOC 2 classification from DC section 200: a vendor "that performs controls that are necessary, in combination with controls at the service organization," for your service commitments to be achieved. A vendor can be one, both or neither, and the obligations follow the classification.

Our vendor has no SOC 2 report. What should we do?

First confirm the vendor is a subservice organization at all; if your description does not rely on a control it performs, it is an ordinary vendor and belongs in your vendor risk programme rather than your system description. If it is, choose a monitoring control from the DC section 200 list that does not depend on a report: testing by your internal audit function, reconciling the vendor's output, periodic reviews against service levels, or site visits. Give it an owner, a cadence and an artifact, because it will be tested. If no method gives you a basis for the controls you assumed, redesign so the vendor's controls are not necessary, bring the vendor inside the report with the inclusive method, or replace it.

Does the GDPR require subprocessors to have a SOC 2?

No. Article 28(2) requires "prior specific or general written authorisation of the controller" before a processor engages another processor, and Article 28(4) requires "the same data protection obligations" to be imposed on that other processor "by way of a contract," with the initial processor remaining "fully liable to the controller" for its performance. The mechanism is authorisation, contract and liability. A SOC 2 report can be useful evidence that a subprocessor operates the security measures the contract requires, but the Regulation does not ask for one.