Is an account ID considered personally identifiable information for data residency?


We are evaluating changes to make our apps on Forge eligible for data residency. We have reviewed the following documentation:

Currently, we have three apps on Forge using Atlassian-provided storage. Our apps include a tool for generating usage metrics for our users (June - Product analytics for B2B SaaS ) to evaluate how users interact within the tool.

Upon reviewing the documentation, we understand that our tool falls under the following case: An external domain defined in fetch (see Runtime egress permissions for additional details).

In this scenario, our event tracker tool uses only the user’s account ID from Jira. We’ve searched various sources to determine if this information is considered PII, and found some community topics suggesting that the account ID is not PII. I am attaching some of the topics we found regarding the matter.

Therefore, we believe we fit into the following context described in the documentation:


We need to verify whether the account ID is considered PII to proceed with the modifications and ensure compliance with data residency requirements.
Does anyone know if there is any Atlassian documentation that covers this topic?

Note: I found this information on the Marketplace app “Details” page. It mentions that this data is not considered End User Data. However, I would like to double-check before considering our apps eligible for Data Residence.

1 Like

I’m not a lawyer - however I’ve dealt enough with this question with our lawyer - yes it’s pii.

AccountId by itself is not PII, however as soon as you have access to an instance which can look up the AccountId - it becomes pii. It’s literally the definition of pseudonymized data (ie it’s not really anonymized and not really directly identfiable).

EU Courts have found that psedonmized data is still pii, if there is anyway for you to convert the data back to a user. For more details - see EU General Court Clarifies When Pseudonymized Data is Considered Personal Data | Inside Privacy .

Simple example - dynamic ip addresses are pii since you could go to the isp and get who had the ip at the time. CJEU Confirms Dynamic IP Addresses To Be Personal Data | Inside Privacy .

If accountId was instance specific (it’s not) then it would stop being pii as soon as the instance uninstalls the app (since you wouldn’t be able to look up the user). However since it’s global - you can look up anyone through other services outside of an instance that uses an accountId.

What makes accountId even more fun is that it’s actually possible to track a user (large vendor with a huge install base for example, could track which instances a user has interacted with their app on). This means that it actually starts landing in various Cookie law realms (see Cooke law).

Now if you were to set a user property on the user that had a uuid - that might make it better for you. However as long as you have access to the instance you could still convert it back so it’s still pseudonimized. Another option would be to set a localStorage/cookie with a uuid and then use that for tracking purposes. It’s still trackable back to the user by you (you could have some code on the client that retreives the value and then syncs up the user).

However your big issue isn’t just gdpr. In your situation you’ll also need to look into the cookie laws (which does overlap with GDPR because of the tracking back to the user). This requires you to request consent of the user before you start tracking them and provide a way for them to withdraw consent.

If you really want to dig into this ball of wax - I suggest reaching out a lawyer to talk about your particular situation.


Hello @danielwester , thank you so much for your response. You brought up several points that were very helpful. In our research here, we’ve concluded that the accountId is PII.