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
Customer
Data Controller
Atlassian
Data Processor
Atlassian
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
Atlassian
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.
Conclusion
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!