The average ransomware recovery takes 22 days. That figure comes from Sophos's annual State of Ransomware report, and it is consistent across multiple years and geographies. Three weeks of degraded operations, emergency contractor costs, lost revenue, and reputational damage — before the organisation is fully back to normal.

Most IT teams, when asked, estimate they could recover in a few days. The gap between estimate and reality is where ransomware operators make their money.

Why Recovery Takes So Long

Understanding the timeline requires understanding what recovery actually involves. It is rarely a single restore operation. It is a multi-phase process where each phase has dependencies on the one before it, and many phases cannot proceed in parallel.

Phase 1: Containment (Hours 0–48)

Before any recovery can begin, the attack must be stopped. This means:

Identifying the scope of compromise. Which systems are encrypted? Which endpoints are infected? Is the attacker still present in the environment, or was this a detonation-and-leave attack? Answering these questions requires forensic analysis that most internal IT teams cannot conduct at speed.
Isolating affected systems. Encrypted systems must be taken offline to prevent further spread. In organisations with flat network architectures or poorly segmented environments, this can mean taking large portions of the network offline.
Identifying the ransomware variant. Different variants require different responses. Some have known decryptors available through tools like NoMoreRansom.org. Most modern variants do not.

This phase routinely takes 24–72 hours even with experienced incident responders engaged. Organisations without a pre-arranged incident response retainer typically add 24–48 hours before any qualified help is on site.

Phase 2: Assessment (Days 2–5)

Once the active threat is contained, the organisation needs to understand what it's working with:

Backup integrity verification. Are the backups clean? Many ransomware strains dwell in environments for weeks before detonating — long enough to have encrypted or corrupted recent backup sets. Verifying that the most recent clean backup is actually clean, and identifying the furthest-back clean restore point, takes time.
Scope of data loss. What was encrypted? What data is confirmed unrecoverable without the decryption key? What is the business impact of the data loss?
Decision: restore vs. pay vs. partial recovery. The organisation must decide whether to restore from backup, whether paying the ransom is viable (most cybersecurity authorities and insurers strongly advise against it), or whether a hybrid approach combining partial decryption with backup restoration is possible.

This phase often takes three to five days. The backup integrity verification step is routinely underestimated.

Phase 3: Environment Rebuild (Days 5–15)

This is where most of the calendar time is consumed. The sequence:

Rebuild or reimage compromised endpoints and servers — not just restore data, but rebuild operating systems to ensure no malware persists
Restore data from verified clean backups
Restore applications and verify they function correctly against the restored data
Restore dependencies and integrations between systems (this step is consistently underestimated)
Test that business processes work end-to-end

The rebuild step is the killer. A 500-person organisation might have 500 endpoints that need reimaging. Even at 30 minutes per endpoint with automated tooling, that is 250 hours of work. Without automation — which most organisations don't have ready — it is far longer.

Data restoration speed depends on backup architecture. Restoring from cloud backup over a typical enterprise internet connection — not a dedicated recovery link — can mean transferring terabytes at speeds that make the recovery window measured in days rather than hours.

Phase 4: Validation and Return to Operations (Days 15–22)

Restored systems must be validated before business operations resume:

Application functionality testing
Data integrity checks
User acceptance testing for critical business processes
Security hardening and patching to close the initial attack vector
Monitoring deployment to detect any persistence that survived the rebuild

Many organisations underinvest in this phase and return to operations before it is complete, only to discover corrupted data or missed attack vectors days later.

What Compresses the Timeline

The difference between a 22-day recovery and a 4-hour recovery is not luck. It is architecture.

Immutable backups eliminate the backup integrity problem. When backups are stored in immutable cloud storage — meaning they cannot be modified, encrypted, or deleted by anything, including a compromised admin account — the backup integrity verification phase is fast. You know the backups are clean because the attacker could not touch them. This removes one of the most time-consuming uncertainties from the early recovery phase.

Pre-staged recovery environments reduce rebuild time. Organisations that maintain documented, tested runbooks for restoring each critical system — and that have pre-configured recovery infrastructure rather than building it during an incident — can execute recovery in parallel rather than sequentially.

Network segmentation limits scope. An attack contained to one network segment means fewer systems to rebuild. Micro-segmentation, zero-trust network architecture, and properly maintained firewall rules all reduce the blast radius and therefore the rebuild scope.

Tested restore speeds set realistic expectations. If you know from quarterly restore tests that your critical ERP can be restored in two hours from the last backup point, you can commit to that timeline under pressure. If you've never tested it, you're guessing during the worst possible moment.

Incident response retainer means no delay in Phase 1. The 24–48 hour delay in getting qualified incident response help on site — which affects organisations without a pre-arranged retainer — has an outsized impact on the overall timeline because everything else depends on containment being complete.

The 4-Hour Recovery Scenario

A 4-hour recovery from a ransomware event is achievable. The prerequisites:

Immutable, air-gapped backup with the last backup point within the RPO window
Pre-built recovery environment (cloud-based standby infrastructure) that can accept a restore without needing to be provisioned from scratch
Documented, tested runbook that has been executed successfully in a drill within the last six months
Incident response retainer with a provider who can be engaged immediately
Network segmentation that limits the attack to a defined blast radius

None of these prerequisites are exotic. All of them require deliberate investment before an incident occurs.

The Question to Ask Your Team Today

Ask your IT team: if ransomware detonated at 9am tomorrow, when would we be operational again?

Then ask them to justify that estimate with evidence — the last tested restore time, the last backup integrity verification, the documented runbook, the incident response arrangement.

If the answer to any of those follow-up questions is "we haven't done that," the 22-day average is probably optimistic for your organisation.

Montana Data Company builds ransomware-resilient backup architectures using IBM and Druva platforms, including immutable cloud storage, anomaly detection, and tested recovery runbooks. We also conduct Recovery Readiness Reviews that simulate the first 48 hours of a ransomware incident and identify gaps before they matter.

How Long Does Ransomware Recovery Take?