If you are a data processor — a SaaS company processing personal data on behalf of your enterprise customers — you cannot onboard a sub-processor without authorisation from your controllers. This is Article 28(2). Failing to manage sub-processors properly exposes you to contract breaches, regulatory violations, and lost enterprise deals.
This article covers the sub-processor management obligations for SaaS companies acting as processors under GDPR.
What Is a Sub-Processor?
A sub-processor is a third party that you engage to help carry out processing you are doing on behalf of a controller.
If you run a CRM SaaS:
- Your enterprise customer is the controller
- You (the CRM company) are the processor
- AWS (hosting the database), Intercom (handling in-app chat), SendGrid (sending emails) — these are your sub-processors
A sub-processor must be explicitly authorised by the controller and contracted by you with GDPR-equivalent obligations.
Note: not every vendor you use is a sub-processor. A tool you use for your own purposes (your internal Slack, your accounting software) is not a sub-processor. The test is whether the vendor processes the controller's personal data as part of delivering your service.
The Authorisation Requirement
Before engaging a sub-processor, you need authorisation from your controller customers. There are two models:
Specific authorisation: The controller pre-approves a named list of sub-processors. Any change requires explicit approval. This is the most protective approach for controllers, but it is operationally demanding for rapidly-evolving SaaS products.
General authorisation: More common in SaaS. The DPA gives the controller a right to be notified of sub-processor changes, with a defined objection window (typically 10–30 days). If the controller does not object within the window, the change is deemed approved.
Enterprise customers increasingly scrutinise the notification window and the sub-processor list. Make sure your DPA terms reflect your actual practice.
Your Sub-Processor Obligations (Article 28(4))
When you engage a sub-processor, you must:
-
Contract with the sub-processor with the same data protection obligations as in your customer DPA. The sub-processor must be bound to the same security standards, purpose limitations, and data subject rights obligations you are.
-
Remain fully liable to your controller customer for the sub-processor's performance. If AWS loses data or Intercom breaches your customer's employee information, you are liable to your customer even though AWS or Intercom caused the problem. This upstream liability flows down — choose sub-processors carefully.
-
Maintain a current list of all sub-processors, publicly available or accessible to controller customers on request.
-
Notify controllers of changes before making them (for general authorisation model) and allow the objection window.
Managing Sub-Processor Risk in Practice
Conduct due diligence before onboarding. Review the proposed sub-processor's:
- Data protection certifications (ISO 27001, SOC 2 Type II)
- DPA and contractual terms
- Track record of breaches or enforcement actions
- Security practices
Execute a written sub-processor agreement. Do not rely on click-wrap terms. If you process customer data with a sub-processor, you need a contract that satisfies Article 28(4) requirements.
Cover international transfers. If the sub-processor is based outside the EEA, ensure the transfer mechanism is in place (adequacy decision, SCCs, or DPF certification). This is part of your due diligence obligation.
Maintain your sub-processor list. This list must be kept current and accessible. Many SaaS companies publish it on their website or in the customer portal.
Monitor sub-processor compliance. You cannot simply contract with a sub-processor and never check them again. Conduct periodic reviews or rely on third-party certifications that are current.
Sub-Processor List: What to Include
Your published or customer-accessible sub-processor list should include:
| Column | Content |
|---|---|
| Sub-processor name | Legal entity name |
| Country/location | Where the processing occurs |
| Purpose | Why this sub-processor is used |
| Transfer mechanism | SCCs, adequacy decision, DPF, etc. |
| Data processed | Categories of personal data involved |
Example:
| Sub-processor | Country | Purpose | Transfer mechanism |
|---|---|---|---|
| Amazon Web Services | Ireland (primary), US (backup) | Cloud hosting and database | Adequacy (Ireland); SCCs for US backup |
| Intercom | United States | Customer support communications | SCCs + DPF certified |
| Stripe | United States | Payment processing | SCCs + DPF certified |
| Datadog | United States | Application monitoring and logging | SCCs |
Sub-Processor Changes: Notification in Practice
When you add or replace a sub-processor:
- Add the new sub-processor to your internal list
- Notify controller customers via email or in-app notification
- Specify: the new sub-processor's name, location, purpose, and transfer mechanism
- Start the objection window (e.g., "If you have concerns, please raise them within 30 days")
- If a customer objects: assess their concern, discuss alternatives; if the sub-processor is essential, you may need to seek alternative arrangements or accept that the customer exits
In practice, most customers do not object to sub-processor changes. But having a documented notification and objection process is what makes your DPA enforceable.