Backup is only one part of recovery
A business can have frequent backups and still experience a prolonged outage. Recovery also depends on access to backup accounts, replacement equipment, software licenses, clean administrator credentials, vendor support, communications, and a documented order of operations.
Ransomware planning should therefore begin with a recovery clock. For each critical service, decide the maximum tolerable downtime and the amount of data the business can afford to lose. These decisions are commonly described as recovery time and recovery point objectives, but the labels matter less than the business conversation behind them.
Rank the services
Create three groups:
- First-hour services: systems needed to protect cash flow, safety, customer communication, scheduling, payroll, or critical operations.
- Same-day services: systems that can operate manually for a short period but must be restored quickly.
- Later services: archives, convenience systems, and lower-priority applications.
Do not rank systems only by technical importance. A small office may be able to work temporarily without a file server but not without access to a payment processor, phone system, appointment schedule, or bank account.
Write down manual alternatives. A printed contact list, temporary call-forwarding plan, offline customer schedule, or preapproved alternate communication channel may be more useful during the first few hours than an untested technical procedure.
Protect the backup environment
CISA recommends backing up business data and keeping backups protected. In practical terms, backups should be separated from ordinary user access, protected against unauthorized deletion or alteration, and monitored for failures.
Review whether the same credentials control both production systems and backups. If so, a compromised administrator may be able to damage both. Ask the backup provider how immutable storage, retention locks, encryption, multifactor authentication, administrator separation, and recovery verification are implemented.
Cloud synchronization is not automatically a backup. If a malicious or accidental deletion synchronizes across devices, the business may lose the information it expected to preserve. Confirm version history, retention, deleted-item recovery, and independent restoration options.
Test restoration, not just backup completion
A successful backup job means that data was copied or processed. It does not prove that the application can open the data, that permissions are correct, or that the restored information is complete.
At least quarterly, restore a representative file. For critical systems, conduct a more realistic test involving the application owner, the technology provider, and the person responsible for business operations. Record:
- What was restored.
- Where it was restored.
- How long the process took.
- Whether the data was usable.
- What credentials or licenses were needed.
- Which step failed or caused delay.
Treat failed tests as findings to fix, not as embarrassing results to hide. A failed exercise is cheaper than a failed recovery during an actual incident.
Plan for compromised credentials
Recovery may require more than restoring files. If an attacker had administrative access, assume that credentials, tokens, forwarding rules, remote-access settings, and backup permissions may need review.
The recovery procedure should include account resets, administrator verification, endpoint inspection, software patching, network segmentation where appropriate, and confirmation that restored systems are clean enough to return to service. A security provider or incident-response specialist may be necessary if compromise is suspected.
Do not reconnect restored systems simply because they appear operational. Confirm who can access them and whether the original attack path remains open.
Confirmed and uncertain points
Confirmed: CISA and NIST treat backups and recovery as core cybersecurity practices, and NIST’s ransomware risk-management materials connect protection, detection, response, and recovery.
Uncertain: No universal backup frequency or retention period fits every business. Requirements depend on transaction volume, legal obligations, application design, insurance terms, and the cost of downtime.
Avoid selecting retention periods solely because a vendor offers them by default.
A 60-day improvement plan
In the first two weeks, identify critical services and recovery priorities. In the next two weeks, review backup administrator access and retention protections. During the second month, perform restoration tests and update the incident contact sheet. End with a tabletop exercise that begins with a locked workstation and ends with a decision about customer communication and temporary operations.
A backup plan becomes credible when the business can state what returns first, who decides, how access is restored, and when the result will be tested again.
Human-reviewed draft. This article is general information and not a guarantee of recoverability.