Does a bare accountId require Personal Data Reporting, and must accountId references be erased after account closure?

General
1

We’re trying to pin down two related questions about accountId handling that the user privacy guide doesn’t answer explicitly. We’d appreciate an authoritative answer from Atlassian, since the two possible readings lead to very different architectures.

Our situation: our apps store accountId values in database records (as owner/assignee/author references), in application logs, and in analytics events. In some of those places it is practically impossible to guarantee complete removal of a specific value - we can only rely on retention windows.

Question 1: Is a bare accountId reportable personal data?

If a record contains only an accountId - no email, display name, avatar, or any other profile attribute, and nothing else in the record relates to the person - do we have to include that accountId in Personal Data Reporting API cycles at all?

In this thread @ibuchanan said that “Atlassian does not consider the Account ID alone to be personal data,” which suggests the answer is no. But the privacy guide says “all apps storing personal data must report” without clarifying whether the identifier alone crosses that threshold. Is the position from that thread still the official guidance?

Question 2: After account closure, must the accountId itself be erased, or only the personal data associated with it?

When the reporting API tells us an account is closed, we will erase all personal data we hold for that user. But must we also purge every occurrence of the accountId string itself - from database foreign keys, historical/audit records, logs, and analytics?

We note that Atlassian’s own products appear to keep the answer at “no”: after an Atlassian account is deleted, Jira retains the accountId on issues, comments, and filters indefinitely and simply renders it as “Former user.” If a retained bare accountId (which post-closure can no longer be resolved to any person via any API) is acceptable in Jira itself, may apps follow the same model - erase all associated personal data but keep the bare accountId as a dangling reference?

Why this matters: if the answer to Question 2 is “you must purge every occurrence of the identifier,” then accountId is effectively unusable anywhere that guaranteed deletion is infeasible (logs, analytics, backups), and vendors would need to introduce their own indirection layer for user references. If dangling references are acceptable (as Atlassian’s own “Former user” behavior suggests), accountId can remain the user key. Explicit guidance on this in the user privacy guide would help the whole ecosystem.

Thanks!

2

Hi @MichaNykiel, three different staffers have said that, across 2018, 2021 and 2022. epehrson first: “if you replace any user identifiers in those user properties by account IDs, then you will not be storing any personal data”, with the Yes required only “as long as you store user keys or usernames or other personal data in user properties”. Then ibuchanan’s reversal, which you quoted. Then AdamSlaski: “AccountId is a personal-data-free replacement for the username”. The only staff post going the other way is ibuchanan’s own first answer, retracted two days later. I think three of them agreeing is about as settled as this room gets.

You will not get a fourth though. Nothing since 2022, and @tbu asked ibuchanan to reconfirm on 54402 this February with no reply.

I have nothing solid for your question 2. Every erasure sentence I found is written about the personal data held against a closed accountId rather than the identifier, which fits your Former user reading, but that is my inference and not something Atlassian has said.

Edit: fixed a quotation. I had “… you can select No” inside epehrson’s quote marks and he does not say that anywhere - it was my own reading of his Yes condition, and it should not have been dressed up as his words.