Data Breach Response Plan for Dental Practices

A breach rarely announces itself. It shows up on an ordinary morning. Someone cannot open a chart, a file has a strange extension, or a patient calls asking why they received a notice from a credit bureau.

What happens in the next few hours shapes three things: whether you can prove what was taken, whether your insurance responds, and how many patients you end up notifying. A data breach response plan for a dental practice is not a compliance binder you produce for an auditor later. It is a short, ordered set of decisions your team can execute while the schedule is full and the phone is ringing. The practices that come through these well are not usually the ones with the best technology. They are the ones who decided who calls whom before it happened.

This is the playbook. For the notification deadlines that follow it, we have written those up separately in our guide to HIPAA breach notification for dental practices, because the clocks deserve their own treatment.

Before Anything Else: Do Not Clean It Up

The most costly instinct in the first hour is the urge to fix it. Reimage the workstation. Delete the suspicious email. Restore from last night’s backup and get the schedule moving again.

Each of those can overwrite the evidence you will need. The Federal Trade Commission is direct about this in its breach response guidance for business: do not destroy any forensic evidence in the course of your investigation and remediation. Without that evidence, nobody can tell you what was taken. Investigators can sometimes reconstruct a picture from other systems, but the narrower your evidence, the wider the population you may have to treat as affected.

There is a second reason, and it is the one that catches practices off guard. Cyber policies commonly attach conditions to response costs you run up before the carrier knows about the incident, which is one of several places where what your cyber policy actually says matters more than what it costs. More on that below, because the detail is where practices lose money.

Isolate, do not erase. Unplug the network cable or disable the wireless adapter. Leave the machine running. Leave the email in the mailbox.

The Call Order That Protects the Claim

Here is the distinction that matters, and most breach-response advice blurs it. There is a difference between calling someone and retaining them. Containment by the IT provider you already work with should start immediately. What should wait for your carrier is the moment you retain anyone new or start spending real money: outside forensics, breach counsel, a remediation firm.

That is where coverage is actually won or lost, and it is genuinely policy-specific. Many cyber policies attach conditions to response costs you incur before the carrier is involved, which is the reason the call goes out early. Others are more permissive than practices assume: Chubb, for one, states plainly that a policyholder “is under no obligation to contract for services with any of the Chubb pre-approved incident response or loss mitigation service providers” and that choosing among them “is the independent choice of the policyholder.” You cannot know which description fits your policy in the middle of an incident, which is the argument for reading it this quarter and for making the carrier call early. It is not an argument for hesitating to phone your own MSP.

So think in four tracks rather than one phone queue. The first two run at the same time, in the first minutes.

Track	Who	When	Have ready
Activate	Incident lead, owner or DSO leadership	Immediately. Often the person already on the phone. Authorizes downtime procedures and spending.	Who is affected, what stopped working
Contain	Your existing IT provider or MSP	Immediately, in parallel. Isolate without destroying evidence.	Which machines, which locations
Notify	Cyber carrier breach hotline	Same hour, and before you retain anyone new or authorize spend.	Policy number, what you observed, time discovered
Engage	Breach counsel and forensics	After the carrier call, usually coordinated through it.	The incident log you started at minute one

Containment never waits on a phone tree. Anything actively spreading, whether that is ransomware encrypting files, an administrator account you do not recognize, or remote access you cannot account for, gets isolated while the other calls are still being made.

Law enforcement is a separate track that runs alongside rather than inside this one. CISA’s StopRansomware guidance tells victims to report the incident to, and consider requesting assistance from, CISA, a local FBI field office, the FBI Internet Crime Complaint Center or the Secret Service, and the federal assistance that follows is furnished on a voluntary request. Keep it separate in your mind from HIPAA notification, which is not optional and which reporting to the FBI does not satisfy. One wrinkle worth knowing: if a law enforcement official tells you that notifying would impede a criminal investigation, the rule lets you delay, but only for a period the official specifies, and an oral request buys no more than 30 days unless it is put in writing. Get that instruction documented, including who gave it, because a delay you cannot evidence is just a missed deadline. For a sense of how fast all of this compresses in a live attack, we walked through a dental ransomware attack hour by hour separately.

What Each Track Actually Involves

1. Name one person to run it

One incident lead. Usually the owner, the office manager, or at a group, whoever holds the compliance function. Their job is not technical. It is to make decisions and keep the log. Without a named lead, five people each do a piece of the response and nobody can reconstruct what happened.

2. Start the log at minute one

This is the step practices skip, and it is the one that pays for itself. Write down the date and time of discovery, who found it, what they saw, what systems are involved, and every action taken with a timestamp and a name.

It matters for a specific reason. HIPAA’s breach clock does not start when you finish investigating. It starts on discovery, and the standard is what you knew or, by exercising reasonable diligence, would have known. A contemporaneous log is what demonstrates diligence. A reconstruction written three weeks later, from memory, does not.

3. Contain without destroying

Disconnect affected machines from the network and leave them powered on. Disable compromised accounts rather than deleting them. Revoke suspicious remote access. Preserve firewall, VPN, email, server and practice-management logs before anything rotates them out, because many of those roll off on a fixed window and the evidence quietly ages out while you are busy.

4. Keep the practice running on paper

Patients are still in the chair. Move to downtime procedures: paper charts, manual check-in, a clean device on a separate connection for anything urgent. Do not send patient information from an account that may be compromised, and do not use the affected system to coordinate the response to the affected system.

5. Decide whether it is actually a breach

Not every security incident is a breach. Under the HIPAA Breach Notification Rule, an impermissible use or disclosure is presumed to be a breach unless you can demonstrate a low probability that the information was compromised, based on a risk assessment covering at least four factors: the nature and extent of the information involved, who used it or received it, whether it was actually acquired or viewed, and the extent to which the risk has been mitigated.

Read that presumption carefully, because it runs against instinct. Where an impermissible use or disclosure of unsecured patient information has occurred, the default answer is breach. The burden is on the practice to document why it is not, and “we think it was fine” is not a risk assessment. Worth keeping straight: this breach risk assessment is a different obligation from the security risk analysis that shows up in nearly every OCR settlement. You need both, and practices routinely believe that having done one covers the other. The security risk analysis is the failure OCR cites most often in its largest settlements, which you can see across every dental practice it has penalized.

6. Tell your team what not to do

Give the staff a script the same morning. Route every question to one person. Do not speculate with patients, do not post about it, do not discuss it with vendors who are not part of the response, and do not delete anything. One well-meant Facebook reply from the front desk can create a second, separate disclosure problem on top of the first.

What This Looks Like Across Multiple Locations

At one practice, the response is a phone tree. At twelve, it is an operational decision under time pressure, and the questions get harder fast.

Does an incident at one office mean you isolate the other eleven? That depends on the compromise path and on how the sites are actually connected, which is why the useful thing to settle in advance is not the answer but the authority: who is allowed to make that call at seven in the morning, and on what evidence. If the locations share a domain, an identity provider, or a flat network, the blast radius question is real. If they are genuinely segmented, you may be able to keep eleven offices producing while one is contained. Either way, that answer is set by architecture decided long before the incident.

The version of this that hurts most is the acquired practice, and it is the most common one we walk into. A group buys an office and keeps the seller’s old MSP through a transition period that quietly becomes permanent. Nobody ever maps the network, because it was always going to be dealt with next quarter.

Then something happens at that location, and the response stalls on questions nobody in the room can answer. Who has domain admin. Where the logs live and how far back they go. Whether the backup that appears in a monthly report is covering that server or a server that was decommissioned two years ago. Whether that office’s front desk shares credentials with the office next door.

None of those are incident questions. They are diligence questions that went unanswered at close, and the incident is simply when the bill arrives. Standardization is not about control, it is about what you can actually do at seven in the morning, and this is one of the moments that shows up or does not. For the broader recovery sequence once containment holds, our IT disaster recovery plan guide covers what comes next.

The Five Things to Decide Before It Happens

A response plan is only useful if the decisions are already made. These five are the ones we see practices scrambling on, every time:

• Who is the incident lead, and who is the backup when that person is on vacation.
• Where the cyber policy number lives, and the breach hotline, somewhere reachable when the network is down. A phone photo counts. A file on the affected server does not.
• What your policy actually conditions, specifically whether it requires consent before you retain outside vendors, confirmed in advance.
• Whether your locations are actually segmented, tested rather than assumed.
• How long your logs are retained, because a thirty-day window means the earliest activity in a months-long intrusion may already have aged out.

The first three cost nothing but a decision and a piece of paper. The last two may need real configuration work, which is exactly why they are worth handling this quarter rather than during an incident. If you want a second set of eyes on where your group stands, a cyber assessment is the usual starting point, and in our experience the log-retention and segmentation gaps are typically the first things it turns up.

Tom’s Take

What I have seen is that the practices that handle this well are rarely the ones with the most security tooling. They are the ones where somebody wrote down who to call, and the team believed the plan enough to follow it at seven in the morning with a full schedule.

The part that still surprises people is how much of the response is decided by paperwork nobody read. The policy language, the log retention setting, the network diagram that was never updated after the last acquisition. By the time the incident starts, those answers are already fixed. All you get to choose is whether you knew them beforehand.

Dental Data Breach Response FAQs

Who should a dental practice call first after a data breach?

Containment and the carrier call happen in the same first minutes: have your existing IT provider isolate what is spreading while someone else calls the breach hotline. The sequencing that matters is not who you dial first, it is that you notify the carrier before retaining anyone new or authorizing spend, because that is the point most policies attach conditions to. If your practice has no cyber policy, the order collapses to containment, then counsel, and you should expect to fund the response yourself.

What should you not do after a data breach?

The ransom decision is the one to flag here, because it is the one most often made under pressure at seven in the morning and the hardest to walk back. It belongs to your carrier and counsel, not to the practice alone. The FBI’s position is that paying does not guarantee you get your data back, and it is worth being clear-eyed about a second point: a payment buys a promise from the people who just attacked you, so data already copied out of your network is out of your control either way. Beyond that: do not reimage, do not delete, and do not restore from backup before forensics has what it needs.

Is every security incident a data breach?

No. A failed login attempt, a blocked phishing email, or malware caught before it touched patient data is an incident, not a breach. The rule only engages once there has been an impermissible use or disclosure of unsecured patient information, and at that point the presumption flips against you. The practical consequence is that incidents still need documenting even when they are clearly not breaches, because the record of what you assessed and dismissed is part of what demonstrates diligence later.

When does the notification clock actually start?

On discovery, not on the day your investigation concludes. That is the part practices get wrong, and it is why the log matters more than it looks: the standard is what you knew or, exercising reasonable diligence, would have known, so a contemporaneous record is what fixes the start date. The deadlines that run from it, including the separate rules for HHS and media notice, are covered in full in our guide to HIPAA breach notification deadlines for dental practices.

Do we need a written breach response plan if we are a single location?

Yes. The plan is what makes the first hour executable when the person who normally handles technology is unreachable. Note the distinction: HIPAA requires covered entities to maintain and follow written policies and procedures, which is a broader obligation than any single named document. A practice that can produce both those policies and a contemporaneous incident log is in a materially different position than one relying on recollection.

Posted in Dental Cybersecurity