Data Processing Agreement (DPA) & GDPR | IT-Medienrecht

Learn how to create a robust Data Processing Agreement (DPA) under Art. 28 GDPR. Discover mandatory contents, practical clauses, and avoid common errors.

Order processing is part of everyday life, encompassing tasks like cloud hosting, newsletter distribution, support desk management, payment gateway operations, AI labeling, and CRM functions. When personal data is processed on behalf of others, Article 28 GDPR mandates a robust data processing agreement (DPA). This DPA is not merely a form attachment; it serves as the legally binding bridge between technology, organization, and liability. This article structures the mandatory contents of Article 28 Paragraph 3 GDPR, offering practical clause mechanics for sub-processors, audits, Technical and Organizational Measures (TOMs), and data portability, while also highlighting typical error patterns. The text builds upon the compact knowledge articles found on itmedialaw.com, but delves deeper into operational aspects relevant for SaaS, agency, games, and AI setups.

Starting Point and Area of Application of a Data Processing Agreement

Order processing refers to the handling of personal data "on behalf of" a controller. The crucial factor is not the label "service provider" but rather the processor's adherence to instructions and purpose limitation. This means the processor acts exclusively within the documented instructions of the controller, not for its own purposes. Typical scenarios include hosting, email dispatch, analytics, payroll accounting, ticket systems, content moderation, or data enrichment.

A clear distinction between joint controllership (Art. 26 GDPR) and independent controllership is essential. Entities that co-determine purposes are no longer considered "mere processors." This legal clarity helps prevent role conflicts and ensures that data subjects’ rights, information obligations, erasure periods, and security levels are correctly assigned. For a deeper dive into the cloud context and contractual features, refer to our article on contractual features of different cloud models.

Core Elements of a Data Processing Agreement

Subject Matter and Duration of Processing

A DPA must clearly specify the subject matter and duration of the processing. This goes beyond a simple heading like "Hosting." It requires a detailed description of the processing operations covered by the contract. These operations can include:

The duration typically aligns with the main contract's lifetime, but requires differentiation for backups, log retention, and follow-up processes. Without such distinctions, deletion and data release might remain purely theoretical.

Type and Purpose of Processing

The DPA also requires a specification of the type and purpose of the processing. For instance, a CRM operator processes master, contact, and interaction data for customer management. A DSP/AdTech partner handles pseudonymous IDs for campaign management. An annotation service processes image, text, or audio segments for AI training. The defined purpose is strict; a "purpose update" for the processor's internal analytics is not permitted without a separate legal basis.

Types of Personal Data and Categories of Data Subjects

The DPA must specify the type of personal data and the categories of data subjects involved. These categories should be project-specific, not generic. Examples include customers, leads, employees, creators, or player accounts. Data types might encompass identification, communication, contract, usage, support, payment, or health data. The more sensitive the data (Art. 9 GDPR), the more precise the TOMs and stricter the sub-processor control must be.

Rights and Obligations of the Controller

The DPA (referred to as GCU in the original text) outlines the rights and obligations of the controller, particularly the right to issue instructions. Instructions must be documented in writing or within a system. The processor is obliged to check obviously unlawful instructions and report any concerns. The instruction regime also covers emergency instructions, crucial for immediate action during security incidents.

Confidentiality, Technical and Organizational Measures (TOMs), and Security Level

The core obligations of the processor include confidentiality, adherence to Technical and Organizational Measures (TOMs), and maintaining a specified security level. Every individual with data access must maintain confidentiality. The TOMs, based on Art. 32 GDPR, are maintained as a dynamic annex. These measures consider the state of the art, implementation costs, type, scope, circumstances, and purposes of processing.

A DPA should not merely reference "ISO certificates." Instead, it must describe specific measures:

For more on structuring these security measures, particularly regarding data separation, you might find our article on Multi-tenant architectures in the SaaS sector insightful.

Processor's Support Obligations

The processor must support the controller in various areas, including:

Each support obligation requires clear response times and process descriptions. Without Service Level Agreement (SLA) cycles, meeting deadlines becomes challenging. For insights into managing security incidents effectively, consider our guide on Data leak in startup practice: GDPR reporting and damage limitation.

Data Deletion or Return Post-Processing

Upon completion of the processing order, personal data—including archive, backup, and log files—must be deleted or returned. This is contingent on the absence of conflicting legal retention requirements. The DPA specifies export formats and verification mechanisms, such as random deletion checks or hash-based comparison procedures, to prevent "deletion fictions."

Verification and Audit Obligations

Finally, verification and audit obligations must be firmly established. The processor is required to provide all necessary information to demonstrate compliance and enable audits. These audits can be conducted by the controller or independent auditors, always with appropriate safeguards. The DPA balances confidentiality, audit frequency, and costs. It typically allows for remote audits, combined audit weeks, recognition of reports (e.g., ISO/SOC), and follow-up audits after major incidents.

For the design of a DPA, it is important that an electronic form is sufficient (Art. 28 para. 9 GDPR). Therefore, a DPA can be signed electronically or managed via a portal. Active change logs and version statuses are crucial for evidentiary purposes during audits.

Sub-processors: Permission, Chain, Control

Modern IT setups rarely operate without sub-processors. Article 28 Paragraphs 2 and 4 GDPR mandate prior authorization and the extension of all data protection obligations to these sub-processors. Two common models exist: specific individual authorization or general authorization coupled with a sub-processor register and an objection right. General approval is standard practice, featuring clear notice periods for changes and new additions, often differentiated by "critical" (e.g., storage, core compute, identity) and "non-critical" (e.g., email delivery) functions.

A sub-processor register meticulously lists the company, its function, country, data categories processed, and relevant TOM anchors. The "flow-down" principle dictates that identical data protection obligations apply throughout the processing chain, including audit cooperation and incident reporting channels. For processing in third countries, additional guarantees like Standard Contractual Clauses (SCCs) and, if applicable, Transfer Impact Assessments (TIAs) are necessary. A streamlined yet robust process is vital to prevent "shadow sub-processors" and to manage change scenarios without disrupting operations.

Audit Rights Without Downtime: Evidence, Remote Verification, Recognition Logic

Audits are designed to ensure compliance, not to halt operations. The DPA explicitly defines how audits are to be conducted, prioritizing remote audits. These typically involve inspecting policies, TOM systems, risk and action registers, random sampling of tickets/incidents, and reviewing pen test summaries and certification reports. On-site audits are reserved for safety-critical situations and are performed during pre-scheduled slots.

A recognition mechanism clarifies which external evidence—such as ISO 27001 or SOC 2 Type II reports—can partially fulfill audit obligations without undermining statutory inspection rights. Defined deadlines, audit day quotas, and confidentiality safeguards (e.g., clean rooms, view-only access) are essential to prevent data leaks and minimize trade secret risks.

Setting Up TOMs Correctly: Art. 32 Level, But Operational

Too often, TOM annexes are reduced to mere lists of keywords. A TOM annex becomes truly effective when its technical and organizational measures are categorized, measurable, and verifiable. These measures include:

The effectiveness of these measures is tested cyclically and after significant changes, with results feeding into a risk register. Supervisory authorities emphasize that TOMs do not necessarily need to be fully detailed within the DPA itself, but must be verifiably evaluated and documented. Operationally, versioning within an annex with a change log is a practical approach. For further insights into compliance, especially for SaaS, consider our article on NIS2 compliance 2025.

Data Portability, Exit Strategy, and Proof of Deletion

Even the most meticulously drafted DPA loses value if the exit process is ambiguous. A portability clause is therefore essential, defining export paths in detail:

For complex client data, especially in SaaS systems, a "read-only phase" is often agreed upon after contract termination. During this period, access remains possible, but no new processing occurs. Deletion extends beyond merely removing data from production systems; the DPA must cover backups, snapshots, cold storage, crash dumps, and log data. Random deletion tests or hash comparisons ensure verifiable proof of deletion without revealing company secrets. In chained relationships, the processor must obligate sub-processors to perform synchronous erasure and document their evidence in the register.

Practical Examples from SaaS, AI, and Games

SaaS Operation of a CRM

Consider a controller utilizing a hosted CRM. The DPA for this scenario would meticulously describe:

The controller receives copies of data subjects via the SaaS export, and the processor supports situations where system fields cannot be directly read out. This approach translates the data protection principles, often outlined in our knowledge database, into practical product implementation. For specific details on such agreements, see our article on SaaS contracts for marketing tools.

AI Annotation and Fine-tuning

In the context of an AI labeling service processing image and text data, the DPA (GCU) specifies:

Standard Contractual Clauses (SCCs) are implemented for third-country data transfers, and sub-processor changes are announced 30 days in advance. DSFA (Data Subject Request Fulfillment Assistance) support receives dedicated reaction windows. Measurable TOM criteria—such as no BYOD storage, copy/paste blockers, and clipboard protection—are integrated into the audit scope. For comprehensive best practices, consult our guide for best practices for AI providers.

Games Live Operations with External Cloud

When telemetry data from games flows into an analytics pipeline using an external cloud, the IaaS provider acts as a sub-processor, as do event processing services and A/B testing tools. The DPA (AVV) for this setup requires:

Given the rapid pace of live operations, the DPA includes an express instruction window for hotfix changes to event schemas, ensuring purpose limitation is not circumvented. This helps define the contractual framework for live service games effectively.

Typical Mistakes – and How to Avoid Them

Undefined Scope

A DPA clause stating "Processor may process data to fulfill the contract" is insufficient, as it fails to describe processes or purposes. This ambiguity can lead to unauthorized data extensions. To remedy this, implement a meaningful scope that includes a catalog of processes and a sample matrix, clearly defining the framework without legalizing rigid technology.

Empty TOM Keywords

Simply listing "encryption, logging, backup" without detailed procedures and audit trails is inadequate. A comprehensive TOM annex must specify procedures (e.g., TLS versions, KMS operation, rotation cycles), controls (e.g., role assignment, recertification), and checks (e.g., recovery tests, pen test frequency).

Shadow Sub-processors

Agencies sometimes engage "little helpers" without updating their sub-processor register, creating "shadow sub-processors." The solution involves general approval with a register, threshold values for "critical" functions, a notification window, an objection option, and exit variants for mandatory changes.

Unrealistic Audit Rights

Demanding "anytime, unannounced, full system access" is impractical in scalable multi-tenant environments. A well-designed DPA balances remote audits, report recognition, and slot audits with clear escalation levels for incidents.

Exit Without Portability

A clause stating "Deletion after end" without defining export formats can result in vendor lock-in. A robust portability section must specify formats, deadlines, interfaces, and cost logic, ensuring data can actually be transferred.

Art. 26/28 Confusion

Incorrectly labeling joint controller models as DPAs (GCU) leads to incorrect information obligations, unclear responsibility for data subject rights, and liability shifts. Differentiation should be based on purpose: those who co-determine purposes are in control, not merely passengers.

"Data Protection Later" in Agile Roll-outs

Delaying DPA implementation until after features go live in agile roll-outs is risky. Contracts and TOM processes should be early enablers, not subordinate formalities, integrated from the outset.

Copied Patterns Without Data Reality

Blindly copying external clauses without considering actual data flows, sub-processor chains, and deletion logic can be detrimental during an audit or after an incident. Practical guidelines emphasize anchoring mandatory content in concrete, real-world terms.

Key Elements of a Data Processing Agreement: A Structural Overview

A well-structured DPA should include the following sections:

Interlocking with the Main Contract

The DPA is not an isolated document; it is intricately linked to the main contract. Service descriptions and SLAs must consistently reflect data protection obligations. For example, if 24/7 support is agreed, incident processes need commensurate 24/7 availability. If nearshore or offshore teams are involved, the sub-processor register and transfer protection mechanisms must accurately reflect this setup.

Price blocks should transparently account for data protection costs, such as export fees or additional audit days, rather than obscuring them. Change processes must incorporate a data protection check (privacy by design/default) to ensure that new features comply with Article 28 GDPR. This creates a consistent approach, visible in the cloud and contract environment examples on itmedialaw.com: data protection is an integral component of product performance, not a disruptive add-on.

Operational Implementation: Governance Beats Form

A signed DPA is merely the starting point. Those responsible must verify that sufficient guarantees are in place before engaging a service provider, not just reacting to incidents. This involves assessing TOMs, inspecting certificates and reports, conducting risk scoring, and meticulous documentation in the vendor register.

This status must be regularly updated throughout the contract term and on an ad-hoc basis for major changes and incidents. The processor is responsible for awareness programs, renewing confidentiality agreements, controlling access rights, and maintaining the sub-processor list. The overarching focus is on verifiable evidence: a company that can demonstrate in three clicks which TOM version was active, when a sub-processor was added, and when the last restore test succeeded will pass any audit—contractually and de facto. This robust governance arises directly from the basic obligations of Article 28 (1) and (3) GDPR and its inherent verification logic.

Key Elements of a Data Processing Agreement (DPA)

What are the essential components of a DPA? A comprehensive DPA includes:

By anchoring these elements at the level of procedures, deadlines, and evidence, you establish not just "a DPA," but a verifiable data protection architecture. Practical checklists reflect this core understanding; the decisive factor is translating these requirements into your specific tech stack.

Conclusion

A well-crafted data processing agreement is precise, auditable, and operationally feasible. Its foundation lies in the mandatory content of Article 28 GDPR, while robust sub-processor control, effective audit mechanics, TOM versioning, and clear portability provisions ensure its everyday applicability. While samples can offer guidance, adapting the agreement to real data flows, systems, and responsibilities remains paramount. For cloud, SaaS, games, and AI projects, the DPA functions as both product and process law. Embracing this perspective mitigates risks, streamlines audits, and fosters trust among customers, partners, and regulators.

Recommendation: Always verify the specific data reality before concluding a contract and in the event of major changes—and seek legal advice.