October is Cyber Security Awareness Month. This is the third article in a series throughout October that will call attention to the importance of cyber security awareness.
Ransomware recovery is proven when the business can resume critical operations safely within an acceptable time. A successful backup job does not establish that capability.
Most established organizations copy data elsewhere and check backup reports. Those practices matter, but they leave an executive question unanswered: how quickly and confidently can employees work, customers be served and revenue resume after a serious attack?
The 2026 Verizon Data Breach Investigations Report found ransomware involved in 48% of breaches, up from 44%, and 69% of victims did not pay. Nonpayment is encouraging, but it does not establish whether victims recovered quickly or avoided other losses.
Business continuity requires protected backups, a workable recovery sequence and evidence the restored environment is secure and usable.
Recovering systems does not undo data theft. Mandiant’s M-Trends 2026 reported extortion activity in 23% of investigations and ransomware-specific intrusions in 13%. Stolen information can give attackers leverage even without encryption.
An organization could restore every system and resume operations by Friday while still facing a leak deadline, customer disclosure and regulatory notification obligations. Backups address one part of the threat. Leadership also needs a response to compromised information, including the reporting decisions we will cover Article 4.
Mandiant describes “recovery denial” targeting backup infrastructure, identity services and virtualization management planes. Attackers may spend time locating these systems before disrupting operations. Exploited vulnerabilities often provide initial access, reinforcing the risk-based remediation argument in Article 2.
CISA recommends offline, encrypted backups and regular testing of availability and integrity because ransomware can destroy accessible backups. Two controls deserve explicit executive attention:
The practical question for an IT provider is specific: can you demonstrate our recovery copies will remain available if production administrative accounts are compromised?
A backup is a copy. Recovery returns the organization to an acceptable level of operation.
Consider a company whose primary business application goes down. Restoring its database accomplishes little without the application infrastructure, network services, security controls, functioning employee devices and identity platform. Connections to customers, suppliers, banks and other applications may also need rebuilding.
Map those dependencies before an incident. A business impact analysis may show identity services and upstream applications must return before accounting, or a supposedly noncritical system supplies information to three critical ones. Technical recovery order should follow these business relationships.
Trust creates another dependency. Was yesterday’s backup taken before attackers arrived? Could it contain malware, compromised credentials or altered information? Recovery planning must define how teams select a trustworthy recovery point and validate the rebuilt environment.
These decisions determine when products ship and revenue resumes. They require business participation, not only infrastructure expertise.
Two measures answer different questions:
| Objective | What it measures | Leadership question |
| Recovery point objective or RPO | How much recent data the business can afford to lose | If backups run every four hours, can we absorb losing four hours of transactions? |
| Recovery time objective or RTO | How long a business service can be unavailable | We say four hours. Have we demonstrated it for the complete service? |
The RTO question is where many plans meet reality. Restoring one server in a planned test differs from recovering dozens or hundreds while investigators determine which systems can be trusted.
Decide in advance where systems will be rebuilt and how an isolated recovery environment will work. Otherwise, pressure to resume can force rushed choices about restoring into infrastructure still under investigation.
Untested recovery objectives are assumptions. Compare stated targets with demonstrated results, including validation by the people who use the service. If the business can tolerate three days but recovery takes three weeks, successful backups have not solved the resilience problem.
Backup testing often stops when a file can be restored. A meaningful recovery test demonstrates an actual business process can operate using complete, secure and usable systems.
NIST’s June 2026 OT Backup Quick Start Guide, SP 1339, recommends creating backups regularly, testing them and reviewing them during recovery exercises. Although written for industrial environments, the testing principle is useful more broadly.
Select a critical process and exercise its dependencies. Restore the relevant data, connect the application, recreate required access and have business personnel verify they can perform essential transactions. Record elapsed time, missing components and the work required to close gaps.
Restored servers without working employee authentication are not operational recovery. Neither is a database the application cannot use.
Tabletop exercises test decisions. Participants discuss who can authorize shutdowns, which operations take priority, when to notify the board, who contacts regulators and insurers, and who addresses a ransom demand. The value is exposing uncertainty before a crisis.
Functional exercises test execution. Teams perform selected recovery tasks: restoring into an isolated environment, rebuilding a critical application, recreating administrative access and having business users validate the result.
Run both. A persuasive discussion does not prove technical execution, and a successful restore does not establish who can make urgent business decisions.
Technology teams can explain how to rebuild servers and restore data. Business leaders must decide which process takes priority, what customers will tolerate and when downtime costs become unacceptable.
Two questions deserve early attention. Which processes have manual fallbacks, who can operate them and for how long? What happens if a critical provider is unavailable at the same time? Your systems may be recoverable while a cloud platform, payroll processor or logistics partner remains down.
Align the recovery plan with those realities. Assign business owners to validate recovered services and fund improvements when demonstrated performance falls short of acceptable downtime.
Four questions for your leadership team
The full 16-question set for all four topics in this series will be available at the end of October.
A successfully tested recovery capability provides evidence of resilience. Ask for demonstrated recovery time, validated business functionality and protected recovery access alongside backup completion reports.
The goal is an organization able to resume essential operations despite disruption. Protected copies make recovery possible; tested dependencies, clear decisions and business ownership make it credible.
The RubinBrown Cyber Security Services and Technology Consulting teams help organizations identify risks, strengthen defenses, and build lasting cybersecurity resilience through proactive strategy, education, and technical expertise. Learn more about RubinBrown Cyber Security Services.
Published: 10/14/2026
Readers should not act upon information presented without individual professional consultation.
Any federal tax advice contained in this communication (including any attachments): (i) is intended for your use only; (ii) is based on the accuracy and completeness of the facts you have provided us; and (iii) may not be relied upon to avoid penalties.