Skip to main content
Cookie Gate
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: TCF and Vendors

Data Processing Addendum

Also known as: DPA, Data Processing Agreement, Data Processing Contract
Simply put

A Data Processing Addendum is a legal contract that sets out the rights and obligations of two parties when one handles personal data on behalf of the other. It typically applies when a service provider processes personal data to deliver its products or services to a customer. The document is intended to govern how that data is handled in line with applicable privacy and data protection laws.

Formal definition

A Data Processing Addendum (DPA) is a legally binding contract, often incorporated into or appended to a broader service agreement, that defines the obligations of the parties involved in the processing of personal data, commonly framed around a controller instructing a processor to carry out processing on its behalf. It typically describes the parties' respective responsibilities under applicable privacy, data security, and data protection laws, and generally applies when a provider processes customer personal data in its capacity as a processor in connection with the provision of its products, services, or related support. The specific scope, required terms, and applicable legal obligations vary by jurisdiction and by the underlying data protection regime; the evidence provided here does not detail the mandated contents of a DPA under any particular law, so this definition should not be treated as an exhaustive statement of statutory requirements.

Why it matters

A Data Processing Addendum is a foundational instrument for allocating data protection responsibilities between organizations that share personal data in a service relationship. In the context of cookie consent and tracking technologies, many organizations rely on third-party vendors, analytics providers, tag managers, consent management platforms, and advertising partners, that process personal data collected through cookies, pixels, SDKs, and similar technologies. A DPA is the mechanism through which the customer, often acting as a controller, sets out the terms under which such a provider handles that data, commonly in its capacity as a processor.

Without a DPA in place, an organization may struggle to demonstrate that its vendor relationships are governed in line with applicable privacy and data protection laws. Because a DPA describes the parties' respective obligations, it supports accountability and helps clarify who is responsible for what when personal data is processed on one party's behalf. It is important to note, however, that the specific contents and mandated terms of a DPA vary by jurisdiction and by the underlying data protection regime; the presence of a DPA supports compliance but does not by itself guarantee it, and it does not replace the legal judgment needed to assess whether a given processing arrangement is lawful.

Who it's relevant to

Privacy and data protection officers
DPOs and privacy teams rely on DPAs to govern how vendors handle personal data on the organization's behalf, including data collected through cookies and similar tracking technologies. A DPA helps document the allocation of responsibilities under applicable privacy and data protection laws, though its adequacy depends on the specific regime and facts involved.
Legal counsel and contract teams
Legal and contract management professionals negotiate, review, and incorporate DPAs into broader service agreements. Because the required terms vary by jurisdiction and data protection regime, counsel must assess what a given DPA needs to contain rather than assuming a standard template satisfies every applicable law.
Marketing and compliance teams using third-party tools
Teams deploying analytics, advertising, and consent management vendors often engage providers that process personal data as processors. A DPA sets out the terms governing that processing, but it supports compliance rather than replacing the separate assessment of consent and lawful basis for the underlying tracking technologies.
Vendors and service providers
Providers that process customer personal data in their capacity as a processor, such as SaaS platforms and infrastructure services, commonly offer DPAs to describe their obligations to customers. These providers use the DPA to define their responsibilities under applicable privacy, data security, and data protection laws in connection with their products and support services.

Inside DPA

Subject Matter and Duration of Processing
A description of what personal data is being processed, for how long, and in connection with which services. Under the GDPR, Article 28 requires that a controller-processor contract set out the subject matter and duration of the processing, so a DPA typically records these details or references the underlying service agreement.
Nature and Purpose of Processing
A statement of the processing operations the processor carries out and the reasons for them. In the cookie and tracking context, this may cover activities such as hosting a consent management platform, storing consent logs, or delivering analytics on the controller's behalf.
Categories of Data Subjects and Personal Data
An identification of whose data is processed (for example website visitors or app users) and what types of data are involved. Where cookies, pixels, SDKs, or similar technologies collect identifiers, these identifiers may constitute personal data under the GDPR and therefore fall within the DPA's scope.
Controller Instructions and Processor Obligations
Terms confirming that the processor acts only on the documented instructions of the controller. Article 28 obligations commonly reflected here include confidentiality commitments, security measures, and cooperation with the controller's own compliance duties.
Sub-processor Provisions
Terms governing whether and how the processor may engage sub-processors, typically requiring authorization from the controller and the flow-down of equivalent data protection obligations. This is relevant where a CMP or analytics vendor relies on further downstream providers.
International Data Transfer Mechanisms
Provisions addressing transfers of personal data outside the EU or UK, which may incorporate mechanisms such as Standard Contractual Clauses. The adequacy of any given transfer mechanism depends on facts and evolving guidance not resolved by the DPA text alone.
Security, Breach Notification, and Assistance
Commitments regarding technical and organizational security measures, assistance to the controller in responding to data subject requests, and obligations to notify the controller of personal data breaches, consistent with Article 28 requirements.
Audit and End-of-Processing Terms
Terms allowing the controller to verify the processor's compliance and setting out what happens to personal data at the end of the engagement, such as deletion or return of the data.

Common questions

Answers to the questions practitioners most commonly ask about DPA.

Does signing a Data Processing Addendum (DPA) satisfy my cookie consent obligations?
No. A DPA governs the relationship between a controller and a processor by setting out how personal data is processed on the controller's behalf, but it does not address whether valid consent was obtained for placing or accessing cookies and similar technologies. In most EU jurisdictions, the obligation to obtain prior consent under the ePrivacy rules, and to have a lawful basis under the GDPR, is separate from and additional to having a DPA in place. A DPA supports compliance in the controller-processor dimension but does not replace the consent mechanisms handled through a consent management platform (CMP) or the underlying legal analysis.
Is a DPA the same thing as a controller-to-controller data sharing agreement?
Not necessarily. A DPA typically documents a controller-processor relationship, where the processor acts on the controller's documented instructions. Where two parties each determine their own purposes and means of processing, they may be joint controllers or independent controllers, and the appropriate arrangement is generally a different instrument rather than a processor-style DPA. Characterising the parties' roles is a fact-specific assessment, and mislabelling the relationship can lead to using the wrong contractual mechanism. The correct classification depends on the actual data flows and decision-making, which fall outside the scope of the DPA definition itself.
When do I need a DPA in the context of cookies and tracking technologies?
A DPA is generally required where you engage a third party to process personal data on your behalf in connection with cookies, pixels, SDKs, or similar technologies, for example a CMP vendor, an analytics provider, or a tag management service acting as your processor. Whether a given vendor is a processor or an independent controller is a fact-specific question, and the answer determines whether a DPA or a different arrangement is appropriate. This definition does not assess any particular vendor relationship.
What terms are typically included in a DPA?
DPAs commonly address the subject matter, duration, nature and purpose of processing, categories of data and data subjects, the processor's obligation to act on documented instructions, confidentiality, security measures, use of sub-processors, assistance with data subject rights and breach notification, deletion or return of data, and audit rights. The precise contents required depend on the applicable framework and the specifics of the engagement. This entry describes common elements rather than prescribing a definitive list for any jurisdiction.
How does a DPA relate to international data transfers involving cookie data?
A DPA often works alongside, but is distinct from, transfer mechanisms used where personal data collected via cookies or similar technologies is transferred outside the relevant jurisdiction. Transfer safeguards, such as standard contractual clauses, are typically addressed as part of or in addition to the DPA. Whether a transfer occurs and which safeguard applies depends on the data flows and the parties' locations, which are not determined by the DPA definition alone.
Does having a DPA in place guarantee compliance with data protection law?
No. A DPA is one organizational component that supports compliance by documenting the controller-processor relationship, but it does not by itself demonstrate that consent was validly obtained, that a lawful basis exists, or that vendors actually meet their obligations in practice. Compliance also depends on the operation of your consent mechanisms, record-keeping, security practices, and ongoing oversight. Tools and contracts assist compliance but do not replace legal judgment or verification of how processing is carried out.

Common misconceptions

A signed DPA means the parties are compliant with cookie consent law.
A DPA principally governs the controller-processor relationship for personal data processing under the GDPR (notably Article 28). It does not, on its own, establish a valid legal basis for placing or accessing cookies. In most EU jurisdictions, obligations to obtain prior consent under the ePrivacy Directive's national implementations are separate and must be satisfied independently. A DPA supports compliance but does not replace the underlying consent or legal judgment.
A DPA is only needed when literal HTTP cookies are involved.
Where similar technologies such as pixels, local storage, SDKs, or fingerprinting collect identifiers that qualify as personal data, the resulting processing may still require a DPA between controller and processor. The relevant question is whether personal data is processed by a processor on the controller's behalf, not whether the technology is technically a cookie.
The same DPA satisfies obligations across the EU, UK, and US alike.
Data protection and cookie obligations vary by jurisdiction. A DPA framed around GDPR Article 28 addresses EU requirements, and UK arrangements may require UK-specific terms and transfer mechanisms. US state privacy laws such as the CCPA and CPRA in California use their own contractual constructs and often rely on opt-out rather than opt-in models, so a single document may not map cleanly onto every regime. The applicable scope should be confirmed for each jurisdiction.

Best practices

Confirm whether the vendor genuinely acts as a processor on your documented instructions, and ensure the DPA reflects the Article 28 elements, including subject matter, duration, nature, purpose, categories of data, and categories of data subjects.
Treat the DPA as separate from your cookie consent obligations; verify that prior consent under applicable ePrivacy implementations is obtained where required in EU jurisdictions, rather than relying on the DPA to cover it.
Map which cookies and similar technologies (pixels, local storage, SDKs, fingerprinting) involve processing by the vendor, since identifiers that constitute personal data may bring that processing within the DPA's scope.
Review sub-processor provisions to confirm authorization procedures and that equivalent obligations flow down to any downstream providers used by your CMP or analytics vendor.
Check that international transfer mechanisms in the DPA fit the actual data flows and applicable EU or UK requirements, and reassess them in light of evolving regulatory guidance rather than assuming a mechanism is permanently sufficient.
Where you operate across multiple regimes, confirm whether jurisdiction-specific terms are needed for the UK and US state laws such as the CCPA and CPRA, and involve legal counsel rather than treating a single DPA as universally adequate.
Promotional banner for the Pentest Readiness checklist download