Free Data Processing Agreement Template (GDPR & CCPA, 2026)
📥 Download This Resource
Get the free data processing agreement template as a fillable PDF, the editable Word version, and an action checklist:
The short version (2026): Hand personal data to any outside vendor and the law wants a contract in place first. GDPR Article 28 flat-out requires one, and California’s CCPA asks for its own written deal with every service provider. The free data processing agreement template below covers both at once. Roles, processing details, security and breach terms, a subprocessor list, CCPA language. Fill it in, sign before data changes hands, keep a copy.
A founder signs up for an email marketing tool, uploads the customer list, and hits send. Nothing about it feels legal. But the moment those names and addresses land on someone else’s server, two companies are processing personal data together, and the law in the EU, California, and a growing list of other US states says they need a contract that sets out who may do what with it.
That contract is a data processing agreement. If your business collects information about people in the EU or California and hands any of it to an outside tool, a payment processor, a cloud host, a help desk, you almost certainly need one. This guide covers what the agreement has to say, where the GDPR and the CCPA pull in different directions, and how to complete the free data processing agreement template at the bottom of the page. Every rule below is tied to the statute it comes from and linked, so you can read the source yourself.
What a Data Processing Agreement Actually Does

Start with the two roles, because every clause depends on them. The controller is the business that decides why and how personal data gets used. The processor is the vendor that handles that data on the controller’s instructions and nothing more. Run the website and choose the email tool, and you are the controller. The email tool is the processor. Personal data means any information that identifies a living person, from the obvious cases like a name or email to quieter ones like an IP address or a device ID. A data subject is the person the data is about: your customers, your users, your leads.
The agreement does one core job. It converts “we trust this vendor” into a written set of rules the vendor is legally bound to follow. Under EU GDPR Article 28(3), the relationship between a controller and a processor has to run through a binding written contract that sets out the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of people that data describes, and the controller’s rights and obligations. Article 28 is not a suggestion. No contract, no lawful processing.
Skip the document and you are not saving time, you are borrowing it. A handshake leaves you no proof of what the vendor actually agreed to. After a leak, you have no security promise to point at and no right to inspect how the data was handled. The agreement is where those protections live, and a ready-made data processing agreement template puts them on paper in an afternoon.
People call the same document by different names. It is a data processing agreement template when you mean the fill-in-the-blank version, and a data processing addendum when it bolts onto a bigger service contract. Same substance, different label.
Controller or Processor? Work Out Which You Are

Here is where businesses get the paperwork backwards. The two roles carry different duties, and the contract reads differently depending on which seat you are in.
You are the controller when you decide what data to collect and why. A shop choosing to email its customers is a controller. You are the processor when another business hands you data to work on for them, the way a payroll company runs a client’s employee records. Plenty of companies are both at the same time. A SaaS platform is a processor for the customer data its clients upload and a controller for its own marketing list. The practical effect is that most growing businesses sign DPAs in two directions: as the controller with their vendors, and as the processor with their customers.
A quick test settles most cases. Ask who would decide to delete the data tomorrow. If that call is yours, you are the controller and the vendor is your processor. If a client could order you to delete it, you are the processor for that client. The answer can differ file by file, which is why the role belongs in the contract and not in your memory.
Roles matter because of liability. Get them wrong and the wrong party ends up carrying duties it never planned for. Under the GDPR, the controller and processor obligations are split on purpose. The controller answers for picking a trustworthy processor and giving lawful instructions. The processor answers for following those instructions and keeping the data secure.
What GDPR Article 28 Requires in the Contract

The GDPR Article 28 requirements read like a checklist, and a valid data processing agreement template has to hit every item. Miss one and the contract is not compliant, however polished it looks.
The contract has to bind the processor to a specific set of duties. Process the data only on your documented instructions, meaning written directions rather than a verbal nod. Make sure every person it lets touch the data has committed to confidentiality. Put in place the security measures Article 32 calls for. And make available to you the information needed to prove it is compliant, including allowing and contributing to audits and inspections. Article 28(3) lists each of these in black and white.
Documented instructions and security are related but separate duties. Instructions govern what the processor may do with the data. Security governs how it protects the data while doing it. The GDPR points to Article 32 for the security piece, which is why the template carries a short menu of measures, from encryption to access controls, for you to confirm with each vendor.
Then there is the subprocessor rule, and it catches more companies than any other clause. A processor cannot bring in its own vendor, a subprocessor, to help handle your data without your prior written authorization, and it has to hold that subprocessor to the same data protection terms by contract. More on that below, because managing it well comes down to keeping a current list.
What the CCPA Adds for Service Providers

California reaches the same problem from a different direction. The CCPA does not say “controller” and “processor.” It talks about a business and a service provider, and it wants a written contract between them too.
A service provider, in the statute’s words, is a company that processes personal information for a business under a written contract. When the business hands personal information to that service provider, California Civil Code section 1798.100(d) requires the contract to obligate the service provider to comply with the CCPA and to give the personal information the same level of privacy protection the law demands. The state’s regulations, 11 CCR 7051, repeat the point in more detail.
So a CCPA service provider agreement is really a bundle of promises written into the same document. Because a service provider only receives the data for the business purpose named in the contract, it cannot turn around and sell or share that information or use it for its own ends, and it has to protect it to California’s standard. The California Privacy Protection Agency, the regulator, notes that the CCPA lays separate obligations on service providers and contractors, the outside companies a business hires to process personal information.
The CCPA also separates a service provider from a plain third party, and the dividing line is the contract. The written service-provider terms are what keep your vendor in the service-provider category, with its narrower on-your-behalf duties, rather than an outside recipient of the data. That is why the CCPA insists the arrangement run through a written contract in the first place.
Does any of this reach you? The CCPA covers a for-profit business that meets one of a few thresholds. One is size: a company with annual gross revenue over $25,000,000 in the prior year is covered under the statute, a figure the California Privacy Protection Agency has since inflation-adjusted to $26.625 million or more, effective January 1, 2025, for the preceding calendar year. Clear that bar, or meet the CCPA’s other triggers, and your service-provider contracts stop being optional.
Your DPA covers the vendor relationship. Your own website still needs a privacy policy and cookie banner that say the same thing about the data you collect. Termly generates GDPR and CCPA-ready privacy policies, terms, and cookie consent banners, and updates them as the laws change.
GDPR vs. CCPA vs. Virginia, Side by Side

There is no single US privacy law. There is a growing patchwork of state ones, and several require a controller-processor contract that looks a lot like the GDPR’s. Virginia’s Consumer Data Protection Act is the clearest case.
Under Virginia Code section 59.1-579, the contract has to be binding and set out the processing instructions, the nature and purpose of the processing, the type of data, how long it runs, and each side’s rights and duties. It also has to make the processor delete or return all the personal data once the services end. Colorado runs parallel: its Attorney General says the Colorado Privacy Act requires a controller and a processor to define their responsibilities in a contractually binding processing agreement. Serve customers across the country and the safe move is one data processing agreement template that meets the strictest rule in the set, not fifty separate contracts.
| Required contract term | EU GDPR (Art. 28) | California CCPA (§1798.100(d), 11 CCR 7051) | Virginia CDPA (§59.1-579) |
|---|---|---|---|
| Written, binding contract before any data is shared | Required | Required | Required |
| Subject matter, nature, purpose, and duration spelled out | Required | Not specified by statute | Required |
| Type of personal data and categories of data subjects | Required | Not specified by statute | Type of data required |
| Process only on the controller’s documented instructions | Required | Through the duty to comply and give the same protection | Processing instructions required |
| Security measures / same level of privacy protection | Required (Article 32) | Same level of privacy protection required | Not specified in §59.1-579 |
| Prior authorization for subprocessors, same terms flowed down | Required | Not specified by statute | Not specified in §59.1-579 |
| Processor reports data breaches to the controller | Required (Article 33) | Not specified by statute | Not specified in §59.1-579 |
“Not specified by statute” means the law does not force that exact term, not that you should leave it out. A well-built agreement carries all of them, which is why one data processing agreement template can cover every regime at once.
The Clauses Your Data Processing Agreement Template Must Include

Open the free data processing agreement template and you will find these sections, each doing a defined job:
- Parties and roles. Who is the controller, who is the processor, and under the CCPA, who is the business and who is the service provider.
- The processing annex. The subject matter, duration, nature, purpose, data types, and data-subject categories GDPR Article 28 wants on paper. This is the part regulators read first.
- Documented instructions. The processor acts only on your written directions.
- Confidentiality. Everyone the processor lets near the data is under a duty to keep it quiet.
- Security measures. The Article 32 safeguards, from encryption to access controls.
- Subprocessors. Your authorization model and the same-terms flow-down.
- Breach notification. The processor tells you without undue delay, so you can meet your own deadline.
- Assistance. Help with data-subject requests and your other duties.
- Deletion or return. What happens to the data when the work ends.
- Audit rights. Your ability to check the processor’s compliance.
- CCPA service-provider terms. The no-sale limit and the same-level-of-protection promise.
- International transfers. The clause that points to Standard Contractual Clauses when data leaves the EU.
- Signatures. Both sides, dated, before data moves.
Two of these get underused and both matter. The breach clause is what lets you meet your own deadline: the processor has to tell you without undue delay, so you are not the last to learn your data leaked. The audit clause turns “trust us” into “show us,” since the processor has to make available the information needed to prove it complies and let you or your auditor check.
The single most important clause is the one GDPR Article 28(3) puts first, and it is short enough to lift straight into any agreement:
Copy and paste: the documented-instructions clause.
The Processor shall process the Personal Data only on the documented instructions of the Controller, including with regard to transfers of Personal Data to a third country or an international organization, unless required to do so by a law to which the Processor is subject. In that case, the Processor shall inform the Controller of the legal requirement before processing, unless that law prohibits such notice. The Controller’s initial documented instructions are set out in Annex 1 (Details of the Processing). Further instructions shall be given in writing to [processor contact / email].
Every one of these clauses is already in the data processing agreement template, pre-labeled, so completing it is mostly a matter of supplying your own facts.
A data processing agreement and a public privacy policy have to agree with each other on the vendors you use and the rights you promise. Termly builds the policy-and-banner side of that pair so the two documents do not contradict.
Subprocessors and the List You Have to Keep

Almost no processor works alone. Your email tool runs on a cloud host. That host is a subprocessor, a vendor your processor brings in to help handle your data. The GDPR treats this as a genuine risk, not a footnote.
Two rules apply. The processor cannot hire a subprocessor without your prior written authorization, either specific, where you approve each one by name, or general, where you approve a category and get notice of changes with a chance to object. And whatever data protection terms your processor signed up to, it has to impose the same ones on the subprocessor by contract. If the subprocessor leaks the data, your processor is still answerable to you.
Which model to pick is a practical call. Specific authorization gives you the most control and the most paperwork, since every new vendor needs your sign-off. General authorization keeps things moving but puts the burden on you to watch the notices and object in time. Most businesses take general authorization for routine infrastructure and reserve specific approval for anything touching sensitive data.
The practical way to stay on top of this is to keep a current subprocessor list: the name of each subprocessor, what it does, and where it sits. Good vendors publish theirs and email you when it changes. Your data processing agreement template should name your authorization model and attach or link that list, so approval is documented rather than assumed.
Sending Data Across Borders: Standard Contractual Clauses

If your processor or one of its subprocessors sits outside the EU, say on a server in the United States, the GDPR treats that as an international data transfer, and the agreement needs an extra piece. The usual tool is a set of Standard Contractual Clauses, or SCCs: ready-made contract language the European Commission has approved so data can move to countries the EU has not separately declared safe.
The Commission’s current set dates to June 4, 2021, and it exists for exactly this situation: data moving from a controller or processor inside the EU or EEA (the EU plus a few neighbors on the same rulebook) to one established outside it. In practice the clauses ride along as an annex to the DPA whenever data leaves the bloc. This data processing agreement template flags where they go; the full clause text comes straight from the Commission.
One caution: attaching SCCs is a step, not a rubber stamp. They carry conditions of their own, and an unusual transfer setup is worth a look from a privacy lawyer before you rely on them.
How to Fill Out the Data Processing Agreement Template

The free data processing agreement template is built to be finished in one sitting. Work top to bottom:
- Name the parties and roles. Legal names and addresses, and who is controller and who is processor.
- Complete the annex. Subject matter, duration, nature, purpose, the data types, and the categories of data subjects. Be specific. Entries like “various” or “as needed” are what get flagged.
- Set the subprocessor model. Specific or general authorization, and attach the list.
- Confirm the security measures. Tick what applies and describe anything unusual.
- Add the CCPA terms if you handle data about Californians.
- Attach the SCCs if the data will leave the EU or EEA.
- Sign before data flows. Both sides, dated, and give everyone a copy.
Because the annex is where auditors and regulators look first, spend your time there. When the setup is out of the ordinary, an outside tool with its own non-negotiable agreement, sensitive categories like health data, a long chain of subprocessors, have a privacy lawyer read the draft before you sign. Use the data processing agreement template to organize the facts, then buy an hour of review where it earns its keep.
What It Costs to Get This Wrong

Skip the agreement and the exposure is not hypothetical. The GDPR files Article 28 failures in its lower fine tier, which still reaches up to 10 million euros, or for a company, 2% of total worldwide annual turnover for the previous year, whichever is higher. Turnover means gross revenue, not profit, so the percentage lands hardest on the businesses least able to claim they did not know the rule. You can read the tier in Article 83(4).
California keeps its own ledger. Civil Code section 1798.155 puts the administrative fine at up to $2,500 per violation. Intentional ones, or violations involving the personal information of a consumer the business knows is under 16, run up to $7,500 each. Multiply either figure by the length of a customer list and the total moves quickly.
There is a quieter cost too. Enterprise customers now ask for your DPA during procurement, and a missing or thin one stalls the deal. Investors and acquirers check for it in diligence. The document that felt like paperwork on a Tuesday becomes the thing standing between you and a signed contract six months later.
None of this needs a lawyer in the ordinary case. A clean data processing agreement template with a standard vendor is exactly what this is for. Bring in counsel when the facts or the stakes get heavier: health or financial data, children’s data, a processor that refuses your terms and pushes its own, or a transfer setup more tangled than a single set of SCCs. This guide is information, not advice on your specific situation. Used well, the template keeps your legal budget for the questions that actually turn on judgment.
Sign the DPA with each processor, then keep your public privacy policy and cookie consent in sync with it. Termly handles the policy and the banner and re-checks them as GDPR and CCPA evolve.
Sources & References
- gdpr-info.eu
- gdpr-info.eu
- gdpr-info.eu
- leginfo.legislature.ca.gov
- leginfo.legislature.ca.gov
- www.law.cornell.edu
- leginfo.legislature.ca.gov
- cppa.ca.gov
- law.lis.virginia.gov
- coag.gov
- commission.europa.eu
Fact-checked: July 2026

Marcus Thorne writes about business law and contracts for ClearLegalTips. He focuses on making non-compete agreements, buy-sell terms, and everyday business paperwork understandable for owners handling them without a lawyer.
