You probably already “have backups”. The uncomfortable question is whether you can restore fast enough to keep the business moving, even if ransomware hits and the attacker tries to wipe your backups too.

CISA’s #StopRansomware guidance is blunt about what works: keep offline, encrypted backups, make them immutable where you can, and test restores regularly. This post is a practical checklist you can run with your IT team to prove you can recover without paying.

What you’re trying to prove (before you need to)

A good ransomware recovery test is not a report that says “backup jobs succeeded”. It is proof of three business outcomes:

  • Your backups survive the attack. Ransomware often goes after backups, not just production data.
  • You can rebuild a working system. Not just restore files, but get a usable server, app, or workstation back.
  • You know your real recovery time. Your “we’ll be back in a day” guess becomes a measured number.

If you keep those outcomes in mind, the checklist below stays focused.

Checklist 1: Make at least one backup copy offline or immutable

CISA’s guidance calls out offline, encrypted backups and regular testing. The key detail is “offline” in the sense of not reachable from your normal network when things go wrong.

  • At least one copy is offline or isolated. A USB drive that stays plugged in all week is not really offline. The goal is a copy that cannot be modified by a compromised admin account or an infected computer.
  • Immutability is enabled where your platform supports it. Immutability means the backup cannot be deleted or altered before its retention period ends (think write-once, read-many behaviour). If you use a cloud backup platform that supports “locked” immutability, turn it on for the most critical workloads first.
  • Backups are encrypted. Encryption should apply both in transit and at rest, and you should know where the keys or passphrases live and who can access them.
  • Retention matches real-world recovery needs. If you only keep 14 days of backups, but ransomware sat quietly for 30 days before detonating, you may not have a clean restore point.

Checklist 2: Segment backup storage so ransomware cannot “walk” to it

A lot of failed recoveries come down to one design flaw: backups were on the same network, with the same credentials, as everything else.

  • Backups do not use your everyday admin accounts. Your backup system should have separate credentials, and access should be tightly limited.
  • Backup storage is on a separate network segment or separate account/subscription. The point is to make it harder for an attacker who compromises one area to reach and destroy backup data.
  • Backup management has extra guardrails. For example, require multi-factor authentication for backup consoles, restrict access by location, and limit who can delete or change retention.
  • You have a “break glass” path documented. If your identity system is down, how do you access the backup platform and start a restore? Write it down and store a copy offline.

Checklist 3: Run a real restore drill (not a file restore)

File restores are good, but ransomware recovery is usually a systems problem. You want to prove you can bring back something your team can actually use.

Pick one representative system each quarter. Rotate through a server, a line-of-business app, and a typical user workstation.

  • Restore into an isolated test environment. Do not restore straight into production. Use a segmented VLAN or a dedicated test network so you can validate safely.
  • Restore the full system, then boot it. The pass condition is “it starts and runs”, not “the restore job completed”.
  • Validate logins and core functions. Can you sign in? Does the app connect to its database? Can you open the shared folder? Can you print an invoice? Pick 3 to 5 checks that match how the business actually uses the system.
  • Time the whole process. Start the clock when you begin the restore and stop when a non-technical user could do their job on that system.

Checklist 4: Prove you can recover without reintroducing the infection

Restoring data is only half the job. The other half is making sure you are not restoring the same malware, persistence, or compromised credentials.

  • Decide what “clean” means for your business. For many environments, that means rebuilding key systems from known-good baselines, then restoring data, rather than restoring entire servers blindly.
  • Scan restored data before reconnecting it. Your security stack should be able to scan restored files and images, especially if you are restoring from a point close to the incident.
  • Reset credentials as part of recovery. If ransomware hit, assume credentials may be compromised. Your recovery runbook should include password resets, token/session revocation, and re-issuing admin access.
  • Document the order of operations. What comes back first so the business can function? Email, identity, finance, file shares, line-of-business apps, then everything else is a common pattern, but yours may differ.

Checklist 5: Turn the test into a repeatable, auditable routine

A one-time heroic test is not the goal. You want a routine that keeps working as your business changes.

  • Assign an owner and a schedule. Put a quarterly restore drill on the calendar with a named owner, not “IT”.
  • Record results in plain English. Capture the restore point used, how long it took, what broke, and what you changed afterward.
  • Track two numbers: RPO and RTO. RPO is how much data you can afford to lose. RTO is how long you can afford to be down. Your test results should update those targets, or force a decision to invest.
  • Fix one thing after every test. Maybe it is a missing driver, a licence key you could not find, a DNS dependency nobody documented, or a backup that was not actually included. Small fixes compound quickly.

A simple way to use this next week

If you do nothing else, do this: pick one system, restore it into an isolated network, boot it, and have someone outside IT confirm it works. That single drill will tell you more about your real readiness than a year of green check marks.

If you would like help building an immutable backup setup and running a restore drill that proves you can recover without paying a ransom, the Flexnet Networks team can help you put the process in place.

Sources