GDPR Article 28: Data Processing Agreements — What Every SaaS Developer Must Include in Their DPA

Post #866 in the sota.io EU Cyber Compliance Series

If you build a SaaS product and use any cloud infrastructure, email delivery service, analytics platform, or logging tool that processes personal data on your behalf, you are legally required to have a written Data Processing Agreement (DPA) in place with each of those vendors. Under GDPR Article 28, the absence of a valid DPA is not a procedural gap — it is a substantive violation that invalidates the legal basis for the processing itself.

The fine for missing or inadequate DPAs is not a minor infraction. Article 83(4) places DPA violations in the €10 million or 2% of global annual turnover tier. But the real risk is operational: if your DPA with a cloud provider is found inadequate during a supervisory authority audit, every personal data transfer to that provider becomes unlawful retroactively, creating exposure for every data subject whose data was processed without a valid legal mechanism.

This guide covers what Article 28 actually requires, the eight mandatory DPA clauses, how sub-processor authorization works, why US-provider DPAs have a structural weakness under the CLOUD Act, and what compliant EU-native processing looks like.

Controller vs. Processor: The Threshold Question

Before drafting a DPA, you need to correctly classify your relationship with each vendor. Article 28 applies specifically to the controller–processor relationship. Getting this wrong invalidates your compliance approach.

Critical distinction: If a vendor processes personal data for their own purposes — including using it to improve their models, train AI systems, or build their own products — they are an independent controller, not your processor. You cannot control this processing via a DPA. This is why certain US AI service providers and analytics vendors cannot be brought into DPA compliance no matter what the contract says: the contract cannot override the underlying processing purpose.

When you are a processor: If you build a B2B SaaS — a project management tool, HR software, or CRM — where the customer decides what personal data goes in and why, you are acting as a processor for your customers. You need both an inbound DPA (from your customers appointing you as processor) and outbound DPAs (with the cloud providers you use to deliver the service).

The Eight Mandatory DPA Clauses Under Article 28(3)

Article 28(3) specifies that every controller–processor contract must include eight minimum elements. The absence of any one of them renders the DPA legally defective.

1. Process Only on Documented Instructions

"processes the personal data only on documented instructions from the controller"

The processor must not process personal data beyond what the controller has explicitly instructed. This clause must include:

• The subject matter, nature, and purpose of processing
• The type of personal data and categories of data subjects
• The duration of processing
• A statement that the processor will not process data for its own purposes

Practical implication: Generic "we process data to provide the service" language does not satisfy this requirement. The instructions must be specific enough that a regulator could verify whether the processor stayed within them.

2. Confidentiality of Personnel

"ensures that persons authorised to process the personal data have committed themselves to confidentiality"

All staff, contractors, and subcontractors with access to personal data must be under a binding confidentiality obligation — either by contract or by statutory duty (such as professional secrecy under national law).

This clause is routinely overlooked in SME DPAs. If your cloud provider allows engineers to access customer data for support or debugging without documented confidentiality obligations on those specific individuals, the DPA fails on this point.

3. Technical and Organisational Measures

"takes all measures required pursuant to Article 32"

The DPA must commit the processor to implementing the security measures required under GDPR Article 32: encryption, pseudonymisation, availability controls, resilience, and regular testing. The DPA should either specify the measures or incorporate the processor's security documentation by reference.

A bare commitment to "maintain appropriate security" without specifying what those measures are will not survive a regulatory audit. Article 32 requires measures appropriate to the risk, and the DPA must demonstrate that both parties assessed what that means for the specific processing.

4. Sub-processor Authorization

"respects the conditions referred to in paragraphs 2 and 4 for engaging another processor"

The processor may not engage sub-processors without the controller's authorization. Article 28(2) allows two models:

Under the general authorization model, the processor must notify the controller of any intended changes to sub-processors before the change takes effect, not after. The controller then has a right to object. The catch: if the controller objects and the processor cannot provide an alternative, the controller may need to terminate the contract. Most hyperscaler DPAs give 30 days notice but limit the right to terminate.

AWS's approach: AWS's DPA uses the general authorization model with a public sub-processor list. Changes are communicated via email subscription or RSS feed. Controller must object within 30 days. AWS does not guarantee it can isolate EU workloads from all listed sub-processors — some are internal AWS entities in third countries.

The sub-processor chain problem: When you use AWS (processor) which uses other AWS entities across regions, you have a sub-processor chain. Each link must have the same Article 28 protections flowed down. AWS's DPA contains a sub-processor obligation cascade, but the practical enforceability across AWS's 190+ internal entities remains untested in litigation.

5. Assist with Data Subject Rights

"taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights"

Your cloud provider must have mechanisms to help you:

• Identify and retrieve specific data for a subject access request
• Delete specific data for an erasure request
• Export data in a structured format for a portability request
• Restrict processing for a restriction request

The DPA must specify how this assistance will be provided. "Contact support" is not sufficient. The processor needs queryable data models, audit logs of data locations, and documented deletion procedures that can isolate individual data subject records.

Why this matters for infrastructure choice: A provider that comingles customer data in shared storage with limited per-record isolation capability cannot satisfy this clause in practice. Object storage with mandatory encryption keys shared across customers, or analytics systems that aggregate data in ways that prevent individual erasure, create structural compliance failures regardless of what the DPA says.

6. Assist with Security and DPIA Obligations

"assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36"

The processor must assist with:

• Security obligations (Art.32)
• Breach notification (Art.33: 72-hour supervisory authority report)
• Communication to data subjects after a breach (Art.34)
• Data Protection Impact Assessments (Art.35)
• Prior consultation with supervisory authority (Art.36)

For breach notification, this means the processor must notify the controller of any personal data breach without undue delay — EDPB guidelines say within 36 hours where possible to give the controller enough time to meet the 72-hour regulatory deadline. A DPA that only requires "prompt notification" without specifying a timeframe creates a gap that regulators scrutinize.

The 36-hour internal breach notification standard: Many hyperscaler DPAs specify 72 hours for incident notification, which leaves the controller zero margin to investigate and prepare the supervisory authority notification. Processors should contractually commit to shorter windows — 24 to 36 hours — to give controllers operational breathing room.

7. Delete or Return Data After Service Termination

"at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services"

The processor must either delete or return all personal data — including copies in backups — upon termination of the DPA. The controller must be able to specify which they want. Critically, backup copies are not exempt: a processor cannot claim that backup retention schedules prevent compliance with deletion requests under the DPA.

Practical complications: Cloud providers with snapshot and backup services often have retention policies that create gaps here. AWS S3 Glacier with Vault Lock, for example, creates immutable archives that cannot be deleted for the configured retention period. If personal data lands in Glacier-backed backups, you have a structural conflict between your DPA obligations and the storage service's immutability features.

The DPA must address this explicitly, either by excluding personal data from immutable storage or by documenting the retention period and getting the controller's informed agreement that this is the minimum technically feasible.

8. Provide Audit Cooperation

"makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller"

The processor must allow the controller (or its appointed auditor) to conduct audits of compliance with the DPA. In practice, most hyperscaler DPAs satisfy this via:

1. SOC 2 Type II / ISO 27001 reports provided in lieu of direct audit rights
2. Questionnaire-based assessments where the controller submits questions and the provider responds in writing
3. Third-party audits commissioned by the provider and shared under NDA

This creates a practical limitation: the controller cannot conduct an unannounced audit of an AWS data centre. The standard alternative — SOC 2 reports — covers a different scope than a GDPR Article 28 compliance audit and does not address jurisdiction, CLOUD Act exposure, or sub-processor chain controls specifically.

The CLOUD Act Problem in US-Provider DPAs

A DPA cannot override the legal obligations of the processor's jurisdiction. This is the structural weakness in every DPA signed with a US-incorporated cloud provider.

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2523) allows US federal agencies to compel US companies to disclose data stored on servers anywhere in the world, including EU data centres. The obligation runs to the parent company, not to the local subsidiary.

The European Court of Justice addressed the underlying principle in Schrems II (C-311/18): transfers to the US cannot rely on adequacy where US law creates surveillance access incompatible with GDPR Article 46. The Data Privacy Framework (DPF, August 2023) provides a temporary adequacy finding for DPF-certified companies, but this finding is contested and subject to annual Commission review.

The CLOUD Act gap in US-provider DPAs is not a hypothetical risk. The Microsoft Ireland case (2016-2018) demonstrated that the US government actively pursues data held by US companies in EU data centres. While the CLOUD Act subsequently created executive agreement mechanisms, no EU–US bilateral agreement under 18 U.S.C. § 2523(b) has been concluded that would give EU data subjects effective redress.

What this means for DPA validity: EDPB Opinion 28/2024 (December 2024) found that DPAs with US providers must include specific risk assessments addressing CLOUD Act exposure and the specific processing context. A standard DPA that does not acknowledge and mitigate this jurisdictional risk may be found inadequate during a supervisory authority review.

DPA Requirements When You Are the Processor

If your SaaS product processes customer data on behalf of business customers, you are their processor. Your inbound DPA — the one you provide to your customers — must satisfy Article 28 from the other direction.

Common SaaS inbound DPA failures:

Sub-Processor Lists and Notification Obligations

Article 28(2) requires that when using general authorization for sub-processors, the processor maintains an up-to-date list of sub-processors and notifies the controller of intended changes.

For a typical SaaS stack, your sub-processor list will include:

Each of these requires a valid DPA. The DPA with your main cloud provider does not cover sub-services that operate under separate contracts or independent service terms.

Notification mechanics: When a sub-processor changes, you must notify customers before the change takes effect and give them a meaningful opportunity to object. If a customer objects and you cannot provide the service without the new sub-processor, the contract may be terminable. Many SaaS providers handle this through email notification to a designated DPA contact, with a 30-day objection window — but this only works if you have accurate contact information and a functioning notification process.

Practical DPA Implementation Checklist

Use this checklist when reviewing existing DPAs or drafting new ones:

Outbound DPAs (with your vendors):

• DPA exists as a written document separate from general vendor terms
• Processing subject matter, nature, purpose, data types, and duration specified
• All eight Article 28(3) elements present
• Sub-processor list available and change notification mechanism defined
• Breach notification timeline specified (target: ≤36 hours to give you margin for your 72-hour obligation)
• Deletion timeline and backup coverage addressed
• Audit rights defined — including what documentation the vendor will provide
• CLOUD Act risk assessment completed if vendor is US-incorporated
• Chapter V transfer mechanism documented if data leaves EEA (Standard Contractual Clauses, adequacy decision, or Binding Corporate Rules)

Inbound DPAs (what you provide to your customers):

• DPA is a separate document or clearly demarcated section of your terms
• Your role as processor clearly stated for each processing activity
• Comprehensive sub-processor list published and maintained
• Change notification process documented with objection window specified
• Security measures described in operational terms, not generic language
• Deletion process and timeline defined for all data, including backups
• Audit cooperation scope and mechanics defined

DPA Violations: Enforcement Trajectory

The DPA framework has moved from a background compliance item to an active enforcement focus. Notable enforcement:

The EDPB's 2024 coordinated enforcement round on cloud contracts specifically reviewed DPA adequacy for sub-processor chains, breach notification clauses, and audit rights. The findings showed that a majority of reviewed DPAs had at least one defective clause under Article 28(3).

Why EU-Native Processors Change the DPA Equation

Choosing an EU-incorporated processor does not eliminate DPA requirements — you still need a compliant DPA. But it removes the foundational jurisdictional problem that makes US-provider DPAs structurally fragile.

An EU-incorporated processor:

• Is not subject to CLOUD Act compelled disclosure
• Cannot be served with a National Security Letter requiring silent data disclosure
• Falls exclusively under EU/EEA legal frameworks that are compatible with GDPR
• Does not require a Chapter V transfer mechanism for EEA-to-EEA processing

The DPA you sign with an EU-native provider does not need to contain risk assessments about foreign surveillance law, cannot be undermined by gag orders that prevent breach notification, and does not create the structural paradox where a DPA clause conflicts with the processor's statutory obligations under foreign law.

For SaaS developers building products for EU business customers, the DPA your customers will review is often part of their procurement checklist. A DPA that does not address CLOUD Act exposure, that relies on Data Privacy Framework adequacy that remains legally contested, or that contains generic security language will fail procurement reviews at mid-market and enterprise EU customers with competent data protection teams.

Summary

GDPR Article 28 creates a mandatory written contract between every controller and processor. The eight required clauses are not defaults — each one must be explicitly present. Sub-processor chains must be authorized, documented, and subject to change notification. US cloud provider DPAs have a structural limitation that no contract clause can fully address: the CLOUD Act can override the DPA's instruction requirement without the controller's knowledge.

For SaaS developers, the practical priority is:

1. Audit your sub-processor list — identify every service that touches personal data
2. Verify DPAs exist for each vendor — standard Terms of Service are not DPAs
3. Check the eight mandatory clauses in each DPA — generic language fails
4. Complete transfer impact assessments for US-incorporated processors
5. Review your inbound DPA — what you provide to customers must satisfy their Article 28 rights, including audit cooperation and sub-processor notification

The EDPB's enforcement trajectory and the coordinated cloud contract review indicate that supervisory authorities are treating DPA compliance as a current enforcement priority, not a theoretical risk.

sota.io is an EU-incorporated PaaS that provides a GDPR Article 28-compliant data processing agreement. Our infrastructure runs exclusively within the EU, our sub-processor list covers only EU-incorporated entities, and we do not use US-incorporated cloud providers for data processing. Start your free deployment →