Patching and Updates: Why “Remind Me Later” Is a Risk Decision

Why “remind me later” is a risk decision

Every “remind me later” click on a security update is a decision — it just does not feel like one. Software vendors release patches because they found holes, and the day a patch is published, attackers know about the hole too. From that day on, every unpatched computer is a known target.

This is not theoretical. The ransomware that recently hit a Coastal Bend dental practice — like most ransomware hitting small businesses — did not use some genius zero-day exploit. It used known vulnerabilities in systems that had not been updated. The patch existed. It just was not installed.

How unpatched systems actually get hit

The sequence is almost always the same:

• A vulnerability is published along with the patch that fixes it. Security researchers, vendors, and attackers all read the same announcements.
• Attackers scan the internet for systems still showing the vulnerable version. This is automated — nobody is targeting your clinic specifically. You get found because you are visible.
• The exploit runs itself. No phishing email needed, no one clicking anything. The vulnerable system gets compromised sitting quietly on your network.
• From one machine to the network. Once inside, ransomware spreads to every reachable system — the EHR server, the file shares, the backups if they are connected.

The window between patch release and mass exploitation keeps shrinking. “We update when we get around to it” is a strategy from a slower era.

Small clinics sometimes assume attackers only target large hospitals. The scanning that finds vulnerable systems is automated and indiscriminate — it does not know or care that you have fourteen employees. Smaller targets are attractive precisely because they are less likely to have monitoring that notices the intrusion. Obscurity is not a control.

What “managed” patching actually means

There is a difference between updates happening and updates being managed. Managed means:

The patching conversation to have with your EHR vendor

Your workstations are only half the picture — the EHR itself, and the server or cloud behind it, need patching too, and that is the vendor’s job. Ask them directly: what is your patch cadence, do you test updates before deploying to our clinic, and will we be notified of maintenance windows in advance? If your EHR runs on a server in your back room, clarify who patches the operating system underneath it — many clinics discover this gap only after an incident, when the vendor points at the clinic and the clinic points at the vendor. Get the answer in writing and file it with your risk assessment. “Somebody handles it” is how unpatched servers are born.

For cloud-based EHRs, ask how quickly critical security patches reach your clinic and whether you have any say over timing — then confirm your own devices are current, because a patched cloud behind an unpatched browser is still exposed.

What to do Monday morning

Ask your IT provider — or check yourself — two questions: when did each computer in the clinic last install updates, and is there a machine nobody is sure about? The answers tell you whether patching is managed or wishful. Anything past 30 days overdue goes to the top of the fix list.

Do not forget the devices nobody thinks about: the networked printer, the firewall on the wall, the old tablet used for intake forms. If it has an IP address, it needs updates — or a documented reason it cannot be updated and compensating controls around it.

Document the patch status of every device in one place — a simple spreadsheet beats a memory. Review it monthly, and treat any device more than 30 days behind as an open risk, not a background task.

Frequently asked questions