Storing personal data in user properties is gdpr compliant?

Effective at 10 Dec 2018 there will be a new required field for cloud apps, stating if personal data is stored outside of Atlassian systems by an app. We have an app that stores user data in user properties (/rest/api/2/user/properties). We think that this means that we still can select “No” in the new field.

Is this correct?, that sounds a bit odd to me. Can you be more specific as to what personal data you are storing in user properties, and for what purpose? - Jira will not clear user properties after data deletion is processed for account close. This means that if you are storing personal data in user properties you should help clear personal data after account close which means you will have to select “Yes” and implement the Personal Data Reporting API.

@epehrson @akassab We currently store the userids of users (covering for a user that is not in office), but change to accountIds there also.

Other data that is stored there is project ids and a personal message, that is send, when someone assigns an issue to this user.

This information is automatically deleted as soon as the date of the absence is over.

Does this still mean we must implement the api?, if you replace any user identifiers in those user properties by account IDs, then you will not be storing any personal data. The project ID is an Atlassian entity identifier, and the personal message is user-generated content. Neither is considered personal data.

As long as you store user keys or usernames or other personal data in user properties, you will be required to select “Yes” in the Marketplace selector and report on these user accounts. Once you complete the migration to account ID, you can select “No”.

1 Like


Is this also need for Server Apps? My Add-on named Timesheet for Confluence stores usernames in MySQL database installed to customers server? So do I need to select “Yes” on this?

Hi @matti.kiviharju -

The field applies to all apps (Server / Cloud / Data Center). The requirement to implement the personal data reporting API is only applicable for Cloud.

Hello @akassab ,

We are only storing account Id and Display Name of the user in our connect app ( replaced userkey /userId with account Id). Will Display Name be considered as personal data?


Hi @sfg - Yes. Display Name is personal data. We recommend only storing accountID.

Wait what? Is it the official stance of Atlassian that user generated content is not considered PII? You people have a weird interpretation of GDPR…

@remie, can you elaborate on what you disagree when comes to PII? I’m still learning.

The disagreement follows from the choices Atlassian is making in regards to PII, which are very inconsistent.

In general, there are three distinct roles defined in the GDPR: the Data Subject (the natural person to which the PII applies), the Data Controller (the entity that requests and handles the PII from the data subject) and the Data Processor (the entity that does a specific task with that PII on behalf of the Data Controller).

Atlassian is in a bit of a tricky spot: it does business with both individual users (making Atlassian the Data Controller) and companies (for which Atlassian is Data Processor, and the company itself is Data Controller on behalf of the employee). To complicate things: Atlassian has decided to enforce an Atlassian ID for all users, meaning that regardless if you are accessing the Jira Cloud instance of your company, you, as a data subject als go into an agreement with Atlassian with Atlassian being the Data Controller.

This mixup makes it really hard: normally, if I were a employee of a company I would be able to ask for removal of my PII upon resignation. The company is than obliged to remove my records from all systems, including Jira. However, because Atlassian is using Atlassian ID, it means my relationship with Atlassian could in theory live beyond my commitment to the Jira Cloud instance of my employer. I could have used that same ID to sign up for a different service within the Atlassian sphere, say BitBucket Cloud.

To fix this problem, Atlassian has embarked on a mission to A) irradiate their systems from PII as much as possible, B) create very complex privacy settings (incl. UI option for each different state) that will make APIs behave differently based on the privacy settings of either the company or the individual user, C) create PII records API for interfacing with 3rd parties (vendors) to allow them to trickle down requests for data removal via Webhooks and D) update all legal documents to make sure everyone in the Atlassian sphere plays by the same rules.

From that perspective, it is really strange to see that Atlassian has taken their hands of user generated content. Because that does not stroke with the fact that they are doing their best to control every aspect of PII within their systems and the systems of 3rd parties (vendors).

There is probably a good technical reason for this, because detecting PII in user generated content is really difficult. And in some extend, Atlassian is right for not touching this. However, they cannot have it both ways: either you want to fully control PII within your systems, or you create a legal structure in which you do not take any responsibility for PII leaving it solely with the Data Controller or Data Subject.

The strange legal mixup Atlassian has created for itself in combination with the practical implementation simply doesn’t make any sense from a GDPR perspective.

1 Like

Thanks @akassab!!

In order to report the user personal data for connect apps using following API
POST /rest/atlassian-connect/latest/report-accounts

Scenario : One database for multiple tenants ,

For the purpose of personal data reporting

  1. Can any tenant be used from database in order to generate JWT token
  2. Use that tenant and jwt to report users for multiple (different) tenants.
  3. Can reporting for jira and confluence users be combined or do they need to be separate?