ESP as GDPR Processor — Roles, DPA Requirements, Transfers

Not legal advice. A reference summary, for ESP operators, of EDPB Guidelines 07/2020 (v2.1, adopted 7 July 2021), GDPR Art. 28, and the European Commission's instruments for international transfers. Consult counsel when you draft contracts.

If your customers upload recipient lists to your ESP and send campaigns through it, you process personal data (email addresses, names, engagement events) on behalf of those customers. Under the GDPR, that makes the customer the controller and the ESP a processor. A processor has obligations that apply to it directly, not only through the contract.

The duties below are the ones that apply at the level of the platform. The rules for the content and sending of marketing email are in EU ePrivacy + GDPR.

Roles (EDPB Guidelines 07/2020)

The concepts are functional, because they follow the roles parties actually play rather than labels, and autonomous, because EU law defines them, not the contract. The definitions:

• Controller: determines the purposes and means ("why and how") of the processing. It must decide both, but may leave "non-essential means" to the processor, such as the practical implementation (choice of hardware or software) and detailed security measures. Essential means (what data, whose data, how long, who has access) are for the controller to decide.
• Processor (Art. 4(8)): a separate entity that processes personal data on the controller's behalf, meaning that it serves the controller's purposes under its instructions, possibly with some discretion over technical and organisational choices.

Applied to an ESP:

• For customers' recipient lists and campaign and engagement data, the customer is the controller and the ESP is the processor. The EDPB's example of a cloud service fits exactly. A standardized, worldwide service is still a processor arrangement, but the customer must be able to impose its instructions (retention periods, deletion) "regardless of what is generally offered in the standardized service."
• Art. 28(10) sets the line an ESP must never cross. A processor that uses the data for its own purposes "infringes the GDPR by going beyond the controller's instructions" and becomes a controller for that processing. The EDPB's MarketinZ example is literally a marketing service provider that used a client's customer database "for other purposes than advertising for [the client], such as developing their own business activity". That change of role is itself an infringement. An ESP must not mine customer lists for its own marketing, for enrichment products, or to build audiences across customers without a separate legal basis of its own as a controller.
• The ESP is a controller for its own customer account data (billing, users, support), its own marketing, its website analytics, and the security and abuse operations it runs for its own compliance and to protect its network. The same entity is routinely a controller for some processing and a processor for other processing, and each activity is qualified separately.
• A gray zone to analyze deliberately: anti-abuse and reputation systems that work across all customers of the platform (aggregating complaints, suppression lists, intelligence about spam traps). Where the ESP itself determines the purposes and means of this processing, it acts as a controller for it. It must then identify its own lawful basis (typically a legitimate interest in protecting its infrastructure and other users) and disclose it, rather than pretend the processing follows a single customer's instructions.
• Joint controllership requires the parties to participate jointly in determining purposes and means, through common decisions or converging decisions that are inextricably linked. A normal relationship between an ESP and its customer is not joint controllership, and simply using the same platform does not create it.

Choice of processor and form of contract

• Controllers must use "only processors providing sufficient guarantees" (Art. 28(1)). The guarantees are assessed on the processor's expert knowledge, reliability and resources, and its reputation in the market is relevant. Following an approved code of conduct or certification (Art. 28(5)) can serve as evidence. The documents exchanged typically include the privacy policy, terms of service (ToS), records of processing, security policy, external audit reports and recognised certifications (for example, the ISO 27000 series). This duty is continuous: the controller verifies again periodically, including through audits, and not only at signature. For an ESP, this defines the due diligence package to keep ready for enterprise customers.
• The data processing agreement (DPA) must be in writing, which includes electronic form (Art. 28(9)), and binding. Not having one is itself an infringement by both parties. It may be part of a broader agreement, but the EDPB recommends that the Art. 28 elements can be found in one place (for example, an annex).
• The parties may draft their own DPA or use standard contractual clauses under Art. 28(7). Commission Implementing Decision (EU) 2021/915 of 4 June 2021 publishes an official set of controller-processor SCCs for use within the EU and EEA. These clauses are optional, and they are not the same as the SCCs for international transfers described below.
• An EDPB warning that applies directly to ESPs (¶110): processors that provide standard terms may update them, but "any proposed modification, by a processor, of data processing agreements included in standard terms and conditions should be directly notified to and approved by the controller. The mere publication of these modifications on the processor's website is not compliant with Article 28." When an ESP changes its DPA, its process must actively notify customers.

The Art. 28(3) clauses an ESP's DPA must contain

The contract must set out the subject-matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects (be specific: "subscribers or recipients of the customer's mailings", "members of contact lists"), and the obligations and rights of the controller. It must also cover the points in Art. 28(3)(a)–(h):

In addition, the processor must immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other EU or member-state data protection law (the final sentence of Art. 28(3)). The EDPB recommends setting out the consequences in the contract: a right to suspend carrying out the instruction, or to terminate if the controller persists. This gives the ESP a legal basis for refusing, for example, a customer's instruction to mail a purchased list where doing so would be unlawful processing.

Some obligations fall directly on the processor under the law, whatever the contract says: records of processing (Art. 30(2)), security (Art. 32), notifying breaches to the controller (Art. 33(2)), designating a data protection officer (DPO) where required (Art. 37), the transfer rules of Chapter V, and, for processors outside the EU that serve data subjects in the EU, designating an EU representative under Art. 27. Processors can be fined directly for breaching these obligations or for going beyond lawful instructions.

Sub-processors

Every downstream vendor that touches list or event data on the ESP's behalf is a sub-processor. That includes hosting and infrastructure-as-a-service (IaaS) providers, subcontracted MTA or SMS gateways, validation services, analytics, and support tools:

• The controller must give prior written authorisation, which may be specific or general (Art. 28(2)).
  • Under general authorisation, the workable model for a multi-tenant ESP, keep a list of sub-processors in the DPA or an annex, with the location, function and proof of safeguards for each vendor. Actively inform the controller of any addition or replacement you intend, pointing to each new vendor, not "generalized access to a list which might be updated from time to time" (¶¶152–156 and footnote 54). Give the controller a genuine opportunity and a reasonable timeframe to object, and set out in the contract the practical steps that follow an objection, including possible termination. Under general authorisation, silence within the timeframe counts as authorisation.
  • Under specific authorisation, a request that goes unanswered counts as denied.
• The same obligations flow down (Art. 28(4)). The sub-processor's contract must impose in substance the same data protection obligations as the main DPA, including the duty to contribute to audits, adapted to the sub-processor's actual role. The whole chain must be covered by written agreements.
• Full liability remains: "the processor remains fully liable to the controller for the performance of the sub-processors' obligations" (Art. 28(4)). Choose sub-processors that provide sufficient guarantees.

Data-subject requests handled as a processor

Requests for access, rectification, erasure, restriction, portability and objection belong to the controller, the ESP's customer. The processor's role (Art. 28(3)(e), EDPB ¶¶130–132):

• Forward promptly to the relevant customer any request a recipient sends to the ESP. This happens often, when a subscriber replies to a campaign or emails the ESP's abuse desk. Do not answer on the merits without instructions.
• Assist as the contract provides. Assistance ranges from simply enabling the controller to extract and manage the data, to specific technical duties where the processor holds the data (export tools, deletion APIs, extracts of each recipient's activity).
• The controller decides whether a request is admissible, and bears the one-month deadline of Chapter III. That deadline is not extended because the information sits with the processor, so the DPA should set internal response times accordingly.
• One practical exception: unsubscribe and objection signals must keep working operationally, whatever the plumbing for data-subject requests. Suppression is both an absolute right under Art. 21 and a deliverability requirement.

International transfers (GDPR Chapter V)

Transfers outside the European Economic Area (EEA) need a mechanism under Chapter V. This includes transfers to the ESP's own infrastructure or divisions outside the EU, and to sub-processors outside the EU. These are the mechanisms relevant to processors:

1. Adequacy decisions (Art. 45): data can be transferred as if within the EU. The current list: Andorra, Argentina, Brazil (from 26 Jan 2026), Canada (commercial organisations under PIPEDA only), Faroe Islands, Guernsey, Isle of Man, Israel, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, the United Kingdom (renewed December 2025), Uruguay, the European Patent Organisation (15 Jul 2025), and the United States, limited to organisations certified under the EU-U.S. Data Privacy Framework:

• Commission Implementing Decision (EU) 2023/1795 of 10 July 2023 finds the US adequate for transfers to organisations certified under the Data Privacy Framework (DPF). The US Department of Commerce administers certification and keeps a public list, and the FTC enforces. Complaints can go to the organisation (with a 45-day response), to independent dispute resolution, to data protection authorities (DPAs), and, as a last resort, to binding arbitration. The decision rests on Executive Order 14086, which sets limits of necessity and proportionality on signals intelligence, and on the redress mechanism of the Data Protection Review Court. These were the fixes for the Schrems II ruling that invalidated Privacy Shield.
• Status of legal challenges (verified July 2026): the DPF survived its first court challenge. In Latombe v Commission (Case T-553/23), the General Court dismissed the action for annulment on 3 September 2025 and upheld the adequacy decision. It found the Data Protection Review Court sufficiently independent and impartial, and found the US limits on bulk collection, and the redress available, substantially equivalent to EU standards. The adequacy decision therefore remains valid as of July 2026. Latombe appealed to the Court of Justice (CJEU) on 31 October 2025, so a further ruling is pending. A US-based ESP or sub-processor that relies on the DPF should keep monitoring its certification status and the pending appeal.

2. Standard Contractual Clauses (Art. 46(2)(c)): Commission Implementing Decision (EU) 2021/914 of 4 June 2021, in force since 27 June 2021. It is a single document in four modules:

How the clauses work:

• The old SCC decisions (2001/497/EC and 2010/87/EU) were repealed on 27 September 2021. Contracts under them remained valid until 27 December 2022 if the processing was unchanged.
• A docking clause (Clause 7) lets new parties join later.
• Clause 14 implements the Schrems II ruling. The parties must assess whether the law and practice of the destination country prevent compliance, document a transfer impact assessment, and apply supplementary measures (technical, organisational or contractual) where needed.
• Modules Two and Three also serve as a DPA that complies with Art. 28 for the transfer relationship, so no separate DPA under 2021/915 is needed for the same relationship.

3. Other Art. 46 safeguards: Binding Corporate Rules (within a group), approved codes of conduct, and certification mechanisms. The derogations of Art. 49 (explicit consent, necessity for a contract and so on) are for occasional transfers that are not repeated, and are not a basis for routine ESP data flows.

Chapter V binds processors as well as controllers. An ESP in the EU is itself the data exporter to its sub-processors outside the EU, and must have Module Three SCCs (or another mechanism) in place, consistent with the controller's documented instructions on transfers.

Why this is deliverability-relevant

The discipline of a processor and the discipline of deliverability lead to the same place:

• Documented instructions, and the duty to refuse unlawful instructions, are the compliance foundation for vetting customers and for refusing purchased lists.
• The processes for notifying breaches overlap with the abuse desk escalation paths that providers expect.
• Keeping roles clearly separate, and never mining customer lists for the ESP's own purposes, is also what keeps an ESP out of the reputation tier of data brokers, which both regulators and Spamhaus police.