GDPR Article 28: DPA Requirements & Processor Duties (2026)
GDPR Article 28 explained: the mandatory DPA clauses, controller due-diligence duties, sub-processor authorisation, EDPB Opinion 22/2024, and how to prove it.
GDPR Article 28: Processor Obligations & DPA Requirements
GDPR Article 28 governs the relationship between a data controller and a data processor. It requires the controller to engage only processors that provide "sufficient guarantees" of appropriate security, and it requires the relationship to be governed by a binding contract — the Data Processing Agreement (DPA) — that contains eight mandatory sets of terms listed in Article 28(3). It also sets the rules for sub-processing: a processor may not appoint another processor without the controller's prior specific or general written authorisation, and remains liable for that sub-processor's compliance.
For any B2B SaaS company, Article 28 is the article that shows up in every enterprise deal. Your customers are controllers; you are their processor; and the DPA is the contract that makes the relationship lawful. This page is the legal reference for what Article 28 requires — the mandatory clauses, the controller's ongoing due-diligence duty, and the sub-processor rules that EDPB Opinion 22/2024 tightened. For the operational side — how to run a public subprocessor list and change-notice workflow that controllers actually trust — see our companion guide on subprocessor management under Article 28.
Key Takeaways
- Article 28 requires a written contract (the DPA) with every processor, containing the eight mandatory commitments in Article 28(3).
- "Sufficient guarantees" is a continuous obligation. Under Article 28(1) and EDPB Opinion 22/2024, the controller must verify the processor's guarantees at appropriate intervals — not once at signing.
- Sub-processors need authorisation (Article 28(2)) — specific or general — and the same data protection obligations must be passed down by contract (Article 28(4)).
- Liability stays with the initial processor. If a sub-processor fails, the processor — not the sub-processor — answers to the controller (Article 28(4)).
- EDPB Opinion 22/2024 raised the bar: controllers must be able to identify every processor and sub-processor in the chain at all times, and remain responsible for onward-transfer safeguards.
- A DPA violation is fineable under Article 83(4): up to EUR 10 million or 2% of global annual turnover.
Jump to:
- What Article 28 Requires
- Selecting a Processor: "Sufficient Guarantees"
- The 8 Mandatory DPA Clauses (Article 28(3))
- Sub-Processor Authorisation (Article 28(2) & (4))
- What EDPB Opinion 22/2024 Changed
- How to Prove Processor Compliance
- Fines and Enforcement
- The UK and Norway Position
- Operationalising Article 28
What Article 28 Requires
Article 28 of Regulation (EU) 2016/679 is the GDPR's answer to a simple structural fact: most personal data is not processed by the organisation that decides why it is processed. A controller (the organisation that determines the purposes and means) almost always relies on processors — cloud hosting, analytics, payment, CRM, support tooling — to actually carry out the processing. Article 28 governs that relationship so that responsibility does not evaporate when data is handed over.
It does three things:
- Sets a selection duty — the controller may only use processors offering "sufficient guarantees" (Article 28(1)).
- Mandates a contract — the processing must be governed by a DPA with prescribed content (Article 28(3)).
- Regulates the chain — a processor may only engage sub-processors under defined authorisation rules, and stays liable for them (Article 28(2) and (4)).
For B2B SaaS companies the point is unavoidable: you are almost always both a controller (for your own employee and customer-account data) and a processor (for the data your customers store in your platform). Article 28 therefore applies to you in both directions — inbound, as you vet your own vendors, and outbound, as your customers vet you.
Selecting a Processor: "Sufficient Guarantees"
Article 28(1) sets the threshold condition:
"Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject."
This is a due-diligence obligation, not a box to tick at onboarding. The EDPB Opinion 22/2024 (issued 9 October 2024) is explicit that "sufficient guarantees" is a continuous obligation: the controller "should, at appropriate intervals, verify the processor's guarantees." The depth of verification scales with risk — high-risk processing demands more scrutiny — but the duty itself applies regardless of risk level.
In practice, "sufficient guarantees" is where certifications earn their keep. An ISO 27001 certificate, a SOC 2 report, or a maintained Trust Center gives a controller a defensible, repeatable basis for concluding a processor is suitable — which is exactly why European procurement teams ask for them before they ask for anything else.
The 8 Mandatory DPA Clauses (Article 28(3))
Article 28(3) requires the processing to be governed by "a contract or other legal act" that is binding on the processor, and it prescribes eight commitments the DPA must contain. This is the single most-tested part of Article 28 in a procurement review — a DPA missing any of these is non-compliant:
| # | Mandatory DPA commitment | Legal basis |
|---|---|---|
| 1 | Process personal data only on documented instructions from the controller (including on international transfers) | Art. 28(3)(a) |
| 2 | Ensure persons authorised to process the data are under a duty of confidentiality | Art. 28(3)(b) |
| 3 | Take all security measures required by Article 32 | Art. 28(3)(c) |
| 4 | Respect the conditions for engaging sub-processors in Art. 28(2) and (4) | Art. 28(3)(d) |
| 5 | Assist the controller in responding to data-subject rights requests | Art. 28(3)(e) |
| 6 | Assist the controller with security, breach notification, and DPIA obligations (Articles 32–36) | Art. 28(3)(f) |
| 7 | Delete or return all personal data at the end of the engagement (controller's choice) | Art. 28(3)(g) |
| 8 | Make available all information needed to demonstrate compliance, and allow and contribute to audits and inspections | Art. 28(3)(h) |
Two of these carry outsized operational weight. Clause 1 (documented instructions) is why "process only as instructed" language appears in every DPA — EDPB Opinion 22/2024 confirms that alternative wording such as "unless required by law or a binding governmental order" does not infringe Article 28, but also does not exonerate either party from their GDPR duties. Clause 8 (audit and information rights) is the one enterprise buyers exercise most: it is the legal basis for the security questionnaire, the audit request, and the demand to see your evidence — the recurring cost that a self-serve Trust Center is designed to eliminate.
Article 28(5) adds that adherence to an approved code of conduct (Article 40) or certification mechanism (Article 42) can be used as an element to demonstrate the sufficient guarantees required by Article 28(1).
Sub-Processor Authorisation (Article 28(2) & (4))
A processor rarely works alone. When it engages another processor — a sub-processor — Article 28 imposes two rules.
Authorisation (Article 28(2)). The processor "shall not engage another processor without prior specific or general written authorisation of the controller."
- Specific authorisation — the controller approves each sub-processor individually, in writing, before engagement.
- General authorisation — the controller gives advance approval on condition that the processor "inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object."
Most B2B SaaS companies operate under general authorisation, because specific authorisation is operationally heavy for both sides. But general authorisation is not a blank cheque: it is conditional on transparent, proactive change notification and a real opportunity to object.
Pass-down and liability (Article 28(4)). When a sub-processor is engaged, "the same data protection obligations as set out in the contract… shall be imposed on that other processor," and — critically — "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." Liability does not cascade away down the chain; it stays with the processor the controller contracted with.
The practical implementation of these rules — the public subprocessor list, the notice window, and the objection workflow — is the subject of our operational companion guide, subprocessor management under GDPR Article 28: what controllers actually expect, and the ready-to-send GDPR subprocessor change-notice workflow.
What EDPB Opinion 22/2024 Changed
In October 2024 the EDPB issued Opinion 22/2024 on obligations arising from reliance on processors and sub-processors. It did not change the text of Article 28, but it clarified how supervisory authorities will apply it — and the reading is strict:
- Full-chain visibility. Controllers "should have the information on the identity (i.e. name, address, contact person) of all processors, sub-processors etc. readily available at all times." The processor must proactively provide this and keep it up to date. Disclosing only the first line of sub-processors is not enough — the whole chain must be identifiable.
- Verification is continuous but proportionate. The controller need not systematically demand every sub-processing contract; it may rely on information the processor provides, assessed case by case, with deeper verification for higher-risk processing. But ultimate responsibility for proving sufficient guarantees rests with the controller.
- Onward transfers stay the controller's problem. Even where the initial processor is in the EEA, the controller remains responsible for ensuring sufficient guarantees — including transfer impact assessments — for any onward transfer of data outside the EEA by a sub-processor.
The Opinion is not legally binding, but it is immediately applicable and national authorities will apply it in investigations. Its practical effect is to make a current, complete, machine-usable sub-processor list — not a stale PDF appendix — the baseline a controller now needs to meet its own accountability duty. That is a requirement your customers will push down onto you.
How to Prove Processor Compliance
Article 28 is a two-sided obligation, and the demonstrable half is where deals are won. Your customer (the controller) has to prove it did due diligence on you; you (the processor) have to make that easy. The processors that convert enterprise pipeline are the ones that turn Article 28 into self-serve evidence rather than a bespoke legal exercise per deal.
| Article 28 obligation | What the controller wants to see | How to provide it |
|---|---|---|
| 28(1) Sufficient guarantees | Certifications and current security posture | ISO 27001 / SOC 2 reports in a Trust Center |
| 28(3) A compliant DPA | A signable DPA with all eight clauses | A pre-published, standard DPA hosted for download |
| 28(3)(c) Article 32 measures | Your TOMs / security whitepaper | A maintained Article 32 measures document |
| 28(2) Sub-processor authorisation | A current, complete sub-processor list + change notices | A public subprocessor page with automated notifications |
| 28(3)(h) Audit & information rights | Answers to security questionnaires, evidence packs | Self-serve evidence in a Trust Center — not a per-deal email thread |
The through-line is the same as the rest of the GDPR: accountability under Article 5(2) means the answer to "prove it" has to be retrievable on demand. For a processor, the cheapest place to make Article 28 evidence retrievable is one hosted surface every customer can reach — which is precisely what a Trust Center is for.
Fines and Enforcement
Violations of Article 28 fall in the lower fine tier under Article 83(4): up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Article 28 findings frequently travel alongside Article 32 (security) and Article 5 (accountability) findings, because a weak processor relationship usually reveals weak security and weak documentation at the same time. Germany's EUR 45 million set of fines against Vodafone in 2025, for example, included inadequate oversight of data processors.
The broader context is an enforcement environment that is no longer sporadic: cumulative GDPR fines reached EUR 7.1 billion by January 2026, with roughly EUR 1.2 billion issued in 2025 alone, according to the DLA Piper GDPR Fines and Data Breach Survey (January 2026). With EDPB Opinion 22/2024 sharpening expectations on sub-processor transparency, the processor relationship is a rising area of supervisory attention rather than a settled one.
The UK and Norway Position
Article 28 is a pan-European standard, and the controller–processor rules are consistent across the wider European compliance landscape.
United Kingdom. UK GDPR retains Article 28 and its mandatory DPA content in identical substance, overseen by the Information Commissioner's Office (ICO). The Data (Use and Access) Act 2025 (Royal Assent 19 June 2025) reformed parts of UK data protection but left the controller–processor framework intact, and the European Commission moved to renew the UK's adequacy decision after reviewing the reforms — so EU–UK data flows, and cross-border DPAs, continue uninterrupted.
Norway and the EEA. Norway applies the GDPR through the EEA Agreement (in force since July 2018), so Article 28 binds Norwegian controllers and processors in identical terms, supervised by Datatilsynet. The DPA clauses, the sufficient-guarantees duty, and the sub-processor rules are the same — meaning a single Article 28-compliant DPA framework and sub-processor process serves the EU, EEA, and UK at once.
Operationalising Article 28 in a Trust Center
Article 28 is a contract-and-evidence obligation, and it is won by removing friction from the two moments it bites: signing the DPA, and proving compliance afterwards. Three capabilities do most of the work:
- A pre-published, standard DPA with all eight Article 28(3) clauses, hosted for self-serve download — so the DPA stops being a per-deal negotiation and becomes a document a customer can accept.
- A current, complete sub-processor list with automated change notifications and a defined objection window — the baseline EDPB Opinion 22/2024 now expects, delivered through a public Trust Center page rather than a stale appendix. Our subprocessor change-notice workflow and free change-notice template cover exactly what each notice must contain.
- Self-serve compliance evidence — certifications, TOMs, and audit-support material in one place — so the Article 28(3)(h) audit-and-information right is satisfied by a link, not a questionnaire cycle.
This is the ISMS-and-Trust-Center model applied to the processor relationship: an ISMS produces the sufficient guarantees Article 28(1) demands, and a Trust Center makes them demonstrable to every controller who asks. Orbiq's Trust Center platform keeps the DPA, subprocessor list, certifications, and evidence current and reachable — turning Article 28 from a recurring legal cost into a standing sales asset.
Host your DPA and subprocessor list in a Trust Center. See how Orbiq handles Article 28 evidence →
Sources & References
- Regulation (EU) 2016/679 (GDPR) — Full Text (EUR-Lex ELI) — Official Journal of the European Union; Article 28 in context.
- gdpr-info.eu — Article 28 (Processor) — Article text and recitals.
- EDPB Opinion 22/2024 on reliance on processors and sub-processors (PDF) — Adopted 9 October 2024; full-chain identification, continuous verification, onward transfers.
- EDPB — Guidelines 07/2020 on the concepts of controller and processor — Version 2.1; controller–processor relationships and sub-processing.
- DLA Piper GDPR Fines and Data Breach Survey: January 2026 — EUR 7.1 billion cumulative; EUR 1.2 billion in 2025.
- ICO — Contracts and liabilities between controllers and processors (UK GDPR) — UK Article 28 guidance.
- Datatilsynet — Norwegian Data Protection Authority — Processor guidance (Norway / EEA).
Related Reading
- GDPR Compliance in 2026: Principles, Rights & How to Prove It
- GDPR Compliance for B2B SaaS: Articles 28–34 Explained
- GDPR Article 32: Security of Processing Requirements
- Subprocessor Management under GDPR Article 28: What Controllers Actually Expect
- GDPR Subprocessor Change Notices: The Article 28 Notification Workflow
- Free Template: GDPR Subprocessor Change Notice
- Trust Center Platform
Frequently Asked Questions
What does GDPR Article 28 require?
Article 28 governs the controller–processor relationship. It requires controllers to use only processors that provide 'sufficient guarantees' to implement appropriate security measures, and it requires the relationship to be governed by a binding contract — the Data Processing Agreement (DPA) — containing eight mandatory sets of terms set out in Article 28(3). It also regulates sub-processor engagement: a processor may not appoint another processor without the controller's prior specific or general written authorisation.
What must a Data Processing Agreement (DPA) contain under Article 28(3)?
Article 28(3) requires the DPA to bind the processor to eight commitments: (a) process only on documented instructions; (b) ensure personnel confidentiality; (c) take all Article 32 security measures; (d) respect the conditions for engaging sub-processors; (e) assist the controller with data-subject rights requests; (f) assist with security, breach-notification, and DPIA obligations (Articles 32–36); (g) delete or return the data at the end of the engagement; and (h) make available all information needed to demonstrate compliance and allow audits and inspections.
What is the difference between specific and general sub-processor authorisation?
Under Article 28(2), a processor can engage a sub-processor only with the controller's authorisation. Specific authorisation means the controller approves each sub-processor individually before it is engaged. General authorisation means the controller gives advance blanket approval, on condition that the processor informs it of any intended addition or replacement and gives it the opportunity to object. Most B2B SaaS companies operate under general authorisation.
Who is liable if a sub-processor breaches the GDPR?
Under Article 28(4), where a processor engages a sub-processor, the same data protection obligations must be imposed on that sub-processor by contract — and the initial processor remains fully liable to the controller for the sub-processor's performance. Liability does not transfer down the chain. EDPB Opinion 22/2024 confirms the controller must be able to identify every processor and sub-processor in the chain at all times.
Does GDPR Article 28 apply in the UK and Norway?
Yes, in equivalent form. UK GDPR retains Article 28 and its mandatory DPA terms, overseen by the ICO. Norway applies the GDPR through the EEA Agreement, supervised by Datatilsynet. The DPA content requirements and the sub-processor authorisation rules are consistent across the EU, EEA, and UK, so a single Article 28-compliant DPA framework works across all three.