In conversations I have with dental organization leaders, a pattern emerges more often than you might expect. A ransomware notice appeared on a screen, or a vendor sent an unexpected alert, or someone clicked a link they shouldn't have. The systems slowed down, locked up, or went dark. And now someone, usually the person running technology for the organization, is standing in a hallway wondering what to do next.
What I've noticed is that for some DSOs, a security incident becomes the wake-up call that accelerates modernization. Whether they've experienced a breach directly or watched a peer organization go through one, that proximity to risk tends to clarify priorities fast.
The organizations that come out stronger are the ones that channel that awareness into real infrastructure investment and a harder look at how they're protecting patient data. Fear, in that sense, can be clarifying, but only if it leads to action.
1. Contain First, Diagnose Second
The first instinct when something looks wrong is to understand exactly what happened. Resist it. In the early hours of a potential breach, containment matters more than forensics.
Think of it like fault tolerance in system architecture. The goal is not to fix everything at once. The goal is to isolate the problem, so the rest of the organization keeps functioning. Disconnect affected systems from the network. Wall off what you can. If you are unsure which systems are involved, err on the side of isolating more rather than less.
This is also the moment to contact your cyber insurance carrier. Many policies require prompt notification, and carriers often have incident response firms available immediately. Do not wait for the full picture before making that call.
2. Assess What Was Accessed
Once the immediate threat is contained, the focus shifts to understanding which data may have been exposed. In a dental organization, that typically means:
Patient protected health information (PHI)
Payment and billing data
Staff records and credentials
Document everything as you go: which systems were affected, over what timeframe, and what data those systems held. This record will matter for every conversation that follows, with legal counsel, regulators, and patients.
If you do not have internal forensic capability, bring in a third-party firm. Conducting your own forensics while simultaneously managing operations and communications is extremely difficult, and gaps in that process create liability.
3. Start the HIPAA Clock
This is the step where I see the most hesitation, and it is also where delay causes the most downstream damage.
HIPAA's Breach Notification Rule carries real deadlines and real consequences for missing them. Engage legal counsel with HIPAA experience as early as possible, even before you have complete information about what happened. Counsel can guide you through the breach risk assessment process and help determine what notifications are legally required and when.
The organizations that struggle most with this step are those that treat legal engagement as something to do only after they have all the answers. You will not have all the answers in 72 hours. Start anyway.
4. Talk to Your Team Before the Rumors Do
Your staff will hear about this, making it important that they hear it from you first.
Brief your leadership team and frontline staff with whatever you can share at that moment. You do not need every answer, but you do need to be honest about what you know, what you are still working to understand, and what steps are being taken. Silence from leadership in a crisis fuels speculation, which spreads faster than facts.
Practically, your front desk staff and practice managers will start fielding patient questions quickly. Give them clear, simple language before that happens, not after.
5. Keep the Practice Running in Parallel
Even in the middle of an incident, clinical care has to continue. This is where the advance work either pays off or it doesn't. Every organization should be able to answer a few basic questions before a breach ever happens:
Which systems are essential to scheduling, records access, and billing?
What is the manual or degraded-mode workflow if those systems go down?
Who is authorized to make real-time decisions about system access and recovery?
One of the principles I come back to constantly in how we build and maintain systems is this: if one component fails, you isolate it and keep everything else running. That same thinking applies to how an organization responds to an incident. The breach is one component of the operation. Patient care, staff communication, and financial continuity are others. The goal is to keep those running while you address what went wrong.
Build the Plan Before You Need It
The DSO leaders I've had the most candid conversations with are remarkably self-aware about where the gaps were. The consistent insight I hear is that having a documented response plan before an incident isn't about predicting failure, but about respecting the organization enough to be prepared for uncertainty. The best operators already know this. They're not looking for a wake-up call; they're looking for the right partner to help them execute and answer the questions that become urgent at the worst possible moment:
Who makes decisions, and who is the backup if that person is unavailable?
Who gets notified, and in what order?
Where are the insurance, legal, and forensic contacts?
Which systems are critical, and what are the workarounds if they go down?
There is real value in removing the unknown before you are under pressure. You may not be able to eliminate every risk. But you can eliminate a lot of the uncertainty around how you will respond. That preparation is what separates a difficult few weeks from a much longer and more damaging recovery.
Figures and Images
Mike Gibson
