Cyberattack Recovery: How to Actually Restore Operations After a Breach

TL;DR

• 90% of organizations are confident they can recover from a cyber incident. Still, only 28% of ransomware victims fully recovered all their data, and 44% recovered less than 75% of it, according to Veeam's Data Trust and Resilience Report 2026.
• 96% of ransomware attacks target backup repositories specifically, and 76% of those attempts succeed, which means "we have backups" and "we can recover" are not the same claim.
• Organizations with compromised backups face recovery costs 8x higher than those with intact ones, a median of $3 million versus $375,000, per Sophos's 2026 State of Ransomware report.
• The cost trend reversed in 2026: average recovery cost rose to $1.7 million, up 11% year over year, even as ransom demands fell by 65% over two years. Backup-based recovery is up, but recovery itself is still getting more expensive.
• Firefly's CAIRS rebuilds into a clean, isolated environment from immutable snapshots specifically designed to sit outside what a compromised credential can reach.

Getting Started: The Basics of Cyberattack Recovery

Cyberattack recovery is often talked about as if it's the same as incident response, but it isn't. Incident response is about containment and eradication: finding the attacker, kicking them out, closing the hole they came through. Recovery starts after that: restoring systems, data, and operations to a state the organization can actually trust again, not just a state that technically boots.

That distinction is worth being precise about because it's where many recovery plans quietly fail. A team can execute containment perfectly, confirm the attacker's access is fully revoked, and still lack a recovery plan because recovery isn't "turn the servers back on." It's proving that what gets turned back on isn't carrying the same vulnerability, the same misconfiguration, or in the worst case, the same attacker's persistence mechanism that caused the incident in the first place. This piece is about that specific process: not the strategy for avoiding an attack, and not the standards that govern how a resilience program should be structured, both covered elsewhere, but the technical mechanics of what recovery actually requires once prevention has already failed.

Why Recovery Is Different When Backups Are the Target

The gap between assumed and actual recoverability is the single most important thing recovery planning gets wrong, and it's now measured directly rather than inferred. Veeam's Data Trust and Resilience Report 2026, published in April 2026, found that 90% of organizations are confident they can recover from a cyber incident. Among organizations that actually experienced ransomware, only 28% fully recovered all their affected data, and 44% recovered less than 75% of it. Confidence and outcome are two very different numbers.

A meaningful part of that gap traces back to where backups actually sit. Veeam's separate ransomware research found that 96% of ransomware attacks now target backup repositories directly, not as an afterthought but as a deliberate step in the attack, and 76% of those targeting attempts succeed in actually compromising the backups. "We have backups" used to be the reassuring sentence in an incident review. Now it's an incomplete sentence; the real question is whether those backups were accessible via the same compromised credentials, the same network segment, or the same administrative account that was compromised in the first place. If they were, they were never really a fallback; they were just another asset waiting to be encrypted along with everything else.

The Veeam data also points to what actually closes the gap: organizations that increased their security budgets saw full recovery rates more than double, 40% versus 16% for those that didn't. That's not a coincidence; it tracks with backup isolation and tested recovery being investments, not defaults.

The Real Cost of Getting Recovery Wrong

The financial gap between organizations that get this right and organizations that don't is large enough to be the single clearest argument for treating backup isolation as a real requirement rather than a checkbox:

• Organizations with compromised backups face a median recovery cost of $3 million, compared to $375,000 for organizations whose backups stayed intact, an 8x difference Sophos's research ties entirely to whether the backup itself survived the attack
• Average recovery cost climbed to $1.7 million in 2026, up 11% year over year, even as median ransom demands fell 65% over the same two-year period
• 48% of encrypted victims paid the ransom in 2026, in line with the roughly 50% four-year average; payment rates haven't meaningfully declined
• Backup-based recovery reached 66% of encrypted-data cases in 2026, up 12 percentage points from 2025

The 8x gap in the first point isn't really about backup frequency; it's about whether the attacker's access could reach the backup at all:

That combination is worth sitting with: ransom demands are falling because organizations have gotten better at negotiating and refusing to pay outrageous amounts. More victims are recovering from backups rather than paying at all. But recovery cost is still rising, which means the expense has shifted from the ransom itself to the operational cost of the recovery process, downtime, rebuild labor, and lost business, exactly the costs a tested, automated recovery plan is built to reduce.

The Steps of the Technical Recovery Process

Recovery isn't a single action; it's a sequence, and skipping or rushing any step is usually where a recovery goes wrong, even after containment succeeded cleanly:

• Containment, confirmed rather than assumed: every credential the attacker touched is rotated, and every persistence mechanism identified during the investigation is removed, not just the one that triggered the initial alert.
• Forensic assessment, the step most often compressed under pressure: deciding what can actually be trusted. A backup created before the attacker's dwell time began is trustworthy. A backup created during the dwell time is not automatically trustworthy just because it predates the encryption event.
• Clean-room rebuild: infrastructure is deliberately restored, not into the same environment the attack compromised, for reasons the next section covers mechanically.
• Validation: confirming the rebuilt environment is both functionally correct and free of anything carried over from the compromise, by checking against a known-good configuration rather than just confirming services are running.
• Controlled cutback: traffic and operations gradually move back onto the recovered environment, with monitoring in place, rather than a single full cutover that leaves no room to notice a problem before it affects every user at once.

Laid out as a pipeline, the sequence and where a shortcut tends to happen look like this:

Given that the median dwell time before encryption is 4-5 days, the honest answer to "which backups are clean" during the forensic assessment step often excludes more recent backups than a team expects going in.

Why You Can't Just Restore Into the Same Environment

The instinct during an incident is to restore as quickly as possible, and the fastest technical path is often to restore straight back into the compromised account or region. That instinct is exactly backward, and the reason is mechanical, not just cautious.

A sufficiently capable attacker doesn't just encrypt files; they often establish persistence: a backdoor account, a modified IAM policy granting quiet access, a scheduled task that re-establishes access if the obvious foothold gets closed. If recovery restores data to the same account using the same IAM roles and the same network configuration that the attacker already had access to, there's no guarantee the persistence mechanism is removed in the process; restoring data doesn't restore trust in the infrastructure surrounding that data. An attacker with a surviving backdoor can simply wait for the restored environment to come back online and pick up where they left off.

This is the specific argument for clean-region or clean-account recovery: rebuilding in an environment the compromised credentials never had access to in the first place, so persistence mechanisms tied to those credentials have nothing to persist into. It's a categorically different guarantee than "we scanned for backdoors before restoring," since a scan can miss something a structural isolation boundary doesn't need to catch; it simply was never reachable.

How Firefly Operationalizes Cyberattack Recovery in Practice

Firefly's approach to recovery is built directly around the two gaps the sections above describe: knowing in advance whether recovery would actually work, and rebuilding somewhere the original compromise structurally can't follow.

Cloud Resilience Posture Management (CRPM) addresses the first gap before an incident ever happens. It scores an environment continuously against built-in resiliency policies under the Governance dashboard, missing snapshot policies, S3 buckets without Object Lock, RDS clusters skipping final snapshots on deletion, the exact configuration gaps that turn "we have backups" into a false assumption. That score updates continuously, so a team finds out a backup policy silently stopped applying to a resource before an incident forces the discovery, closing exactly the confidence-versus-outcome gap the Veeam data quantifies.

When recovery is actually needed, Firefly's Backup & DR feature is what actually executes it, rebuilding into a clean, isolated region or account using immutable, versioned IaC snapshots, the operational layer behind what CAIRS (Cloud Application Infrastructure Recovery) refers to as a category. This directly addresses the persistence-mechanism problem described above. The immutability isn't just a label; it has a specific mechanical effect: a snapshot stored this way can't be modified or deleted by the same credentials that manage production, so an attacker who has fully compromised a production account, including its IAM roles and admin access, still has no path to reach or corrupt the recovery snapshot sitting outside that blast radius. Every restore generates Terraform and routes it through a pull request rather than making direct cloud API calls, so the rebuilt environment is reviewable and auditable. The validation step in the recovery process above has an actual artifact to check against, not just a claim that recovery happened correctly.

A Resiliency check that would catch a backup configuration exposed to exactly the isolation failure this piece has been describing, a snapshot repository still reachable by the same account it protects, looks like this in Firefly's policy schema:

package Cx

import data.generic.terraform as tf_lib

CxPolicy[result] {
	resource := input.document[i].resource.aws_backup_vault[name]
	resource.iam_role_arn == input.production_account_role_arn

	result := {
		"documentId": input.document[i].id,
		"resourceType": "aws_backup_vault",
		"resourceName": tf_lib.get_resource_name(resource, name),
		"searchKey": sprintf("aws_backup_vault[%s].iam_role_arn", [name]),
		"issueType": "IncorrectValue",
		"keyExpectedValue": sprintf("aws_backup_vault[%s].iam_role_arn should differ from the production account role", [name]),
		"keyActualValue": sprintf("aws_backup_vault[%s].iam_role_arn matches the production account role, defeating isolation if that account is compromised", [name]),
		"remediation": json.marshal({
			"before": "shared IAM role with production",
			"after": "dedicated IAM role scoped to backup vault only",
		}),
		"remediationType": "replacement",
	}
}

For teams investigating what happened during an incident, AI SRE answers questions like "which of our production applications would fail to recover cleanly right now" by cross-referencing Inventory, Governance, and Backup & DR data directly, turning "are we recoverable" from an assumption into a number checked continuously rather than discovered during the incident itself.

Recovery Time in Practice: What RTO Actually Depends On

An RTO written into a disaster recovery plan is a target, not a guarantee, and the gap between the two depends heavily on decisions made well before an incident starts. Median dwell time before encryption is 4-5 days, which means the window between initial compromise and the visible attack has narrowed compared to prior years, leaving defenders less lead time to catch issues before they escalate.

The recovery-speed picture has held remarkably steady even as costs rose: median weeks to recover stayed at three in both the 2025 and 2026 Sophos reports, down from five in earlier years. Sophos's 2025 State of Ransomware report broke that down further: 53% of ransomware victims fully recovered within one week that year, up sharply from 35% in 2024. Recovery speed, in other words, has genuinely improved and stabilized at a better baseline, even as the earlier sections' cost and confidence numbers moved in the opposite direction.

What separates fast recoveries from slow ones isn't luck; it's whether recovery was tested before it was needed and whether backups were actually isolated. Organizations combining immutable backups with automated recovery workflows report recovery times that are meaningfully faster than the industry averages above, which tracks with everything the earlier sections describe: automation removes the manual, error-prone steps a rushed human process introduces. Immutability removes the possibility that the recovery path itself was part of what was compromised.

Testing Recovery Before You Need It

A documented recovery runbook that's never been executed is a hypothesis, not a plan, and the gap between the two only becomes visible during an actual incident, which is the worst possible time to discover it. Testing recovery specifically, not just testing detection or testing the incident response communication plan, means actually executing a restore into an isolated environment and confirming it produces a working, trustworthy system within the RTO the plan claims.

This is a narrower exercise than general chaos engineering, which tests whether an architecture survives a failure. Recovery testing tests something more specific: whether the recovery mechanism itself works as designed, whether the immutable snapshot actually restores cleanly, whether the clean-region rebuild produces an environment that passes validation, and whether the team executing the restore can actually do it within the claimed time window under realistic conditions, not a best-case walkthrough with no time pressure. A recovery plan that's never been tested this way is exactly as reliable as a backup that's never been restored, which is to say, unverified. It's exactly the gap between the 90% confidence figure and the 28% full-recovery figure this piece opened with:

Conclusion: Where Should You Start With

Recovery isn't the part of a resilience plan most teams get around to testing; prevention and detection tend to absorb the budget and attention, and recovery stays a documented assumption until the day it's the only thing that counts. The data in this piece points at the same conclusion from every angle: backups that were never isolated from the systems they're meant to protect aren't a real fallback, restoring into the same compromised environment can hand persistence right back to an attacker, and the 62-point gap between organizations that feel confident and organizations that actually recover fully exists because a recovery plan that's never been executed is a hypothesis wearing a runbook's clothing. None of that gets fixed by a better incident response process. It gets fixed by continuously verifying that recovery would actually work if it had to.

That's a concrete thing to check this week, not a project to schedule for next quarter. Explore Firefly's Governance dashboard to see how much of a live environment would actually survive a clean recovery test right now, or read Building a Cyber Resilience Strategy for the broader framework this piece's recovery process fits into. For teams specifically wrestling with the backup isolation problem covered above, Enterprise Drift Management covers the related question of how unmanaged, undocumented resources end up outside every recovery plan in the first place.

FAQs

What is cyberattack recovery?

Cyberattack recovery is the process of restoring systems, data, and operations to a trusted state after an attack, distinct from incident response, which focuses on containing and removing the attacker. Recovery starts once containment is confirmed and covers rebuilding infrastructure, validating it's free of anything carried over from the compromise, and returning to normal operations.

Why does confidence in recovery not match actual outcomes?

Because most organizations base their confidence on a documented plan or backups rather than on a tested restore, Veeam's 2026 research found that 90% of organizations were confident they could recover from a cyber incident. Still, only 28% of actual ransomware victims fully recovered all their data, a gap that closes only through tested, verified recovery capability rather than documentation alone.

Why do ransomware attacks specifically target backups?

Backups are the fallback that allows an organization to recover without paying. Veeam's research found 96% of ransomware attacks target backup repositories directly, and 76% of those attempts succeed, which is why an organization's actual recoverability depends on whether backups were isolated from the systems that got compromised, not just whether backups existed.

Is recovery cost actually improving or getting worse?

Both, in different ways. Ransom demands have fallen sharply, down 65% over two years, and more victims are recovering from backups rather than paying. But the average recovery cost still rose to $1.7 million in 2026, up 11% year over year, as the expense has shifted from the ransom itself to the operational costs of the recovery process.

Why can't you just restore data into the same account after an attack?

Because a capable attacker often establishes persistence, a backdoor account, a modified IAM policy, or a scheduled task that survives a straightforward restore if the underlying infrastructure isn't rebuilt somewhere the compromised credentials never had access to. Restoring data without addressing infrastructure trust can let an attacker with surviving access simply resume once the restored environment comes back online.

How does Firefly specifically support cyberattack recovery?

Firefly's CRPM continuously scores whether an environment would actually survive a clean recovery, closing the confidence-versus-outcome gap directly, and CAIRS rebuilds compromised infrastructure into a clean, isolated environment using immutable IaC snapshots that compromised production credentials structurally cannot reach or corrupt, with every restore generated as reviewable Terraform rather than an unauditable direct mutation.

‍