Third-Party Risk: Managing Your Sub-Processor List

Every SaaS company has sub-processors: AWS, payment providers, email services, LLM APIs, analytics tools, whatever. The list isn't static. Managed poorly, it becomes an audit finding, a customer breach-of-contract, or a GDPR violation.

Why it matters more than it used to

A few years ago, sub-processor lists were a legal artifact buried in a DPA. Now they're a first-class security concern:

• SOC 2 requires vendor management as an operational control (CC9.2).
• GDPR requires you to publish your sub-processor list and notify customers before adding new ones.
• Enterprise buyers compare your list against theirs and flag overlaps that concern them.
• Supply chain attacks have made sub-processor diligence a real security concern, not just a compliance one.

What to maintain

A good sub-processor registry includes, for each vendor:

• Company name and what they do for you
• Data types they access (no PII, some PII, full customer data, etc.)
• Regions where they operate
• Current security certifications (SOC 2, ISO 27001, etc.)
• DPA status and date signed
• Last review date

Annual review process

Once a year, every sub-processor gets a review. It's lightweight — not a full security assessment, but:

• Is their latest security certification still current? (Pull their updated SOC 2 report.)
• Has anything changed in their sub-processor list that affects us?
• Have there been any publicly disclosed incidents involving them?
• Does the DPA terms still work? (Sub-processors sometimes update unilaterally.)

Document the review. Auditors ask for this evidence.

When you add a new sub-processor

Under most DPAs you need to notify customers before onboarding a new sub-processor. Best practice: maintain a public sub-processor page (at /sub-processors or similar), email a notice to customers with DPAs, and give them a 30-day objection window.

Yes, this feels heavy-weight. It's also genuinely what enterprise customers expect. Skipping it is one of the most common GDPR/DPA violations we see at early-stage SaaS.

The incident cascade problem

When a sub-processor has an incident, you're potentially liable to your customers. If your payment processor has a breach, you have to notify your customers in the affected timeframe — often within 72 hours under GDPR. Make sure your sub-processor contracts require them to notify you within 24 hours. Cascade timing is where incident response usually fails.

The sub-processor list isn't glamorous work. It's a quarterly hour to keep it current, and it's the difference between a smooth enterprise review and a panicked scramble in month eight.