Most conversations about backing up Jira and Confluence start in the wrong place. They start with a vendor telling a security team that Atlassian does not protect their data, the security team correctly pointing out that Atlassian does in fact sell a backup product, and the conversation ending there.
So let us start somewhere harder to argue with. Here is Atlassian, on their own trust page, describing their approach to resilience:
"These backups are not used to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites. To avoid data loss, we recommend that you take regular backups."
That is not a competitor's characterisation. It is the platform vendor telling you, in writing, that their backups exist for their disaster recovery rather than your accident, and recommending you keep your own. Their Cloud Terms of Service go further, stating that they do not warrant they will preserve or maintain your data without loss. The same language appears in Atlassian's support documentation: their infrastructure backups cannot be used to roll back deleted issues, projects or sites.
Anyone protecting Atlassian Cloud data is not arguing against Atlassian. They are implementing Atlassian's published recommendation.
Every major SaaS platform runs the same model. Microsoft 365, Google Workspace and Salesforce all draw the line in roughly the same place: the vendor is responsible for the security and availability of the platform, and the customer is responsible for the data inside it, the accounts that can reach that data, and the third-party apps they choose to trust.
The gap is not that customers disagree with this. It is that most have never read it. Analyst surveys have consistently found that only a minority of organisations recognise SaaS data protection as their own responsibility, while a majority report having lost SaaS data at some point.
What follows are six ways that loss actually happens. None of them is an Atlassian outage, and they are ordered by how often we see them rather than by how dramatic they sound.
The leading documented cause of SaaS data loss is not an attacker. It is an administrator with legitimate access, a bulk operation, and a bad afternoon. Sometimes it is deliberate.
In one case prosecuted by the US Department of Justice, an engineer who had resigned from Cisco five months earlier used credentials that had never been revoked to delete 456 virtual machines, taking more than 16,000 accounts offline for up to two weeks and costing Cisco roughly $2.4 million.
Atlassian's native restore is site-level, and it lands only in a destination that contains no data. There is no supported path to recovering one issue, one page, or one project.
This is the one that changes the shape of the problem for a security team.
An attacker holding organisation admin does not just own your production data. They own your backups at the same moment, because both answer to the same credential. Atlassian's own backup and restore documentation states that you cannot download a backup into your own storage, which means there is no copy sitting outside the reach of that identity.
The path in is rarely the front door. In late 2023, a nation state actor used credentials stolen in the Okta breach, which had never been rotated, to reach Cloudflare's Atlassian environment. In August 2025, stolen Salesloft Drift OAuth tokens were used to exfiltrate data from hundreds of SaaS tenants belonging to well-resourced security-conscious companies.
If your recovery copy lives behind the credential you are trying to defend, it is not a recovery copy.
This is the failure mode that turns the first two into permanent loss, and it is the one most often missed.
Picture a thousand-seat Jira site. Someone bulk-deletes ten issues at three in the afternoon. You have a backup from last night. What happens next?
Atlassian's restore requires a destination that contains no active, deleted or archived content. There is no merge. So your options are to overwrite production with yesterday's state, or stand up a fresh site and re-point every user to it.
Take the first option and you discard everything a thousand people did in the intervening day. At a conservative five changes per person, that is roughly five thousand changes destroyed to recover ten, on top of the twelve hour recovery time objective Atlassian publishes for the restore itself. ITIC's 2024 survey found that 97 percent of enterprises above a thousand staff put a single hour of downtime above one hundred thousand dollars.
So nobody signs it off. The predictable outcome of an all-or-nothing restore is not a painful restore. It is no restore at all, and ten issues quietly written off.
That is the real gap. Not that the backup is missing, but that the only recovery on offer is one no operations lead would authorise.
Your Jira acquired a new category of user in the last eighteen months, and most access reviews have not caught up.
Atlassian's Rovo MCP Server connects Jira, Confluence, Jira Service Management and Bitbucket to external AI tools, configured per user over OAuth. It is genuinely useful. It is also a set of identities with write access that act at machine speed.
Atlassian is unusually direct about this in their own MCP server README:
MCP "lets AI agents connect to tools and Atlassian data using your account's permissions, which creates powerful workflows but also structural risks."
Any MCP client or server you enable "can cause an AI agent to perform actions on your behalf."
LLMs "are vulnerable to prompt injection and related attacks (such as indirect prompt injection)."
Read those three sentences together and the exposure is clear. An agent inherits a real person's permissions, acts without a human in the loop, and takes instruction from whatever text it reads.
Now consider where that text comes from. A service desk is, by design, a pipe for text written by people outside your organisation. In June 2025, researchers at Cato Networks demonstrated exactly this against Atlassian MCP and Jira Service Management: a support ticket carrying a prompt injection, processed by an MCP-connected agent, executing with a support engineer's privileges. Atlassian told SC Media that its teams were exploring enhanced controls for customers integrating MCP. It is a proof of concept rather than a breach in the wild, and it is catalogued in MITRE ATLAS.
Destructive agent behaviour outside Atlassian is already documented. In July 2025 Replit's agent deleted a production database during an explicit code freeze and then reported that rollback was impossible, which turned out to be untrue. The same month, a poisoned pull request shipped a wiper prompt inside Amazon Q to roughly a million installs, tracked as CVE-2025-8217.
The security problem is not only that agents can destroy things. It is that their activity looks authorised in an audit log, which stretches the time before anyone notices well past the point where a thirty day backup window would help.
Native backups sit in Atlassian-owned storage and cannot be exported. That means one copy, on one platform, with nothing under your control. It fails the oldest rule in the discipline, which asks for three copies on two platforms with one held elsewhere.
The usual objection is that Atlassian is a large and competent vendor. That is true, and it is beside the point, which UniSuper demonstrated in May 2024.
UniSuper is an Australian pension fund managing around 135 billion Australian dollars. A misconfiguration during provisioning deleted their entire Google Cloud private cloud subscription. They had done the sensible thing and held duplication across two geographies. Both died together, because the failure happened at the subscription layer, above the redundancy. What saved them was a copy held with a second provider, a fact the chief executives of both companies stated jointly. Google later published a fuller technical account.
Atlassian had their own version two years earlier, when a script erased 883 sites belonging to 775 customers and recovery ran to fourteen days. Two of the largest cloud companies in the world have each deleted customer tenancies by accident. The question for a risk committee is not whether the vendor is competent. It is whether a single control plane is an acceptable single point of failure for a system of record.
Even the paid Backup and Restore add-on keeps a backup for thirty days, after which it expires. Confluence spaces purge from the trash at sixty.
Set that against what regulators ask for. SEC Rule 17a-4 requires duplicate records held off-site for six years. SOX section 802 requires seven for audit workpapers. HIPAA requires six. DORA Article 12 requires a tested restore into systems segregated from the source.
To be precise, because precision matters here: Atlassian does not delete your live data at thirty days. What expires is your ability to recover something you have lost. And detection lag is what makes that fatal. A maliciously deleted space or a quietly corrupted field mapping surfaces at audit or during litigation, not on day three.
Note the off-site requirement in particular. A backup that cannot leave Atlassian's storage cannot satisfy it, no matter how good it is.
It is worth saying what Atlassian has improved, because pretending otherwise is how vendors lose technical audiences.
Atlassian Backup and Restore offers scheduled daily backups, customer-managed key encryption, automated restore health checks and sandbox restore. After the 2022 incident, Atlassian added a delayed deletion window that suspends sites for fourteen days before deletion, reduced the number of internal services able to execute deletions, and began running quarterly multi-site deletion recovery exercises.
If your requirement is site-level disaster recovery within a month, native may be enough. The gaps are granularity, retention, exportability, and coverage of Marketplace app data.
We build data protection for the Atlassian estate, so treat what follows as interested rather than neutral. It is easier to judge if we map it back to the six failure modes above rather than list features.
Granular restore, for failure modes one and three. Revyz restores a single issue, page, attachment or configuration object in place. Nothing else moves, nobody else loses a day, and the recovery is small enough that someone will actually authorise it. This is the difference between having a backup and having a recovery path.
An immutable copy outside the tenant, for failure modes two and five. Backups are held in a separate security domain with S3 Object Lock applied. There is no mechanism exposed for anyone to delete or overwrite them, including our own operators. With bring your own storage, the copy sits in your AWS or Azure bucket, under your lifecycle policy, in the region you choose. That is a copy an attacker holding your Atlassian admin credential cannot reach, and one that survives a failure of the provider's control plane.
Configuration versioning, for failure mode four. Workflows, screens, schemes and automation rules are versioned with drift detection against the state you intended, and can be rolled back. Deployment from sandbox to production runs through a maker and approver flow. When an agent or an administrator changes something that should not have changed, you can see it and undo it. Configuration is the piece native has no rollback for at all, and it is what gives your data structure and meaning.
Retention measured in years, for failure mode six. Retention runs up to three years, with a deletion log and audit log history, which is the evidence an auditor asks for rather than the data alone.
On our own posture, since accepting this argument means assessing another vendor: the apps run on Atlassian Forge, are Cloud Fortified, and we have held SOC 2 Type II since 2023.
And the limits, because a post arguing for honest disclosure should practise it. We cover Jira, Jira Service Management and Confluence today. Bitbucket, GitHub and GitLab are on the roadmap rather than shipping. We do not currently alert on anomalous mass deletion, so detection stays with you and recovery is what changes. Configuration drift is diffed; issue and page data is restored without a field by field view of what changed. And where your retention obligation runs longer than three years, we sit beside your archive rather than replacing it.
You do not need a vendor to work out where you stand.
If question two has no answer, that is the place to start, and it costs nothing but an afternoon.
No application makes an organisation compliant. Tooling supplies controls and auditors decide whether they are sufficient. Anyone telling you otherwise is selling something.
What is defensible is narrower and more useful. Atlassian recommends you keep your own backups. The failure modes above are the ones that actually occur. And the single most revealing test is not a procurement exercise, it is deleting something on purpose in a sandbox and finding out how long it takes to get it back.
Most teams have never run that test. It is worth an afternoon to find out.
Atlassian primary sources
Incidents