Ransomware backup advice gets weirdly abstract, fast. “Immutable.” “Air-gapped.” “Cloud-to-cloud.” If you are running a business, you do not need more buzzwords. You need a simple way to tell whether your backups will still be usable on the day you actually need them.

CISA’s #StopRansomware guidance is refreshingly direct: keep backups offline (or otherwise out of reach), protect them from deletion or tampering, and test your restores. Here is what that means in owner terms, plus a one-page checklist you can keep.

What ransomware tries to do to your backups

Ransomware is rarely satisfied with encrypting one laptop. Attackers go after whatever will stop you recovering, including your backup system and your cloud data.

The pattern CISA calls out is simple: if your backups are reachable with the same accounts and network access as everything else, they are reachable by the attacker too. That is why modern guidance keeps repeating three ideas: offline copies, immutability, and restore testing.

Backup buzzwords translated into decisions you can make

You do not have to become technical here. You just need to be clear on what you are buying, what you are relying on, and what “good” looks like.

  • Immutable storage (can’t be changed or deleted). This means your backup copies are written in a way that they cannot be overwritten or wiped for a set period, even by an admin account. Owner decision: do you have at least one backup copy with deletion protection or object lock turned on, with a retention period you have chosen on purpose?
  • Offline or “air-gapped” copies (out of reach). Offline can be literal (a drive that is disconnected) or logical (a cloud repository that is not continuously accessible from your production network). Owner decision: do you have at least one copy that is not always connected to the same environment your staff use every day?
  • Cloud-to-cloud backup for Microsoft 365 (separate from Microsoft). Microsoft keeps the service running, but you are still responsible for protecting your data. Owner decision: if someone deletes a Teams channel, a SharePoint library, or an entire mailbox, do you have a separate backup that can restore it quickly, without a week of scrambling?
  • Restore testing (proof, not hope). A backup that has never been restored is a guess. Testing is how you find out about missing data, broken permissions, or a restore that takes days instead of hours. Owner decision: do you have a calendar cadence for restore tests, and do you keep a short record of what you tested and how long it took?

The “good before bad” checklist (print this)

This is the one-page version. If you can tick most of these before an incident, you are in a very different position when something goes wrong.

  • You know what you are backing up. You have a written list of the key systems and data sets (file shares, line-of-business apps, servers, laptops, Microsoft 365, cloud apps) and you can point to how each one is protected.
  • You have at least one offline or isolated copy. One backup copy is not continuously reachable from your normal network and admin accounts.
  • You have at least one immutable copy. One backup repository has immutability or deletion protection enabled, with a retention window that matches your risk (and is long enough to survive a slow-moving incident).
  • Your backup system has separate access. Backup admin accounts are not the same as everyday IT admin accounts, and they are protected with strong multi-factor authentication.
  • Backups are encrypted. Backup data is encrypted in transit and at rest, so a stolen backup does not become a data breach.
  • Microsoft 365 is covered by a real backup plan. You can restore Exchange, OneDrive, SharePoint, and Teams content from a backup or recovery feature you have deliberately enabled and tested.
  • You have clear RPO and RTO targets. You have decided, in plain language, how much data you can afford to lose (RPO) and how long you can afford to be down (RTO), and your backup setup matches those targets.
  • Restore tests are scheduled. At minimum, you run a monthly small restore (a few files, a mailbox item, a SharePoint folder) and a quarterly bigger restore (a server or a full application workflow).
  • Restore tests include “real life” details. You test not just that a file comes back, but that permissions, timestamps, and application function are acceptable.
  • Test results are recorded. You keep a lightweight log: what you restored, when, who ran it, how long it took, and what you fixed.
  • You have a clean-room option. You have a plan for where restores land if you do not trust your network yet (for example, an isolated VLAN, a separate recovery environment, or dedicated recovery hardware).
  • Your backup vendor is not a single point of failure. You know how to contact support, how to access the admin console if your identity system is down, and what your emergency restore path is.

A practical restore-test routine that does not derail your month

Testing does not have to be a dramatic “full disaster recovery day.” The point is to build confidence and catch surprises while the stakes are low.

  • Start small. Pick one file restore and one Microsoft 365 restore each month. Time it. Write down what was annoying.
  • Rotate what you test. This month: accounting share. Next month: a sales folder. Next month: a key mailbox or a Teams channel.
  • Include one “permission-heavy” restore. A restore that brings back the right access is more meaningful than a simple file copy.
  • Do one quarterly scenario. For example: “A server is encrypted on a Tuesday morning. What is our first restore target, and how long until the team can work again?”

What to ask your IT provider (or your internal IT lead)

If you want to cut through vague assurances, ask for specifics you can verify.

  • “Show me where immutability is enabled.” You want to see the setting and the retention period, not just hear that it exists.
  • “Which backup copy is offline or isolated, and how?” If the answer is “it’s in the cloud,” press once more. Is it always connected, or is it protected from deletion and overwrite?
  • “When was our last successful restore test, and what did we restore?” A date, an item, and a duration is a good sign.
  • “If Microsoft 365 is the problem, how do we restore Teams and SharePoint?” Many businesses find out too late that they only ever planned for laptops and servers.

The takeaway you can keep

Ransomware-resistant backups are not about buying one magic product. They are about making sure at least one copy of your data is both out of reach and unchangeable, then proving you can restore it on a normal Tuesday.

If you would like help reviewing your current backups against this checklist, the Flexnet Networks team can map what you have, spot the gaps, and put a practical testing cadence in place.

Sources