A GDPR data processing agreement (DPA) is the written contract between a business that decides why and how personal data is used (the controller) and a vendor that handles that data on its behalf (the processor). If you are a US company that stores, hosts, supports or analyzes the personal data of people in the EU for a customer or vendor, you will almost certainly be asked to sign one, or need to ask for one. This guide explains what the contract must say, when it applies to a US business, how it differs from a HIPAA business associate agreement, and how to review one before you sign.
TL;DR
- A DPA is the contract Article 28 of the GDPR requires whenever a processor handles personal data for a controller. It can be a standalone document or part of a larger agreement.
- US businesses are pulled in when they process EU personal data for someone else, for example as a hosting, IT support, backup or software vendor.
- The contract must cover instructions, confidentiality, security, subprocessors, rights requests, breach help, deletion or return, and audits.
- A DPA protects EU personal data. A HIPAA business associate agreement (BAA) protects US health information. Healthcare organizations with EU data may need both.
- Review the roles, the data, the subprocessor list and the exit terms before signing, not after an incident.
Table of Contents
- What a GDPR data processing agreement is
- When a US business needs a DPA
- Does a DPA have to be a separate document?
- What a GDPR-compliant DPA must include
- DPA vs BAA: GDPR and HIPAA contracts compared
- How to review a vendor's DPA before you sign
- Our perspective: the DPA is where IT practice meets the contract
- Getting the technical side behind your DPA
- FAQ
- Sources
What a GDPR data processing agreement is
The GDPR distinguishes two roles. The controller determines the purposes and means of processing, while the processor handles personal data only on the controller's behalf. When a controller uses a processor, the relationship has to be governed by a contract or other legal act that spells out the processor's duties. That contract is what the industry calls a DPA.
A few practical points about roles:
- Roles are functional. The European Data Protection Board (EDPB) says that controller and processor status depends on what each party actually does, not on the label in the contract. Calling yourself a processor does not make you one.
- Processors follow instructions. The same guidelines state that a processor must act on the controller's instructions. A vendor that decides for itself why it uses the data, for example to build its own marketing lists, becomes a controller for that activity.
- One company can hold both roles. An IT provider may be a processor for customer data it hosts and a controller for its own employee records.
In plain terms, the DPA answers one question: what is the vendor allowed to do with your data, and what must it do to protect it?
When a US business needs a DPA
The GDPR applies based on whose data is involved and how it is handled, not only where a company is incorporated. Three common US situations lead to a DPA.
1. You are a vendor to a company with EU data. If your EU customer sends you personal data to host, back up, support or analyze, that customer will ask you to sign a DPA. The U.S. Data Privacy Framework says that a contract is required when EU personal data is transferred to the United States solely for processing, whether or not the US processor participates in the Framework. That contract must require instruction-only processing, appropriate technical and organizational safeguards, and help with individual-rights requests.
2. You use vendors for EU personal data. If you are the controller, for example an online retailer with EU customers, every cloud host, help desk, email platform and analytics tool that touches that data needs a DPA with you. Your own IT provider counts if its staff can access the data.
3. You pass data further down the chain. Your processor's own vendors are subprocessors, and the contract has to control how they are brought in.
When you probably do not need one
GDPR does not reach every file. University guidance from UW–Madison notes that a DPA is generally not required when the data does not relate to individuals in the EEA and is processed with a non-EEA entity. A Los Angeles dental office that only serves local patients is generally in that position. Before you decide, map where your data subjects live. Our guide to GDPR for small business walks through that scoping step for US companies.
Does a DPA have to be a separate document?
No. The European Commission explains that Article 28 requires a binding written contract, including in electronic form, but the DPA does not need to be a standalone document. The Article 28 terms can sit inside a master services agreement, a statement of work or an online terms-of-service page, as long as they cover the required content.
The Commission adds that the Article 28 requirements can be satisfied through the controller-to-processor or processor-to-processor modules of the standard contractual clauses (SCCs) for international transfers, without a separate DPA. The transfer decision itself confirms that its clauses also address Article 28 rights and obligations for controller-to-processor and processor-to-subprocessor transfers. If you want to understand how transfer clauses and processor duties interact when vendors move data across borders, this overview of GDPR transfer rules for faxed data shows the same logic applied to one specific channel.
Data processing addendum or agreement?
You will see both names. Neither term appears in the regulation, which only speaks of a contract or other legal act. In everyday use, an agreement is typically a standalone contract, while an addendum attaches to an existing commercial contract. Both can satisfy Article 28(3); the difference is structural. It matters in practice for four things: which document wins if the two conflict, whether the vendor can change terms unilaterally, how liability caps apply, and what happens to data at the end. Ask for the addendum to take precedence over the main contract on data protection topics.
What a GDPR-compliant DPA must include
The Commission has adopted standard contractual clauses for controller-processor contracts under Article 28(7), which many parties use as a baseline. Parties may place these terms in a broader commercial contract and add safeguards, provided the additions do not contradict the clauses or prejudice data-subject rights.
The clauses must identify the subject matter and duration of the processing, its nature and purpose, the types of personal data, the categories of data subjects, and the controller's rights and obligations. UW–Madison's guidance summarizes the remaining obligations. Use this table as a checklist.
| Clause | What it should say | What to look for |
|---|---|---|
| Scope of processing | Subject matter, duration, nature, purpose, data types, data-subject categories | Specific descriptions, not "all customer data" |
| Documented instructions | Processor acts only on the controller's written instructions | Who can issue instructions and how |
| Confidentiality | Everyone with access is bound by confidentiality | Staff and contractors both covered |
| Security | Appropriate technical and organizational measures | Named controls such as encryption, access control, logging |
| Subprocessors | Prior authorization, same obligations passed down | A current list and a notice period for changes |
| Data-subject rights | Help the controller answer access, deletion and similar requests | Response timelines the controller can actually meet |
| Breach and impact assessments | Notify the controller and assist with assessments | A fixed notification window |
| Deletion or return | Delete or return data when services end | A deadline and written confirmation |
| Audits | Information and audit rights for the controller | Practical scope, not a blanket refusal |
One more point from the EDPB: a DPA should contain concrete information about how compliance and security will be achieved, rather than merely repeating the text of the GDPR. A contract that only restates "appropriate security measures" without describing them is weak evidence of compliance.
DPA vs BAA: GDPR and HIPAA contracts compared
Healthcare providers and their vendors often ask whether a DPA replaces a HIPAA business associate agreement. It does not. They answer different laws.
HHS explains that HIPAA applies to covered entities and certain business associates, and that a BAA is the written arrangement giving satisfactory assurances that a business associate will safeguard protected health information (PHI).
| GDPR DPA | HIPAA BAA | |
|---|---|---|
| Law | GDPR Article 28 | HIPAA Privacy and Security Rules |
| Protects | Personal data of individuals in scope of GDPR | PHI held by covered entities and business associates |
| Parties | Controller and processor | Covered entity and business associate (or business associate and subcontractor) |
| Ending the work | Delete or return personal data | Return or destroy PHI |
| Subcontractors | Subprocessor authorization and flow-down | Restrictions flowed down to subcontractors |
| Audit | Controller audit and information rights | Access, amendment and accounting support, plus incident reporting |
Under 45 C.F.R. §164.504(e), a BAA must specify permitted and required uses and disclosures of PHI, prohibit unauthorized use, require safeguards, address incident reporting, pass restrictions to subcontractors, support access, amendment and accounting, and require return or destruction at termination.
The two documents overlap in concept, but a signed DPA does not satisfy HIPAA, and a BAA does not satisfy Article 28. HHS also states that a cloud provider that creates, receives, maintains or transmits ePHI for a covered entity is a business associate and needs a BAA, even if it stores only encrypted ePHI and does not hold the key. A medical practice with patients in both the US and the EU, using one cloud backup service, should expect to sign both. For the HIPAA side, see our guide to the HIPAA business associate agreement.
How to review a vendor's DPA before you sign
Treat the DPA as an operational document, not a formality. A practical review runs in six steps.
- Confirm the roles and the data. Decide who is controller and who is processor for each activity. Identify whether the data includes special categories such as health information. UW–Madison recommends reviewing the lawful basis, special-category data and role allocation before signing.
- Check the scope description. It should match what the vendor really does with the data, including support access and backups.
- Read the security terms. Ask what encryption, access controls, logging and staff vetting the vendor commits to. Compare these to what its other documents promise.
- Inspect the subprocessor terms. Look for the current list, a notice period for changes and a right to object. The Commission's transfer framework treats subprocessor authorization, equivalent written protections, information access and audits as central controls.
- Check the transfer mechanism. If personal data leaves the EEA, confirm that a safeguard such as the Data Privacy Framework or SCCs covers it.
- Test the exit. Look for a deletion or return deadline, a format for returned data and written confirmation of deletion.
When a vendor will process sensitive personal data in a high-risk way, the review often connects to a data protection impact assessment. If you want to see how that discipline plays out in one function, this piece on DPIAs for GDPR recruiting shows why role allocation and documented instructions should be settled before a tool goes live.
Two related contract topics are worth reading in parallel. Your managed service provider's service level agreement should align with the DPA on breach notice and incident response; our list of audit-ready MSP service level agreement clauses covers that. And because rights requests flow from the controller to the processor, the processor's help matters when you run your DSAR process.
Our perspective: the DPA is where IT practice meets the contract
Most DPA problems we see are not legal drafting errors. They are gaps between what the contract promises and what the IT environment can deliver. A clause that requires encryption, access logging, a subprocessor list, 72-hour breach help or deletion on exit only has value if someone can show those controls exist on an ordinary Tuesday.
That is why we approach DPAs as part of proactive IT management rather than a paperwork exercise. For small and mid-size businesses in Southern California, the practical advice is simple:
- Inventory where personal data lives, including backups and email, before you negotiate anything.
- Keep an up-to-date list of the vendors and subprocessors that touch regulated data.
- Make sure the security terms you sign can be evidenced by monitoring, access records and tested recovery.
- Treat a DPA, a HIPAA BAA and California privacy duties as one coordinated program. Our guides to CCPA and CPRA compliance and California data breach law cover the state side.
A DPA does not make a business compliant. It documents who is responsible for what, and the day-to-day controls make that documentation true.
— Alex
Getting the technical side behind your DPA
If you are signing DPAs as a processor, or asking vendors to sign them, the controls behind the contract need to be real. Secure Techies provides managed IT services and cybersecurity for small and mid-size businesses in Southern California, with 24/7 monitoring, backup and disaster recovery, and HIPAA, GDPR, SOC 2 and CMMC compliance audits. Our compliance and security audits show where your data, vendors and controls stand against what your contracts promise.
To discuss how the pieces fit together, start with our managed IT services or see how we handle cloud infrastructure data compliance.
FAQ
What is a DPA under GDPR?
A DPA is the binding contract between a controller and a processor that sets out how the processor may handle personal data on the controller's behalf. It must cover subject matter, duration, data types, security, subprocessors and deletion or return, among other terms. It can be a separate document or part of a broader agreement.
Is a data processing addendum the same as a DPA?
In practice, yes. Both names describe a contract meeting Article 28(3), and the regulation uses neither. An addendum is simply a DPA attached to an existing commercial contract, so check which document prevails if the two conflict.
Does a US company need to sign a DPA?
It does when it processes EU personal data on behalf of a customer, or when it uses vendors to process EU personal data it controls. The Data Privacy Framework also requires a contract for transfers to the US made solely for processing. A company with no EEA data subjects generally does not need one.
What is the difference between a DPA and a BAA?
A DPA implements GDPR Article 28 for personal data, while a BAA implements HIPAA for protected health information. They have similar elements, such as safeguards, subcontractor controls and return or destruction of data, but one does not replace the other. A provider handling both EU personal data and US patient data needs both.
Who should review a DPA before signing?
Have your privacy counsel review the legal terms and your IT provider confirm that the security, subprocessor and deletion commitments can be met in your environment. For health data, include someone who knows your HIPAA obligations.
Sources
- What is a data controller or a data processor? (European Commission)
- EDPB Guidelines 07/2020 on controller and processor
- Data Privacy Framework: Obligatory Contracts for Onward Transfers
- New Standard Contractual Clauses: Questions and Answers (European Commission)
- Commission Implementing Decision (EU) 2021/914
- Commission Implementing Decision (EU) 2021/915
- UW–Madison GDPR contractual provisions guidance
- Data Processing Agreement vs Addendum
- HHS Business Associates FAQs
- HHS Guidance on HIPAA and Cloud Computing
- 45 CFR § 164.504
- GDPR and Fax: What the Rules Allow
- Recruiters: Make DPIAs Nonnegotiable for GDPR Recruiting