Protecting Your Jira Data in the Cloud: What Every Admin Should Know

[#1]

Recently, Atlassian announced the end of support for Jira Data Center in March 2029… Thus, organizations have already started migrating their Jira sites from DC to Cloud or are about to do so…

And here appears the question - “Does moving to Jira Cloud automatically solve the problem of data protection? After all, Atlassian manages the infrastructure, reliability, and uptime of the platform…”

And the answer is that’s true… but only to a certain extent.

To fully understand how Jira Cloud data protection works, it’s important to know where Atlassian’s responsibility ends and where the customer’s responsibility begins.

Let’s break down the Shared Responsibility Model

Like most SaaS providers, Atlassian operates under the Cloud Security Shared Responsibility Model. In Atlassian Cloud, this model clearly defines which security and protection responsibilities belong to Atlassian and which belong to customers.

So who is responsible for what?

Atlassian is responsible for platform-level protection, including:

• infrastructure security
• service availability
• high availability architecture
• infrastructure redundancy
• disaster recovery mechanisms of its services and infrastructure

These measures ensure that the Atlassian platform itself remains operational, resilient, and secure.

Source: Atlassian Cloud Security Shared Responsibilities

However, this does not mean Atlassian provides restorable backups of individual customer account data.

In practice, this means:

• Atlassian protects the platform infrastructure
• Customers are responsible for protecting and recovering their own data
• Point-in-time restore for individual customers is not available in most cases

If data is accidentally deleted, corrupted, or overwritten, restoring it can be very difficult, or even impossible, without a dedicated backup solution.

Understanding this distinction is key to building a reliable Jira data protection strategy.

Real-world scenarios show better why there is a need for backup…

Even in well-managed environments, data loss can happen. Some of the most common scenarios include:

• Human error, e.g., a Jira administrator accidentally (or maliciously) deletes a space that contains years of worklogs, comments, and issue history. Or bulk edits or automation rules mistakenly overwrite or remove time entries across hundreds of issues.
• Configuration mistakes, e.g., a misconfigured workflow, automation rule, or integration, may unintentionally modify or remove important data.
• Security incidents and data breaches, e.g., unauthorized access, compromised accounts, or malicious activity, can lead to data deletion or manipulation.
• Migration and integration issues, e.g., during Cloud-to-Cloud migrations or sandbox-to-production migrations, some data may not transfer correctly, which increases the risk of data loss. Integrations with external systems may also overwrite historical records.
• Compliance and audit requirements, as organizations may suddenly need historical records of worklogs, time tracking, or project history for: audits, financial reporting, legal disputes, compliance verification, etc.

Without reliable backups, retrieving this information can turn into an extremely difficult task.

All of these examples show that data protection should be treated as a strategic process and not just an infrastructure feature.

SaaS provider’s approach - Atlassian’s Backup and Restore

Recently, Atlassian introduced its Backup and Restore. Available for Premium and Enterprise plans, this solution can help organizations complement and address the requirements of the Shared Responsibility Model. As in this case, there is 3 layers of resilience:

1. Trash - the ability to restore data quickly for simple mistakes
2. Atlassian Backup and Recovery - to roll back in case of accidental deletion, configuration mistakes, etc.
3. Atlassian Disaster Recovery, which covers platform-level protection to address and recover its services in case of Atlassian-caused outages

But there are still some limitations…

While Atlassian’s Backup and Restore capabilities are helpful, organizations should be aware of several limitations, like:

• The feature is paid per user, similar to third-party backup tools
• Backups are limited to Jira sites with up to 300 GB of app data and up to 7 million attachments
• Backup retention is limited to 30 days
• Backups are stored only within the Atlassian infrastructure

So, what do if:

• your Jira site is larger than 300 GB?

• your instance contains more than 7 million attachments?

• your compliance regulations require storing backups outside Atlassian infrastructure?

• your organization must follow the 3-2-1 backup rule?

• your security and compliance regulations require long-term retention, for example, 3 or 5 years?

Let’s not forget, account data protection remains the customer’s responsibility.

And since every organization has different regulatory, operational, and security requirements, it’s up to the customer to choose the backup strategy that fits their needs. But when designing this strategy, one important category of data is often overlooked - the data generated and stored by Marketplace apps. 

App data that’s often overlooked

Teams treat Jira work items as the center of their focus. Yet, all other critical data related to them seems forgotten. Take time-tracking data: used for tracking hours across projects, billing, legal and compliance obligations, client reporting, or resource allocation. Plus, all the external systems like HR or finance, are often fed by this data. 

In case of a human error, an incident, or while migrating from the Data Center to the Cloud, multiple business areas can get impacted: 

• Payroll and billing might be disrupted
• Project cost calculations can get distorted
• Client reporting has become delayed

This shows that protecting app data should be a top priority for admins and migration teams. 

Challenges of app data protection 

The main challenge of app data protection is where to store it. Many apps are hosted and managed directly by their vendors, so data is transferred to and hosted on infrastructures outside of Atlassian. This leaves you with little control over its security. There’s no guarantee that the vendor fully complies with standards like GDPR, or that the physical location of the data matches the customer’s instance location. If data crosses regional boundaries, this can create legal and compliance issues. Plus, it can complicate audits, backups, or Cloud migrations. 

All app data under one roof with RoA  

To mitigate these risks, Atlassian introduced Runs on Atlassian (RoA). Under this model:

• All app data is stored within Atlassian’s infrastructure. 
• Each Jira instance is isolated, so one instance’s data can’t be accessed by another.
• There’s also no uncontrolled third-party hosting - only approved services that meet strict RoA requirements are allowed (for example, tools like Sentry may be used for monitoring purposes, but only under defined compliance and security controls aligned with RoA standards). 
• Atlassian governs access through its identity, permission, and authorization layers.
• App data remains in the same region as the Jira instance and adheres to the same security and storage policies. 

Benefits of RoA

Apps that run on RoA come with:

• Improved data protection and greater control over security
• Simplified backup and data recovery processes
• Compliance with regulations and audit requirements 

Focus on security

For both customers and app vendors, security has become one of the key priorities across the Atlassian Marketplace ecosystem. Many popular Marketplace apps already operate under the Runs on Atlassian model - including time-tracking apps, one of the most widely used categories of Jira add-ons. A good example is Worklogs - Time Tracking, Time Reports, Timesheets - when filtering the Atlassian Marketplace by the “Runs on Atlassian” option, it appears at the top of the results. The app was designed to run entirely within Atlassian, without involving any third parties. This ensures that all app data remains safely stored on Atlassian’s infrastructure. Despite security aspects, the app: 

• Is a lightweight tool that can be ready to use within minutes, as it relies on native Jira user groups and existing native and custom data fields. 
• Allows users to easily create personal, team, or project time reports with advanced filtering options.
• Enables export of fully customized reports. 
• Provides data that can be used to feed external systems such as Power BI, HR tools, or invoicing systems.

Protecting Jira app data with a dedicated backup solution - GitProtect backup for Jira Cloud

To properly secure Jira Cloud environments, organizations should consider implementing third-party backup and recovery solutions for Jira Cloud, like GitProtect backup and restore for Jira Cloud, which can help organizations to meet the most demanding needs.

So, what backup requirements can organizations with strict regulations search for?

• the ability to schedule and automate backups for Jira Cloud site data,
• wide data coverage for backups, including Assets, Jira Automation Rules, spaces, work items, and their metadata,
• the possibility to set and run granular backups of only selected work items or spaces, as some data, due to its criticality, may need more frequent backups to achieve shorter RPO and RTO,
• long-term or unlimited retention to be able to restore data from 3 months or 3 years, or any point in time,
• ability to store data in a few storage destinations so that in case one storage destination is unavailable, the organization can restore data from another location,
• multiple data restore destinations, e.g., to the local device or both the same or a new Jira account.
• possibility to migrate a Jira site, e.g., from sandbox to production, or from one Jira Cloud site to another Jira Cloud organization, or to the same Jira.

Key takeaways for Jira Admins

Protecting Jira data, especially during Cloud migrations or from sandbox to production,  requires a proactive approach. A few practical principles can significantly reduce risk:

1. Understand the shared responsibility model - Atlassian protects the infrastructure, but customers remain responsible for their own data recovery strategy.
2. Implement a dedicated backup solution - backup tools can provide the ability to restore data after human error, misconfiguration, or migration issues, or any other event of failure.
3. Avoid external data layers - limit the number of tools that add another data layer and store data outside Jira.
4. Review apps you currently use - if you already use Jira apps, take a moment to evaluate if your Jira backup will cover all app data.
5. Consider moving to more reliable tools - choose apps that hold a Runs on Atlassian badge to ensure smooth backup in the future without adding complexity.
6. Plan backups as part of the Jira Cloud-to-Cloud or sandbox-to-production migration strategy - before migrating to Jira Cloud, ensure that both Jira data and app-generated data are properly protected.

Try GitProtect on Atlassian Marketplace - GitProtect for Jira Cloud (backup & restore)
Try SolDevelo on Atlassian Marketplace - Worklogs - Time Tracking, Time Reports, Timesheets

The article was written in Marketing Collaboration between GitProtect and SolDevelo.