The answer nobody wants to hear: longer than you expect, usually longer than your insurer estimates, and almost always longer than your vendor told you it would be when they sold you the backup solution.
After responding to ransomware incidents across dozens of sectors, the honest answer is that recovery time is highly variable — but there are consistent patterns that determine whether you're back in three weeks or three months. This post breaks those down.
What "Recovery" Actually Means
The first problem is that organisations define recovery differently. IT teams often declare recovery when systems are back online. The business defines it when it can process orders, ship products, or serve customers normally. Finance defines it when the numbers reconcile. Legal defines it when the breach notification obligations are met. These are rarely the same date.
For this analysis, we mean full operational recovery — the point at which the business is functioning at pre-incident capacity, with reasonable confidence that the threat actor is no longer present.
The Realistic Timeline Breakdown
Phase 1: Containment (Hours 0–72)
Isolating affected systems, disabling compromised accounts, understanding the scope of encryption and exfiltration. In smaller environments this can be done in hours. In enterprises with fragmented IT, distributed sites, and no centralised EDR visibility, it takes days. We have seen containment phase alone run to five days where there was no network segmentation and the attacker had been present for six weeks before deploying ransomware.
Phase 2: Investigation and Scope (Days 1–14)
You cannot begin recovery until you understand what was taken, how the attacker got in, and whether they still have access. This is where most organisations cut corners and pay the price — restoring from backup onto a network the attacker still controls, only to be re-encrypted within days.
Forensic investigation takes time. Memory acquisition, log analysis, timeline reconstruction, dark web monitoring for exfiltrated data. In our experience this phase runs 7–14 days for a mid-market incident. Larger, more complex environments take longer.
Phase 3: Environment Rebuild (Weeks 2–6)
The safest recovery path is to rebuild rather than restore. That means rebuilding Active Directory from scratch, redeploying endpoints from clean images, and restoring only data (not applications or configurations) from backup. This is slow. It is also the only way to be confident the threat actor has been fully evicted.
Organisations that short-circuit this phase — restoring entire systems rather than rebuilding them — frequently discover they have reintroduced attacker persistence mechanisms. We have responded to re-extortion events caused by exactly this.
Phase 4: Data Restoration (Weeks 3–8)
Assuming backups exist and are intact, data restoration is often faster than the rebuild — but it rarely goes smoothly. Backup solutions fail in ways they have never been tested against. Partial corruption, version incompatibility, restore jobs that stall at 90% and never complete. If your backup has never been tested by a full restore to production, assume it will take twice as long as expected.
Where there are no backups, or where backups were also encrypted, the options are a paid decryptor (which does not always work cleanly), specialist data recovery, or starting over. We have seen businesses choose to start over from clean because the cost of partial data recovery exceeded the value of the data recovered.
Factors That Extend Recovery Time
Active Directory Compromise
If the attacker reached Domain Admin — and in most of the incidents we respond to, they have — you cannot trust any credential or configuration in the environment. Full AD rebuild is the only defensible option. This adds weeks. Organisations that try to clean a compromised AD rather than rebuild it consistently regret it.
No Tested Backup Strategy
A backup that has never been fully tested is not a backup — it is a hypothesis. We regularly encounter organisations with backup solutions that were sold to them on the basis of daily incrementals and 4-hour RTO, that in practice cannot restore more than a fraction of the data under incident conditions. Test your backups. Restore to a clean environment. Verify data integrity. Do this before an incident, not during one.
Cloud Sprawl and SaaS Dependencies
Modern environments are not a single on-prem data centre. Recovery now involves coordinating with Microsoft, Salesforce, AWS, and a dozen other vendors simultaneously. SaaS providers have their own recovery processes, their own timelines, and their own security posture questions. This complexity is rarely factored into recovery estimates.
Legal and Regulatory Obligations
GDPR requires notification to the ICO within 72 hours of becoming aware of a breach. Sector-specific regulators — FCA, PRA, CQC — have their own notification requirements and timelines. Managing these obligations in parallel with a live incident adds significant overhead. It also means you cannot make purely technical decisions about recovery pace — legal and compliance teams must be in the room.
Cyber Insurance Approval Delays
Cyber insurers have their own approved vendors, their own forensic requirements, and their own decision-making timelines. Waiting for insurer approval before engaging IR, or before approving ransom payments, adds days or weeks. Understand your policy terms before an incident occurs.
Realistic Expectations by Organisation Size
- SME (under 100 users, simple IT): 2–4 weeks to operational recovery if backups are intact; 6–10 weeks without
- Mid-market (100–1,000 users, mixed cloud/on-prem): 4–8 weeks typically; can extend to 12–16 weeks with AD compromise and complex data dependencies
- Enterprise (1,000+ users, multi-site, OT/ICS present): 8–20 weeks is realistic; production environment recovery in critical infrastructure can take longer
These are ranges, not guarantees. We have seen well-prepared organisations recover faster. We have seen organisations with significant IT resource take far longer because of poor decision-making in the early hours.
The Decisions That Determine Speed
Recovery speed is largely determined in the first 48 hours. Organisations that call IR immediately, preserve evidence, contain without destroying forensic data, and make clear decisions about rebuild vs restore tend to recover faster. Organisations that spend days trying to handle it internally, cleaning infected machines, and arguing with their backup vendor lose time they will never recover.
The other decision that significantly affects speed is whether to engage with the threat actor. Negotiations, handled professionally, can secure a working decryptor and reduce overall recovery time where backups are insufficient. They can also provide intelligence on what data was taken. This is not a recommendation to pay — it is context that should inform decision-making.
What You Should Be Doing Now
- Test your backups with a full restore to a clean environment — not a spot-check
- Understand your AD recovery runbook — do you have one?
- Know your regulatory notification timelines before you need them
- Read your cyber insurance policy, particularly the approved vendor list and ransom sublimits
- Have an IR retainer in place so you are not triaging vendors during an active incident
If you are in an active incident, contact us at enquiries@binary-response.com. If you want to reduce recovery time before an incident occurs, speak to us about IR retainer options and tabletop exercises.