Data Processing Agreements (DPAs) 101: What app developers need to know

Reading Time: 5 minutes

Note: This blog post is provided for informational purposes only. It is not intended to be a substitute for legal advice. As such, we recommend that you consult a lawyer before acting on any matter discussed within this post.

In 2018, the General Data Protection Regulation (GDPR) came into effect. The GDPR strengthened privacy rights for European Economic Area (EEA) residents and created new obligations for any company that collects, stores, or processes personal data of EEA residents.

This blog post focuses on one key area of GDPR compliance: the requirement for a "processor" of personal data to have a data processing agreement (DPA) in place with the "controller" of that data.

This is an important topic for our app developer community, as developers often act as processors when processing personal data on behalf of their customers, who act as controllers. As a result, those developers have an obligation under the GDPR to enter into a DPA with their customers.

Many app customers that are based in the EEA, or that have end-users based in the EEA, have strict internal requirements for ensuring that the apps they use comply with the GDPR and will not use cloud based apps that do not comply with these requirements. If an app is a processor, having a DPA in place will often be a minimum requirement for these customers.

How do you know if you're a controller or a processor? What's a DPA and what should it contain? We'll answer all of those questions and more in this blog post.

What is a Data Processing Agreement (DPA)?

A DPA is a written contract between two parties that sets out the responsibilities, obligations and rights of both parties concerning the protection of personal data.

Who should enter into a DPA?

The GDPR requires a "controller" to enter into a DPA with a "processor" that processes personal data on behalf of the controller.

A "controller" is a person or entity that determines the purpose and the means of processing personal data. A "processor" is a person or entity that processes personal data on behalf of a "controller." This means that the processor processes personal data according to the controller's instructions.

Apps have different ways of handling different types of personal data, so both of these definitions may apply to your app at once. In other words, you may be a data processor for some personal data (e.g. account information used to provide services to customers) and a data controller of others (e.g. billing data used to process payment). Regardless of this mix, if you are a data processor of any personal data, you are required to enter into a DPA with your customers in order to govern your processing of that personal data.

How do you know if you are processor?

This is a legal assessment that each app developer will need to make based on its own processing activities, but it may be helpful to think about the following questions:

Do you process personal data for your customers on behalf of your customers?;
Do you process personal data at the instructions of your customers?; or
Do you process personal data in order to provide app functionality to your customers (and not for your own purposes)?
- For example: You process customers’ end-users’ account information in order to provide end-users with the ability to login to the app, save and store profiles and create and edit content.

If you answered yes to any of the above questions, you are likely a data processor of at least some subset of the personal data that you process and you are required to enter into a DPA with your customers.

For reference, Atlassian predominantly acts as a data processor on behalf of our customers in connection with the provision of our cloud products. For that reason we enter into a DPA with our customers – see Data Processing Addendum | Atlassian. Specifically, take a look at Exhibit A, where we describe the personal data that we process as a processor.

For more information on how to determine whether you are a data processor see: What is a data controller or a data processor?

What should be included in a DPA?

The GDPR requires that following elements be included in a DPA:

The nature, purpose and categories of personal data being processed;
The duration of processing;
The categories of data subjects;
The rights and the duties of the controller;
That the processor will process data only upon written instructions from the controller (i.e. in the form of the DPA);
That the processor will delete or return all data to the controller after the processor stops providing services;
The technical and organizational measures that the processor has taken to protect the data it processes;
That the processor will seek the controller's approval for appointing new sub-processors;
That the individuals the data processor authorizes to process the controller's data are under an appropriate confidentiality obligation;
That the processor will help the data controller to comply with applicable laws; and
That the processor will make available to the controller information necessary for GDPR compliance, including audit and inspection reports.

Should you include Standard Contractual Clauses (SCCs) in your DPA?

If you transfer personal data relating to EEA residents out of the EEA (e.g. to a third party service provider, like a cloud storage service), you have an obligation to use a cross-border transfer mechanism that is approved under the GDPR. A cross-border transfer mechanism is a method for transferring EEA residents’ personal data outside of the EEA in a way that ensures that data is still protected in the country that it is exported to, in the same way that it would be within the EEA.

Standard Contractual Clauses (SCCs) are one such transfer mechanism that SaaS providers typically use. These are model contract clauses published by the European Commission that companies can enter into with third parties, and are typically included within a DPA. As an example, Atlassian includes SCCs within our Data Processing Addendum | Atlassian in order to govern cross-border transfers of our customers’ personal data.

See our recent blog post here for more information on the SCCs and why you might want to include them in your DPA.

Closing thoughts

If you are an app developer that has customers or end-users based in the EEA, you are likely subject to the GDPR. If you are subject to the GDPR and you are a "processor", you are required to enter into a DPA with your customers.

Beyond ensuring compliance with your own obligations, for many Atlassian customers, having a DPA in place with an app developer who is a processor is a clear signal that the developer understands their commitments under the GDPR and takes the privacy of their customers seriously.

Bottom line – privacy compliance is not just about internal compliance, but about meeting the expectations of your customers, who put their valuable data into your hands. Set yourself up for success by assessing your obligations and, if necessary, putting a DPA in place with your customers.

Remember, the GDPR is a complex law and will apply differently to different apps, depending on where and how you do business, what data you collect about your customers and end-users, and how you use that data, among other things. If you have any concerns or questions, consult a lawyer about how the GDPR specifically applies to you.