Deleting Former Staff(User) Details

Hi
I have a quick query re, your (https://developer.atlassian.com/cloud/confluence/user-privacy-developer-guide/)[‘user privacy developer guide’].

Some context
I’m part of a team that is developing an app that looks at how work flows in large organisations. Based on our user research, a must-have feature of our app is being able to scroll back in time to compare and contrast and visualise changes over time. This would involve looking at workload (partly implied by JIRA issues) for a team over time and therefore, show team member names.

What we’d like to know from you
When looking into how to connect JIRA to our app, we’ve come across your ‘user privacy developer guide’. From this, we have picked up that you would request us to delete user PII within 15 days of the user leaving their team / organisation. Please can you outline your intent and rationale as to why you have put this requirement in place?
I ask because following your guidance would mean that we (and therefore our clients) would no longer be able to make use of the core feature mentioned above. Looking back in time, i.e. looking at an incomplete data set (not showing team member names) becomes significantly less meaningful. Our well-grounded legal advice has been that we are in a position to retain user data (incl PII - in this instance, name only) as long as we have an active commercial relationship with said client (as long as the users themselves don’t request deletion).

Clearly, we are not the only tech company with said challenge and therefore, I’d appreciate if you could come back to me with a view on the above. From a personal perspective, I am yet to be convinced that all employers delete their former employee records from any tooling they may use in the work place - ranging from HR to Finance to day-to-day workplace productivity tools.

Thank you

Hi Team,
Looking forward to your reply!

I’m not an Atlassian but what you’re hitting is GDPR. I should also say I’m not a lawyer - I don’t even play one on tv - please take whatever comes next with that in mind. This is going to be heavily superficial pass to try to answer your question (you’re better off getting somebody like @akassab to chime in).

So a couple of things - the user data in Atlassian Cloud land is stored in Atlassian ID. The relationship is between Atlassian and the user. Atlassian is just being nice and letting us look at it. :slight_smile:

The reason that you have to delete the data of 15 days isn’t because that they left the org - they were removed from Atlassian ID. That means that all systems downstream that has gotten the data needs to remove it. That removal could be for several reason - the biggest one being that the user requested it. More than likely a user won’t know that you’ve received the data (they didn’t acknowledge installing the app on the Jira, Confluence, [insert Atlassian app here] - so they can’t give you the permission to keep the data.

If you want to get a better understanding of the rationale etc - https://www.atlassian.com/atlascamp/watch-sessions/code-and-beyond/data-privacy-gdpr-and-beyond-what-does-it-mean-for-atlassian-developers .

Best approach though is not to store the data at all. The other gotcha that you’re going to run into is the profile controls where the user may specify that only the admins and them can see portions of their data (ie the user is there - but you’re not going to see much of the info based on the user’s setting).

If you have to store data about the user - store the accountId and then at runtime - look up the user’s information. I believe storing the accountId is fine…

Hoping that @akassab will speak up here and tell us how wrong I am…

Oh my @LisaMariaVoigt, have you unknowingly opened up a can of worms here.

To add upon what @danielwester already mentioned: the problem fully originates from the fact that Atlassian is offering their services to both companies and individuals. This means that they cannot hide behind the contractual clauses loophole that most SaaS companies are abusing to avoid having to get consent from real persons.

To solve this predicament, Atlassian went fully overboard with centralising any and all PII in the Atlassian ID, making this the one true source of PII. You can use this Atlassian ID for any service offered by Atlassian. Which means that I can be provided with a Jira account by my employer, but use the same Atlassian ID for hosting my personal Git repositories on BitBucket.

By choosing the real person with their Atlassian ID as the single point from which all PII is distributed amongst Atlassian and 3rd party services, this also means they had to implement all the user rights from that specific point. So the right to be forgotten applies to the Atlassian ID account and all information that has been passed down to 3rd party sources. Hence the requirement for vendors to remove any and all locally stored PII within 15 days.

So yes, your legal counsel is correct in stating that you have a contractual clause with your customer, however, your customer does not have any control over the Atlassian ID. This is a 1-on-1 relationship between Atlassian and the real person behind the Atlassian ID. Your customer was only given permission to use such Atlassian ID and the PII within the context of their use of Jira, as were you within the context of your vendor agreement with Atlassian.

If you feel like your head is spinning by now, join the club. Atlassian has created a really intriguing web of legal love triangles (or maybe squares?) between Atlassian, users, companies and vendors.