If ransomware hit your business tomorrow, the question would not be “do we have backups?” It would be “can we restore clean data fast enough to keep operating, without the attacker being able to delete our backups first?”

That is why modern guidance keeps coming back to the same theme: backups that are isolated, protected from deletion, and routinely proven.

Start with two numbers: RPO and RTO

Before you touch a backup product, get clear on expectations. These two numbers turn a vague goal like “recover quickly” into something you can actually design for.

  • RPO (Recovery Point Objective). How much data you can afford to lose, measured in time. If your RPO is 4 hours, you are saying “in the worst case, we can rebuild up to 4 hours of work.”
  • RTO (Recovery Time Objective). How long a system can be in recovery before the outage starts causing unacceptable impact to the business.

If you are not sure where to start, pick one or two “keep the lights on” systems (often email, file access, accounting, and line-of-business apps) and set RPO and RTO for those first. You can tighten the numbers later.

What “immutable” and “offline” actually mean (in plain English)

Ransomware rarely stops at encrypting files. Attackers often try to delete or corrupt backups so you have fewer options.

Two backup properties help a lot here:

  • Immutable backups. Backups stored so they cannot be changed or deleted until a retention period expires (often described as WORM, write once, read many). If an attacker gets admin access, immutability helps stop the “delete the backups” move.
  • Offline backups. A copy that is not reachable from your normal network or day-to-day admin accounts. This can be as simple as media that is disconnected and stored securely, or a vault that is strongly separated from production access.

CISA’s #StopRansomware guidance calls out both ideas in practical terms, including backing up often, keeping offline copies (or cloud-to-cloud backups), and using delete protection or object lock to prevent deletion or overwriting on storage services that attackers commonly target.

Step 1: Map what you must restore first

During an incident, you will not restore everything in one go. You will restore what gets people working again.

Make a short “restore order” list now:

  • Tier 1: revenue and operations. File shares used daily, ERP/accounting, scheduling, customer systems.
  • Tier 2: supporting systems. Print services, internal apps, secondary databases.
  • Tier 3: nice-to-have. Archives, old projects, non-critical shares.

This list keeps your restore plan aligned with business reality. It also helps you choose where to spend money on faster recovery versus slower, cheaper storage.

Step 2: Build a ransomware-resistant backup stack (three layers)

A simple, resilient setup usually has three layers: a fast restore copy, an immutable copy, and an offline copy.

  • A fast restore copy (for everyday problems). This is the backup you use for “someone deleted a folder” or “that server died.” It should be quick to restore from.
  • An immutable copy (to survive admin compromise). Use storage with immutability features (for example, object lock / WORM-style controls) so backups cannot be deleted or overwritten before retention expires.
  • An offline copy (to survive a worst-case event). Keep a copy that is not reachable through your normal network paths. The goal is simple: even if production credentials are compromised, there is still a clean copy you can reach through a separate, controlled process.

If you only do one upgrade this quarter, make it the immutable or offline layer. Those are the pieces ransomware attackers hate.

Step 3: Lock down the backup system like it is production (because it is)

A lot of ransomware “backup failures” are really access failures. The backup console gets compromised, or the keys to the vault are too easy to grab.

Here is a practical checklist that holds up well:

  • Separate admin accounts. Backup administration should not use the same accounts your IT team uses for email and daily admin work.
  • Minimum access. Only a small number of people should be able to delete jobs, change retention, or approve restores.
  • Deletion protection and retention controls. Turn on features that prevent deletion or retention reduction before expiry where your platform supports it.
  • MFA everywhere. Especially on backup consoles, cloud portals, and any privileged account.

This is boring work. It is also the work that keeps a bad Tuesday from turning into a business-ending week.

Step 4: Encrypt backups, and store the keys like you mean it

Encryption is not just for laptops. Backups often contain the most concentrated set of sensitive data you have.

Aim for two things:

  • Encryption in transit and at rest. This protects data as it moves to backup storage and while it is stored.
  • Recoverable keys. If encryption keys are lost, your backups can become useless. Store recovery keys and vault access details somewhere protected and documented, with a clear “break glass” process.

A simple rule: if you cannot explain how you would access your encrypted backups during an outage, you do not yet have a recovery plan.

Step 5: Do monthly restore tests that answer business questions

Backups can look healthy for months and still fail when you need them. A monthly restore test is the cheapest way to avoid that surprise.

Keep it realistic and repeatable:

  • Pick one system per month. Rotate through your Tier 1 list.
  • Restore to a safe place. Use an isolated test location so you are not reintroducing malware into production.
  • Prove usability, not just “it restored.” Can you open the files? Does the database mount? Can a user sign in? Does the application actually run?
  • Record two times. How long did the restore take (your real-world RTO), and how far back was the newest clean restore point (your real-world RPO)?

If the numbers are worse than what the business expects, that is not a failure. That is useful information you can act on.

A simple takeaway you can use this week

You are aiming for backups that ransomware cannot easily reach, cannot easily delete, and that you have already proven you can restore.

If you want a straightforward starting point, do these three things in order:

  • Add immutability. Turn on WORM-style protection (object lock, immutable vault features, or equivalent) for your backup storage.
  • Add an offline copy. Keep a genuinely separate copy with a controlled access path.
  • Add monthly restore tests. Make them small, scheduled, and tied to RPO/RTO so they stay business-focused.

Want a second set of eyes on your backup plan?

If you would like help designing ransomware-resistant backups (immutable plus offline), setting realistic RPO/RTO targets, and running a monthly restore-testing routine, the Flexnet Networks team can help you put that in place.

Sources