Article 28 GDPR: What Processors Must Say About Subprocessors
Article 28 GDPR, read as written: prior authorisation, the duty to inform and the chance to object, and the same obligations flowed down to subprocessors.
By The ClauseTrail team 8 min read
Article 28 GDPR is the rulebook for controllers that use processors, and for processors that engage other processors. On subprocessors, the text is short and strict: no engagement without the controller’s prior authorisation, a duty to inform before changes where authorisation is general, and the same data-protection obligations flowed down the chain.
This post reads those paragraphs as they are written. It is not a clause-by-clause review checklist for a vendor PDF. For how teams extract notice windows, objection periods and breach clocks from a live DPA, see how to review a data processing agreement. Here we stay with what Article 28 of the GDPR requires processors to say and do about other processors, read alongside the EDPB Guidelines 07/2020 on controllers and processors and the Commission’s Article 28(7) standard contractual clauses (Decision (EU) 2021/915).
What Article 28 GDPR requires before another processor is engaged
Paragraph 2 is the subprocessor hinge:
The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.
Three points turn on that wording.
First, authorisation comes first. The processor may not engage another processor and regularise it later. “Prior” qualifies both the specific and the general routes.
Second, authorisation is written, and it is either specific or general. Specific authorisation means the controller approves particular other processors (or particular changes) in writing. General authorisation means the controller pre-approves engagement of other processors on conditions, usually including a current list and a change process. Almost every SaaS data processing agreement uses the general route.
Third, general authorisation carries an information duty. The processor must inform the controller of intended additions or replacements “thereby giving the controller the opportunity to object”. The Regulation does not fix a number of days. It fixes the sequence: inform, then afford a real chance to object, before the change is treated as settled under that general authorisation. EDPB Guidelines 07/2020 develop that sequence for controllers and processors in practice.
Paragraph 3(d) ties the contract to that hinge: the binding act between controller and processor must stipulate that the processor “respects the conditions referred to in paragraphs 2 and 4 for engaging another processor”. A DPA that is silent on subprocessors is missing a mandated stipulation, not an optional schedule.
Flowing down the same obligations: paragraph 4
Paragraph 4 is what processors must impose on the other processor:
Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 3 shall be imposed on that other processor by way of a contract or other legal act under Union or Member State law, in particular providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing will meet the requirements of this Regulation. Where that 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.
Two consequences matter for SaaS stacks.
Same obligations. The subprocessor contract must carry the paragraph 3 substance (instructions, confidentiality, security, assistance, deletion or return, audit cooperation, and the paragraph 2/4 conditions themselves), not a thinner courtesy NDA. “Same” is about the data-protection obligations in the controller-processor act, not about copying every commercial schedule.
Full liability up the chain. If the other processor fails, the initial processor “shall remain fully liable to the controller” for that performance. Controllers reading a vendor DPA should expect the vendor to accept that statutory allocation, not to empty it with wording that makes the subprocessor the controller’s sole recourse.
Paragraph 1 sets the quality bar the controller must apply when choosing any processor, and paragraph 4 repeats “sufficient guarantees” for the other processor. Paragraph 5 allows adherence to an approved code of conduct or an approved certification mechanism as an element by which to demonstrate sufficient guarantees under paragraphs 1 and 4. It does not replace the authorisation, information and flow-down rules in paragraphs 2 to 4.
What the contract must contain beyond subprocessors
Paragraph 3 requires a contract (or other binding legal act) that sets out subject-matter, duration, nature and purpose of the processing, types of personal data, categories of data subjects, and the obligations and rights of the controller. It then lists mandatory processor stipulations in points (a) to (h): documented instructions (including on transfers), confidentiality, Article 32 security, the paragraph 2 and 4 subprocessor conditions, assistance with data-subject rights, assistance with Articles 32 to 36, deletion or return at the end, and information plus audit cooperation.
On subprocessors, points (a) and (d) interact. Instructions can constrain transfers and onward processing; point (d) forces the DPA to respect the authorisation and flow-down rules. A published subprocessor list is how general authorisation usually becomes operable. For what that list is in practice, see what a subprocessor is.
Paragraph 9 requires the contract or act in paragraphs 3 and 4 to be in writing, including electronic form. Electronic acceptance can meet the form requirement; the substance of paragraphs 2 to 4 still has to be present.
How Decision 2021/915 Clause 7.7 illustrates the missing days
The Regulation demands information and an opportunity to object. It does not supply a day count. The Commission’s Article 28(7) clauses in Decision (EU) 2021/915, Clause 7.7, show how parties fill that gap in a standard text.
Clause 7.7 offers two options. Option 1 is specific prior written authorisation: the processor may not engage another processor without the controller’s prior specific written authorisation. Option 2 is general written authorisation: the processor has the controller’s general authorisation for lists of subprocessors already relied on, and informs the controller of intended changes “at least [SPECIFY TIME PERIOD] in advance”, giving the controller time to object before the other processor is engaged. The placeholder for a time period is the Commission’s own proof that the days are contractual, not statutory.
That is the split of labour Article 28 GDPR sets up: the Regulation sets authorisation, information and objection; the contract (or the Article 28(7) clauses the parties adopt) sets the period and the channel. How Stripe, HubSpot or Atlassian word those periods on a given day belongs in a DPA review, not in a reading of the article itself; use our data processing agreement checklist for that operational pass. ClauseTrail’s DPA and contract terms we watch are built around those fields so the statutory sequence is not lost between versions.
When a new subprocessor sits outside the EEA, Chapter V transfer tools join the file. That is adjacent to Article 28, not a substitute for it. See standard contractual clauses versus the Data Privacy Framework.
What processors must be able to show
Taken together, paragraphs 2, 3(d) and 4 mean a processor should be able to show:
- Written general or specific authorisation from the controller covering other processors.
- A way the controller learns of intended additions or replacements in time to object.
- Contracts with other processors that impose the same data-protection obligations as in the controller-processor act.
- Acceptance that failure by the other processor leaves the initial processor fully liable to the controller for that performance.
Lists, notice emails and DPA schedules are how those showings appear in SaaS. They are the visible edge of Article 28’s subprocessor rules, not decorative trust centre content.
The one check worth making this week
Open one processor DPA you rely on. Highlight every sentence that implements paragraph 2 (authorisation type, information channel, objection mechanics) and paragraph 4 (flow-down and liability). Compare the notice period you find with Clause 7.7 option 2’s “at least [period] in advance” structure. If either paragraph is only implied by a list URL with no authorisation language, that is a documentation gap against the statutory structure.
ClauseTrail reads vendor DPAs and subprocessor lists so the Article 28 fields above are tracked when wording changes. See what we watch in vendor contracts and pricing.
Frequently Asked Questions
What does Article 28 GDPR say about subprocessors?
A processor needs the controller’s prior specific or general written authorisation before engaging another processor. Under general authorisation it must inform the controller of intended additions or replacements so the controller can object. It must also impose the same data-protection obligations on that other processor, and remains fully liable to the controller if the other processor fails.
Is a published subprocessor list enough to satisfy Article 28?
A list helps general authorisation work in practice, but paragraph 2 still requires prior written authorisation and information before changes with an opportunity to object. Paragraph 3(d) requires the contract to stipulate respect for paragraphs 2 and 4. A URL alone, without authorisation and notice language, is incomplete against that structure.
What is the difference between specific and general authorisation?
Specific authorisation means the controller approves particular other processors, or particular changes, in writing before engagement. General authorisation pre-approves engagement of other processors on conditions, usually with a current list and a duty to inform the controller of intended additions or replacements in time to object. Decision 2021/915 Clause 7.7 sets out both options in the Commission’s Article 28(7) clauses.
Does Article 28 set a 30-day notice period?
No. The GDPR text requires the processor to inform the controller of intended changes under general authorisation and to give an opportunity to object. Periods such as 30 days appear in contracts, including as the placeholder time period in Decision 2021/915 Clause 7.7 option 2. They are how parties operationalise paragraph 2, not a number the article itself fixes.
Is the processor liable for its subprocessors?
Yes, under Article 28(4): where the other processor fails to fulfil its data-protection obligations, the initial processor remains fully liable to the controller for the performance of that other processor’s obligations. Controllers should expect the DPA to reflect that allocation rather than shift sole recourse onto the subprocessor.
Written from the primary sources as they stood on 27 October 2026. General information, not legal advice.
ClauseTrail watches vendors' subprocessor lists, DPAs, privacy policies, terms and AI terms, and tells your team what changed and by when to object.