Person holding anonymous mask near servers, hinting at cybersecurity and hacking themes.

Before Ransomware Teaches You the Hard Way: Lessons From a Real Government Network Shutdown

This past weekend, Chelan County in Washington State had no Monday morning at all. A malware attack hit Sunday around 10 a.m. Officials sent one message across the county: “Our network and phones are down. Do not turn on PCs.” Every computer went dark. Every phone line went down. Two-plus days offline — the full extent of the damage still unknown at time of writing.

What Went Right

Emergency services — 911 via RiverCom — never went down. That is not luck. It is the result of a decision made before the attack: 911 runs on a separate network segment from the county’s administrative systems. When everything else went dark, the most critical service kept running.

That is the first lesson. Not everything should be equally connected.

What Two Days (and Counting) Offline Actually Looks Like

Two days of complete operational shutdown. Courts rescheduled. Staff unable to use computers or phones. A single malware event cascading through every connected system.

The county isolated their network immediately — the right call. That decision gave their outside contractors something to work with. But isolation only stops the bleeding. Recovery is what most organizations have not practiced.

The Question for Your Organization

If your SQL Server environment went dark today, what would your organization look like? Start here:

  • Are your backup systems on the same network segment as production?
    • Are they stored on immutable storage so malware cannot destroy them?
  • Have you tested a full restore in the last 30 days?
  • Are ALL your databases monitored for unexpected changes anywhere in the TDE key hierarchy — not just databases already running TDE?
    • The full chain must be audited: the Database Master Key (DMK), TDE Certificates, and Database Encryption Keys (DEK). Attackers can target any link — creating, altering, exporting, or destroying keys and certificates on any database, encrypted or not. Any unexpected change anywhere in that chain is a signal an attacker may already be inside.
  • Do you have an isolation procedure written down — or does it live in one person’s head?
    • Have you ever actually built and physically tested it so you know it works when you need it?
  • Who makes the call to shut down the network, and how fast can they make it?
    • Lose the memory state and you lose the attack profile — and your fastest path back.
  • Is your team prepared to execute the recovery workflow ransomware forces you to follow?
    • An Isolated Recovery Environment, a tested runbook, a full team tabletop, and quarterly live simulations — before the night you need them.

These questions determine whether recovery takes two days or two weeks. Or whether you recover at all.

The Decision That Changes Everything

One thing we know they got right: isolate immediately. That decision bought them a path forward.

Ransomware does not give you time to figure out your runbook mid-incident. The preparation either exists before the attack — or it doesn’t exist when you need it.


Not sure where your gaps are? A SQL Server Security Discovery Call with Data Systems Architecture is an honest look at your actual exposure — backup architecture, network segmentation, recovery procedures, and the things most organizations only find mid-incident. Request your Discovery Call today.

Scroll to Top