Cybersecurity · Las Vegas

Your Ransomware Recovery Plan

A backup is not a recovery plan. Here is what a Las Vegas business actually needs in place — before the morning the screens go dark.

Talk to Brydan →
A server room with a single monitor showing a recovery-in-progress screen, calm blue light rather than a red alert
← Back to Blog Cybersecurity

Ransomware Recovery Plan for Las Vegas Businesses: What You Need Before an Attack

Most businesses that get hit by ransomware did have backups. What they did not have was a plan — a tested, written answer to how fast, from where, and in what order we come back. That gap is the difference between a bad Tuesday and a closed business.

Published August 31, 2026  |  Brydan Solutions Inc

Not sure you could actually come back? Brydan builds and tests the recovery plan for Las Vegas businesses — see our backup & business continuity services.

Talk to Brydan →

A backup is not a recovery plan

This is the single most expensive misunderstanding we correct. A backup answers one question: do we still have the data? A recovery plan answers a much harder one: how, and how fast, do we turn that data back into a working business — email flowing, the phones answering, the line-of-business app open, staff logging in?

Having the data and being back to work are not the same thing, and the distance between them is where businesses lose days they did not budget for. A recovery plan is what closes that distance on purpose, ahead of time, so the answer on the day is a checklist rather than a scramble.

The two numbers that decide everything: RTO and RPO

Before you talk about tools, you set two numbers, per system, in plain business terms:

RTO — recovery time objective. How long can this be down before it really hurts? For a Las Vegas medical office, the scheduling and records systems might be measured in hours; the marketing file share might be fine for a couple of days. You do not need everything back at once — you need the right things back first, and the RTO is how you decide the order.

RPO — recovery point objective. How much work can you afford to lose? If your last good copy is from midnight and you are hit at 4pm, everything after midnight is gone. An RPO of "one hour" and an RPO of "24 hours" are completely different backup designs and completely different costs.

These two numbers are the whole point of the exercise. They turn "back up everything, all the time" — which nobody can afford — into "protect these systems this tightly, because that is what the business actually needs." Set them wrong and you either overspend or discover a gap at the worst possible moment.

One copy has to be somewhere ransomware cannot reach

The old shorthand still holds: keep three copies of your data, on two kinds of storage, with one off-site. But ransomware has added a fourth word that matters more than the rest — immutable. At least one copy must be one that cannot be changed or deleted, even by an administrator login, for a set retention window. Air-gapped, immutable object storage, or a properly isolated cloud copy — the specific technology matters less than the property: an attacker who owns your network still cannot touch it.

A backup that sits on a drive plugged into the same network, reachable by the same admin account the attacker just stole, is not a safety net. It is one more thing that gets encrypted.

Ransomware goes after your backups first

This is the part that surprises people. Modern ransomware does not encrypt your files the moment it lands. It waits, quietly, and looks for the backup server and every connected copy — because the attackers know that a business with working backups will not pay the ransom. So they delete or encrypt the backups first, then trigger. By the time you see the ransom note, the copy you were counting on may already be gone.

That is exactly why the immutable, offline copy is not a nice-to-have. It is the one thing standing between "we restored and moved on" and "we had backups, and they took those too."

The recovery runbook — the part nobody writes down

When it happens, nobody is thinking clearly. The runbook is what you follow instead of your nerves. A usable one, written before the incident, names the concrete things:

  • Who to call, in order — your IT partner, your cyber-insurance carrier's hotline (call them before you touch anything — it can affect your coverage), and legal or a breach coach if data was exposed.
  • Isolate, do not power off. Pulling network cables stops the spread; yanking the power can destroy evidence and, sometimes, the ability to recover in-flight work.
  • The restore order — identity and domain controllers first, then the systems with the tightest RTO, then the rest. Restoring things in the wrong order can mean doing it twice.
  • Where the clean copy is, and who has the keys to reach it — documented somewhere that is not on the network that just got encrypted.

None of this is exotic. It is simply written down and agreed on while everyone is calm, so the answer on the bad day is "step three" rather than "does anyone know…?"

A restore you have never run is a hope, not a plan

Here is the uncomfortable truth we find most often: the business had backups, the little green checkmark said "successful" every night, and no one had ever actually restored from them. The first real test was the emergency — and that is when they learned the backup had been silently failing for months, or that a full restore took three days when the business needed three hours.

A recovery plan is only real once you have rehearsed it. Restore a system to an isolated environment, on a schedule, and confirm it actually comes up and works. The point is not to trust the checkmark; it is to know — because you have seen it — how long recovery really takes and that the copy is genuinely good.

Your cyber insurance is going to ask for this

If you carry cyber insurance, or you are renewing it, the application is increasingly the checklist we have just walked through: Do you have immutable or off-site backups? Is multi-factor authentication on everywhere? Do you have a documented, tested recovery plan? Answering these honestly is not just about getting covered — a wrong answer on the form can void a claim exactly when you need it. Building the plan and building the insurability are the same work.

Where to start

You do not need to solve all of this at once. Start with the two questions that drive the rest: for each critical system, how long can we be down (RTO) and how much can we lose (RPO)? Then make sure one backup copy is genuinely immutable and off the network, and pick a date to actually test a restore. That alone puts you ahead of most businesses that get hit.

Brydan does this for Las Vegas businesses as a managed service — we set the RTO/RPO with you, put the immutable copy in place, write the runbook, and run the restore tests so "tested" is a fact and not a hope. If you are not sure where your gaps are, a short review will tell you plainly.

Talk to Brydan

Would your business actually come back from ransomware?

We will review your backups and recovery plan and tell you, plainly, where the gaps are — before an attacker finds them for you.

Talk to Brydan → Backup & Continuity Services