"Atlassian has backups covered" is something most Jira and Confluence admins have heard, and it's worth understanding exactly what that means. Atlassian does run backups, and they do a solid job keeping its own infrastructure resilient, but these backups weren't designed to undo what happens after a ransomware attack or a compromised admin account. That distinction is easy to overlook until you actually need to recover from one of these incidents, which is exactly when it's worth already knowing what's covered and what isn't.
Once an attacker has legitimate account access and uses it to delete, corrupt, or alter your data, the question that matters isn't just whether backups exist; it's whether the affected data can be returned to a known-good state without rolling back everything else along with it. That's the recovery problem this article is about.
What is ransomware, in plain terms?
Ransomware is malicious software that locks or encrypts your data, then demands payment to release it. In a SaaS context like Jira or Confluence, an attacker doesn't need to touch your servers; they need a valid login. Once inside, they can bulk-edit fields, delete projects or spaces, exfiltrate data, or lock admins out entirely.
The financial impact is well documented. McKinsey estimates the global cost of ransomware could reach $265 billion annually by 2031, driven by a sharp rise in attack frequency and ransom demands over the past several years (McKinsey). Separately, industry cost analyses put the average total cost of a single ransomware incident,including downtime, recovery, and reputational damage,between $1.8 million and $5 million.
What is an Account Takeover (ATO)?
An account takeover happens when someone gains unauthorized control of a legitimate user or admin account, usually through stolen, phished, or leaked credentials, rather than by "hacking" a system directly. Once an attacker has valid credentials for a Jira or Confluence admin, the platform doesn't see an intruder. It sees an authenticated user with normal permissions, which is what makes ATO so hard to catch in real time for any platform, not just Atlassian's.
Verizon's 2025 Data Breach Investigations Report (DBIR) found that stolen credentials were the most common initial access vector, used in 22% of breaches, and that credential abuse was involved in 30% of breaches caused by human error or manipulation. The 2026 edition goes further: it found that 50% of ransomware victims had experienced a credential leak or infostealer event within 95 days before the ransomware attack. In other words, account takeover is frequently the door ransomware walks through, not a separate problem.
(For a closer look at exactly how attackers obtain that initial access in 2026 environments, with techniques across phishing, infostealer malware, credential-stuffing, and session compromise, see They're Not Breaking In, They're Logging In.)
Why the two threats are connected
Attackers rarely "hack" Jira or Confluence in the traditional sense. They obtain valid credentials and log in like a normal user or admin. Once inside, that legitimate access is what causes the damage that matters for recovery: deleting projects, corrupting configurations, exfiltrating sensitive tickets and pages, or locking out real admins by changing permissions and MFA settings.
From Atlassian's perspective, none of this looks like an attack. It looks like an admin doing admin things, which is a genuinely hard thing for any platform to detect in the moment. That's precisely why this scenario falls outside what native backup was ever designed to solve, and why recovering from it is a distinct problem from simply having backups at all.
What Atlassian's native recovery covers
It's worth understanding exactly what Atlassian's native recovery is designed to do in the scenario above. Once an attacker with valid credentials has altered or deleted data, here's what's available to help bring it back, straight from Atlassian's own documentation.
This part matters, and it's stated by Atlassian itself, not implied by a vendor. Atlassian's own trust and security documentation says:
"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." (Atlassian Trust Center)
A few concrete details, based on Atlassian's own support documentation:
- Native backups protect Atlassian's infrastructure, not your specific data changes. They're built for disaster recovery scenarios like a data center outage, not for reversing something a logged-in user (or attacker with that user's credentials) did.
- Retention is capped at 30 days. Backups expire on day 31 and can't be restored after that (Atlassian Support).
- Recovery is all-or-nothing, not granular. You typically can't pull back a single deleted project, space, or set of issues without restoring a much larger chunk of the instance.
- The paid Backup and Restore add-on is Premium/Enterprise-only and has data size caps (for example, Jira sites up to 300 GB and Confluence sites up to 32 GB at general availability), and excludes some configuration data and third-party Marketplace app data.
- Audit log retention is limited to 180 days in most plans, which matters if you need to investigate how an account takeover happened after the fact.
None of this is a criticism of Atlassian, whose native backup is a strong foundation for infrastructure resilience. It just wasn't built to give individual customers a way to surgically undo an incident,that's a reasonable, deliberate design choice, and it means native backup is solving a different problem than incident recovery.
For a deeper, more general look at how native backup and purpose-built recovery tools complement each other, beyond just the ransomware/ATO scenario, see Why Jira Cloud Backups Fail When You Need Them Most and The Resilience Gap: Why Atlassian's Native Backup Fails the Enterprise Risk Test.
What happens after a Jira or Confluence account takeover?
Picture this sequence, which mirrors what security researchers actually see:
- An admin's credentials are phished or picked up from an infostealer log.
- The attacker logs in to Atlassian. This looks like a normal session, which is a reasonable thing for any authentication system to conclude from a valid login.
- Over hours or days, they quietly delete or corrupt Jira projects, Confluence spaces, or configuration data, sometimes after first probing to see what backups exist.
- By the time the team notices, the changes are inside the 30-day backup window, but Atlassian's own policy says customer-initiated changes, even malicious ones, aren't reverted by its backups.
- Recovery, if it happens at all, means manually rebuilding lost work from memory, exports, or whatever fragments team members have saved locally.
Gartner's ransomware resilience research for 2026 found a related pattern at the infrastructure level: 78% of organizations have implemented or are implementing isolated recovery environments, but 53% of those still lack immutable backups or "golden images": the very things needed for a clean recovery. The core lesson, whether it's on-prem infrastructure or a SaaS tool like Jira, is the same: a backup that isn't isolated from the attacker's reach, and isn't restorable to a precise point in time, isn't a safety net during an active incident.
What genuine recovery capability looks like
Based on how Atlassian, Gartner, and Verizon describe the problem, a recovery approach built for ransomware and ATO scenarios (rather than infrastructure disasters) generally needs:
- Storage that's isolated from your Atlassian instance and its admin credentials, so an attacker who compromises your Jira admin account can't also touch your backup copies.
- Point-in-time restore, so you can go back to the state just before the incident instead of losing everything since the last full backup.
- Granular restore, so you can bring back one project, space, or set of issues without disrupting everything else.
- Retention longer than 30–180 days, to support investigations, audits, or legal holds that outlast Atlassian's native windows.
The point-in-time and granular-restore requirements above are covered in more depth in Jira Data Disaster? Why "Full Restore" Won't Cut It (and What Will); the isolation requirement is covered in more depth in Why Immutable Backups Matter for Atlassian Cloud Data.
Where Revyz fits into this picture
Here's how that plays out against the ransomware and account-takeover scenario walked through above:
- Backups sit outside your Atlassian instance. Revyz stores data in its own cloud environment with object-lock immutability, so if an attacker takes over an admin account, they can't reach or alter the backup copies.
- Point-in-time restore. Instead of an all-or-nothing snapshot, admins can restore data to the exact point before an incident occurred.
- Granular restore. Recovery can be scoped to a single item, project, or space, and restored to its original location or a new one: no need to roll back an entire instance to fix one project.
- Audit log retention beyond Atlassian's native limits, which matters when you're trying to piece together how an account was compromised in the first place.
- Coverage beyond core Jira and Confluence data, extending to third-party Marketplace apps like Xray and Tempo, which native backup doesn't cover.
None of this replaces good security hygiene: MFA, credential monitoring, least-privilege access. It's what stands between your team and a blank slate if those defenses are ever bypassed. Revyz is built to work alongside Atlassian's own protections, not instead of them.
A practical checklist before you evaluate any backup vendor for this
Regardless of which vendor you consider, if ransomware or an account takeover is the scenario you're most worried about, it's worth getting straight answers to:
1. Is backup storage logically or physically isolated from our Atlassian admin credentials?
2. Can we restore a single project or space without restoring the entire instance?
3. How far back can we restore, and is that retention window longer than Atlassian's native limits?
4. Does the backup cover configuration data and the third-party apps we actually use?
5. Do we retain audit logs long enough to investigate an incident properly?
FAQs
Can Jira be recovered after a ransomware attack?
Yes, if you have backup storage that's isolated from your Atlassian instance and admin credentials. Atlassian's native backups are built to protect its own infrastructure, not to reverse customer-initiated destructive changes, which is exactly what a ransomware attack executed through a compromised, authenticated account looks like from Atlassian's side. Recovery in that scenario depends on point-in-time, granular restore capability that sits outside the reach of the compromised account.
Can I recover Jira or Confluence after an admin account takeover?
Native recovery is designed around a different scenario, so the platform generally can't distinguish a legitimate admin action from the same action performed by an attacker using valid, stolen credentials. Recovery in this case depends on whether you have a separate, isolated backup that the compromised account can't reach.
Does Atlassian back up my Jira and Confluence data?
Yes, but for infrastructure resilience, things like data center failures, rather than for reversing changes a logged-in user (including an attacker using stolen credentials) made. Atlassian's own documentation states these backups aren't used to revert customer-initiated destructive changes.
How long does Atlassian keep backup data?
Native Atlassian Backup and Restore (available on Premium and Enterprise plans) retains backups for 30 days, after which they expire and can no longer be restored. Native audit logs are retained for up to 180 days depending on plan.
What's the difference between Atlassian's native backup and third-party tools like Revyz?
Atlassian's native backup is built for full-instance, infrastructure-level recovery, with a 30-day retention window and no reversal of user-initiated changes (by design, since that's a different job than incident recovery). Third-party tools like Revyz are built specifically for granular, point-in-time recovery from incidents like accidental deletion, account takeover, or ransomware, with backup storage kept isolated from the Atlassian instance itself.
Is ransomware really connected to account takeovers?
Yes. Verizon's 2026 DBIR found that 50% of ransomware victims had experienced a credential leak or infostealer event within 95 days before the ransomware attack, indicating that stolen credentials are frequently the entry point that leads to a ransomware incident.
Do I need a third-party backup tool if I already pay for Atlassian's Backup and Restore add-on?
That depends on your risk tolerance and compliance needs. If your retention, granular-restore, or third-party-app coverage requirements exceed what Atlassian's native add-on provides, a purpose-built third-party tool addresses that specific gap. It's worth mapping your requirements against the checklist above before deciding.
