It is a quarter to eight on a Monday. The first patient is at eight. Nobody can log in, and the screen on the front desk machine is showing a note explaining that your files have been encrypted and giving an address to contact.
This walkthrough is not meant to frighten anyone. It is meant to show you where the decision points are, because almost all of them happened weeks or months before this morning.
The first hour
The immediate job is containment, and it is counterintuitive: get machines off the network rather than start fixing them. Ransomware spreads laterally, and every minute a machine stays connected is a minute it can reach something else. Pull the network cables, switch off the Wi-Fi at the access points, leave the machines powered on but isolated.
Do not power things down in a hurry. Memory on a running machine can hold information useful for working out what happened and how it got in. This is also the point where you call your IT provider and, for a practice, start the clock on whether this becomes a notifiable event.
Meanwhile somebody needs to deal with eight o'clock. This is where a practice discovers whether it has a paper fallback: a printed schedule for the day, a way to take patient details on paper, a phone number for the answering service. Practices that have thought about this run a degraded but functioning morning. Practices that have not send people home.
The four questions that decide everything
By mid-morning the situation resolves into four questions, and the answers were all set in advance.
1. Are the backups reachable from the infected network?
This is the one that matters most. Modern ransomware looks for backups first and encrypts or deletes them, because a victim with good backups does not pay.
A backup drive plugged into the server is not protection. A network share the server can write to is usually not protection either. What survives is a copy the infected network cannot reach and cannot authenticate to: offsite, immutable, or both. If that copy exists, this is a recovery job. If it does not, you are looking at rebuilding from whatever paper and cloud records survive.
2. Has anyone ever restored from them?
Backup jobs that report success and produce nothing usable are common enough that we treat an untested backup as no backup. The failure modes are mundane: a job that has been silently skipping the database for months, a retention setting that keeps two days instead of two weeks, a restore that works but takes four days because nobody sized the connection.
The time to find that out is a quiet Tuesday, not now.
3. How long does a full restore actually take?
There is a difference between having a backup and being back at work. Restoring a server, reconnecting workstations, verifying data integrity and getting the practice management software talking to everything again is a day or more of work even when it goes well.
Knowing that number in advance changes what you plan for. A practice that knows recovery is two days can arrange those two days. A practice that assumed it was two hours cannot.
4. What actually got taken?
Encryption is the visible part. Most ransomware operations now copy data out before encrypting it, precisely so they still have leverage over a victim who can restore.
For a healthcare practice this is the part with the longest tail, because it turns a technical incident into a question about patient information, with notification obligations attached. Working out what left the building requires logs, which is one of the less obvious reasons logging matters.
On paying
We are not going to tell you what to do, because that is a decision for you, your insurer and your counsel. What we will say is what we have seen: payment does not guarantee a working decryption tool, it does not get the copied data back, and it does not shorten the recovery work by as much as people expect. Decryptors are frequently slow and imperfect.
If you carry cyber insurance, involve them early. Many policies have requirements about how an incident is handled, and breaching those can affect the claim.
What actually prevents most of this
The interventions that matter are unglamorous and mostly cheap.
- Multi-factor authentication everywhere. A large share of incidents start with a stolen password, and MFA stops that path cold.
- Segmented networks, so a compromised front desk machine cannot reach the server or the clinical systems.
- Isolated backups, with at least one copy the network cannot touch, and a documented test restore.
- Patching that is tracked, particularly on anything internet-facing and anything running an operating system past end of support.
- Staff who have seen a realistic phishing example and know they will not be blamed for reporting one.
- Removing access on the day someone leaves, every time.
None of that is exotic. All of it is the sort of thing that gets deferred because it is not urgent, right up until the Monday it becomes the only thing that matters.
The paper plan
One last thing, which costs nothing and which almost no small practice has. Write down what happens if the systems are unavailable for a day. Who prints the schedule, and from where. How patients get seen. Where staff write things down. Who calls whom.
A single page, printed, in a drawer that does not need a computer to open. It is the cheapest item on this list and the one most likely to save your Monday.
- Ransomware
- Backup
- Healthcare