Do you run or manage Atlassian Cloud apps and integrations? If so, are you aware of the upcoming March 29, 2019 deadline to ensure that those apps and integrations comply with Atlassian’s developer guidelines for GDPR?
If these questions made your heart race, don’t sweat, we’ve got answers for you.
We recently ran a webinar with Marketplace Product Manager, Alexandra Kassab, and Atlassian’s Head of Privacy, Erika Fisher, to make sure you know how to prepare ahead of the March 29, 2019 deadline.
They shared information about:
- The Atlassian privacy model
- Recommended implementation approaches
- Speeding up data migration to Account ID
- Recently released developer guidelines, including details on in-product data storage and user generated content recommendations
–
We had several questions asked during the webinar and we want to make sure everyone has access to the responses. Have a question that hasn’t been addressed yet? Please leave a comment below!
As an app vendor, when we should start rolling out accountID related changes in production?
You should start rolling out the changes as soon as possible. We are currently in a deprecation period for our old user references which means accountID currently works, as well as legacy user references, however legacy user references will stop working after the deprecation period.
What happens when an employee hides all of their personal data?
A masked version of name and avatar will always be available and returned through our APIs. All other fields will not be present or will return null.
How do you prove that personal data was deleted when requested?
On the Atlassian side, we have a built a process that can be audited. On the developer side, you would want to demonstrate you are listening to the account deletion events and that you are logging some sort of action that can be audited by the customer, 3rd party, or regulators if necessary. A Jira ticket or automated flow would work.
Are privacy settings per Atlassian Account ID, or per Atlassian Cloud instance?
Privacy settings are per Atlassian Account ID.
Are any of these changes applicable to server products and apps?
We do not currently have these settings planned for Server products, though we are exploring how we can translate these to add value for our Server customers. Our Server customers tend to use products in a more “walled garden” environment than our Cloud customers, so we wanted to get these settings right in Cloud first, and learn from adoption before rolling out to Server customers.
Can you expand on best practices for collecting analytics (for example, Google Analytics) with relation to data minimization, purpose limitation, and data retention?
Here are a few rules for data you may collect for analytics purposes (ie, understanding product engagement, improving features, etc.). Note, these rules do not apply for analytics you collect for security purposes - for security-related analytics you are welcome to collect much more specific info, but access should be restricted to those with a role re: security and limited to that use.
For analytics, you want to collect de-identified or pseudonymized data. This means, rather than storing info against a name/email, you store it against an anonymous account ID. In addition, you may be collecting IP addresses, but you want to store those as a city, zip code or even country so that the data element belongs to more than one person. For example, if you were to store "job title," I would encourage you to choose a general taxonomy like "Executive," which may belong to several people, rather than "Head of Product at X Company" which is likely PD. If you are collecting metadata (ie, clicks, activity, etc.) these are not PD if you are storing those data points against an anonymous account ID.
Re: purpose limitation, this is generally handled by restricting access to those who need it for product development.
Getting rid of the data when it is no longer needed or when it is stale is important - having clear data retention or refresh guidelines depending on when the data is no longer needed is key.
We will also spend some time on this at Developer Day if you have a chance to attend.
How should we handle support request that come through our Jira Service Desk Cloud instance?
Jira Service Desk customers also have customer accountIDs (similar format - likely with the pre-fix "qm:"). We intend to treat that personal data similarly. If a customer requests data deletion anywhere that user is referenced (including support tickets) we will honor that request.
For the data retention management pieces, will Atlassian be providing a stable manner for apps to be aware of whether an app installation is expired?
We are planning to address the issue around termination of cloud instances. We don't have an estimate yet for when that will be fixed though.
Is it correct to think that a user’s choice to erase their information will only be exposed in instances that they have actually logged into? Otherwise, thousands of users redacting data could end up being multiplied by the number of instances (a lot of queries).
User choice will be reflected anywhere that the user has been referenced regardless of whether or not they've actually logged in. For redaction, as long as you are pulling the data from accountID directly, which is what our products will be doing, the name will be updated to reflect the redacted version.
Is there any personal data that would be mandatory for security purpose?
You may require IP address, email addresses or passwords for security purposes (and to support incident investigations). It is perfectly fine to store and keep that data for security purposes, but the data would need to be stored separately and only accessed by the security team. It would also need to be deleted after a reasonable period of time. For example, here at Atlassian, the security team logs quite a bit more info that our product teams ever see. They keep that info up to 365 days (even where a user is requesting data to be deleted) in case of an investigation/incident. But only the security has access to that data.
–
We’ll be sharing a series of posts over the coming months in the here, in the developer community, about what to expect ahead of the March 29, 2019 deadline and how to prepare. Please follow the ‘gdpr’ tag here for the latest updates.