• Products
  • Documentation
  • Resources

Understand data residency

If a product shows COMING SOON on the data residency overview, it means self-serve is unavailable for products with more than 2 hours of downtime on Standard and Premium plans. We're working to offer this option, but if you have urgent needs, contact support.

Check if your products can be data resident. Go to admin.atlassian.com > Security > Data residency.

This feature is available for Jira Software, Jira Service Management, Jira Product Discovery, and Confluence with Enterprise, Premium and Standard plans. It’s also available for Jira Work Management with Standard plans.

Data residency gives you control over where your in-scope product data for Jira Software, Jira Service Management, Jira Work Management, Jira Product Discovery, and Confluence is hosted. It allows you to choose whether it’s globally distributed or held in place in a defined geographic location, such as Europe or the US.

We're adding Canada to the list of supported locations in phases. You'll see it as a supported location within the next few weeks.

If you work in a regulated industry like finance, government, or healthcare, data residency may be a necessity for operating in a cloud environment. More generally, it can also help you meet company data management requirements.

View where your product data is hosted

You can view where your in-scope product data is hosted from your organization administration. You must have organization admin permissions to do this.

To view where your product data is hosted:

  1. Go to admin.atlassian.com. Select your organization if you have more than one.

  2. Select Security > Data residency.

This will open the data residency page for your organization. This page lists the products in your organization, the location of each product, and the AWS regions the location corresponds with. If a product is PINNED to a location, its in-scope data is held in place there.

If data residency is available for your product, you can request to have its in-scope data moved and pinned to a new location. To learn more about this, see Move data to another location.

To protect your data, we create automated Amazon Relational Database Service (RDS) backups daily. When you choose a data residency location, we also store backups of your data in this location. Learn more about how we manage your data

What are locations and AWS regions?

A product’s location is the geographical boundary where its in-scope data is hosted. Each location corresponds with one or more AWS regions, which are physical locations around the world where AWS clusters its data centers. Learn more about AWS infrastructure and the role it plays in our cloud hosting infrastructure.

The following locations are available for you to select from:


AWS regions


All Atlassian cloud in AWS regions


Consists of AWS Sydney region


Consists of AWS Canada (Central) region


Consists of AWS Frankfurt and Dublin regions


Consists of AWS Frankfurt region


Consists of AWS Singapore region


Consists of US East and US West regions

By default, all products are hosted in the Global location, which includes all of our AWS regions. For these products, we determine where their in-scope data is located. To optimize product performance, we don’t limit data movement for these products, and we move data between AWS regions as needed.

If you require your in-scope product data to stay in a specific location, and data residency is available for your product, you can request to have its in-scope data moved to a location and pinned there. To learn more about this, see Move data to another location

In-scope product data 

This table lists in-scope product data types that can be pinned, and out-of-scope product data that can’t. For definitions on these data types see the glossary.


✅ Can be pinned

❌ Can’t be pinned

Jira Software

  • All attachments

  • Board and sprint data

  • Comments

  • In-product notification data

  • Jira issues and field content (including system and custom fields)

  • Jira search data

  • Project configuration data (including workflows, custom field configuration, and board configuration)

  • Connected DevOps data (including commits, branches, pull requests, builds, deployments. feature flags, remote links)

  • Product analytics

Jira Service Management

  • All attachments

  • Comments

  • In-product notification data

  • Knowledge base category data (if integrated with Confluence)

  • Asset object data and schema configuration data

  • Jira issues, request types, and field content (including system and custom fields)

  • Jira search data 

  • Project configuration data (including workflows and custom field configuration)

  • Queue data

  • Configuration management databases (CMDB) used for the external asset platform.

  • SLA configuration data

  • Any incident management features powered by Opsgenie. Learn about data residency for Opsgenie.

  • Customer accounts

  • Product analytics

  • Data used by Halp

Jira Work Management

  • All attachments

  • Comments

  • In-product notification data

  • Jira issues and field content (including system and custom fields)

  • Jira search data

  • Project configuration data (including workflows, custom field configuration, and board configuration)

  • Product analytics

Jira Product Discovery

  • Jira Product Discovery ideas

  • All attachments

  • Idea comments

  • Fields values (except values for votes, reactions and formulas)

  • Jira search data

  • In-product notification data

  • Project configuration data

  • Product analytics

  • Views configuration & comments

  • Insights

  • Field configuration

  • Dynamic fields (Vote, Reactions, and Custom formula)


  • All attachments

  • Comments

  • Confluence page and blog data

  • In-product notification data

  • Page and comment likes

  • Page metadata

  • Source data for notifications in emails

  • Permission and restriction configuration data

  • Product analytics (search data and space keys)

Atlassian Access


  • User account information data

  • Audit log events

All products

  • Some Atlassian Marketplace and app data

  • Some Atlassian Marketplace and app data

  • Automation rule configuration data

  • Cached content, such as emails and notifications (up to 30 days)

  • Data in transit (up to 30 days)

  • Product, audit, and operational logs

  • Product analytics

  • Team profile information data

  • Third-party product integration data

  • Transient rule execution data

  • User account information data

  • User analytics

Atlassian Analytics and Atlassian Data Lake

  • Product data stored in the Atlassian Data Lake

  • Chart metadata (including chart titles, settings, annotations, queries, and comments)

  • Dashboard metadata (including dashboard titles, URL slugs, and other settings; comments; variables; subscription configuration (including email, frequency, and variables); and text elements)

  • Data sources (including data source names and configuration data)

  • Activity (including query logs and activity logs for dashboards and data sources)

Why we don't pin user account information data

We store user account information in a central identity service, and a small, controlled set of replica services. We don’t pin these services, and the user account information in them, because we host them around the world to meet the performance needs of our customers.

We store user account information this way to limit its footprint in our system. It means that this information is not stored in our products at all. Instead, our products store representative IDs that they use to retrieve it from our identity services.

For these reasons, data residency cannot apply to user data at this time. We understand that this may be a challenge for some of our customers, and we are happy to help you find a solution that would work better for your data residency needs.

For more information on where and how we store user data, see the Atlassian Trust center.

How we maintain GDPR compliance

We take privacy seriously, and operate a global privacy program to meet the requirements of the GDPR, CCPA, LGPD, and beyond. We treat all user data the same way and use industry-standard technical and organizational measures to secure the information we store. Our Privacy Program is tailored to meet both legal requirements as well as your needs.

Learn more at the Atlassian Trust center. Or, for information specific to the EU, read about our GDPR commitment.

How does data residency work for Marketplace apps?

An app, sometimes called an add-on or plugin, is an installable component that supplements or enhances product functionality. You can find apps on the Atlassian Marketplace.

Atlassian Marketplace is comprised primarily of apps built by third-party Marketplace partners. These partners often work closely with Atlassian and use Atlassian's tools and APIs, but are not part of Atlassian. Only some Marketplace apps support data residency, which means pinning and migrating app data from one location to another. If an app supports data migration and pinning, you can request your data to be moved and stored within the same location as your host product. To learn more about this, see Moving your Marketplace apps data to another location.

Data residency for Marketplace apps largely depends on third-party Marketplace vendors. When you request a data residency move for an app, your request is sent to the third-party Marketplace partner who operates and handles the app data move.

When you move app data to a new location, keep in mind the following:

  • Once your product data has moved to a location, you can request to move eligible app data to the same location.

  • Both product and its apps will be offline, during the data residency move for apps.

  • Moving data for apps will require separate downtime, as the app data can only be moved once the product data is pinned.

  • Moving app data will require up to 24 hours of downtime

  • Some apps may not support the ability to move data because of one or more of the following reasons:

    • They don't support data residency in the same location as the host product yet.

    • They don't store any in-scope data, so no data needs to be migrated or pinned to a location.

    • They store data exclusively within the host product.

    • They currently don't support data residency move.

  • All eligible apps will be pinned together to the product location when the move is finished.

For more information on a specific app, refer to the app's listing on Atlassian Marketplace, where you will find a privacy policy, documentation and contact information.

How data residency works for Opsgenie features

Jira Service Management combines rich service management capabilities with modern incident management powered by Opsgenie. The result is a next-generation solution for both IT and Enterprise Service Management (ITSM & ESM).

Currently, Jira Service Management features powered by Opsgenie aren’t incorporated into the Jira platform. However, Opsgenie data can be independently moved to a new location using the cloud migration feature in Opsgenie. Learn more about moving your Opsgenie data.

When you move Opsgenie data to a new location, keep in mind:

  • Opsgenie data and Jira data each move independently and have separate downtimes.

  • Currently, the downtime for an Opsgenie data migration is up to 24 hours from the time of request. When Opsgenie experiences downtime, any Jira Service Management features that are powered by Opsgenie will also experience downtime.

Learn more about data residency for Opsgenie.

Data residency glossary 



Asset data

Third-party asset data stored in the asset platform used to synchronize with Jira functionality.

Atlassian Access

Atlassian Access is a subscription that you purchase for your whole company. It enables visibility and security across all Atlassian accounts and products, and gives you one place to manage your users and enforce security. Learn more about Atlassian Access

Atlassian Marketplace and app data

Data from Connect apps that may be stored outside of the Atlassian cloud environment by a third-party app vendor.


Files attached or added to Jira Software, Jira Service Management, Jira Work Management, or Confluence issues, pages, or other content.

Audit logs

Logs generated by admin actions.

Automation rule configuration data

Data that we capture when an Automation rule is created or edited to enable us to define its behavior.

AWS region

Amazon Web Services regions. Learn more about AWS infrastructure

Cached content

Content stored in a non-specified region for up to 30 days with the purpose of:

  • Progressive content migration to a nominated location

  • Temporary storage of transactional content, such as emails and notifications, until delivery has been confirmed or abandoned.

  • Temporary storage of query results and rendered charts for dashboards in Atlassian Analytics

Connected DevOps data

Data related to the Jira DevOps experience including:

  • commits

  • branches

  • pull Requests

  • builds

  • deployments

  • feature flags

  • remote links

Customer accounts

User data in your customer accounts for Jira Service Management projects. 

Data in transit

Data being processed or moved across, and not stored, by Atlassian store.

Incident management functionality data

The data used in functionality for the incident management feature powered by Opsgenie.

In-product notification data

Data related to Jira Software, Jira Service Management, Jira Work Management, and Confluence in-product notifications.

Jira Service Management features powered by Opsgenie

All features accessed through the Opsgenie URL. Some of these features are displayed in the Jira Service Management product screen.

Knowledge base category data

Categories for the Jira Service Management knowledge base, including description and configuration displayed in the portal when integrated with Confluence.

Operational logs

Atlassian system logs used for operational maintenance and diagnostic purposes.

Page metadata

The data used to describe a Confluence space for the purpose of search indexing.

Permission and restriction configuration data

Data related to the configuration of product or site access permissions or restrictions.


Product data that is held in place in a location.

Product analytics

Events fired by our cloud products for in-product user experience optimization and performance.

Product data

Data added directly by a user.

Product data at rest

Data added directly by a user, that has persisted for 30 days or longer in our cloud data stores.

Product logs

Logs generated by Jira Software and Confluence product changes related to content and configuration.

Queue data

Data in customer requests triaged for teams to answer. For example, a summary, status, or customer name.

SLA configuration data

Service Level Agreement text field names, time metric configuration, calendar configuration, and JQL queries for SLA Goal configurations.

Source data for notifications in emails

Data in an email with notification details. For example, an email that contains issue names and comments.

Team profile information data

Data related to your Atlassian team profile, including:

  • name, description, or header image

  • all team links information and activity

Third-party product integration data

Data from any product integrated with Jira Software, Jira Service Management, Jira Work Management or Confluence. For example, a Github integration.

Transient rule execution data

Data that we pass to an Automation rule, or is looked up by an Automation rule, so it can perform its actions. We only keep this data for the duration of the rule execution. It may include issue and user data.

User account information data

Personal account information including:

  • name

  • email address

  • avatar

User analytics

Events fired by our cloud products to help understand experiences based on how a user interacts with products.


Additional Help