oneDPA v1 (download, how to use, playbook, feedback)
What is oneDPA?
oneDPA is a crowdsourced, standardised DPA. We worked with a group of lawyers from some of the world’s leading law firms and in-house teams to collaboratively create a standard DPA.
|Use this form to create your oneDPA documents for free via ContractPodAi.||Download the Word documents here to manually complete them using the flowchart below.|
Find a redline comparison of oneDPA v0.1 and v1 here with release notes here.
How to manually complete oneDPA
Katie breaks down how to choose your oneDPA documents and complete them in this handy tutorial here.
Which oneDPA documents should I use?
The chart below explains which documents you should use in the different circumstances.
(click on image to enlarge)
Do you have a completed example of oneDPA?
Click here to see a working example on how we complete oneDPA.
Get oneDPA adopted in your organisation
We understand that driving organisational change and getting a new document adopted within your company can be a challenge.
Click here to read our step by step guide on how to get oneDPA adopted.
Need help communicating the benefits of oneDPA internally? We've put together a Comms Pack for you here.
We've created a playbook to help you use oneDPA and push back on requests for changes to the main terms.
Download the playbook here.
What happens when the other side sends you their DPA? We suggest you push back and ask them to sign oneDPA instead. Here’s a template email we suggest you use:
As you may be aware, a new general purpose standard wording Data Processing Agreement has been launched recently by oneDPA which we at [COMPANY NAME] have adopted for all suitable transactions. I am sure you will agree that much time is wasted unproductively reviewing different DPAs when the same legal requirements are required in most scenarios, and standardised contracts are of course successfully used in many commercial situations.
oneDPA was created collaboratively by a group of leading law firms and in-house teams with input from the wider legal community. The terms of oneDPA have been discussed extensively to not only ensure it meets legal requirements, but also to make it balanced, fair and easy to understand. Adopters of oneDPA have had very little push-back when proposing its use, so clearly confidence about the document is being expressed. To see a list of other oneDPA adopters, please have a look at the directory.
oneDPA can be used at no cost but cannot be amended other than to populate the details specific to our engagement with you on the first page. The purpose of this is to prevent unnecessary negotiations from being a blocker to the business, given the balanced nature of oneDPA’s content. I would like you to consider using the oneDPA document for this project without amendments to the Terms, and attach a copy below.
If you have any questions on oneDPA, you can read the FAQs or leave your question here and the oneDPA team will get back to you.
We're always trying to improve oneDPA. If you have any feedback on oneDPA, leave it below and we'll review it for the next version of oneDPA.
This document is subject to the CC BY-ND 4.0 Licence.
Got a question?
Read our FAQs here, leave a comment below or drop us an email at firstname.lastname@example.org
An idea for the Playbook ... a lot of pushback we receive as processors comes from controllers wanted to expand our obligations (beyond what is statutory). Think extra audit obligations (unreasonable ones), consent for absolutely everything (which would paralyse a business in practice), expecting us to accept their individual TOMs (again, how could any business have 500 templates for different TOMs for a standardised product offering?!) and more. Is there a way of including requests to expand terms with standardised pushbacks in the playbook?
Also, one other observation, is that a lot of sub-processors (or processors where we're controllers) are expecting to charge for basic (and statutory) requests for assistance, such as a DSAR. I think it's unreasonable as all in the chain now have to live with a certain element of providing support for DP requests as a cost of doing business . Maybe too much of a commercial point for the Playbook, but possibly worth a mention.