nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Data Residency Feedback: User Account Data, Licensing, and New Regions

RJ Gazarek

Hi everyone! If you're joining me from the community post I published earlier: https://community.atlassian.com/t5/Enterprise/Data-Residency-Roadmap-Plans-and-your-Feedback-wanted/ba-p/1598260#U1599531

Welcome!

I'd like to use this thread to get some feedback on anything published in the article, and more specifically on the points I highlighted in the title:

User Account Data and Data Residency
Data Residency outside of Enterprise plan
New Regions we're expanding into

One of our biggest areas is around both User Account Data being part of data residency, as well as the external regulations that you are looking to meet with this need. When we speak to customers, partners, and even our tech peers - we've learned that a lot of these laws are still widely open for interpretation. Especially in some areas, such as EU when events like the Schrems II court case striking down the privacy shield.

So when it comes to those customers that are asking for User Account Data (e.g. your name and email address) to be stored within your country, I'd love to learn more on what the underlying internal policy or external regulatory control is that you're looking to meet by having this included.

Another interesting side to this is, if it really is Name/Email that you require within country, does that also include not just your profile/account data in Jira, for example, does that also include our customer records of you in our IT systems (like for billing, as an example).

What our initial finding with customers is, when it comes to user account data, again Name/Email, that they don't really care/need that to be permanently stored within the country. But what they do care about is any personal data they generate in the product, (such as putting your customer's name and email into a jira issue or confluence page) - and of course that is already covered today by our data residency strategy.

So would love to hear more from you all on that topic specifically, and of course anything else you'd like to give feedback on!

Comments

Jerome Skalnik

As part of a Canadian company, very happy to see that Canada is on the roadmap especially as it will factor into our consideration as we look at a migration to the cloud.

RJ Gazarek

Great to hear @Jerome Skalnik

We have lots of work to do here, and things to work through, but we know how important this region is to that part of our customer base, so we're committed to delivering it!

unknown

We are a cyber security firm in Belgium. We have an internal policy that no data can leave the EU whatsoever. If this trust is violated then we have to inform our clients which could potentially cause them to go to another provider.

It's paramount that we get the ability to ensure our data stays in the EU as soon as possible. I understand its on the roadmap for Q2 this year. Are there any other guarantees besides this? For example we see that our data is in Germany at the moment, what is the possibility of this data moving outside the EU?

The second we see that our data leave the EU, we have to make a phone call to our clients. It's very serious for us. Hoping to see some further updates.

Thanks again for this initiative,

Alexander

RJ Gazarek

Hi @[deleted]So a few things to unpack here, to make sure we're on the same page.

First is that we do offer data residency in the EU today for our Enterprise Cloud plan. We have two datacenters, one in Frankfurt and the other in Dublin, where we host the data. Today you have to be on the Enterprise Plan, and make sure in the data residency admin settings, you pin your instance to the EU.

As far as what type of data is stored there, you can visit our support documentation on that: https://confluence.atlassian.com/cloud/manage-data-residency-976763149.html

But essentially, we store your data in the EU that was generated by you in our JIra and Confluence products. This is usually your most sensitive data, and what customers are asking we store in the EU. Some of that data, whether it's in transit, or cached up to 30 days, or processed for your use of the product - can leave the EU boundaries.

For example, if you have an employee that leaves the EU, say for a work trip in Japan, or Australia, and needs to access the data, that data leaves the EU for that customer and employee, but it is still permanently stored in the EU.

So I'd love to get some more clarification on what the boundaries are on "can't leave the EU". Does that mean it can never leave the EU, even in any type of processing, in-transit, or for employees that work in other parts of the world? Or do you mean, can't leave the EU, as in it can't be permanently stored outside of the EU?

unknown

Hello @RJ Gazarek

Thanks for the detailed response. The issue is we are a small firm with 120 employees. So it would be nonsensical for us to purchase the enterprise plan. Therefore, we do not have the component for pinning our instance to a specific data center, in this case we'd prefer Frankfurt.

For GDPR EVERY data flow that occurs outside of the EU needs to be reported to the client. So if some one logs in from Australia and their data is stored there for whatever reason, this would need to be reported to the client. Our customers all request that their data (user data, incident data, audit data) pertaining to their organizations should remain in the EU. Otherwise it needs to be immediately reported to them.

Thanks again for your speedy response!

Regards,

Alexander Sinno

RJ Gazarek

Hi @[deleted]- I would love if you'd be willing to go a little more into details with your concern here, and if you're more comfortable doing so over a phone call, I'm happy to do that as well.

So first thing, I agree 120 employees is probably not economical to purchase Enterprise Cloud, unless you need some of our other features in that tier. With that said, we are currently working to provide Data Residency to customers with less than 1000 users, so hang tight - we should have something to talk about in a few weeks around that.

On your other comment about GDPR data flowing outside of EU. I have a couple of questions about that (and anyone else feel free to chime in and answer as well).

Is the requirement to inform your customers of data flowing outside of the EU a requirement that your customers are specifically asking for? Or is this a legal requirement of your country/EU that you have to adhere to?
If this is a legal requirement, could you help me understand which part of GDPR this applies to?
Do you ever have employees that access data from outside of your country? Like employees that are traveling for work? If so, that means they're accessing data outside of the EU, do you report that to your clients as well?
Does the type of data matter? If it's just name & email that travels outside of the EU, does that change if it's more sensitive information like their birthday, or address, or something?
When you talk about data flowing, do you mean all data, even temporary data, cached data, data in transit? Or do you only mean data that is permanently stored?

The reason for some of these questions is I'm looking to get clarity on what some customers in the EU are pointing to for their requirements, because it's not a broad application to all customers. We have EU customers on our cloud today, and with the recent GA announcement of Enterprise Cloud, we have many more who are joining us from the EU in our cloud. We've worked with our customers, and their legal teams, to make sure they're happy about everything we're doing with the data - and they all feel comfortable enough to move to our cloud. So what I have to better understand is why is it okay for some customers, but not okay for others. The more I can understand that, the better I can make sure we're building the right things to meet the majority of our customers' needs.

The other thing we do get told from time to time is "I need to have all of my data remain in the EU at all times". We've worked with our legal team, especially as this relates to the Schrems II court case, to make sure we were still adhering to the legal requirement, and this is what they came back with.

Like most global software-as-a-service companies, Atlassian’s cloud products require some data access by its employees around the world, as well as by its sub-processors listed here. As a result, we cannot meet this requirement.

Fortunately, such a requirement is not part of the current law or the Schrems decision. In its decision, the CJEU upheld Standard Contractual Clauses (SCCs) as a valid data transfer mechanism for transfers of personal data at this time. Atlassian relies on SCCs with its suppliers, and offers a data processing addendum that includes the SCCs here.

So thanks for continuing to engage with us, and again, anyone feel free to jump in and answer those - and if you'd feel more comfortable answering some of them on a call instead of on our community - feel free to send me an email, and let's set up some time to meet and talk! rgazarek@atlassian.com

Marcel Semmler

@RJ Gazarek Thanks for the information.
As a German/European company, I can say that we would really like to see Data Residency for identity/access management/user account being part of the EU data residency. This is something that is coming up in every discussion around Data Privacy and Schrems II as this is a risk.

In the same way, Data Residency for smaller license would definitely help. Jira Enterprise is just to large for a lot of customers which actually is a huge hurdle for them to work with Jira in the future.

Based on recommendations by European data privacy authorities, the alternative for data residency in the EU could only be things like "Bring your own key" encrypting for all data (product data like uploads and identity/access management/user account) and ideally with a European Encryption mechanism. I can see this part being hard in a SaaS environment.

So in my experience, also with other SaaS providers in others areas, full data residency of all data (product data like uploads and identity/access management/user account) is the best suitebale option to move forward.

Concerning the access of employees of Atlassian to data, a detail access log and strict policy/system around access management is something that is necessary, but I already see this in the security policies of Atlassian.

RJ Gazarek

HI @Marcel Semmler - thanks for jumping in and providing your feedback and input!

I'd love to hear a bit more about wanting to see data residency for user account data. And want to level set on the different types of "user account" data, because when I bring this up to EU/Germany customers. They share the same sentiment that they want user account info to be data resident compliant, but then afterwards say it's actually not a big deal. So when it comes to user data, especially as it applies to GDPR, the two buckets are:

Your account data as it relates to your profile and use of the product. Meaning your employees' names, emails, etc. A lot of information which is pretty publicly well known.
Your customer's account data that you store on a confluence page or a jira issue. The type of data that you have to protect due to GDPR requirements.

The latter one, we already meet with our current data residency offering, as any data you put into the product, and is permanently stored, we do so in the region you request. The primary one, we don't have on our roadmap, and when we talk to customers they say in general, they don't really care about that information. It's more of something that, sure, would be nice of course - but is not a hard requirement.

Does that difference make sense, and is your requirement for user account residency still within the same need based on that difference?

Also, with respect to Schrems II court case, our privacy/legal team reviewed the outcome and the commentary about it. This is a copy/paste response from that team, so you can read through it directly yourself:

Privacy and Security are among the highest priorities at Atlassian, and we’re analyzing developments after the most recent Schrems decision.

To address the court’s decision, we currently provide a pre-signed DPA that includes a full copy of the Standard Contractual Clauses (SCCs). Additionally, older versions of our DPA include the SCCs as a fallback data transfer mechanism in the event of invalidation of the Privacy Shield. If your organization wishes to update to the latest DPA, please follow the instructions here.

To the extent we have ongoing obligations under our Privacy Shield Certification, we will continue to honor them.

We're committed to protecting our customers' data and keeping your trust by ensuring data is protected with the utmost care and in compliance with applicable data privacy laws and requirements, including in circumstances where legal standards evolve. For more information see https://www.atlassian.com/trust/privacy/gdpr#data-transfers. For more information around security and data encryption, see: https://www.atlassian.com/trust/security/security-practices#product-security.

So as far as we can see, working with regulators, customers, partners, and peers in tech - we are still ensuring we are maintaining our obligation to the EU in light of the Schrems II court case.

My ask is, if this isn't true for you and your company - can you help me out by pointing to what part of the court case, or what other regulations you need to meet, so I can review these and have a more informed conversation both with you, our customers, and also our privacy/legal team.

Thanks!

Daniel_296onp

As far as I see it, also from my past professional experience, European laws and policies do not distinguish between user account data and content. That's the whole thing. Your differentiatian is artificial, by means means of law. Thinks like the GDPR essentially require governance to be applied when handling personal data, that may be user account data, but also content in the case of Jira, Confluence and also the other products like Bitbucket. It's also not important which role the user has regarding the organization that holds data, may it be user, contractor or customer.

RJ Gazarek

So it's not necessarily artificial as we dig into these with customers. And yes there are two different areas where "personal data" can be stored. That which is in your profile/user account, which we store and control, and meet the legal obligation of GDPR. And then there is data that our customers store within our products, which they may choose to store personal data. Customers are less concerned about their employee data (name, email) being stored in the country, versus the data they store in the product, in the event they store personal data there and have to meet GDPR requirements. With that said, it may be worth it for some companies that deal with extremely sensitive data to adjust their workflows. For example, rather than attaching highly sensitive data to a confluence page, instead, store the attachment locally on your network, and add a link to it from the confluence page, so the document remains on your local network, under your direct control, and can only be accessed by employees on your network and within the confines of your country's borders.

Our terms & service do direct customers not to store highly sensitive data.

Because Sensitive Personal Data is expressly prohibited from being used in the Cloud Products, per Section 5.3 of the Cloud Terms of Service, Atlassian believes that its limitation of liability is commensurate with the nature of the Customer Data likely to be processed in the Cloud Products.

Marcel Semmler

Hi @RJ Gazarek , Thanks for asking.

I agree with Daniel response below. The EU does not distinguish between user account data and content data. The user data of our employees is equally important as the data of our end-users, customers etc. that we might upload and it is held to the same level of data privacy. So the split you make between user access data and product data is only artificial on your side, from the GDPR side that doesn't matter as it is personally identifiable information in both areas.

And the Schrems II does not distinguish which kind of personal data is transferred to the US, either.

So in general, by GDPR, there is this need to store everything within EU or apply appropriate measures. The measures recommended my EU privacy authorities are very strict like Bring Your Own Key-Encryption with a key that only we know or complete anonymization of data (in order to not have personal data anymore).

Daniel_296onp

From my professional experience it's a good practice when adopting new cloud services to perform a kind for "cloud check" - often supported by the CISO or information security team - where the kind of data that is suited for a cloud service at hand.

From an architect view I want to circumvent media breaks, because:

- it's opposite to usability goals defined

- it’s hard to enforce the allowance of data

So, from my view it's better to choose platforms which you can use platforms that can be used without restrictions, due to policies.

Kesha Thill

Hi all, just adding an update to this thread - we recently announced that data residency will be included in our Standard and Premium cloud plans later this year. To learn more and sign up for updates, visit our page here.

To see what else we're working (like additional geographies and functionality) related to data residency, visit our cloud roadmap here.

Bernhard Breit

Hello all!

I am just this guy using confluence to document all the things I want to document about my private IT setup in my basement. I do not care about all the regulations and GDPR and whatnot. I just WANT my data to be in my basement and nowhere else. What can Atlassian offer me? As of now: Nothing. I will need to quit using the fine tool confluence and go look elsewhere.

I am mad at Atlassian for leaving me behind and just like all the other lemmings jump on the cloud rush ... madly down the nearest cliff.

Feel free to comment.

Bernhard.

Welcome!

It looks like you're new here. Sign in or register to get started.