Ransomware Backups: What They Cannot Save You From

Quick Answer

Ransomware backups can help restore encrypted or deleted data. They cannot erase copies an attacker has stolen, automatically remove unauthorized access, or prove that your business can operate again. A credible recovery plan needs protected backups, an incident response team, and a tested path back to essential work.

Picture this hypothetical Monday morning: your IT team restores the order database and the backup dashboard turns green. Then a customer asks whether their records were stolen. In the warehouse, nobody can sign in to process shipments.

The files are back. Orders are still stuck.

That distinction should shape how you buy managed security services and how you test the provider you already have. Ask three questions: Can we recover the data? Can we trust access? Can we run the business?

1. Restoring Data Does Not Undo Data Theft

A backup gives you another copy of your information. It does not take a stolen copy away from an attacker.

The UK's National Cyber Security Centre makes this boundary explicit: its ransomware-resistant backup principles address destructive attacks, while stolen-data extortion requires additional protections. That matters even when every restore test succeeds.

Consider a hypothetical professional services firm with intact backups and stolen client documents. Getting its file server running resolves an availability problem. It still needs to investigate which records were accessed, establish what evidence supports that assessment, and coordinate communications with the people responsible for them.

Give data theft its own line in your provider evaluation. Our recommendation: have the supplier list the identity, cloud, endpoint, and network activity it can investigate, how long it retains that evidence, and what it cannot see.

An honest coverage gap is more useful than a confident promise to detect everything. Add those answers to your MSSP evaluation checklist, along with who leads the investigation when an alert becomes a confirmed incident.

2. Intact Backups Do Not Guarantee Trusted Access

The files might be available while the credentials needed to reach them are compromised, disabled, or inaccessible. The restoration process itself may depend on the same identity service involved in the incident.

The NCSC's cloud backup principles cover more than deletion protection. They also address continued customer access, usable historical versions, encryption key protection, and alerts for significant changes. Immutability is one part of that picture.

Put this question to your backup supplier: "If our administrator accounts and corporate email are unavailable, how do authorized staff get our backups?"

Have the team demonstrate the agreed recovery method in a controlled test. Confirm who can approve it, how that person is authenticated, and where the instructions are available during an outage.

Restoring an application also does not, by itself, revoke stolen credentials or remove every route an intruder used. Ask the response lead how identity recovery and system restoration will be coordinated. This is a useful place to distinguish the contracted responsibilities of MDR and MSSP services.

The NCSC's ransomware mitigation guidance recommends testing restores, checking backups for malware, and connecting them to known clean devices. Your incident team should determine the appropriate recovery sequence and validation for the systems involved.

The same guidance calls for offline backups kept separate from the network, or a cloud service designed for that purpose, and multiple copies across different solutions and locations. A synchronized folder is not enough if it immediately copies encrypted files over the versions you need. Ask your backup provider to demonstrate what survives a compromised administrator account and how long those recovery points remain available.

3. A Successful Restore Does Not Prove Business Recovery

A recovered database is encouraging. A completed customer order is better evidence that a business process works.

An application may need identity services, network configuration, integration credentials, and an external supplier before anyone can use it. A restore exercise that stops at "the server boots" leaves those dependencies untested.

The NCSC's recovery framework, published in July 2026, separates immediate response, recovery toward minimum viable operations, and the subsequent rebuild. It recognizes that investigation and recovery evolve together.

To apply that framework, we suggest choosing one essential business outcome and testing the chain required to deliver it. For a distributor, that might mean accepting an order, reserving stock, and producing a shipping instruction. For another organization, it could be running payroll.

Set the acceptable interruption and data loss with the business owner before the exercise. Record the time from exercise start to an accepted transaction, including access problems and approval delays. Report those findings alongside the technical restore time.

This also clarifies decisions about in-house security and outsourced support. A provider can contribute technical expertise. The organization still needs someone who can say whether the recovered service is fit to use.

Ransomware Recovery Drill: Six Questions to Test Readiness

Use this suggested exercise with your IT team, security provider, backup provider, and the owner of one critical business process. During a real incident, the response team should adapt its actions to the evidence and systems involved.

Start with a tabletop discussion. Schedule technical validation in an isolated environment with agreed boundaries and synthetic or appropriately protected test data. Do not disable production accounts or delete real backups to make the exercise convincing.

Record every step where somebody says, "I thought the other team handled that." Give each gap an owner and a due date. Keep the failed steps in the report; they are the reason to run the drill.

For the leadership discussion, bring three results: the time to complete the business transaction, the difference from the agreed recovery target, and the unresolved access or evidence gaps. Those findings belong in your next renewal meeting, too.

Who Owns Containment, Restoration, and the Decision to Resume?

Separate the responsibilities in writing, then exercise the handoffs. CISA's official announcement of the joint StopRansomware guide describes distinct activities for detection and analysis, containment and eradication, and recovery. Your contract needs to assign those activities to people who can perform them.

Your agreement should identify who can isolate systems, who investigates access and data theft, who preserves evidence, and who restores infrastructure. It should also identify who approves reconnection and who accepts the business service after validation. In the planning exercise, have the investigation and recovery leads agree which evidence they need to preserve before systems are rebuilt. Missing logs leave uncertainty; they do not establish that no data was stolen.

These roles may sit with different organizations. That is workable when the handoffs are explicit. An MSSP monitoring alerts might have no contractual responsibility for rebuilding applications; a backup provider might restore data without conducting forensics. Confirm the actual scope through the MSSP selection process.

When you compare security providers, bring the drill table to the conversation. Ask each candidate to mark the rows it owns, supports, or excludes. You will have a comparison of who can help your business recover, with the gaps visible before an incident.

Frequently Asked Questions

Are backups enough to protect against ransomware?

No. Protected, tested backups help recover data that has been encrypted or deleted. Ransomware readiness also requires measures to reduce intrusion risk, investigate suspicious activity, contain an incident, and validate recovery. Data theft can remain a problem after a successful restore.

Can ransomware affect cloud backups?

Yes. Cloud backups still need deletion protection, usable historical versions, recovery access, protected encryption keys, and monitoring. Ask your supplier which controls are enabled and how your team verifies them.

Does an immutable backup stop data theft?

No. Immutability restricts changes or deletion under configured retention controls. Unauthorized copying is a separate risk, so protecting access to sensitive backup data still matters.

Should my MSSP restore systems after an attack?

Only if that work is included in its agreed scope. Confirm whether the MSSP investigates, contains, restores, or coordinates other specialists. Name the person who approves technical reconnection and the business owner who accepts the recovered service before an incident occurs.