Skip to main content
a promotional graphic telling you that PCI Compliance is no longer an annual exercise and that continuous monitory must be built in
Category: Third-Party & Vendor

Data Processing Agreement

Also known as: DPA, Data Processing Addendum, Data Protection Agreement
Simply put

A Data Processing Agreement (DPA) is a legally binding contract that sets out the rights and obligations of the parties involved when one organization processes personal data on behalf of another. It typically governs the relationship between a data controller (the entity that decides why and how data is processed) and a data processor (the entity that handles the data on the controller's instructions). The agreement commonly addresses matters such as security, the use of subprocessors, and how requests from individuals about their data are handled.

Formal definition

A DPA is a contractual instrument, distinct from data protection regulation itself, that allocates responsibilities and liabilities between a data controller and a data processor with respect to the processing of personal data. Its provisions generally cover definitions and interpretation, the scope and nature of processing, obligations on processor personnel, security measures, the engagement of subprocessors, and support for data subject rights. A DPA derives legal force from the contract between the parties; note that in certain jurisdictions and sectors such agreements may be required or shaped by applicable law, though the specific triggering conditions, mandatory clauses, and enforcement vary by jurisdiction and should be verified against the current authoritative text. This entry defines the instrument generally and does not itself specify the statutory requirements of any particular regime, nor does it substitute for professional judgment applied to specific circumstances.

Why it matters

A Data Processing Agreement matters because it converts abstract data protection responsibilities into concrete, enforceable contractual terms between the party that decides why and how personal data is processed (the controller) and the party that acts on its instructions (the processor). Without such an instrument, the parties may lack clarity on who bears responsibility for security measures, how subprocessors are authorized, and how requests from individuals about their data are handled. The DPA is the mechanism through which the controller extends its expectations down the processing chain and through which the processor documents the limits of its role.

It is important to keep the DPA distinct from data protection regulation itself. The agreement derives its legal force from the contract between the parties, not from being a statute; in some jurisdictions and sectors applicable law may require or shape such agreements, but the triggering conditions, mandatory content, and enforcement differ across regimes and should be verified against the current authoritative text. A DPA is therefore best understood as the contractual layer that sits alongside, and may be prompted by, the regulatory layer rather than as a substitute for it.

For organizations, a well-drafted DPA reduces ambiguity in the event of a security incident, an audit, or a dispute over liability. Because it allocates obligations and liabilities between the parties, its terms often become the first reference point when questions arise about who was responsible for a given control. Its practical value depends heavily on how accurately its scope, security provisions, and subprocessing terms reflect the actual processing arrangement.

Who it's relevant to

Data controllers
Organizations that determine the purposes and means of processing use a DPA to set out their instructions and expectations for a processor, including provisions on security, subprocessing, and support for handling data subject requests. The DPA is a primary tool for extending the controller's obligations to parties that handle data on its behalf.
Data processors and service providers
Entities that process personal data on a controller's instructions rely on the DPA to define the boundaries of their role and the obligations they accept. This includes third-party vendors and any subprocessors they engage, whose use is commonly addressed within the agreement's subprocessing terms.
Legal counsel and contract managers
Those responsible for negotiating, drafting, and reviewing commercial arrangements handle the DPA's provisions on definitions, scope of processing, liability allocation, and security. Because mandatory content and enforceability depend on the applicable regime and the underlying contract, counsel typically tailor terms to the specific arrangement and verify them against current authoritative sources.
Data protection and compliance professionals
Privacy officers and compliance teams use the DPA to confirm that processing relationships are documented and that responsibilities for security, personnel obligations, subprocessing, and data subject rights are clearly allocated. They should note that specific triggering conditions and required clauses vary by jurisdiction and sector.

Inside DPA

Subject Matter and Duration
A description of the nature and purpose of the processing, the types of personal data involved, the categories of data subjects, and the period over which processing will occur. Under the GDPR, these particulars are generally required to be set out in the agreement, though the precise level of detail may vary with the arrangement.
Processor Obligations
Commitments binding the processor, which typically include processing only on documented instructions from the controller, ensuring confidentiality of personnel authorized to process data, and implementing appropriate technical and organizational security measures. These obligations flow from the controller's accountability but bind the processor directly.
Sub-processor Provisions
Terms governing the engagement of sub-processors, which generally require prior authorization from the controller (specific or general) and the imposition of equivalent data protection obligations on any sub-processor by contract. The exact authorization mechanism depends on the parties' agreement.
Data Subject Rights Assistance
Provisions requiring the processor to assist the controller in responding to requests from data subjects seeking to exercise their rights, taking into account the nature of the processing and the information available to the processor.
Security, Breach, and Support Duties
Terms addressing the processor's assistance to the controller with security obligations, breach notification, and where applicable data protection impact assessments and prior consultation with a supervisory authority. Scope of assistance is typically calibrated to the processing and information available to the processor.
End-of-Processing and Audit Terms
Provisions covering the deletion or return of personal data at the end of the engagement (per the controller's choice, subject to legal retention requirements) and the processor's obligation to make available information demonstrating compliance and to allow for and contribute to audits or inspections.

Common questions

Answers to the questions practitioners most commonly ask about DPA.

Is a Data Processing Agreement the same thing as a general commercial contract or NDA?
No. A DPA is a distinct instrument that specifically governs the processing of personal data by a processor on behalf of a controller, addressing matters such as the subject matter and duration of processing, the nature and purpose of processing, the types of data and categories of data subjects, and the obligations of each party. A general commercial contract or non-disclosure agreement may sit alongside a DPA, but it does not substitute for one. Under the GDPR, the processing relationship generally must be governed by terms addressing the elements the regulation prescribes; confidentiality clauses in a broader agreement typically do not, on their own, satisfy those requirements. Readers should verify the specific required elements against the current official text of the applicable law.
Does having a DPA in place mean the processor becomes solely responsible for compliance?
No. A DPA allocates and documents obligations between the parties, but it does not transfer the controller's accountability. Under the GDPR framework, the controller generally retains primary responsibility for determining the purposes and means of processing and for demonstrating compliance, while the processor takes on defined obligations and can bear direct liability for its own failures. The two roles remain distinct: signing a DPA does not convert a controller into a party free of obligations, nor does it make the processor a controller. Actual allocation of liability in any given case is fact-specific and depends on the roles the parties genuinely play, not merely on labels used in the document.
Who is responsible for drafting and providing the DPA, the controller or the processor?
There is no single fixed rule. In practice, either party may present the initial draft, and the outcome often depends on relative bargaining position and business model. Larger processors, particularly cloud and software vendors, frequently supply a standardized DPA on their own terms, while a controller with sufficient leverage may insist on its own template. Regardless of who drafts it, the controller generally remains accountable for ensuring the agreed terms address the required elements and reflect the actual processing arrangement. Both parties should review the substance rather than assume a supplied template is adequate for their specific circumstances.
How should a DPA handle the use of sub-processors?
A DPA typically addresses whether and how the processor may engage sub-processors. Under the GDPR framework, this generally involves obtaining the controller's authorization (which may be specific or general), imposing equivalent data protection obligations on any sub-processor, and providing the controller with information about intended changes so it can object. The precise mechanics, such as notice periods and objection rights, are matters for negotiation within the bounds of the applicable law. Because sub-processor requirements and the treatment of onward transfers are areas where practice and interpretation continue to develop, parties should confirm their approach against the current authoritative text and any relevant supervisory guidance.
What should a DPA say about international data transfers?
Where processing involves transferring personal data outside the jurisdiction that granted its protections, a DPA often needs to reference an appropriate transfer mechanism, such as standard contractual clauses or another lawful basis recognized under the applicable regime. Requirements differ across jurisdictions, and the availability and adequacy of particular mechanisms have been subject to change and legal challenge. A DPA should identify which transfers occur and on what basis, but the underlying transfer analysis is a separate exercise. This entry does not set out which mechanism applies in any given situation; readers should verify the current state of the relevant transfer rules and any supplementary measures that may be expected.
What happens to the DPA and the data when the underlying arrangement ends?
A DPA commonly includes terms governing the end of the processing relationship, such as the processor's obligation to return or delete the personal data at the controller's choice and to delete existing copies, subject to any retention required by law. It may also address the return of data in a usable format and the timing of deletion. The specific obligations, exceptions for legally mandated retention, and how they are evidenced are matters to be set out in the agreement itself. Application of these provisions to particular circumstances requires professional judgment, and parties should confirm that the drafted terms align with the current requirements of the applicable law.

Common misconceptions

A DPA is merely a voluntary best-practice document that organizations can adopt at their discretion.
Where the GDPR applies, a contract or other legal act binding the processor to the controller is generally a legal requirement for processing arrangements, not an optional formality. That said, the specific contractual particulars required and their application to a given relationship depend on the facts, and requirements differ across jurisdictions such as the EU, the UK, and the United States. Readers should verify against the current official text.
Signing a DPA transfers or discharges the controller's compliance responsibilities to the processor.
A DPA allocates obligations between distinct roles but does not eliminate the controller's accountability. The controller and processor remain separate roles with distinct duties; the agreement binds the processor to act on documented instructions while the controller generally retains responsibility for the lawfulness and purposes of the processing. It shifts contractual duties, not overall accountability.
A single standard DPA template satisfies all obligations regardless of the data, parties, or transfer involved.
The adequacy of any DPA is fact-specific and depends on factors such as the nature of the processing, the data categories, and whether international data transfers are involved, which may require additional mechanisms beyond the DPA itself. Interpretations and enforcement practice continue to evolve, and application to particular circumstances requires professional judgment.

Best practices

Confirm the roles of the parties before drafting: determine whether each party acts as controller or processor (or joint controllers), as the required contractual terms follow from that classification.
Ensure the agreement specifies the subject matter, duration, nature and purpose of processing, data categories, and categories of data subjects, rather than relying on generic language.
Address sub-processor engagement explicitly, including the authorization mechanism and the requirement to flow equivalent data protection obligations down to any sub-processor.
Include clear terms on assistance with data subject rights, security, breach handling, and end-of-processing deletion or return, calibrated to the processing and the information available to the processor.
Assess whether international data transfers are in scope and, if so, verify that any additional transfer mechanisms required beyond the DPA are in place under the applicable jurisdiction.
Review and update DPAs periodically against the latest authoritative text, since regulations and guidance are amended over time and application to specific circumstances warrants professional judgment.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.