Michael Wu is GM and President of Phison Technology Inc. (USA), a leading provider of NAND controllers and NAND storage solutions.
For years, the cybersecurity conversation has centered on prevention through stronger firewalls, smarter endpoint detection and more rigorous employee training. These measures will always be essential.
But adversaries increasingly go after not just production systems, but the backups organizations depend on to recover. When attackers can compromise both the primary environment and the safety net meant to restore it, keeping them out is no longer the end of the story.
The stakes are high. According to Gartner, the cost of recovery, downtime and reputational damage following a ransomware attack can reach 10 times the ransom amount itself. A ransomware event quickly becomes a business continuity crisis that touches customer trust, revenue and brand value.
That’s why recovery deserves a central place in ransomware planning, alongside prevention and detection. The question that matters most once systems are compromised is how quickly you can access, validate and restore large volumes of clean data, and whether you know the answer before you need it.
Make Recovery An Infrastructure Priority
Too often, recovery planning is a checkbox exercise handled within the cybersecurity function. Backups are scheduled, tested occasionally and assumed to be sufficient.
But recovery is fundamentally an infrastructure challenge, and it comes down to simple arithmetic, or the volume of data you must restore, divided by the sustained throughput your environment can actually deliver, plus the time it takes to sequence and validate that data before it returns to production.
That arithmetic is where many recovery time objectives (RTOs) break down. Once teams isolate compromised systems and find a trustworthy recovery point, several constraints surface:
• Restore Speed Lags Backup Speed: Backup targets are optimized to ingest data. Pulling it back out, especially deduplicated data, is often slower.
• The Network Becomes A Choke Point: Links that handle nightly backups saturate when dozens of systems restore simultaneously.
• There May Be Nowhere To Restore To: Compromised systems are often held for forensics or untrusted, so data must land on clean capacity that may not exist yet.
• Dependencies Dictate Order: Identity services, DNS and core databases must come back before the applications that rely on them.
Consider a hypothetical example. Restoring 200 TB of critical data at a sustained 2 GB per second takes roughly 28 hours of continuous transfer, before a single file has been scanned or an application tested. If the stated RTO is 24 hours, the plan fails on arithmetic alone.
Design For Recovery From The Outset
Designing for recovery starts with knowing whether your current environment can meet the objective you’ve promised the business. Four measurements tell you:
• Critical Data Volume: How much data must be restored to resume minimum viable operations? This isn’t your total storage footprint.
• Sustained Restore Throughput: How fast can that data move end to end, from backup target to network to trusted storage, while many systems restore at once? Use measured numbers, not rated specifications.
• Restore Sequence: Which systems must come back first, and how much can truly run in parallel?
• Validation Time: How long does it take to scan, verify and confirm data is clean before it reconnects to production?
Divide volume by throughput, add the time imposed by sequencing and validation and compare the result to your stated RTO. The difference is your readiness gap.
The gap also helps weigh resilience against cost. Tier workloads by business impact, such as systems that must be back within hours, those that can wait days, and those that can wait longer. Then, for each tier, ask what an hour of downtime costs and how many hours a given architecture decision adds to or removes from recovery. Viewed this way, protections such as immutable backups and isolated backup networks, often cut for budget reasons, look less like expenses and more like insurance against days of downtime.
Next, test math under realistic conditions. Restore one critical application fully into an isolated environment at production scale, timing each stage separately. Then ask, if production were off-limits, where would we restore to? Have we ever restored this volume at once? Does the measured time beat our stated RTO?
Too many organizations discover during an actual incident that their RTOs were aspirational. A drill surfaces that gap while there’s still time to close it.
Build A Strategy For Rapid Restoration
Security teams understand the threat landscape, while infrastructure teams understand what systems can deliver under pressure. Working in isolation, they produce plans that look strong on paper but fail under real constraints.
The four readiness measurements give both a common scorecard, and each point to a way to close the gap:
• Reduce Critical Data Volume: Define precisely what minimum viable operations require and keep protected recovery copies of that tier ready to restore first.
• Raise Throughput Where It’s Lowest: Restore speed is set by the slowest link, whether that’s the backup target, the network or the destination storage. Measure each link and invest in the one that constrains you.
• Shorten The Sequence: Map application dependencies in advance and keep clean recovery capacity ready so teams aren’t sourcing hardware mid-incident.
• Compress Validation: Verify backup integrity continuously rather than for the first time during an incident. Restoring compromised data can reintroduce the very threat you’re trying to eliminate.
Finally, track time to fully restore operations as closely as you track time to detect and contain. Rerun the readiness calculation whenever data volumes or infrastructure change, and report the gap alongside other risk metrics.
When leaders see that gap expressed in hours of downtime, recovery spending stops looking like a technical line item and starts looking like the business continuity investment it is.
The Bottom Line
Ransomware will keep evolving, and attackers will keep targeting the backups meant to restore what they’ve compromised. Organizations that have done the math, tested it and closed the readiness gap will be in a strong position to withstand the next attack, and more likely to still have customers, revenue and credibility when the dust settles.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?