Hey @MarkPitsilos,
I can offer my 2c here, but please note that I am not a lawyer and my interpretation does not represent legal advice or an official policy stance from Atlassian.
The personal data reporting API was built to support compliance with GDPR legislation (and emerging data privacy legislation in other jurisdictions) for apps that run on top of Atlassianâs products. The personal data reporting API allows Atlassian to offer our customers a streamlined process for actioning âright to be forgottenâ requests for Atlassian accounts that may also have data stored by third parties through the usage of these apps. Without this, an Atlassian customer would need to issue a separate âright to be forgottenâ request to Atlassian and every single provider of every single app they may have used across every single Atlassian site they ever logged in to. We did not view this as an acceptable user experience.
The idea that sits underneath this is that for a typical Atlassian app, if the user chooses to exercise their right to erasure for Atlassian products, they would no longer use Atlassian products and therefore also no longer use the apps, so the data can be safely erased.
The situation sounds a bit more complex for you since it seems like even if a user stops using Atlassian products, they may still want to retain usage of the product you are building the integration for?
Do we need to implement Personal Data Reporting API as a platform, or is this responsibility transferred to the Atlassian app owners who will be entering their OAuth credentials on our platform?
I believe the onus is still on you to handle the userâs personal data appropriately, regardless of who is configuring the connection.
Also what is the usage of the PDR API?
Atlassian will funnel accurate data into the API for you to action based on your requests. We also use information from the API to periodically identify apps which may not be in compliance with their obligations.
By posting accountIds there should the responsible party proceed with data deletion if the account has since been deactivated?
Yes, even if the account has been de-activated, you are still responsible for ensuring that you are no longer storing any of the userâs personal information.
How is the response from the PDR API supposed to be utilized?
The response should include information about which user accounts require action on your part to delete or update. Does that answer your question?
You should be confident that whatever course of action you take complies with your privacy policy/data policy. Presumably there would be a privacy policy or specific terms that explain to the user what will happen if they use the âsign-in with Atlassian OAuth 2â option? Within Atlassian, we typically would involve a legal counsel or privacy expert in helping us understand the requirements for a feature like this and ensuring the legal terms are updated.
Depending on the stance you take with regards to your privacy policy, you might:
- Go ahead with deleting your paired account if the Atlassian account has been deleted⊠or;
- Scrub personal data synced from Atlassian from the paired account, but keep it active and accessible to the user⊠or;
- Disassociate the paired account from the deleted account, but retain the personal information in your systems so that the userâs experience in your product is unchanged.
Either way, I think that you will need to integrate with the Atlassian personal data reporting APIs unless you have specific legal guidance that says its un-necessary.
Hope this helps! Cloud data privacy is a complex and tricky topic, and I certainly donât consider myself an expert.
Joe