Data processing agreement (DPA): what it is and what to include

What a data processing agreement is

A data processing agreement (often shortened to DPA) is a contract, or a contractual addendum, between a controller (the organization that decides why and how personal data is used) and a processor (the vendor that handles that data on the controller’s instructions). It translates broad privacy promises into enforceable, specific commitments: what data may be touched, for what purpose, under what safeguards, and for how long.

In the United States, the DPA sits at the intersection of two regimes. When a US company processes the personal data of individuals in the European Union or United Kingdom, Article 28 of the GDPR requires a written contract containing a defined set of processor obligations. Domestically, state privacy laws impose their own contract requirements: the California Consumer Privacy Act as amended by the CPRA mandates specific terms in agreements with “service providers,” “contractors,” and “third parties,” and comparable statutes in Virginia, Colorado, Connecticut, Utah, and a growing list of other states follow a similar pattern. A single, well-drafted DPA is often used to satisfy several of these regimes at once.

The DPA does not change who owns the data or who is ultimately accountable to regulators and individuals. The controller stays responsible for the lawfulness of the processing; the processor agrees to act only within the guardrails the contract draws.

Key terms and clauses to include

A defensible DPA is specific rather than aspirational. The core building blocks are:

• Subject matter and scope. Describe the nature and purpose of the processing, the types of personal data involved, and the categories of individuals affected. Vague descriptions such as “as needed to provide the services” undercut the whole document.
• Processing only on documented instructions. The processor should act only on the controller’s written instructions and should flag any instruction it believes violates applicable law.
• Confidentiality. Personnel with access to the data must be bound by confidentiality obligations.
• Security measures. Specify the technical and organizational safeguards, such as encryption, access controls, and monitoring, that protect the data. Referencing a recognized standard or a named security exhibit is stronger than a generic promise of “reasonable” security.
• Subprocessors. State whether the processor may engage subprocessors, how the controller is notified or consents, and the requirement to flow the same obligations down by contract.
• Data subject rights assistance. The processor must help the controller respond to access, deletion, correction, and opt-out requests within statutory deadlines.
• Breach notification. Set a clear timeline and method for the processor to report a security incident, along with the information the controller needs to meet its own reporting duties.
• Audit and cooperation rights. Give the controller the ability to verify compliance through information, audits, or recognized third-party certifications.
• Return or deletion at termination. Specify what happens to the data when the engagement ends, including certification of deletion.
• International transfers. If data leaves the US or the EU, identify the transfer mechanism, such as the EU Standard Contractual Clauses, and any supplementary measures.
• Liability and indemnity. Allocate responsibility for fines, claims, and losses arising from a data incident, consistent with the master agreement’s limitation of liability.

A DPA that is missing any of the mandated GDPR Article 28 terms, or the specific certifications a US service provider must make under the CPRA, can be treated as non-compliant even if the parties behave responsibly in practice.

When you need one

You need a data processing agreement whenever a third party will process personal data on your behalf. Common triggers include:

• Engaging a SaaS or cloud vendor that stores or handles customer, employee, or user records.
• Using a payroll, benefits, or HR provider that receives employee personal data.
• Working with marketing, analytics, or advertising platforms that process contact or behavioral data.
• Outsourcing customer support, fulfillment, or IT services where staff can view personal data.
• Any arrangement that involves EU or UK personal data, which brings the GDPR Article 28 requirement into play regardless of where your company is based.

If your organization is the vendor, the mirror-image obligation applies: your customers will expect you to sign, or to offer, a DPA before they route regulated data through your product. Increasingly, enterprise procurement teams will not complete a purchase without one on file.

Common pitfalls

• Treating the DPA as boilerplate. Copy-pasted addenda often describe the wrong data flows or omit terms a specific state law requires. Match the document to the actual processing.
• Leaving the data description blank. An unfilled schedule of data types and purposes is one of the most common defects and one of the easiest for a regulator to spot.
• Ignoring subprocessors. Failing to control and flow down obligations to downstream vendors breaks the chain of accountability.
• Silence on breach timelines. “Prompt” notification is not a deadline. State the number of hours or days.
• Forgetting international transfers. Relying on a vendor that quietly stores data outside approved regions, without a valid transfer mechanism, is a frequent source of exposure.
• Signing and forgetting. A DPA that is never revisited drifts out of date as products, subprocessors, and laws change. Renewal and review dates matter.
• No central record. When DPAs live in scattered inboxes, no one can answer the basic audit question of which vendors hold which data under what terms.

Sound DPA management is really contract management applied to privacy. Keeping every signed DPA in a searchable repository, standardizing on reviewed templates, tracking subprocessor and renewal dates with deadline alerts, and preserving an audit trail of who signed what and when turns a pile of addenda into a defensible program. Pactolane centralizes these agreements and their obligations, while PactAI compliance playbooks can flag missing clauses and score the risk of a given draft, so the humans on your legal and privacy teams decide with the full picture in front of them. A DPA is only as strong as the discipline behind it, and that discipline is what stands up when a regulator, a customer, or an auditor asks to see it.