ESP as GDPR Processor — Roles, DPA Requirements, Transfers

Not legal advice. Reference digest of EDPB Guidelines 07/2020 (v2.1, adopted 7 July 2021), GDPR Art. 28, and the Commission's transfer instruments, for ESP operators. Consult counsel for contract drafting.

An ESP whose customers upload recipient lists and send campaigns through the platform processes 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 — with obligations that apply to the ESP directly, not only via contract. This article covers the platform-level duties; the rules for the content and sending of marketing email are in EU ePrivacy + GDPR.

Roles (EDPB Guidelines 07/2020)

The concepts are functional (they follow actual roles, not labels) and autonomous (defined by EU law, not the contract). Definitions:

• Controller — determines the purposes and means ("why and how") of processing. It must decide both, but may leave "non-essential means" (practical implementation: choice of hardware/software, detailed security measures) to the processor. Essential means — what data, whose data, how long, who has access — are controller territory.
• Processor (Art. 4(8)) — a separate entity that processes personal data on the controller's behalf, i.e. serving the controller's purposes under its instructions, with a possible margin of discretion on technical/organisational choices.

Applied to an ESP:

• For customer recipient lists and campaign/engagement data: customer = controller, ESP = processor. The EDPB's cloud-service example 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) — 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 conversion is itself an infringement. An ESP must not mine customer lists for its own marketing, enrichment products, or cross-customer audience building without a separate controller-grade legal basis.
• The ESP is a controller for: its own customer-account data (billing, users, support), its own marketing, website analytics, and security/abuse operations it runs for its own compliance and network protection. The same entity is routinely controller for some processing and processor for other processing; qualification is per-activity.
• Gray zone to analyze deliberately: platform-wide anti-abuse and reputation systems (complaint aggregation, suppression lists, spamtrap intelligence) that operate across customers. Where the ESP determines purposes and means of such processing itself, it acts as a controller for it and must identify its own lawful basis (typically legitimate interests in protecting its infrastructure and other users) and disclose it — rather than pretending the processing is on any single customer's instructions.
• Joint controllership requires joint participation in determining purposes and means (common or converging, inextricably-linked decisions). A normal ESP-customer relationship is not joint controllership; 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)) — assessed on the processor's expert knowledge, reliability and resources; market reputation is relevant; adherence to an approved code of conduct or certification (Art. 28(5)) can evidence it; documentation exchanged typically includes privacy policy, ToS, records of processing, security policy, external audit reports, recognised certifications (e.g. ISO 27000 series). This duty is continuous — periodic re-verification, including audits, not just at signature. For an ESP this defines the due-diligence packet to keep ready for enterprise customers.
• The DPA must be in writing, including electronic form (Art. 28(9)), binding, and its absence is itself an infringement by both parties. It may be embedded in a broader agreement; the EDPB recommends the Art. 28 elements be identifiable in one place (e.g. an annex).
• 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 controller-processor SCC set for use within the EU/EEA. These are optional, and are not the same as the international-transfer SCCs below.
• ESP-specific EDPB warning (¶110): processors that ship 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." ESP DPA-change workflows need active notice.

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, categories of data subjects (be specific: "subscribers/recipients of the customer's mailings," "contact-list members"), and the obligations and rights of the controller — plus, per Art. 28(3)(a)–(h):

Clause	Requirement	ESP practice notes
(a) Documented instructions	Process only on the controller's documented instructions, including for transfers to third countries; deviation allowed only where EU/member-state law requires it (with prior notice to the controller unless the law forbids it).	Keep an instruction procedure/template annexed; ad-hoc instructions in writing (email suffices). If instructions do not allow third-country transfers, no non-EU sub-processor or non-EU division may touch the data.
(b) Confidentiality	Persons authorised to process are under contractual or statutory confidentiality.	Must cover employees and temporary workers; access limited to staff who need it.
(c) Security (Art. 32)	Take all measures required under Art. 32.	Contract must include/reference the concrete measures (not restate the GDPR), an obligation to obtain the controller's approval before changing them, and periodic review. Detail sufficient for the controller to assess appropriateness.
(d) Sub-processing	Respect Art. 28(2) and (4) — see next section.
(e) Data-subject rights	Assist the controller, by appropriate technical and organisational measures insofar as possible, in responding to Chapter III requests.	See "Data-subject requests" below.
(f) Assistance Art. 32–36	Assist with security, breach notification, DPIAs and prior consultation.	Processor must notify the controller of any breach affecting its (or a sub-processor's) systems without undue delay; parties may fix a specific timeframe (e.g. a number of hours), point of contact, modality and minimum content. Direct processor-to-authority notification can be agreed, but legal responsibility stays with the controller. Duty to assist ≠ shift of responsibility: DPIAs remain the controller's initiative.
(g) End of contract	At the controller's choice, delete or return all personal data and delete existing copies, unless EU/member-state law requires storage.	Contract should allow the controller to change the choice before termination; secure deletion confirmed within an agreed timescale.
(h) Information + audits	Make available all information necessary to demonstrate Art. 28 compliance, and allow and contribute to audits/inspections by the controller or its mandated auditor.	Information includes systems functioning, security measures, retention handling, data location, transfers, access, recipients, sub-processors. Processor may suggest an auditor but the controller decides; clauses imposing clearly disproportionate audit fees that deter exercise of the right are non-compliant.

Additionally the processor must immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other EU/member-state data protection law (Art. 28(3) final sentence). The EDPB recommends contracting the consequences (right to suspend execution, or terminate if the controller persists) — the ESP's legal hook for refusing, e.g., a customer instruction to mail a purchased list where that would be unlawful processing.

Direct statutory obligations also sit on the processor regardless of contract: records of processing (Art. 30(2)), security (Art. 32), breach notification to the controller (Art. 33(2)), DPO designation where required (Art. 37), the transfer rules of Chapter V, and Art. 27 EU-representative designation for non-EU processors serving EU data subjects. Processors can be fined directly for breaching these or for exceeding lawful instructions.

Sub-processors

Every downstream vendor that touches list or event data on the ESP's behalf — hosting/IaaS, sub-contracted MTA or SMS gateways, validation services, analytics, support tooling — is a sub-processor:

• Prior written authorisation from the controller, specific or general (Art. 28(2)). Under general authorisation (the workable model for a multi-tenant ESP): keep a sub-processor list (in the DPA or an annex, with per-vendor location, function, and proof of safeguards), and actively inform the controller of any intended addition or replacement — pointing at each new vendor, not "generalized access to a list which might be updated from time to time" (¶¶152–156 + fn. 54) — with a genuine opportunity and reasonable timeframe to object, and contracted practical steps following an objection (including possible termination). Silence within the timeframe counts as authorisation under general authorisation; under specific authorisation, an unanswered request counts as denied.
• Same obligations flow down (Art. 28(4)): the sub-processor contract must impose substantively the same data protection obligations as the head DPA — including the audit-contribution duty — tailored to the sub-processor's actual role, and 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 with sufficient guarantees.

Data-subject requests handled as a processor

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

• Forward promptly any request a recipient sends to the ESP (common: a subscriber replies to a campaign or emails the ESP's abuse desk) to the relevant customer; do not answer on the merits without instructions.
• Assist per the contract — from simply enabling the controller to extract and manage the data, to specific technical duties (export tooling, deletion APIs, per-recipient activity extracts) where the processor holds the data.
• The controller decides admissibility and bears the Chapter III one-month deadline, which is not extended because the information sits with the processor — the DPA should set internal response times accordingly.
• Practical carve-out: unsubscribe/objection signals must also keep working operationally regardless of DSR plumbing — suppression is both an Art. 21 absolute right and a deliverability requirement.

International transfers (GDPR Chapter V)

Transfers outside the EEA — including the ESP's own non-EU infrastructure or divisions, and non-EU sub-processors — need a Chapter V mechanism. Processor-relevant toolkit:

1. Adequacy decisions (Art. 45) — transfer as if intra-EU. Current list: Andorra, Argentina, Brazil (from 26 Jan 2026), Canada (commercial organisations/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 DPF-certified organisations. Certification is administered by the US Department of Commerce (public list); FTC enforces; complaint routes include the organisation (45-day response), independent dispute resolution, DPAs, and binding arbitration as last resort. The decision rests on Executive Order 14086 (necessity/proportionality limits on signals intelligence) and the Data Protection Review Court redress mechanism — the fixes for the Schrems II invalidation of Privacy Shield.
• Legal-challenge status (verified July 2026): the DPF survived its first judicial challenge. In Latombe v Commission (Case T-553/23) the General Court dismissed the annulment action on 3 September 2025, upholding the adequacy decision — it found the Data Protection Review Court sufficiently independent and impartial and US bulk-collection limits and redress 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 relying on DPF should continue to monitor 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 27 June 2021. One modular document, four modules:

Module	Transfer
One	Controller → controller
Two	Controller → processor (EU customer → non-EU ESP)
Three	Processor → processor (EU ESP → non-EU sub-processor)
Four	Processor → controller

Key mechanics: the old SCC decisions (2001/497/EC, 2010/87/EU) were repealed 27 September 2021, with legacy contracts valid until 27 December 2022 if processing was unchanged; a docking clause (Clause 7) lets new parties accede later; Clause 14 implements Schrems II — the parties must assess whether destination-country law and practice prevent compliance, document a transfer impact assessment, and apply supplementary measures (technical/organisational/contractual) where needed. Modules Two and Three double as an Art. 28-compliant DPA for the transfer relationship, so no separate 2021/915 DPA is needed for the same relationship.

3. Other Art. 46 safeguards — Binding Corporate Rules (intra-group), approved codes of conduct, certification mechanisms. Art. 49 derogations (explicit consent, contract necessity…) are for occasional, non-repetitive transfers — not a basis for routine ESP data flows.

Chapter V binds processors as well as controllers: an EU ESP is itself the data exporter toward its non-EU sub-processors 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

Processor discipline and deliverability discipline converge: documented instructions and the refuse-unlawful-instruction duty are the compliance backbone for vetting customers and refusing purchased lists; breach-notification plumbing overlaps with the abuse-desk escalation paths providers expect; and clean role separation (never mining customer lists for the ESP's own purposes) is also what keeps an ESP out of the data-broker reputation tier that both regulators and Spamhaus police.