← Back to Resource Center
GDPR · Supplier documents 7 min read

Sub-processors: what a supplier must tell you, and when

What GDPR Articles 28(2), 28(4) and 30(1)(d) require of a supplier's sub-processors: authorisation, notice of changes, the right to object and your own record.


Your supplier’s sub-processors are the companies that process your customers’ and employees’ personal data on the supplier’s behalf: its hosting provider, its e-mail sender, its support tool, the model provider behind its AI features. You signed nothing with them, yet the GDPR makes them your concern twice over: the supplier may use them only on your authorisation (Article 28(2)), and your own record must show who receives the data (Article 30(1)(d)). This guide sets out what a supplier must tell you, when, and what you do with it.

Who counts as a sub-processor

Article 28(2) and (4) speak of “another processor”: a party the processor engages to carry out processing on the controller’s behalf. Infrastructure counts when personal data sits on it — a cloud provider hosting the database is a sub-processor even if it never looks at the data. A payment provider acting as its own controller is not. A supplier’s affiliates in other countries are, if they can access the data. The EDPB’s Guidelines 07/2020 on the concepts of controller and processor expect each sub-processor to be identifiable to the controller, which is why a sub-processor list is a list of company names, not “trusted third parties”.

Article 28(2): authorisation, specific or general

The processor “shall not engage another processor without prior specific or general written authorisation of the controller”. With specific authorisation you approve each sub-processor by name; it is rare in SaaS because the supplier would have to ask every customer before adding a vendor. With general authorisation — almost every SaaS DPA — you authorise the supplier to choose, and in return it “shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object”. Three parts: a current list, notice before the change, an opportunity to object. The differences between suppliers sit in the last two:

  • Notice period. The GDPR sets none; the EDPB says it must be long enough to actually object. Thirty days is common, fourteen exists, “we will update this page” is not notice, and a notice that arrives after the change has taken effect is not notice of “intended changes”.
  • Channel. E-mail to the account owner, a subscription link on the sub-processor page, an RSS feed — or “check the page”. Only the first three reach you unasked.
  • Objection. Good DPAs say the supplier will try to resolve an objection and, failing that, let you terminate the affected service without penalty and with a refund of prepaid fees. Weak ones say you may terminate, full stop. A DPA with no consequence at all has not given you an opportunity to object in any meaningful sense.

Article 28(4): the flow-down and who is liable

When a processor engages a sub-processor, “the same data protection obligations as set out in the contract” between you and the processor must be imposed on the sub-processor by contract, and if the sub-processor fails, “the initial processor shall remain fully liable to the controller”. You therefore need no contract with the sub-processor — you need to know your supplier has one, and a DPA that says so. A sub-processor outside the EU and EEA is also a transfer under Chapter V: the supplier owes you the mechanism — an adequacy decision (Article 45), standard contractual clauses (Article 46(2)(c)) or binding corporate rules (Article 47) — and the list should show the country of each entry so you can check.

Article 30(1)(d): the list belongs in your own record

Your record of processing activities must contain “the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries”. A supplier’s sub-processors are recipients. Article 30(5) exempts organisations under 250 employees only when the processing is occasional, involves no special categories and is unlikely to result in a risk; an SME running a CRM, a payroll tool and a support desk meets none of those conditions.

Two further articles reach the same list. Articles 13(1)(e) and 14(1)(e) require you to tell data subjects the recipients or categories of recipients. Article 15(1)(c) gives them a right to that information on request, and the Court of Justice held in Österreichische Post (C‑154/21, 12 January 2023) that a data subject who asks must be given the actual recipients, not only categories, unless that is impossible or the request is manifestly unfounded. You cannot name recipients you have not recorded.

What a supplier must tell you, in one list

  • The current sub-processor list: company name, country of processing, purpose (hosting, e-mail, support, AI inference), and a date on the list.
  • The transfer mechanism for each entry outside the EU and EEA.
  • The notice period and channel for changes, and each change before it takes effect.
  • What happens when you object.
  • That each sub-processor is bound by a contract with the same obligations and that the supplier stays liable (Article 28(4)).

The questions to put to the supplier

  1. Where is the current sub-processor list, and when was it last changed?
  2. How will we be told of a new or replaced sub-processor, and how many days before it takes effect?
  3. If we object, what are our options and within what period?
  4. Which sub-processors process our data outside the EU and EEA, and under which Chapter V mechanism?
  5. Which sub-processor runs your AI features, and does our data leave the EU when they run?

Keeping the list without keeping the supplier’s page

The list on the supplier’s site is the supplier’s; the entry in your record is yours. Record, per supplier: the sub-processors as read on a date, the country and purpose of each, the notice terms, and what changed since the last reading. Then watch the page, because the one thing a general authorisation guarantees is that the list will change — see watching suppliers’ terms for changes. The same list, seen from the other side, is why the sub-processor question is on every customer’s security questionnaire: your customers need your sub-processors in their register exactly as you need your suppliers’ in yours.

How Maditon does this

Maditon reads a supplier’s sub-processor page and DPA, records each sub-processor with the passage it was read from, and shows the list under the supplier in your register with the date of the reading. Missing notice terms or an absent right to object appear as findings — questions to put to the supplier, not verdicts — and a change on the page arrives in the next day’s e-mail with the difference. For your own customers’ questionnaires, your sub-processors are derived from the same register, so that part of an answer stays true by itself. See What does Maditon do about my suppliers? and How does Maditon know when a supplier changes their terms?, or start your register in the app.