Short answer: A GDPR sub-processor is any company your processor engages to process personal data on behalf of your controller customer. Under Article 28, a processor needs the controller's prior specific or general written authorisation first, must announce changes so the controller can object, and must pass the same data protection obligations down by contract.
Related guides:
- Data controller vs data processor: differences explained
- Data processing agreement
- Fourth-party risk management
Key takeaways
- A sub-processor sits one link further down the chain than your processor. If you are a SaaS vendor, your cloud host, email delivery service and support desk tool are usually your sub-processors.
- Article 28(2) GDPR says a processor "shall not engage another processor without prior specific or general written authorisation of the controller".
- With general authorisation, the processor must tell the controller about intended additions or replacements so the controller has a chance to object. A published sub-processor list plus a notification process is the usual way to do this.
- Article 28(4) requires the same data protection obligations to flow down by contract, and the initial processor stays fully liable to the controller for the sub-processor's performance.
- Treat your sub-processor register as living evidence. Buyers, auditors and regulators all ask for it.
What is a sub-processor under GDPR?
A sub-processor is a third party that a processor engages to carry out specific processing activities on personal data it handles for a controller. GDPR itself does not use the word "sub-processor". Article 28 talks about a processor engaging "another processor", and the industry term stuck.
The EDPB Guidelines 07/2020 on controllers and processors describe the arrangement in plain terms: a controller engages a processor, and that processor, with the controller's authorisation, may engage one or more other processors.
A simple test helps you decide whether a vendor belongs on your list:
- Does the vendor touch personal data you process for customers? Hosting, databases, logging tools that capture user identifiers, email and SMS delivery, customer support platforms and AI model APIs that receive customer content usually do.
- Does it act on your instructions rather than for its own purposes? If yes, it is a processor to you and a sub-processor to your customer.
- Is it only processing your own company data? A payroll provider that only handles your employees' data is your processor, but not a sub-processor for your customers.
For a HealthTech vendor, the same chain often carries protected health information as well. HIPAA has its own subcontractor rules under business associate agreements, which we cover in our BAA guide. Many teams run one vendor register that answers both questions.
What does Article 28 require before a processor adds a sub-processor?
Article 28 sets four conditions that every sub-processor arrangement has to meet. Read them as a checklist your DPA and your internal process should both cover.
| Requirement | Where it comes from | What it means in practice |
|---|---|---|
| Prior written authorisation | Article 28(2) | The controller agrees in advance, either per vendor (specific) or to a category of change with notice (general) |
| Notice and a chance to object | Article 28(2) | Under general authorisation, the processor announces intended additions or replacements before they take effect |
| Same obligations flow down | Article 28(4) | The sub-processor contract imposes the same data protection obligations as the controller-processor contract |
| Sufficient guarantees | Article 28(4) | The sub-processor must offer sufficient guarantees of appropriate technical and organisational measures |
| Contract term covering all of this | Article 28(3)(d) | The DPA must state that the processor respects the conditions in paragraphs 2 and 4 |
The EDPB guidelines add a useful detail: under a general authorisation, the processor has to inform the controller of any change of sub-processors and give the controller the opportunity to object. They also confirm that the processor is liable to the controller for the other processors' compliance.
Processors also have a record-keeping duty. Article 30(2) requires each processor to keep a record of processing activities carried out on behalf of each controller, which in practice means your sub-processor list should line up with your processor records. Our GDPR data mapping guide shows how to keep the two in sync.
Specific or general authorisation: which should you use?
Most SaaS vendors choose general written authorisation, because asking every customer to approve every new tool does not scale. Specific authorisation still makes sense for small numbers of high-sensitivity customers.
| Specific authorisation | General authorisation | |
|---|---|---|
| How approval works | Controller approves each named sub-processor before use | Controller approves the approach once; processor gives notice of intended changes |
| Speed of change | Slow, one approval per customer | Faster, notice period then go-live |
| Customer control | High | Moderate, through the objection right |
| Typical fit | Regulated buyers, bespoke enterprise deals | Standard SaaS terms with many customers |
| Operational burden | Tracking approvals per customer | Running a reliable notice and objection process |
The European Commission's questions and answers on standard contractual clauses describes the same two options for its controller-to-processor clauses. In both cases the processor has to name the individual sub-processors, and the Commission leaves the notice period for the parties to agree.
In our experience, enterprise customers often negotiate a longer notice period or a stronger termination right rather than switching to specific authorisation. Decide in advance which concessions you can support operationally.
What should a sub-processor list include?
A sub-processor list should let a customer understand who touches their data, why, and where, without opening a support ticket. Publishing it on your website or trust center, and linking it from your DPA, is common practice.
Include at least these fields for each entry:
- Legal entity name of the sub-processor, not just the brand name
- Purpose of the processing, for example "application hosting" or "transactional email"
- Categories of personal data involved, for example contact details or usage logs
- Processing location and, where data leaves the EEA, the transfer mechanism you rely on
- Which product or service the sub-processor supports, if you sell more than one
- Date added, so customers can see what changed and when
Internally, track more than you publish: the signed contract or DPA, the date of the last security review, the evidence you received (for example a SOC 2 report or ISO 27001 certificate), the data owner, and the renewal date. That internal record is what your auditor will sample, and our privacy questions in security reviews guide shows how buyers use the public version.
How should change notices and objections work?
A good change process gives customers advance notice, a clear way to object, and a defined outcome if they do. Article 28(2) only says the controller must have the opportunity to object, so the mechanics live in your DPA.
A workable sequence looks like this:
- Review the vendor first. Complete your security and privacy review, sign a contract with flow-down terms, and confirm the transfer mechanism before you announce anything.
- Update the list and notify. Publish the new entry and send notice through the channel your DPA promises, such as email subscription or an RSS feed.
- Run the objection window. Use the period agreed in your DPA. A 30-day window is an example many vendors use, not a legal requirement.
- Resolve objections in good faith. Typical options are explaining the safeguards, offering a configuration that avoids the new vendor, or letting the customer terminate the affected service.
- Go live and keep records. Record the notice date, objections received and how each was closed.
Keep emergency replacements in mind. If a sub-processor fails suddenly, your DPA should describe how you will notify customers as soon as possible after an urgent change.
Who is liable when a sub-processor fails?
The processor that engaged the sub-processor stays on the hook. Article 28(4) states that where the other processor fails to fulfil its data protection obligations, "the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations".
That has three practical consequences for a vendor:
- Due diligence is not optional. You need evidence that each sub-processor offers sufficient guarantees, and that evidence has to be refreshed, not collected once.
- Contracts must mirror your DPA. Audit rights, breach notice, deletion at the end of the service and confidentiality all need to flow down. If your DPA promises a customer breach notice within a set number of hours, your sub-processor terms must give you enough time to meet it.
- Monitoring continues after onboarding. Track vendor incidents, certificate expiry and ownership changes. The fourth-party risk management guide linked above covers how to watch the vendors your vendors use.
How do international transfer rules apply to sub-processors?
Each sub-processor outside the EEA needs a valid transfer mechanism, just like a direct transfer from a controller. The sub-processor chain does not dilute Chapter V of GDPR.
Common situations include:
- Sub-processor in a country with an adequacy decision. No additional transfer tool is needed for that country, but keep the decision referenced in your list.
- Sub-processor elsewhere. Standard contractual clauses are the usual route. The Commission's Q&A confirms that Module 3 of the 2021 clauses covers transfers from a processor to a sub-processor.
- Support access from other countries. Buyers ask where data can be accessed from, not only where it is stored, so record support locations for each sub-processor too.
Document the mechanism next to each entry on your list, and record any transfer impact assessment you completed. Buyers increasingly ask for both in the same questionnaire.
How SecureSlate helps
SecureSlate gives you one place to run the sub-processor side of GDPR alongside your other frameworks. Vendor risk management keeps each sub-processor's contract, security evidence, review dates and data categories together, so your published list and your internal register stay consistent. Built-in GDPR support with multi-framework control mapping links sub-processor controls to SOC 2, ISO 27001 and HIPAA requirements, and custom controls let you track your own notice and objection process. The trust center lets you share your sub-processor list and security documents with customers, and security questionnaire automation drafts consistent answers when buyers ask about sub-processors and transfers.
FAQ
Is a cloud hosting provider a sub-processor?
Usually yes. If you host customer personal data on a cloud provider, that provider processes it on your behalf, so it is your processor and your customers' sub-processor. List it with its legal entity, purpose and data locations.
Do I need customer approval before adding a new sub-processor?
You need prior written authorisation under Article 28(2). With specific authorisation, that means approval for each vendor. With general authorisation in your DPA, you give advance notice of the change and let the customer object instead.
What happens if a customer objects to a new sub-processor?
GDPR does not prescribe the outcome, so your DPA should. Common approaches are addressing the concern with additional safeguards, offering a way to avoid the new vendor, or allowing the customer to terminate the affected service.
Is a sub-processor the same as a fourth party?
They overlap but are not identical. A sub-processor is a GDPR role tied to personal data processed for a controller. A fourth party is any vendor of your vendor, whether or not it handles personal data.
Do sub-processors need their own records of processing?
Yes, where Article 30(2) applies. A sub-processor is a processor in its own right, and Article 30(2)(a) asks for the name and contact details of "the processor or processors and of each controller" it acts for. The Article 30(5) exemption for some smaller organisations can still apply.
Disclaimer (legal note)
This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
