DPA Frequently Asked Questions

General Data Protection Info

What is a DPA?

A data processing agreement (DPA) is a written contract between 2 parties that:

• governs the sharing of personal data between parties,
• outlines each parties' obligations and responsibilities when handling personal data, and
• provides contractual assurance that both parties will comply with the GDPR (and any other relevant data protection laws).

When do I need a DPA?

You will need to agree to a DPA whenever you're processing (i.e. sharing, storing, collecting, etc) personal data from a third party. If no personal data is being processed, a DPA won't be needed!

How do I know if I am a controller or a processor in a DPA?

Controllers are the main decision-makers – they exercise overall control over the purposes and means of the processing of personal data. Processors act on behalf of, and only on the instructions, of the controller.

To determine whether you are a controller or processor, you will need to consider your role and responsibilities in relation to your data processing activities:

• Controller. If you exercise overall control of the purpose and means of the processing of personal data (i.e. you decide what personal data to process and why), you are a controller.
• Processor. If you don't have your own purpose for processing the personal data and you only act on a client’s instructions, you are likely to be a processor – even if you make some technical decisions about how you process the data.

What are the legal requirements for a DPA?

For a DPA to be compliant with the GDPR it must meet all of its Article 28 requirements, such as obliging the processor to only process personal data on instructions from the controller, rights for the controller to audit the processor, ensuring processors have appropriate security measures in place, and more.

However, there are other data privacy laws which require specific terms in a DPA, such as:

• the UK Data Protection Act 2018,
• the US California Consumer Privacy Act 2018 / California Privacy Rights Act 2020, and
• Australia's Privacy Act 1988.

What are the data processing principles?

There are seven key principles parties should adhere to when processing personal data, including:

1. Lawfulness, fairness and transparency. Processing must be compliant with laws and fair and transparent to the individuals whose personal data is being processed.
2. Purpose limitation. Personal data can only be processed for a specific and legitimate purpose.
3. Data minimisation. Only personal data which is necessary to fulfil the purpose should be processed.
4. Accuracy. Personal data must be complete, accurate and up-to-date.
5. Storage limitation. Personal data must be destroyed or returned to the controller at the end of the processing activity and can't be kept any longer by a processor (unless to meet the processor's legal requirements).
6. Integrity and confidentiality. Personal data must be processed securely to prevent any loss, damage or destruction to an individual's personal data.
7. Accountability. Controllers, processors and sub-processors must be accountable to an individuals for how they process their personal data and respond to any requests by an individual about their personal data.

About oneDPA

What is oneDPA?

oneDPA is a crowd-sourced, legal-community led, open-source initiative to standardise the DPA

Why use oneDPA?

The Data Processing Agreement (DPA) is ripe for standardisation. Most of its content is driven by regulation or case law and very few commercial points are usually included.

The premise for oneDPA is simple - if we all agreed to agree to the same DPA template, we’d save ourselves enormous amounts of time, cost and painful negotiations.

With input from of some of the brightest legal minds in the industry and feedback from a wider community of 1300, we’ve created a DPA that’s fair, balanced and written in plain English. And it’s free. It’s a no brainer.

Who drafted oneDPA?

oneDPA has gone through an extensive drafting process with leading law firms and in-house lawyers from around the world. It’s been a collaborative process and no one firm or company is responsible for the drafting.

None of the law firms involved were engaged by TLB to give legal advice - all their time was kindly volunteered. The participating law firms haven’t assumed a duty of care or approved the final draft and therefore are not professionally responsible to you. You should speak to a lawyer if you have any doubts as to whether the oneDPA is appropriate for you and your circumstances.

Why does oneDPA not include some of the clauses I'm used to seeing?

We've carefully considered what terms to include in oneDPA and have ensured it contains the key obligations required under data protection laws. We haven't included unnecessary and overly onerous obligations or terms which are more commercial in nature to prevent burdening either party.

Have a look at the Playbook to find out more about why the terms we've included are the only ones you need. If you have feedback on our Playbook, please let us know on our feedback page.

Which jurisdictions does oneDPA apply to?

oneDPA is a jurisdiction agnostic agreement and works with global data protection laws. We've drafted the agreement particularly with the GDPR, UK DPA and CCPA requirements in mind, however the parties can include whichever data protection laws apply to them in the variables table.

If in doubt, please seek legal advice to make sure oneDPA will work as expected with your governing law.

Should we include a liability cap?

Including liability caps in oneDPA is optional for the parties. It's a fairly standard practice for parties to agree to all commercial terms (such as liability limitations) within the overarching Main Agreement. However, if the Main Agreement is silent on a party’s liability levels with respect to a breach of their data protection obligations, this information can be included in oneDPA.

You'll find template wording in oneDPA which refers to the parties in the Main Agreement for where to find information regarding liability caps, however you may also choose to delete this row entirely if you and the counterparty agree that an extra reference is not necessary. 

If the data processing activity involves international data transfers which requires you to enter into the SCCs, the liability provisions in the SCCs will ultimately take precedence over any agreed liability limitations in the Main Agreement/oneDPA (if they conflict with SCC wording). 

Does oneDPA apply to privacy laws in China?

oneDPA has been drafted to be jurisdiction-agnostic, allowing the parties to insert the relevant data protection laws that apply to them. If personal data from China will be processed under the DPA, you can include relevant Chinese privacy laws as the "Data Protection Law". 

We understand the Chinese Personal Information Protection Law has been based on the principles of the GDPR, therefore the obligations on controllers and processors in oneDPA should capture legal requirements. However, if you and the counterparty feel there are certain terms in oneDPA which should be adjusted, you're always able to amend the Terms if necessary via the "Special Provisions" row in oneDPA.

Both parties are joint data controllers - can I use oneDPA?

If both parties are joint data controllers, you should enter into a separate transparency agreement which includes different types of requirements than a data processing agreement. oneDPA would not apply to that relationship.

What should I send to the other side to tell them about oneDPA?

We've drafted a cover note explaining what oneDPA is and why it's mutually beneficial for the parties to agree to, which you can send alongside oneDPA to the counterparty.

What should I do if I'm receiving pushback from the other side?

As oneDPA is non-negotiable, we've prepared this Playbook which includes canned responses that you can use to explain to the other side why you can't accept their suggested changes. These responses will help prevent long negotiations and we are confident they'll encourage the other side to see the value in oneDPA and its content.

If you have feedback on our Playbook, please let us know on our feedback page.

Do I need to use any other documents with oneDPA?

If you are transferring personal data internationally, you'll need to agree to additional "Transfer Mechanisms" required under the GDPR and UK DPA. There are 6 options for you to choose from which work with oneDPA. We've created a flowchart to help you determine which Transfer Mechanism applies to your processing activity.

Annex 1 – Security Measures: Presumably this could be used to insert our own security measures that we want to oblige the processor to follow?

While we usually see the processor insert their own security measures in Annex 1, you’re completely free to insert the security measures which you want the processor to follow. 

Article 30(2) of UK GDPR contains a provision requiring a processor to maintain a record of all categories of processing activities carried out on behalf of a controller (unless the organisation employs less than 250 people). Is this provision covered at a high level?

DPAs must contain all Article 28(3) obligations for processors, however additional legal obligations under the GDPR are not expressly required (such as Article 30). Additionally, the warranty on both parties to comply with relevant obligations under applicable data protection laws generally resolves any concerns for controllers, knowing that the processor will not only comply with the requirements set out in this DPA, but additional legal obligations not expressly covered.    

We would normally expect to see processor obligations to assist the controller with things like data accuracy, data portability (Art 20), data minimisation (Art 5(1) ) and generally to ensure compliance with GDPR. These are not specifically mentioned - do you consider this is covered more broadly in the OneDPA?

Similar to the above, other GDPR requirements which don’t need to be expressly set out in DPAs are generally caught by the warranty to comply with relevant obligations under applicable data protection laws. 

We hope this resolves your concern however, if your internal practice generally requires compliance with additional Articles to be expressly mentioned in your DPA, you are always welcome to add these in the “Special provisions” row of the variables table at the start of the DPA. We appreciate some organisations may have additional requirements depending on the risk profile of the data processing activity concerned, which can be inserted as a special term.

Clause 2.2(g) covers processor assistance with DPIAs, responses to data subject requests and engagement with the likes of the ICO. Should there not be an additional provisions for processors to notify controllers if they receive a DSAR, complaint or any correspondence with the supervisory authorities or is this clause aimed  to cover this?

Clause 2.2(g) has been drafted to generally cover notice of and assistance with any requests, complaints or correspondence with a data subject or supervisory authorities. Based on feedback from the wider legal community, the process and obligations described in oneDPA are generally acceptable for controllers and processors as it allows the parties to collaborate as needed to respond to these types of requests. In order to also satisfy these assistance obligations in practice, the processor would need to notify the controller if  it received a request/complaint/etc in any event. 

However, as mentioned above, you are welcome to insert additional notice requirements if your company has a particular process it requires its data processors to follow if it receives these types of requests, as a “Special provision”. 

For controller to controller relationships, the ICO Code refers to having to set out procedures in the data sharing agreement for access to data in compliance with individual rights as well as requests for rectification and erasure and that all controllers remain responsible for compliance. The code also refers to stating in the agreement the lawful basis for sharing. Do you consider these are covered?

The Controller-Controller sections of oneDPA have been drafted for independent data controllers. We completely agree with your comments in respect of a joint-controller relationship, and have mentioned in other resources that if a joint-controller relationship is identified, the parties should not use oneDPA and should instead enter into a transparency agreement / data sharing agreement that accurately reflects their activity.

For the purpose of independent data controllers though, the terms of oneDPA are sufficient under the EU and UK GDPR.  

The ICO Code lists information governance provisions to be dealt with by the agreement which don’t appear in the OneDPA, including having common rules on retention and deletion of data. Do you consider these are covered?

As mentioned above, we agree information governance provisions should be included if the parties are joint-controllers. However, under an independent controller relationship, these provisions are not legally required and the terms of oneDPA adequately cover legal requirements for that type of relationship.  

How would special category data be dealt with if using OneDPA?

We would suggest completing a DPIA before entering into oneDPA if you’re processing special category personal data. This is to:

• ensure appropriate technical, security and organisational measures are included at the outset,

• determine what transfer mechanism should be used and whether any “Special provisions” should be included in respect of additional safeguards, if the special category data may be transferred internationally, and

• confirm whether or not collecting that type of personal data is absolutely necessary for the identified purpose and that there are no other reasonable or less intrusive ways to achieve that purpose.

What's next for oneDPA?

I have feedback, how can I share it?

Feedback is strongly encouraged. We need to iterate to make oneDPA better. Please leave your feedback here.

How are updates going to be agreed?

Once a version of oneDPA is published, we'll put it out to the public to provide us with feedback.

The community will also be asked to ‘upvote’ on the suggestions they agree with. That feedback will then be collated at specific intervals and incorporated into the agreement which will be released as a next version. When we release a new version, it won't have any impact on any previous versions you've signed.

What's after oneDPA?

We firmly believe that the future of contracts lies in standardisation. There is no reason why each and every contract should be expressed in different words, especially when 90% of standard commercial agreements say more or less the same thing.

We want the oneDPA community to tell us what they want to see built next, whether that be a clause to layer on top of oneDPA to make it fit for purpose for a different use-case, a completely different agreement or another process which is causing friction and delays.

The more the legal community sings off the same hymn-sheet, the more efficient we become as an industry and the less of a bottleneck we’ll be to the businesses that rely on us to help them promote their commercial interests. Item description.

Does it cost anything to use oneDPA?

No, it’s entirely free to use oneDPA.

How do I start using oneDPA?

Easy! Just go ahead and download it and then tell us you're using it. It’s free and a total no brainer.

To use it, just populate the Variables fields on the first page and send to the other side for signature.

House rules for using oneDPA

Can I add my company logo to oneDPA?

No. The fact that oneDPA is not your template, but an industry standard, gives you leverage. If the other side pushes back, you can say that this is a standard that’s been adopted by hundreds of companies and therefore, shouldn't be changed. The objective of this initiative is to reduce the time we spend on DPAs and keeping the branding neutral is a strategic part of that.

Why can't I change or add my own text to oneDPA?

Because the outcome of everyone being able to add their own language to it is that everyone will end up with their own ‘flavour’ of oneDPA resulting in a world where we all have to go back to reviewing, redlining and negotiating. Not ideal and certainly not in the spirit of the initiative.

However, if you end up negotiating it and changing the language, please make sure you remove any reference to oneDPA and all branding.

I'm a tech vendor, can I add oneDPA to my platform?

Yes, you can do whatever you like with it except actively allow or encourage people to change anything in oneDPA other than the variables. You will not need a tech vendor licence agreement, you may just go ahead and use oneDPA. We would be grateful if you could just let us know you're doing that and that you send us usage data annually so that we can monitor how the document is being used on the ground.

For more information, please contact us at hello@claustack.com.

What does the licence agreement say?

oneDPA itself will be governed by a Creative Commons licence which grants you permission to share, copy and redistribute the material in any medium or format for any purpose.

If you make changes to oneDPA, other than filling in blanks, remove all mention of oneDPA or the brand assets associated with oneDPA.

Will anyone be held liable if oneDPA doesn't work as expected?

No. By using oneDPA, you also agree that oneDPA comes as is, without any warranty at all. No one involved in writing, reviewing, or improving oneDPA will be liable to you for any damages related to this licence or use of oneDPA, for any kind of legal claim.