Backups are not a ransomware strategy until restore has been tested

A successful backup job proves that data was copied. It does not prove that the copy is clean, complete, accessible during an incident, or capable of restoring a business service. That distinction matters when credentials, management systems, and connected backups may all be affected at once.

NIST’s 2025 draft ransomware profile recommends secured and isolated backups, restoration testing, verified backup integrity, current response contacts, and exercised response plans. IBM’s 2026 global breach research also reinforces the commercial importance of reducing the time required to identify and contain incidents.

Define recovery around services, not servers

• —Rank business services and agree recovery time and recovery point objectives with their owners.
• —Map application, identity, network, certificate, database, vendor, and infrastructure dependencies.
• —Keep protected copies that compromised production credentials cannot modify or delete.
• —Document clean-room recovery steps, decision rights, communications, and evidence handling.
• —Test representative restores and record actual timing, failures, manual steps, and corrective actions.

Exercise the decisions as well as the technology

A technical restore can still fail operationally if nobody knows who may isolate a network, notify affected parties, approve a rebuild, or communicate with customers. Tabletop exercises expose these gaps before a real incident compresses every decision into minutes.

A recovery programme becomes credible when restore results are measured, exceptions are visible, and lessons from each exercise update architecture, support procedures, and investment priorities.