A data processing agreement, or DPA, is the legally required contract that governs how a processor handles personal data on a controller's instructions, and if you outsource any processing of personal data to a third party, you need one under Article 28(3) GDPR. The fastest path to compliance is pulling a solid template and tailoring the mandatory clauses to your actual processing activities rather than writing from scratch.
TL;DR:
- Describe actual processing, data categories, and duration, then name Article 32 security controls, assistance duties, audit rights, and return or deletion terms; generic wording is insufficient.
- Specify a concrete breach notification deadline; the sample clause uses 72 hours, while sensitive data may warrant a shorter window based on risk.
- Classify each vendor relationship by who actually determines purposes, collection, and retention, since contract labels do not decide controller or processor status.
- For EU transfers, identify the legal mechanism and require transfer assessments, subprocessor locations, and safeguards; contract terms alone may not address local disclosure laws.
- Request SOC 2 or ISO 27001 reports, penetration test summaries, and an accessible subprocessor register; sampled audits can ease resistance to broad inspection rights.
Table of Contents
- What a data processing agreement actually is
- The Article 28(3) checklist every DPA must cover
- When you need a DPA and how to confirm your role
- Cross-border transfers and what your DPA needs to say
- How to draft and negotiate a DPA without losing the essentials
- Sample clauses and a quick redline checklist
- Why verification matters more than the template itself
- Why most DPAs fail before they're ever tested
- Another option: hire a vetted privacy specialist through Aura Social
- FAQ
- Sources
What a data processing agreement actually is
A DPA is a binding legal instrument, not a courtesy document. Under Article 28, it must exist in writing (including electronic form) whenever a controller hands personal data to a processor to handle on its behalf. The agreement is what makes the processor's handling of that data lawful: without it, the processing itself falls outside GDPR's framework for third-party arrangements.
Two roles sit at the center of every DPA. The controller decides why and how personal data gets processed. The processor acts only on the controller's documented instructions. Sometimes two organizations jointly decide purposes and means together, which creates joint controllership rather than a simple controller-processor split, and that arrangement needs its own transparency terms rather than a standard DPA.
A DPA does not replace your master service agreement, your privacy policy, or a dedicated security schedule. It sits alongside them, usually as an annex or standalone contract referenced by the MSA, focused specifically on the data protection obligations.
Before drafting, record the basics that anchor the whole agreement:
- The categories of personal data involved and where they originate.
- The specific business purpose the processing serves.
- The systems, locations, and sub-processors that will touch the data.
- The expected duration of processing and what happens when the relationship ends.
The Article 28(3) checklist every DPA must cover
Article 28(3) GDPR lists the mandatory elements a DPA must contain, and regulators treat this as a floor, not a suggestion. Here is the checklist mapped to what you actually need to write into the contract:
- Subject matter and duration of processing. State what the processor is doing with the data and for how long, tied to the underlying service term.
- Nature and purpose of processing. Describe the operations (storage, analytics, transmission) and the business reason behind them.
- Types of personal data and categories of data subjects. Name the data fields (names, emails, payment details) and whose data it is (employees, customers, applicants).
- Processing only on documented instructions. The processor may act solely on the controller's written instructions, including for international transfers, unless law requires otherwise.
- Confidentiality commitments. Everyone with access to the data must be bound by confidentiality, whether through contract or statutory duty.
- Security measures under Article 32. The processor must implement appropriate technical and organizational measures matched to the risk.
- Sub-processor rules. Sub-processors need prior authorization (general or specific) and must be bound by the same data protection obligations as the primary processor.
- Assistance with data subject rights and controller obligations. The processor must help the controller respond to access, deletion, and portability requests, and support breach notification and impact assessments.
- End-of-contract return or deletion. At termination, the processor must return or delete personal data, unless law requires retention.
- Audit and inspection rights. The controller needs the ability to verify compliance, typically through audits or inspections, including of sub-processors.
The EDPB's guidance on controllers and processors is specific on one point that trips up a lot of drafters: a DPA that simply restates Article 28's language without describing the actual technical and organizational measures in place does not meet the bar. Regulators expect concrete detail: which encryption standard, which access controls, which breach response timeline, not a copy-paste of the statute.
Evidence matters as much as the clause itself. Build in a right to request SOC 2 or ISO 27001 reports, penetration test summaries, and a sub-processor register, so compliance is verifiable rather than assumed.
When you need a DPA and how to confirm your role
Any time a third party processes personal data on your behalf, you need a DPA. That covers a wide range of everyday vendor relationships:
- Outsourced payroll, HR, or customer support functions.
- Cloud storage, hosting, or SaaS tools that touch customer or employee data.
- Analytics vendors, email marketing platforms, and call centers.
- Subcontractors brought in by your primary processor.
Figuring out whether you are the controller or the processor in a given relationship is not always obvious from the contract's title. The ICO's guidance on controllers and processors is clear that factual control over purposes and means decides the role, not whatever label the contract uses. Ask who decided to collect the data in the first place, who sets retention periods, and who could stop the processing if they wanted to. Whoever holds that control is the controller.
Mixed relationships are common: a vendor might process some data as your processor and other data as an independent controller for its own purposes (billing, for example). Document each role separately in your procurement records so the right clauses apply to each data flow.
Pro Tip: Keep a short written record of your role analysis for every vendor relationship, it saves time when a regulator or auditor asks how you classified the arrangement.
Cross-border transfers and what your DPA needs to say
Once personal data crosses a border, the DPA has to do more work. Three mechanisms currently cover transfers out of the EU: adequacy decisions for countries the European Commission has approved, Standard Contractual Clauses (SCCs) for everyone else, and, for transfers to the United States, the EU-U.S. Data Privacy Framework. Companies that self-certify under the DPF remain subject to FTC enforcement under Section 5 if they fail to meet its principles.
Your DPA should explicitly reference whichever mechanism applies and build in supporting obligations:
- A requirement that the processor assist with transfer impact assessments.
- Disclosure of where sub-processors are located and what safeguards they use.
- An obligation on the processor to implement and maintain the agreed transfer mechanism, not just promise to "comply with applicable law."
The EDPB has cautioned that contract wording alone is not always sufficient. Where a third country's laws could compel disclosure that conflicts with GDPR protections, the contract has to be paired with a genuine assessment of local law and, where needed, supplementary technical measures.
How to draft and negotiate a DPA without losing the essentials
Treat mandatory GDPR clauses and commercial terms as two separate conversations. A modular template that keeps Article 28 elements in one section and commercial terms (liability caps, indemnities, service levels) in another makes negotiation faster because everyone knows which parts are fixed and which are up for discussion.
- Start from a template built around Article 28, not a generic contract shell. This keeps the mandatory elements visible instead of buried in boilerplate.
- Push security measures into a schedule or annex. Describe measurable controls (encryption standards, access logging, incident response times) and attach evidence like ISO certificates or recent audit summaries.
- Negotiate commercial terms separately. Liability, indemnities, and service credits are legitimate negotiation points, but they should never dilute the Article 28 obligations themselves.
- Set a practical process for sub-processor onboarding. Require advance notice of new sub-processors, the right to object, and a standing register you can check at any time.
Pro Tip: When a vendor pushes back on audit rights, sampled audits or third-party certification review usually satisfy both sides better than an all-or-nothing access demand.
Sample clauses and a quick redline checklist
Short, specific language beats long paragraphs every time a reviewer is scanning a draft. Here are adaptable starting points for the clauses that cause the most back-and-forth:
- Instruction-only processing: "Processor shall process Personal Data only on documented instructions from Controller, including regarding transfers, unless required to do otherwise by applicable law."
- Confidentiality: "Processor shall ensure that persons authorized to process Personal Data are bound by confidentiality obligations, whether contractual or statutory."
- Security reference: "Processor shall implement technical and organizational measures as described in Schedule [X], consistent with Article 32 GDPR."
- Sub-processor flow-down: "Processor shall impose the same data protection obligations on any sub-processor as set out in this Agreement, via a written contract."
- Breach notification: "Processor shall notify Controller without undue delay, and in any event within 72 hours, upon becoming aware of a Personal Data Breach."
- Return or deletion: "Upon termination, Processor shall, at Controller's choice, delete or return all Personal Data, unless retention is required by law."
For special categories of data (health, biometric, or data relating to children, for instance), tighten the security schedule with named controls rather than general language, and shorten the breach notification window where the risk warrants it.
| Clause | What to check in a draft |
|---|---|
| Subject matter and duration | Matches the actual service term, not left open-ended |
| Sub-processor rules | Prior authorization process specified, register accessible |
| Security measures | Reference to a specific schedule, not just "appropriate measures" |
| Breach notification | Concrete timeline, not "promptly" or "as soon as practicable" |
| Return or deletion | Covers both return and deletion, with a stated method and timeline |
Why verification matters more than the template itself
A template only works if the party signing it can back up what it says. Before relying on any processor's DPA, ask for documentation: SOC 2 or ISO 27001 reports, a current sub-processor list, evidence of identity verification for anyone with data access, a documented dispute-resolution process, and a named contact for security reporting.
When evaluating freelance platforms or marketplace vendors as part of your processing chain, the same checklist applies. We maintain a Trust Center and a security reporting channel specifically so clients and partners can verify these points directly rather than taking claims at face value.
Why most DPAs fail before they're ever tested
The biggest mistake in DPA drafting is treating it as a compliance checkbox instead of a working description of real risk. A tick-box DPA that lists generic "appropriate technical and organizational measures" without naming a single control will not survive a regulator's questions or a breach investigation.
The second most common failure is sub-processor obligations that exist on paper but were never actually passed down the chain, or audit rights so broad they get negotiated away entirely. Sampling-based audits are a reasonable compromise and usually get signed faster than demands for full access.
If you fix one thing in your next DPA, make it specificity: documented Article 32 measures, a firm breach notification window, and an unambiguous deletion clause at termination.
— Danell
Another option: hire a vetted privacy specialist through Aura Social
Not every organization has an in-house privacy lawyer or data protection officer ready to draft or review a DPA on short notice, and bringing in outside help is often the faster route. We connect businesses with freelance privacy lawyers, DPOs, and security consultants who can turn around a tailored DPA in days rather than weeks.
That structure tends to attract experienced specialists rather than the lowest bidder, which matters when the document in question is your main defense in a regulatory inquiry. Clients cover a transparent platform fee when hiring, with no hidden costs layered on top.
If your team needs a DPA reviewed, redlined, or built from scratch, you can post your project and start receiving proposals from verified privacy and legal freelancers, often within 24 hours.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
FAQ
What is a data processing agreement?
A data processing agreement is a legally required contract that sets out how a processor must handle personal data on a controller's behalf, including security, confidentiality, and sub-processor obligations. Article 28(3) GDPR defines the mandatory contents of this agreement.
What should be included in a data processing agreement?
A compliant DPA must cover the subject matter, duration, nature, and purpose of processing, the types of personal data and categories of data subjects involved, and clauses addressing instruction compliance, confidentiality, security measures, sub-processor rules, data subject rights support, breach notification, return or deletion of data, and audit rights, as set out in Article 28(3) GDPR.
Are data processing agreements required in the US?
The United States has no single federal law mandating a GDPR-style DPA, but any organization processing data on behalf of EU or UK residents, or transferring data from the EU, still falls under GDPR's reach and needs one. US companies that receive personal data from the EU can rely on mechanisms like the Data Privacy Framework to support those transfers.
Is a DPA the same as an NDA?
No, a DPA and an NDA serve different purposes. A DPA governs how personal data is processed, secured, and returned or deleted under data protection law, while an NDA protects confidential business information from disclosure and does not address GDPR's specific processor obligations.
Sources
- Requirements for GDPR data processing agreement | KirkpatrickPrice
- How do you determine whether you are a controller or processor? | ICO
- Data Privacy Framework | Federal Trade Commission