We need to talk about GDPR (again)

Hej Atlassian,

Thanks for sharing this blog post about the importance of having a Data Processing Agreement: Data Processing Agreements (DPAs) 101: What app developers need to know - Atlassian Developer Blog

However, can we please have an honest discussion about how the generics of GDPR do not rely apply to the Atlassian Marketplace, given that you yourself have created some twisted form of GDPR? Personally, I always refer to it as ADPR: the Atlassian Data Protection Regulation.

You see, when you started to implement GDPR, you came to the conclusion that you were in a tight spot because you are selling your products to business as well as individuals.

If you would only sell to businesses, you could have gotten away with the shortcut every B2B SaaS vendor was taking: simply state that the business was the Data Controller and hide behind the contractual necessity clause. That way you would not need consent, as you would be able to offload that burden to the business.

Because the mix of B2B and B2C was just to darn difficult, you came up with a brilliant solution: everyone needed an Atlassian ID, which would be tied to an individual. Regardless of their association with a business. The individual would give their consent, you would be able to record that, and that was that.

But what about those pesky Marketplace Partners who also needed access to PII?

This is when you invented the infamous love triangle between customers, Atlassian and Marketplace Partners. You see, you did not want any legal obligation other than being a reseller. So you were very adement that customers would actually enter into a contract with Marketplace Partners. But if that would be the case, that also means that Marketplace Partners and customers would be able to create individual agreements with regard to data processing, basically allowing Marketplace Partners to set their own contractual necessities for accessing PII.

However, this was causing some headache, because in fact, the customer did not have the right to enter into any agreement with regard to data processing of PII of their users because that was actually governed by the contract between Atlassian and the individual user as part of their Atlassian ID. The only PII that could be shared between customers and Marketplace Partners was user-generated content (although it must be noted that it is already very difficult to determine if that user-generated content actually belongs to the individual Atlassian ID user, or the customer because of your love triangle).

To work around this hot mess, you created the Personal Data Reporting API, a separate process to govern access to email addresses, granular privacy control settings for users and a lot of other technical limitations with regard to accessing the PII of the user.

Anyway, long story short, the blog post is a very decent overview of GDPR within the context of a regular SaaS business. But we’re not regular SaaS businesses. We are bound by the weird constraints of this relationship.

Here is my attempt to clarify that relationship for you in terms of GDPR:

Billing data
This is the most easy part as this data pertains specifically to the relationship between the customer (usually a business), Atlassian and the partner.

Data Subject

Data Controller

Data Processor

Data Subprocessor
Marketplace Partner

You see, Atlassian actually governs this data and shares it with us, the Marketplace Partners. Customers enter into a Marketplace Agreement with Atlassian when they purchase an app which also acts as the Data Processing Agreement. As a vendor, our relationship to this data is governed by the Atlassian Marketplace Partner Agreement. As such, we do not need separate DPA for this data as it is controlled by Atlassian. We simply sub-process the data, for instance in order to provide product update information.

Customer data that may contain PII (user-generated) stored within Atlassian infrastructure

This is where it get’s tricky. This relates to Jira tickets, Confluence pages, etc. which might contain PII. However, due to how Atlassian decided to implement GDPR, that PII is actually entered into the system by the individual user based on their Atlassian ID.

Data Subject
Because of the use of Atlassian ID and the fact that Atlassian entered into an Data Processing Agreement with the individual, one might argue that the Data Subject for that PII is actually the individual, and not the customer.

Data Controller
Because the customer gave access to the user with their Atlassian ID to an Atlassian Cloud instance, the customer becomes the Data Controller over that PII provided by the individual behind the Atlassian ID.

Data Processor
This would then be Atlassian, given that Atlassian processes and stores that data on behalf of the customer in the Atlassian host product.

Data Subprocessor
Marketplace Partner

The reason we are Data Subprocesor again here is because Atlassian again governs every part of the chain with regard to that data. You provide the access to the data, you set the permissions, you determine the scope. The customer enters into an agreement with Atlassian with regard to installing the app and Atlassian provides the information of what data is shared with the app to be able to provide that service. This is even more true with granular scopes, as this basically allows Atlassian and the Customer to further limit the access.

Keep in mind that the customer cannot enter into an agreement with Marketplace Partners with regard to Atlassian product data access independently of Atlassian. This is of crucial importance to determine the relationship.

Customer data that may contain PII (user-generated) stored outside of Atlassian infrastructure

If for some reason, an app requests users to enter information, or if the app stores data from the customer in their own systems (even when retrieved from the host system), this is when we finally get into a situation in which there is a direct relationship between the customer and the Marketplace Partner with regard to data.

Data Subject
Again we need to say that the individual behind the Atlassian ID is the Data Subject and not the customer.

Data Controller
Because the customer gave access to the user with their Atlassian ID to an Marketplace Partner app, the customer becomes the Data Controller over that PII provided by the individual behind the Atlassian ID.

Data Processor
Marketplace Partner

Now this is a scenario in which the Marketplace Partner would need to create a Data Processing Agreement. But only if they allow customers to store data outside Atlassian infrastructure and if that data can potentially contain PII.

Atlassian ID user information

Data Subject
The individual behind the Atlassian ID

Data Controller

Data Processor
Marketplace Partner

This part is actually already well covered by Atlassian, with the Personal Data Reporting API and a lot of technical controls to limit PII of the Atlassian ID account. Again, this does not require the Atlassian Marketplace Partner to enter into a separate DPA with the individual behind the Atlassian ID as the data is already governed by the agreements between Atlassian and the individual as well as the Atlassian Marketplace Partner Agreement.

Due to the complex relationship between Atlassian, customer, individuals with Atlassian ID and Marketplace Partners, one can conclude that there is only one scenario in which Atlassian Marketplace Partners would need to enter into a separate DPA with customers:

if they allow users to enter PII within the context of their app, or if they retrieve content with PII from the Atlassian systems and process/store that data in their own infrastructure outside of Atlassian.

Looking forward to hearing your thoughts about this!


Thanks @remie , your thoughts are quite interesting. There’s also the upcoming security tab, where questions related to GDPR data controller and processor are asked.


Thanks for the analysis. You have been able to put words to a problem that I have also observed with asking Security & Privacy questions with regard to independent SaaS vendors. I was struggling to understand what it means to ask about security & privacy for “an integration”, where an App on the Atlassian Marketplace is effectively just a “pipe” between data controllers.

You make the point for “Marketplace Partners”:

Keep in mind that the customer cannot enter into an agreement with Marketplace Partners with regard to Atlassian product data access independently of Atlassian.

Yet your explanation illuminates what “an integration” means because GDPR still needs interpretation even when the data subject can enter into an agreement independently, as would be the case between Atlassian & Slack. If I have your argument right, then I think it follows:

Data Subject
An individual with an Atlassian ID

Data Controller
A customer organization who “claims” the individual with Atlassian ID

Data Processor(s)
Atlassian for its products & data. Slack (or any other SaaS vendor) because both the data subject & data controller can and do enter in to a separate Data Processing Agreement (DPA).

Data Subprocessor
When the integration is built by either Atlassian or Slack, then the integration is covered by both Data Processing Agreements, not just 1. Or, when the integration is built by yet another party (a Marketplace partner), there might be an additional DPA.

On this last point, I think your logic still applies that DPAs for data subprocessors should be provisional:

But only if they allow customers to store data outside Atlassian infrastructure and if that data can potentially contain PII.

As “pipes”, what integrations might store outside of Atlassian is usually configuration, like for auth and routing. Here Atlassian’s interpretation becomes important again because Atlassian has sometimes said that user-anonymizing tokens (like an OAuth access token) are PII. While that might be true for the primary data controller and processor, that doesn’t make sense for a subprocessor, where either the controller or processor can revoke the “identity” (for example, by revoking the client id & secret, or even revoking the token itself, in which case, it becomes “a null pointer”).

Overall, I find your reasoning informative and compelling. I would be happy to pull the right people into this thread but I’m not entirely clear on your ask or the implications of your conclusion. (My confusion may be a function of “I am not a lawyer” and “I’m not aware of all the history”.) Does your argument suggest something should be done in Marketplace? For example does it suggest changes to the upcoming Security & Privacy Tab? Or does it inform some other artifacts like documentation?

NOTE: My comments were an attempt to interpret the argument in the original post. The post does not represent the official position of Atlassian and should not be construed as legal advice.

Hi @remie - thanks for your post, we appreciate that GDPR analysis can be complex.

Atlassian’s own in-house legal team, with assistance from subject matter experts in the privacy space, have devoted significant resources towards ensuring that our Cloud products are built and designed in accordance with widely accepted standards and certifications - for anyone following this discussion, you can learn more about our GDPR commitment here if you haven’t already seen it. While we are unable to provide any specific legal guidance on how our partners should interpret GDPR in relation to the products and services they offer to customers, we would like to pass along some high-level information to help clarify some of the questions raised in this thread. Ultimately, we recommend that partners always consult a lawyer with any concerns or questions about if and how the GDPR specifically applies to you.

Atlassian’s relationship with end-users. Where an individual end-user has access to Atlassian products purchased by an organization (for instance, the end-user’s employer), that organization (the customer) is the administrator of the Atlassian products that they purchase and is responsible for the accounts it controls. Atlassian enters into an agreement with that customer to provide these services and to process personal data on behalf of that customer (i.e., the employer) and not the individual end-user.

For more details, please see the preamble to the Cloud Terms of Service; the Atlassian User Notice; Exhibit A, Part A under “Categories of data subjects” of our customer Data Processing Addendum; and the Atlassian Privacy Policy sections on managed accounts and the “Notice to End Users.”

When is Atlassian a controller or processor? We publish this information in our Data Processing Addendum (DPA) with customers. At a high level: Atlassian predominantly acts as a processor of personal data on behalf of our customers, in connection with the provision of our cloud products. In certain circumstances, Atlassian acts as a controller of personal data (e.g. for billing processes, to comply with applicable laws and to ensure the security of our cloud products etc.) You can learn more by reading our section 2.2 of our customer DPA, as well as Exhibit A, Annex 1(B), Part B of the customer DPA.

Are Marketplace Partners sub-processors? No. When Atlassian engages a sub-processor who will process customer personal data on behalf of and at the direction of Atlassian, we enter into an agreement with that sub-processor and list them on this page. We do not list Marketplace Partners on this page because Marketplace Partners are not sub-processors to Atlassian.

If you think back to the controller / processor guidance in our DPAs 101 guide: Marketplace Partners who list their own customer-facing apps in our Marketplace aren’t processing customers’ personal data on behalf of Atlassian, or at the instructions of Atlassian, or in order to provide functionality to Atlassian - they’re usually either processing personal data for the benefit of the customers using their apps, or for themselves. This is in contrast to the companies you’ll see on our sub-processors list: vendors who process data on our behalf to provide a service to us, like AWS.

What’s the relationship between Marketplace Partners and customers? Marketplace Partners and their customers enter into an independent legal relationship each time a customer chooses to install an app. Under our Marketplace Partner Agreement, Marketplace Partners agree to: (1) enter into their own End User Terms and (2) End User Privacy Policy with customers, for each Marketplace app they list (see Section 5.6 - End User Terms). Marketplace Partners are responsible for determining how they process data, what data processing role they take on with respect to their customers, and ensuring that data is processed in accordance with the commitments they make to their customers (see Section 8.4 - End User Data and Privacy-Related Obligations).e

When should Marketplace Partners enter into a separate DPA with customers? Atlassian is not a part of this relationship and can’t dictate what legal terms you use to offer your apps to customers. That’s why we recommended in our DPAs 101 guide that if you are processing personal data, you should consider whether you are a data processor and whether you need a DPA in place with your customers. That said, 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 partners have any concerns or questions about how the GDPR specifically applies to you, we recommend that you consult a lawyer for further guidance.

Hi @amardesich,

As always, thank you for responding so eloquently on my pesky questions. I fully appreciate that you have a lot of other tasks to attend to, so please know that I am really grateful that you still manage to find the time to engage!

I have definitely read the Cloud Terms and Privacy policy, and I think they are exceptionally well constructed to try and create a legal reality that matches how Atlassian wants GDPR to work. It is obvious that you have spent a lot of time on this and have engaged with high profile legal experts.

In addition, I am also very much aware that what I’m about to say sounds painfully arrogant. I’m not a legal scholar. Not even a lawyer. Heck, I didn’t even graduate. I run a extremely small coding shop. What the hell do I know about the legal intricacies of GDPR. I get it if my statements are disregarded because of lack of expertise.

Yet here we are: I’m 100% confident that the Atlassian interpretation of GDPR is (partially) incorrect, that several Atlassian agreements are in contradiction of each other and that your policies are a legal construct meant not to implement the goals of GDPR but to enable your business in the least disruptive way.

For what it’s worth: Atlassian is not to blame. You’re in good company, as all other SaaS vendors have created similar policies. They probably engaged with the same high profile law firms. The legal world settled on an interpretation of GDPR that was least disruptive to businesses and implemented it everywhere. Which in turn created a confirmation bias: everyone else is doing it, so this must be the right implementation.

I can even argue that Atlassian has gone further than many other companies, with the ironic result that your misdirections of GDPR have created even greater inconsistencies/contradictions.

However, given that there has not been a final ruling by the Court of Justice of the European Union (CJEU) on these type of constructs, it is unclear what their status is. Until that happens, I cannot blame you for sticking with what Atlassian Legal department and legal experts are telling you. I can only disagree.

If you want, I can dissect every part of the agreements that I think are incorrect/incoherent/contradictory, but that would only make sense if Atlassian is willing to question the legal construct Atlassian has created.

Or, if you are open to go a step further: I would love to work together with you and @efisher and present this case to the Dutch Data Protection Authority, and pursue it until it ends up with the CJEU for a definitive answer. Atlassian has a legal entity in the Netherlands, so it would make sense to do it here. Would you be open to that?


Hi @amardesich ,
thank you for your reply.
I want to advise you that the list of sub-processors you reference ( List of Data Subprocessors | Atlassian ) is not complete.
Atlassian lists additional partners (i.e. sub-processors) here: IP addresses and domains for Atlassian cloud products | Atlassian Support . I think from a legal standpoint it would be important to have a complete list of sub-processors. Especially Launchdarkly, Optimizely, Segment, Gravatar, Google, and Sentry.

Who is the right person to ping for this discrepancy in these lists?

Hi @remie we won’t always agree, but a healthy discussion is always beneficial so thank you for that.

In the end, we depend on our legal counsel to help us understand how to interpret complex privacy regimes like GDPR. They keep up to date on the latest developments, so if the CJEU were to release a final ruling that impacted our operations, we would assess and make any necessary changes.
For everyone following this conversation, it’s important again to stress we encourage all of our Marketplace Partners to contact lawyers of their own for any guidance on GDPR and how it applies to them and their apps.

Hi @marc
The entities listed on our sub-processors list are vendors that Atlassian has determined meet the definition of a sub-processor, as set out in our customer Data Processing Addendum.

The sub-processor list does not include all vendors that Atlassian engages, only vendors for which Atlassian has made the legal determination that they are sub-processors. For example, some of the vendors listed on the page that you shared are not sub-processors of Atlassian because they may not process personal data of our customers, or Atlassian may act as a controller of the customer personal data processed by those vendors. A detailed description of our processing activities is set out in our customer data processing agreement (DPA).

Also, Segment is on the sub-processors list but under the name of its parent company Twilio.

Hi @amardesich ,
Thank you for your explanation. I think I now understand Atlassian’s reasoning.