A useful DPA does more than satisfy legal review; it makes data handling responsibilities operational.
A data processing agreement template helps a business define how a vendor, software platform, contractor, agency, or service provider may process personal data on its behalf. It is often called a DPA, data processing addendum, processor agreement, or controller-processor contract.
This resource is for business teams that need a practical starting point before legal review. It is not legal advice; counsel or a qualified privacy specialist should review the final agreement.
What’s included
- A practical DPA template structure you can adapt for vendor and processor reviews
- A checklist for collecting the information needed before drafting
- A clause-by-clause table for business owners, legal, security, procurement, and operations
- An example workflow for approving and managing a DPA after signature
- Common mistakes and business-specific FAQs
How to use this DPA template
Use the template when one organization decides why and how personal data is processed, and another organization processes that data for it. Under GDPR Article 28, processing carried out on behalf of a controller must be governed by a contract or other legal act that sets out specific processor obligations. Similar contract requirements may appear in customer agreements, privacy laws, security programs, or vendor risk policies.
Before drafting, collect the operating facts. What data is shared? Who are the data subjects? Why is the vendor processing the data? Where is it hosted? Which subprocessors are involved? Who receives breach notices? A DPA that skips those details creates confusion during audits, renewals, incidents, or offboarding.
Data processing agreement template
| Section | What to include | Business owner |
|---|---|---|
| Parties and roles | Name the controller, processor, and any relevant affiliates. Confirm whether the agreement is one-way or covers both parties. | Legal |
| Subject matter and duration | Describe the service, processing period, contract term, renewal rules, and post-termination obligations. | Procurement |
| Nature and purpose | Explain what the processor does with the data and why the processing is necessary for the service. | Business owner |
| Types of personal data | List data categories such as contact details, account data, HR records, payment details, usage data, support tickets, or identity documents. | Privacy or security |
| Categories of data subjects | Identify whose data is processed: customers, employees, contractors, applicants, vendors, patients, students, or platform users. | Business owner |
| Documented instructions | State that the processor may process personal data only on documented instructions from the controller. | Legal |
| Confidentiality | Require personnel with access to personal data to be bound by confidentiality obligations. | Legal |
| Security measures | Attach or reference technical and organizational measures such as access controls, encryption, logging, backups, vulnerability management, and incident response. | Security |
| Subprocessors | Define approval rules, notice periods, objection rights, and the requirement to flow down equivalent obligations. | Privacy or procurement |
| Data subject requests | Explain how the processor helps the controller respond to access, deletion, correction, portability, or objection requests. | Privacy operations |
| Breach notification | Set notification timing, escalation contacts, evidence required, investigation support, and communication responsibilities. | Security and legal |
| Audits and evidence | Define audit rights, security reports, certifications, questionnaires, review cadence, and evidence storage. | Security or procurement |
| Return or deletion | State how personal data will be returned, deleted, archived, or retained when the service ends. | Business owner and IT |
Pre-draft checklist
- Confirm whether your organization is acting as controller, processor, joint controller, or subprocesser for this relationship.
- Map the personal data categories, data subject categories, systems, integrations, locations, and subprocessors involved.
- Identify the business owner, legal owner, security reviewer, privacy reviewer, procurement owner, and renewal owner.
- Collect the vendor’s security documentation, privacy policy, subprocessor list, breach contact, data retention terms, and standard DPA.
- Check whether the customer contract, industry rules, data residency needs, or internal policy requires stronger terms.
- Decide what evidence must be stored after signature: approval notes, completed questionnaire, signed DPA, security review, and deletion confirmation.
What regulators expect the contract to cover
The UK’s Information Commissioner’s Office explains that controller-processor contracts should cover the subject matter, duration, nature, purpose, personal data type, data subject categories, and the controller’s obligations and rights. It also highlights required processor commitments such as confidentiality, security, subprocessor controls, assistance with individual rights, breach support, deletion or return, audits, and making information available to demonstrate compliance.
Ireland’s Data Protection Commission gives similar controller-processor contract guidance and notes that Article 28(3) prescribes minimum provisions. For a business template, the practical lesson is simple: the processing schedule is as important as the legal clauses.
Example DPA workflow
| Step | Action | Output |
|---|---|---|
| 1 | Business owner requests vendor approval and describes the processing purpose. | Intake record |
| 2 | Privacy or security maps data categories, systems, regions, and subprocessors. | Processing schedule |
| 3 | Legal reviews the DPA, negotiates required clauses, and confirms role definitions. | Approved agreement |
| 4 | Procurement stores the signed DPA with the vendor contract and renewal date. | Contract record |
| 5 | Operations sets review reminders for subprocessor changes, security evidence, and data deletion. | Live compliance workflow |
Common mistakes
- Using a generic template without a processing schedule. The agreement should explain what data is actually processed and why.
- Skipping subprocessor review. If the vendor relies on hosting, analytics, support, or AI subprocessors, approval and notice rules matter.
- Leaving breach notice as a clause only. The right contacts, escalation path, and evidence expectations should become an operational workflow.
- Forgetting offboarding. Return, deletion, retention, and certificate requirements should be checked when the vendor relationship ends.
- Separating the DPA from vendor management. The DPA should connect to security review, procurement, contract renewal, access control, and data inventory.
Where Workhint fits
Workhint fits when the DPA needs to become a managed workflow instead of a signed PDF stored in a folder. A team can turn this template into intake questions, role-based approvals, privacy and security review steps, subprocessor review tasks, contract storage, renewal reminders, breach escalation ownership, and deletion confirmation.
That matters when vendor relationships involve multiple teams. Legal may own contract language, security may own controls, procurement may own vendor records, operations may own the workflow, and the business owner may own the service. Workhint helps connect those responsibilities so the DPA remains tied to the work system around the vendor.
FAQ
What is a data processing agreement?
A data processing agreement is a contract or contract addendum that defines how a processor handles personal data on behalf of a controller. It sets processing instructions, security obligations, confidentiality rules, subprocessor controls, support duties, audit rights, and return or deletion requirements.
When does a business need a DPA?
A business usually needs a DPA when it shares personal data with a vendor or service provider that processes the data on the business’s behalf. Common examples include HR systems, payroll providers, CRM platforms, email tools, analytics vendors, support software, and outsourced operations partners.
Is a DPA the same as a privacy policy?
No. A privacy policy explains how an organization handles personal data, usually for customers, users, employees, or website visitors. A DPA is a contract between organizations that defines processing duties for a specific service relationship.
Can we use the vendor’s standard DPA?
Often, yes, but review it against your data, risk level, customer commitments, security requirements, and jurisdictional obligations. A low-risk vendor may need limited negotiation. A vendor handling sensitive, regulated, or high-volume data needs deeper review.
Who should own the DPA process?
Legal usually owns contract terms, but the process should be shared. The business owner explains the use case, security reviews controls, privacy reviews data obligations, procurement manages the vendor record, and operations keeps the workflow moving.
Conclusion
A strong data processing agreement template gives teams more than legal language. It creates a repeatable way to describe the processing, assign responsibility, review risk, approve subprocessors, handle incidents, keep evidence, and close the loop when the relationship ends. Start with the required clauses, then make sure each clause has an owner and a workflow.
Leave a Reply