The honest answer: about 3 weeks on average. For the unprepared, longer.
Imagine coming in on Monday morning to find every system encrypted. When will we be back up and running? That's the first question everyone asks — executives, customers, employees. And the answer is more painful than most organizations expect. According to research by Cigent and multiple security firms, the average recovery time after a ransomware attack is 21 to 24 days. Three weeks without full access to systems, data, and business processes. For some organizations it takes longer — sometimes months. But the number "21 days" doesn't tell the whole story. Recovery time is not a fixed value. It is determined by choices you make long before an attack occurs.
Key Takeways:
• The average recovery time after ransomware is 21 to 24 days, regardless of whether ransom is paid (Cigent).
• Organizations with isolated, tested backups recover significantly faster — sometimes within hours for critical systems.
• Recovery time is determined by three factors: backup quality, recovery plan completeness, and whether the plan has ever been practiced.
What counts toward recovery time
Recovery time after ransomware doesn't start when you see the ransom note. It starts earlier — and ends later than you think. A ransomware attack has multiple phases. First there is the so-called "dwell time": the period between initial intrusion and the moment ransomware is activated. According to ESG (part of Omdia), malware remains active in the network for an average of eight days or more before encryption begins. During that time, attackers steal data and map the backup infrastructure. Then comes the acute phase: detection, isolation, forensic investigation, and a decision on payment or recovery. The negotiation phase alone, when paying, takes an average of 8 to 10 days. Then comes the technical recovery: reinstalling systems, restoring backups, validating systems, and restarting processes. And finally: business normalization — informing customers, resuming contracts, rebuilding trust. The last part takes longest.
The real cost of three weeks of downtime
Three weeks without systems means three weeks without revenue for many organizations. According to Huntress, the total damage from a ransomware incident averages more than $4 million, most of which is not the ransom but the business damage from downtime.
For SMBs, the absolute amounts are lower but the impact is greater. Customers who can't be served for three weeks look for alternatives. Contracts that can't be fulfilled lead to penalties. Employees who can't be productive for weeks cost payroll without return.
Why paying doesn't shorten recovery time
A common misconception is that paying accelerates recovery. In practice, that is rarely the case.
Even if you pay and receive a decryption key, you then spend hours to days manually decrypting files, validating data integrity, and checking whether the system is still infected. Attackers sometimes leave backdoors — even after payment.
The average ransomware negotiation period is 8 to 10 days. Add the technical recovery time on top, and you quickly exceed 21 days — while also having paid.
Organizations that recover from a clean, isolated backup skip the negotiation phase entirely. They can start technical recovery immediately once the backup is available and validated.
What Colonial Pipeline taught us about recovery time
In 2021, Colonial Pipeline paid nearly $5 million in ransom — not because they lacked backups, but because no one could say how long recovery from backup would take. The uncertainty about recovery time was itself the reason for payment.
This is a lesson every organization should take seriously: a backup whose recovery time is unknown is not a backup you can rely on in a crisis. Recovery time must be known in advance — through measurement, not guesswork.
What factors determine your recovery time
Your organization's recovery time is determined by a limited number of factors that are all influenceable in advance.
First: backup quality. Is the backup isolated from the production network? Is it immutable (cannot be changed after writing)? How recent is the last backup? A backup from yesterday means a maximum of one day of data loss. A backup from last week means seven days.
Second: backup completeness. Do all critical systems have a backup? Are configurations, databases, applications, and user data all included? A backup covering 80% of data requires manual recovery for the remaining 20% — which takes considerable time.
Third: recovery plan quality. Is there a documented recovery plan? Does everyone know their role? Is there a priority list of which systems to restore first?
Fourth: whether the recovery plan has ever been practiced. A recovery plan that has never been executed always contains unexpected issues — systems configured differently than expected, overlooked dependencies, or simply time estimates that don't hold up.
For more information on disaster recovery planning, see our Disaster Recovery page.
Step-by-step: what to do immediately after a ransomware attack
1. Inventory all critical systems and applications that need to be restored.
2. Determine the estimated recovery time from backup for each system (including installation, configuration, and validation).
3. Determine the restoration order based on business priorities.
4. Add up recovery times in the correct order (accounting for parallel recovery operations).
5. Add a buffer of 20-30% for unexpected issues.
6. Compare this theoretical recovery time with your current RTO (Recovery Time Objective).
7. If the theoretical recovery time exceeds your RTO, adjustments to the backup strategy or recovery plan are needed.
How to structurally shorten recovery time
The most effective way to shorten recovery time is not investing in faster hardware — it's investing in better preparation.
Isolated backups shorten recovery time because attackers couldn't encrypt or damage them. You don't need to search for a clean copy — it exists and it's ready to use.
Regular recovery tests make recovery time predictable. Organizations that periodically practice their recovery process know exactly how long it takes, where the bottlenecks are, and what needs improvement. They also have certainty that the recovery plan works — not just hope.
Automated recovery solutions shorten the time needed for manual steps. Instead of manually reinstalling and configuring systems, they can be restored through automated workflows.
Visit our Backup as a Service page for more information on how to structurally build recovery capacity. For further background, see ENISA Best Practices for Cyber Crisis Management.
What is a realistic RTO for your organization?
RTO stands for Recovery Time Objective: the maximum time it may take to restore systems after an incident. It is a deliberate choice — not a technical given.
For critical systems (production planning, financial administration, customer portals), an RTO of a few hours is realistic with the right backup infrastructure. For less critical systems, an RTO of 24 to 72 hours may be acceptable.
According to the State of SaaS Backup and Recovery Report 2025 by Spanning/Kaseya, more than 60% of organizations believe they can recover within hours. Only 35% actually can. The difference lies not in intention, but in preparation: tested recovery plan, isolated backups, and known recovery times per system.
An RTO that has never been tested is a wish — not a guarantee.
Conclusion
The average recovery time after ransomware is 21 to 24 days. But that average masks a wide range: organizations with good preparation recover in days or hours, organizations without preparation sometimes in months.
Recovery time is not fate. It is the result of decisions you can make now: an isolated backup, a documented recovery plan, and periodic recovery tests that turn theoretical time into proven capability.
If you want to know what your recovery time is, the only way to find out is to run a recovery test — not estimate it.
Frequently asked questions
How long does recovery from a ransomware attack typically take? +
The average recovery time after a ransomware attack is 21 to 24 days (source: Cigent), regardless of whether ransom is paid. This includes time for forensic investigation, system remediation, backup restoration, and business normalization. Organizations with an isolated, tested backup and a documented recovery plan can recover significantly faster — sometimes within hours for the most critical systems.
Does paying the ransom speed up recovery? +
Not significantly. Even after payment, decryption takes hours to days, and the integrity of restored data must be validated. The system may also still contain backdoors. The average negotiation period when paying is 8 to 10 days — which already eliminates most theoretical time savings. Organizations recovering from a clean backup bypass the negotiation phase entirely.
What is a Recovery Time Objective (RTO) and how do I set one? +
An RTO is the maximum time it may take to restore a system or service after an incident. You set an RTO by determining what level of downtime is acceptable for each system based on business impact. Critical systems (finance, customer communication) get a short RTO (hours), less critical systems a longer one (days). An RTO is only meaningful when tested: run regular recovery tests to verify that your backup solution actually meets the RTO.