What Is a Subprocessor in SOC 2 Context?

A subprocessor is any third-party vendor that processes customer data on your behalf. If your SaaS product stores customer data, and that data is processed by, transmitted to, or accessible by a third-party service, that third party is a subprocessor.

Common examples for a typical SaaS company:

• Cloud infrastructure: AWS, GCP, Azure (the most critical)
• Database hosting: Managed databases like RDS, PlanetScale, Supabase
• Email delivery: SendGrid, Mailgun, Postmark (if they handle customer-identifying data in emails)
• Payment processing: Stripe, Braintree (for payment data)
• Error monitoring: Datadog, Sentry, New Relic (if they receive stack traces containing customer data)
• Customer support: Intercom, Zendesk (if agents view customer data)
• AI/ML models: OpenAI, Anthropic (if customer data is sent for inference)
• CDN: Cloudflare (if they cache pages containing customer data)

The distinction between a subprocessor and a regular vendor: subprocessors actually access, process, or store your customers' data. A vendor you pay for your internal Slack workspace is not a subprocessor; a vendor you use to send transactional emails containing customer account information is.

CC9.2: The SOC 2 Requirement

SOC 2 CC9.2 is part of the Risk Mitigation criteria. It requires:

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

In auditor practice, this means you need to demonstrate that:

You know who your subprocessors are

You've assessed their security posture

You have contractual protections in place

You monitor for changes to their subprocessor list or security posture

You can respond if a subprocessor has a security incident

This is separate from (but related to) the broader [vendor risk management program](/blog/soc2-vendor-risk-management-guide). Vendor risk management covers all significant vendors; subprocessor management specifically focuses on those who touch customer data.

Building a Subprocessor Inventory

Start by mapping every place customer data flows outside your own infrastructure. Walk through your architecture:

Customer registration: Where does user account data go? (Authentication provider, database, email system)

Core product functionality: What third-party APIs or services does your product call? Does customer data go in requests or responses?

Monitoring and observability: What do your logs contain? Where are they sent?

Customer communications: What system sends transactional emails? Do they log message content?

Payments: Who processes payment data?

Customer support: Can support agents view customer data through your support tool?

For each identified subprocessor, document:

• Company name and service description
• Data types processed (account data, payment data, content data, usage data)
• Processing location (US, EU, other regions)
• Security certifications held (SOC 2 Type II, ISO 27001)
• Data processing agreement in place (Yes/No, date of last review)
• Subprocessor's own sub-subprocessors (relevant for GDPR; noted in SOC 2)

Collecting Evidence from Subprocessors

For each significant subprocessor, collect their security attestation:

SOC 2 Type II report: The gold standard. Request the full report (not the summary) and review:

• The scope of the examination (does it cover the service you use?)
• Any exceptions noted in the opinion
• The Complementary User Entity Controls (CUECs) — controls your subprocessor expects you to implement on your end

ISO 27001 certificate: Acceptable in lieu of SOC 2 for non-US vendors. Note the scope and certification date.

Security questionnaire responses: For vendors that don't have SOC 2 or ISO 27001, conduct a security assessment. Use CAIQ (Consensus Assessment Initiative Questionnaire) or a custom questionnaire aligned to CC9 controls.

Bridge letters: SOC 2 reports cover a specific period (e.g., January 1 – December 31, 2025). If there's a gap between the report period and your review date, request a bridge letter from the vendor stating no material changes to their security controls.

Contractual Protections

Contracts with subprocessors should include:

• Security obligations: Require the subprocessor to maintain security controls appropriate to the data they process
• Breach notification: Require notification within a defined timeframe (many enterprises expect 48–72 hours; GDPR requires 72 hours to the supervisory authority)
• Data use restrictions: Prohibit the subprocessor from using your customers' data for their own purposes (especially critical for AI/ML model providers)
• Subcontracting restrictions: Require approval before the subprocessor engages their own subprocessors
• Audit rights: The right to audit the subprocessor or receive security reports on request
• Termination and data return/deletion: What happens to your customers' data when you terminate the relationship?

For major cloud providers like AWS, Microsoft, and Google, these terms are in their standard Data Processing Agreements. Reviewing and executing the DPA is itself a required step.

Monitoring Subprocessor Changes

Your subprocessors change their own infrastructure and subprocessors over time. A subprocessor who met your security standards six months ago may have changed in ways that matter. Building a monitoring process is the CC9 control that most companies skip.

What to monitor:

• Changes to the subprocessor's own subprocessor list
• Security incidents involving the subprocessor
• Changes to their SOC 2 scope or report qualifications
• Data center or infrastructure changes (new regions, new providers)

Practical monitoring approach:

Subscribe to subprocessor security bulletins and changelog notifications

Set Google Alerts for major subprocessors' security incidents

Re-review SOC 2 reports annually (or when new reports are published)

Document each review with date and outcome

Customer-Facing Subprocessor Disclosure

Enterprise customers increasingly require a current subprocessor list as part of your data processing terms. If you process EU personal data, GDPR Article 28 requires you to list subprocessors in your DPA.

Best practices:

• Maintain a public subprocessor list on your security or legal page
• Provide notice of new subprocessors before engaging them (30 days is common)
• Allow customers to object to new subprocessors (with a defined process for objections)

Your [SOC 2 trust center](/blog/soc2-trust-center-guide) is the natural place to publish and maintain your subprocessor list.

SOC 2 Audit Evidence for CC9

When an auditor reviews your subprocessor management program, they will ask for:

Your subprocessor inventory

SOC 2 reports or other security documentation from major subprocessors

Evidence that you reviewed those reports (date of review, noted exceptions)

Evidence that DPAs or security addenda are in place with subprocessors

Documentation of any significant subprocessor changes during the observation period and how they were handled

Evidence that customer-facing subprocessor lists are maintained and current

Keep this documentation organized and accessible in your [auditor portal](/blog/soc2-auditor-portal-guide) before the audit starts — it significantly reduces audit fieldwork time.