Controllers and processors must implement effective data processing agreements (DPAs) under the GDPR whenever personal data is processed by a third-party processor. Most organisations rely heavily on standard templates without accounting for their specific processing activities, an approach that creates compliance gaps and operational risks that supervisory authorities and data subjects can exploit.
An effective DPA must identify the parties and their roles, document processing purposes and legal bases, specify categories of personal data and data subjects, set out security measures, regulate sub-processing, address breach notification obligations, and govern international data transfers. We draft, review, and negotiate DPAs that are tailored to the actual processing relationship and enforceable in practice, not generic templates that satisfy the form of compliance without addressing its substance.
The market is flooded with DPA templates: vendor-supplied agreements attached to terms of service, downloadable templates from legal information providers, and standard forms circulated within industry groups. These templates typically satisfy the minimum structural requirements of Article 28 GDPR (they include the mandatory clauses) but they rarely reflect the specific processing relationship they are meant to govern.
Common failures include: security measures described in generic terms that do not reflect the actual technical environment; sub-processor clauses that grant blanket authorisation without meaningful notification or objection rights; breach notification timelines that are unrealistically short or that fail to specify the information the processor must provide; and international transfer provisions that do not reflect the actual data flows between the controller and the processor's infrastructure. A DPA that does not accurately describe the processing relationship it governs is a compliance liability, not a compliance asset.
We start with the processing relationship, not the template. Before drafting or reviewing a DPA, we map the actual data flows: what personal data is processed, whose data it is, where it is processed, who has access, what sub-processors are involved, and where the data physically resides. This mapping informs every provision of the DPA, ensuring that the agreement reflects reality rather than a standardised approximation.
For clients engaging new vendors, we draft bespoke DPAs that address the specific processing activity, the applicable security requirements, and the jurisdictional considerations (including international transfer mechanisms where the vendor processes data outside the EEA). For clients reviewing vendor-supplied DPAs, we assess the agreement against the actual processing relationship and negotiate amendments where the vendor's standard terms create compliance gaps or unacceptable risk allocations.
The proliferation of AI-powered services creates new DPA challenges. Where a vendor uses AI to process personal data on behalf of a controller, the DPA must address whether the vendor will use the controller's data to train or improve its AI models, how AI-generated outputs that contain personal data are handled, what logging and audit trail capabilities exist for AI-driven processing, and how the AI Act's provider-deployer responsibility framework interacts with the GDPR's controller-processor relationship. Standard DPA templates do not address these issues. We draft AI-specific DPA provisions that address the intersection of GDPR and AI Act obligations.
A DPA is required whenever a controller engages a third-party processor, meaning any entity that processes personal data on behalf of the controller. This includes cloud providers, payroll processors, IT service providers, marketing platforms, CRM systems, and any other external party handling personal data under your instructions. The obligation applies regardless of the size of the engagement or the volume of data processed.
A controller determines the purposes and means of processing personal data. A processor acts on the controller's instructions. Some parties act as joint controllers, sharing responsibility for determining purposes; this relationship also requires a documented arrangement under the GDPR. The classification is determined by the actual decision-making authority over the processing, not by the label the parties assign in their contract.
You can, but you should review it first. Many vendor-supplied DPAs are drafted to minimise the vendor's obligations and maximise flexibility, which may not align with your compliance requirements. We review vendor DPAs against your specific processing activity and recommend amendments where the standard terms create compliance gaps. For critical vendor relationships, a bespoke DPA is preferable to an adapted standard form.
Where the processor is located outside the EEA or uses sub-processors outside the EEA, the DPA must specify the transfer mechanism relied upon: adequacy decision (such as the EU-US Data Privacy Framework for certified US recipients), Standard Contractual Clauses with a Transfer Impact Assessment, or Binding Corporate Rules for intra-group transfers. The DPA should also address the processor's obligation to notify the controller if the legal framework in the destination country changes in a way that affects the transfer mechanism's validity.
%402x.svg){kind=icon}
%402x.svg){kind=icon}
%402x.svg){kind=small}