We plan to release the tab to customers gradually, starting with a small cohort of visitors to the Atlassian Marketplace in March (tentatively March 29, 2023). We are currently planning a wider customer announcement when the tab is visible to 100% of customers, which is planned for May 2023.
You can find more context and information on this release in our announcement blog or in the resources listed above.
And of course, feel free to add questions here on this post.
Iâm having trouble understanding the questions âIs your app a âdata controller/processorâ under the General Data Protection Regulation (GDPR)?â (and the corresponding CCPA questions).
First of all, as far as I understand, withing the GDPR, only a person/organization (and not an app) can be a data controller/processor, so the answer would always be no.
But even if the question is about my company rather than my app, what is the subsequent question âPlease specify the End-User Data with respect to which your app is a âdata controller/processor.ââ about? Is it about the data that we are storing/processing, but then why do we have to fill it out again, since we have specified the answers already above? Or is it about the data that we theoretically have access to, so basically all the data in the whole Confluence instance?
You might want to surface explanations and questionnaires in plain English that help vendors decide how to answer these questions - particularly all the jargon-heavy red tape ones.
I doubt Atlassian has any idea what percentage of marketplace vendors have dedicated security specialists on their team. My guess is itâs very low. Knowing that stat would radically change how you guys go about rolling out these things.
Yes, the question is asking whether you, the person or entity that processes End-User Data, is acting as a controller or processor with respect to the processing activities that your app performs. Your point is well taken that the wording could be updated in a future iteration of the questionnaire to be more clear.
As far as the definitions are concerned, we published a blog on the topic of these definitions here last week. I recommend reading the full blog, but here are some relevant pieces:
â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.â
â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.
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.
The question from @candid is very relevant, because this questionnaire does not seem to take into account this complex relationship, making it very hard for vendors to enter this. It would have been more appropriate to only ask whether vendors offer a DPA, and provide a link to that DPA instead of trying to parse the position of the vendor with regard to GDPR without going into the details of this very complex relationship.
This is a false statement, because of the fact that Atlassian has chosen to make Atlassian ID a 1:1 relationship with the individual Data Subject. The number of Atlassian ID accounts far outnumber instances, making Atlassian predominantly a Data Controller.
For all Atlassian ID accounts, Atlassian acts as the Data Controller. This includes all the PII related to the individual Data Subject that has registered the Atlassian ID. Whenever Marketplace Partners request access to the PII of the Data Subject behind the Atlassian ID, the Marketplace Partner becomes the Data Processor in relation to Atlassian.
Atlassian acts as a Data Processor for user-generated data entered into the host products for the instance of the customer. Any customer data hosted by Atlassian accessible to Marketplace Partners turn partners into Data Subprocessors.
Atlassian acts as a Data Controller for all billing data entered into the Atlassian Marketplace, and vendors are Data Processors in relation to Atlassian.
If Marketplace Partners allow customers to enter data directly into the app, they become Data Processors on behalf of that customer.
How to determine the relationship between Atlassian ID Data Subjects, customers, Atlassian and Marketplace Partners is something only legal scholars might someday manage to understand.
I am still in the process of understanding the difference between a data controller and a data processor (I find this checklist quite useful). As far as I understand, similar to Atlassian in regards to Confluence, we are a data processor in regards to our app, since we are not asking our customers to enter personal information, but if they do, itâs their own choice. (What confused me here was that the the Privacy & Security form was asking a lot about end-user data, and it took me a while to realize that GDPR is about personal information and not end-user data. Since our end users decide whether to use our app for personal information about themselves or about others, our end-users are the data controllers and not the data subjects when using our app.)
Iâm still really confused about the question âPlease specify the End-User Data with respect to which your app is a data processor.â. We are the data processor and our end-user is the data controller, so our end-user is the one who decides what data to use our app for. So what should I respond here? Like every data processor, we process the data that the data controller instructs us to process.
The problem with user-generated content is that you cannot rule out that it will be used to add sensitive information. When you ask for a name, itâs obvious, but if youâre processing free-text form fields (like Jira comments or Confluence pages) there is no way in telling if those contain information governed by GDPR.
It is for this reason that many businesses will simply assume any free-text field will contain sensitive information.
Now letâs look at the definition of Data Controller from GDPR (art. 4):
âcontrollerâ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data;
I think the crucial question is whether or not you are allowing users to enter the data in your app, or if you are merely fetching that data from the Atlassian API. If your end-users are entering the data in form fields in your app, you might actually be the Data Controller as you determine the purpose & means of processing.
If you simply retrieve the data from the Atlassian API (i.e. Jira comments, Confluence pages, etc), you might actually qualify as Data Processor, although this is subject to debate. It is my opinion that because of the agreements between Marketplace Partners and Atlassian, and the fact that Atlassian maintains control of the data and the purpose of processing, I consider Marketplace Partners to be Data Processors on behalf of Atlassian. Atlassian obviously views this differently, which I can imagine because of other legal interests. Itâs up to you to decide
Iâm new to this topic and Iâm generally quite bad at understanding legal topics, but from what I have read so far, my understanding of the terms is a bit different than yours. From what I understand, the distinction between controller and processor boils down to who makes the decision that personal data is collected and processed:
If I provide a form where I ask you for your name, you are the end-user and data subject and I made the decision to collect personal data about you, so I am the data controller. I, not you, have the responsibility to make sure that the data is handled in a GDPR-compliant way. If my form is hosted on AWS, AWS is a data processor and I have to ensure that they also treat the data in a GDPR-compliant way.
If I provide an online text editor and you decide to use it to collect information about your co-workers, you are the end-user, your colleagues are the data subjects, but you are also the data controller, since you made the decision to enter personal information into my tool. I am not collecting the personal information, but you are collecting the personal information using my tool. You are using me as a data processor, and you have the legal obligation to get consent from your co-workers for processing the data and to make sure that I am treating the data in a GDPR-compliant way. If I host my text editor on AWS, AWS is a sub-processor that I have to declare in my DPA, which you have to read to ensure that all my sub-processors and their sub-processors are also GDPR-compliant.
Everything else wouldnât make any sense. If I provide a form asking for the speed limit in Germany, and you enter your friendâs phone number there, it cannot make me a data controller. Otherwise every data processor would be a controller and the distinction wouldnât make any sense.
Now imagining that my text editor is a Confluence app, I would assume:
If you open my app, type in some text containing personal information and press save, you are the data controller and I am the data processor. If I store the data in Confluence, Atlassian is the sub-processor, if I store it on AWS, AWS is the sub-processor.
If you open my app and I collect your IP address and where you clicked when, I am the data controller for this data.
If my app provides a button that scans through your text documents and extracts phone numbers from them and displays them to you, and you click that button, you are the data controller and I am the provider.
If my app scans through your text documents, extracts phone numbers from them and uses them to create internal statistics that I use for analytics, I am the data controller for this data.
I donât think the means how the data is collected (through a form hosted by us or through an API provided by Atlassian) makes a big difference, I think the question is who makes the decision, gives the instruction, initiates the collection of the data.
Now there are of course some specific details that are really confusing. For example, every website needs to process the userâs IP address in order to send the IP packets containing the HTTP response back to the user. So in that sense everyone online would be a data controller. But I guess courts would solve this dilemma by arguing that simply receiving/sending IP packets does not count as processing the IP address, although the recent court decisions regarding Google Fonts suggest otherwiseâŠ
The real question is: did you or did you not anticipate that your input field could be used to provide personal information.
If you take the example of the speed limit: you already know that this will not exceed 3 digits. Accepting the phone number to be entered and not doing any validation whether or not the data is valid will make you vulnerable to personal data being entered (albeit one might argue that a phone number in and of itself is not personal data, but just 10 random digits).
Now with Confluence data or Jira comments, it is reasonable to assume that personal data will be entered. Given that you can assume your form might contain personal data (and in some way solicit it, given the myriad of examples & blueprints of Jira comments / Confluence pages that emphasis personal collaboration), I would say it is hard to uphold that you are not making the decision to collect and process personal information.
Youâre right, the means are irrelevant. However, the reason I make the distinction between retrieving data from the Atlassian API and having a form field in your own app is that it is important to realise that with regard to the Atlassian API, the relationship becomes really complex.
Take into consideration:
The âend-userâ provides the data to Atlassian.
Atlassian decides which apps are allowed to retrieve what data (incl. limiting access based on granular scopes and the ability to block access on their discretion)
âCustomersâ decide which apps to install, thus accepting their access to Atlassian API
âCustomerâ and âend-userâ are often not the same entity
This is a wildly different scenario than:
You decide which forms to put in your app
End-user decides which data to enter in your form
So the means in and of itself do not determine the relationship, but how to govern the data stored in the Atlassian API is very complex with regard to GDPR.
{"statusCode":400,"errors":[{"message":" Third party details are not applicable as App does not stores End-User Data outside of Atlassian products and services.","errorCode":" 006 "}]}
The error above is neither surfaced to the user nor is it clear where things went wrong.
This seems to be a bug. I answered the question âDoes your app store End-User Data outside of Atlassian products and services?â with NO, however, âDoes your app share End-User Data with any third party entities (e.g. sub-processors)?â I would like to answer YES and provide my list of subprocessors (because I answered question 2 on Data Storage with YES).
The data egress question asks if data is shared, which I guess could mean stored (Data Storage question 1) or processed (Data Storage question 2).
Hi @tbinna ! Many thanks for highlighting the issue, we are very sorry for the inconvenience caused, please allow me some time to get back to you with an update on unblocking you here.
Sorry if i missed it in this long thread. Can you clearly state exactly what end-user data is. I know what personal data is and I know what company data is (the stuff they enter into Jira) but what is end-user data?
