A data processing agreement (DPA) is a contract between a business and a vendor that handles personal data on the business’s behalf. It sets out what the vendor may do with the data, how it must protect it, which subcontractors it may use, how it reports breaches, and what happens to the data when the contract ends. DPAs are most closely associated with the EU’s General Data Protection Regulation (GDPR), which requires a written contract of this kind between a data controller and a data processor, and some other privacy laws require similar terms.
At a glance
- A DPA governs a vendor’s handling of personal data it processes for you and records each party’s role, usually controller to processor or processor to subprocessor; roles can differ by data use.
- Under the GDPR and UK GDPR, a written controller-processor contract is required; several US state privacy laws require similar service provider terms.
- It is usually an addendum to the main contract or master services agreement.
- Key terms cover processing instructions, security, subprocessors, breach notice, audits, international transfers and deletion.
- Signing one is necessary under those laws but is not compliance on its own.
What problem it solves
When a business uses a cloud application, a managed service provider or a contact center platform, the vendor often stores or accesses personal data about the business’s employees and customers. Privacy laws generally hold the business responsible for that data even while a vendor handles it. Without clear contract terms, the business cannot show what the vendor is allowed to do, how the data is protected or how fast it will hear about a breach.
A DPA fills that gap. It limits the vendor to processing data only on the business’s instructions, requires appropriate security, controls the use of subcontractors, and typically gives the business rights to information and audits. It also gives a business evidence to show its own customers, auditors and regulators that vendor relationships involving personal data are under contract.
How it works
Roles. The DPA records each party’s role for the processing it covers. In the most common case, the business decides why and how data is used (the controller, under GDPR terminology) and the vendor processes it on the business’s behalf (the processor); a processor that passes the work to its own subcontractors needs similar terms with them (processor to subprocessor). Roles can differ by data use: a vendor may act as a processor for your customer data but as an independent or joint controller for other data, such as its own billing or service analytics, and those uses are not governed by the processor terms in the same way. Under some US state laws the vendor in a processor-like role is called a service provider or contractor.
Scope. It describes what personal data is processed, about whom, for what purpose and for how long, often in an annex.
Obligations. Typical clauses require the vendor to follow documented instructions, keep staff bound by confidentiality, apply security measures, assist with requests from individuals exercising their rights, notify the customer of personal data breaches without undue delay or within an agreed time, and delete or return data at the end of the service.
Subprocessors. The vendor lists its subcontractors that handle the data and agrees to give notice of changes, often with a right for the customer to object.
Transfers. Where data moves between countries, the DPA usually includes or references a transfer mechanism. For restricted transfers from the EEA this is commonly the EU standard contractual clauses; for restricted transfers from the UK, the UK IDTA or the UK Addendum to the EU SCCs. Adequacy decisions or regulations, and other safeguards, may apply instead, depending on the destination.
Which laws apply, and what they require, depends on where you operate, whose data you handle and the rules in force at the time. This is general information, not legal advice; have privacy counsel review your obligations. For a broader view of vendor risk and compliance programs, see our governance, risk and compliance overview.
When it matters for buyers
- When buying any service that stores customer or employee data. Ask for the vendor’s DPA as part of contracting, not after go-live.
- When expanding into Europe or the UK. Contracts with vendors and customers will need GDPR-style terms.
- When a customer sends you their DPA. You may be the processor, with obligations to flow down to your own vendors.
- During security and privacy reviews. Auditors and customers often ask for signed DPAs with key vendors.
- When a vendor changes subprocessors or hosting locations. Your DPA decides what notice and rights you have.
Questions to ask vendors
- Do you have a standard DPA, and which privacy laws is it written to address?
- Which subprocessors handle our data, where are they, and how will you notify us of changes?
- Where will our data be stored and accessed from, and what transfer mechanisms do you use?
- How quickly will you notify us of a personal data breach, and what information will you provide?
- What security certifications or audit reports can you share?
- How and when do you delete or return our data at the end of the contract?
How it differs from a BAA
A business associate agreement (BAA) is a contract required under HIPAA in the US when a vendor creates, receives, keeps or transmits protected health information for a healthcare covered entity or another business associate. A DPA covers personal data more broadly under general privacy laws such as the General Data Protection Regulation (GDPR). The two overlap in purpose but answer to different laws, and a vendor serving healthcare clients with European data may need both.