In Defense of the Dental IT Guy (And Why He Might Sink Your Practice)

Every dental technology conversation eventually reaches the same silence. Somebody asks what happens if the one person who understands all of this is unavailable, and the room moves on.

I was the IT guy.

Not metaphorically. Literally. Most of dentistry still runs on one person, and if your practice depends on a single dental IT guy, you are carrying a business risk that has never appeared on a budget line, been priced into a valuation, or been tested before the morning it matters.

I drove the car with the trunk full of patch cables. I knew which operatory had the flaky wall jack. I once brought a server back from the dead in a supply closet that shared a wall with the sterilizer, at 6:40 in the morning, so the 7:00 hygiene column would not blow up. When a doctor called my cell on a Sunday, I answered, because that is what you do.

I built that into a company with more than 60 employees and dedicated teams for security, compliance, networking, applications, and project work. The single most uncomfortable thing I learned along the way is this:

I was very good at my job, and I was also a single point of failure for every practice that trusted me.

Both of those were true at the same time. Being smart did not fix it. Being available did not fix it. Being nice definitely did not fix it.

So before anyone accuses me of writing a hit piece on the IT guy, understand: this is a letter from a recovering one.

And yes, I now run a company that sells the alternative I am about to describe. You should weigh what follows accordingly. I would rather you read it skeptically than not read it at all, because the arithmetic underneath it does not care who is doing the math.

First, The Part Nobody Says Out Loud: The IT Guy Is Often Excellent

Let us give the man his flowers.

He shows up. Not “we have created a ticket and someone will contact you within one business day.” He shows up. Often in under an hour. Often on a Saturday.

He actually knows your practice. He knows Dr. Patel hates being remoted into during a crown prep. He knows the front desk printer needs to be power-cycled in a specific order or it prints everything in Wingdings. That institutional memory is real, and big vendors are famously bad at it.

He is cheap. Astonishingly so, usually. Frequently he undercharges to the point of self-harm.

He cares. This is the one people underestimate. The IT guy is usually emotionally invested in your practice in a way an account manager at a 500-person firm never will be. He takes it personally when your office goes down. That is not nothing.

None of that is fake. None of that is something to sneer at. Most IT guys are genuinely good at break-fix, and break-fix is genuinely valuable.

The problem is that break-fix is now a fraction of what a dental practice needs from technology. The rest is the part that quietly determines whether you still have a business in eighteen months.

The Math Problem: One Person Cannot Be In Two Operatories At Once

Here is the uncomfortable arithmetic.

An IT guy is one human being with, generously, 50 working hours a week. He has a family, a life, and occasionally a vacation. He supports somewhere between 15 and 60 practices, because that is what it takes to make the model work financially.

Now ask the question every practice owner should ask and almost none do:

What is your fault tolerance if he gets the flu?

Not “what if he quits.” What if he gets the flu. On a Tuesday. During open enrollment. When your practice management server decides to eat its own database.

For most single-IT-guy practices, the honest answer is that nothing happens until he is better. There is no second pair of hands. There is no documentation, because it is all in his head. There is no escalation path, because he is the escalation path. There is no after-hours coverage, because he is the after-hours coverage and he is currently unconscious on cold medicine.

Now scale that up. You have grown to three locations. Ransomware hits at 6:15 a.m. and it does not hit one office. It hits all three, because they share a VPN tunnel and a domain controller. One human being now has to triage three simultaneous emergencies in three different buildings.

He will pick one. He has to. Two of your offices are going to sit dark while he works the first.

This is not a competence problem. Superman has this problem. It is a physics problem.

And it gets worse than the flu, because the flu ends. What happens when your IT guy has a heart attack? Retires? Moves across the country? Takes a salaried job because his family wants health insurance and predictable weekends? Every one of those is a normal life event, and every one of those leaves you holding a network you have no passwords to, documented by no one, running software nobody wrote down the license keys for.

Software teams call this the “bus factor,” meaning how many people have to get hit by a bus before the project dies. Most dental practices have a bus factor of one, and they have never once thought about it.

For groups past a handful of locations, this is usually the moment the model breaks in public rather than in private. We covered what changes structurally in DSO IT support for multi-location groups.

The Knowledge Treadmill Nobody Can Outrun Alone

Here is where I have to be blunt, and where I am criticizing my own past self.

When I was the IT guy, my recommendations were shaped almost entirely by what I already knew how to support. That is not malice. That is bandwidth. If I had built forty local-server environments, my forty-first recommendation was going to be a local server, because I could deploy it in my sleep and I knew exactly what would break.

Was that the best answer for the practice? Increasingly, no.

The market has moved, though not as far as vendors like to claim. On-premises deployments still held 45.56% of dental practice management software revenue in 2025 according to Mordor Intelligence, which also forecasts cloud revenue surpassing on-premises before 2029. So cloud is not yet the majority, but the crossover is close enough that architecture chosen today will outlive the assumption behind it. Cloud is not automatically right for every practice either. If your internet is genuinely unreliable, a well-managed local environment still works. The problem is that a lot of IT guys are still recommending 2015’s architecture because that is the architecture they are fluent in, not because they weighed it.

Meanwhile, look at the volume of things a dental IT provider is now expected to be current on:

• Dentrix, Eaglesoft, Open Dental, Curve, Denticon, CareStack, plus their cloud variants
• Imaging platforms and sensor drivers that break on every Windows feature update
• CBCT storage, retention, and transfer
• Intraoral scanners and their cloud pipelines
• AI diagnostic tools and how they touch patient data
• Endpoint detection and response, tuned so it does not quarantine your imaging bridge
• Identity, conditional access, and phishing-resistant MFA
• Immutable, tested, off-site backups
• Business associate agreements with every vendor touching patient data
• Security risk analysis documentation that will survive an OCR investigation

That is not one person’s job. That is a department. Asking one generalist to be current on all of it is like asking your hygienist to also read your CBCTs, do your ortho cases, and handle your insurance appeals. She is smart. She is willing. That is not the point.

If you want to see the size of the surface area in one place, our IT checklist for dental practices lays out what should actually be inventoried and verified.

Meanwhile, Criminals Figured Out That Dentistry Is Soft

This is the part that has changed most since I was crawling under desks, and it has changed fast.

Attackers target dental practices because we are, economically speaking, an efficient victim. A single-doctor practice produces meaningful daily revenue that stops the moment the practice management system stops. You cannot pull a chart, submit a claim, or in many cases legally treat a patient. State boards require you to retain records for years, so you cannot simply walk away from the data. And there is almost never real IT staff.

The cost math is genuinely alarming. Healthcare remains the most expensive sector for a data breach, and IBM’s 2026 Cost of a Data Breach Report puts the US healthcare average at roughly $11.5 million. Recovery from a healthcare ransomware event is routinely measured in weeks of disrupted operations, not days.

Run your own numbers on three weeks of empty chairs while you still make payroll.

Now, and this is the important part, nearly all of that is preventable, and the prevention is boring. Tested, immutable, off-site backups turn a three-week shutdown into a same-day restore. MFA everywhere closes the single most common front door. Patch discipline closes the second. None of this is exotic. It is just relentless, and relentless is exactly what one overextended human cannot be across forty clients.

The backup half of that is worth its own read: dental data backup and disaster recovery covers what “tested” actually has to mean.

The Compliance Trap: The Job Changed From Fixing Things To Proving Things

Here is the shift that has genuinely blindsided the IT guy model.

HIPAA compliance used to be mostly about doing reasonable things. It is now about documenting that you did reasonable things, on a schedule, with evidence.

The HHS Office for Civil Rights launched a Risk Analysis Initiative in late 2024 aimed squarely at the security risk analysis requirement, and the same finding shows up in case after case: the organization failed to conduct an accurate and thorough risk analysis. That is the finding that writes the check. The breach just opens the envelope.

And being small is not a shield. OCR has pursued penalties against dental practices ranging from a few thousand dollars for a solo practitioner up into six figures.

Ask yourself, honestly. Does your IT guy currently maintain a written technology asset inventory and network map for your practice, reviewed annually? Does he run vulnerability scans and document the remediation? Could he produce evidence of continuous MFA enforcement if a federal investigator asked tomorrow?

If the answer is “he would probably put something together,” that is not a compliance program. That is a fire drill with a deadline.

Our HIPAA compliance checklist for dental practices covers what documentation actually has to exist before someone asks for it.

The Insurance Trapdoor

This is the one that keeps me up at night, and there are two separate problems inside it. Most practices are vaguely aware of the first and completely unaware of the second.

Problem one: your cyber policy may not actually pay

Cyber insurance applications are attestations. When you check “yes, we have MFA enforced on all accounts,” that becomes a continuing warranty, one your carrier can audit forensically after an incident, comparing what you attested against what was actually running when the attacker got in.

This is not hypothetical. In Travelers Property Casualty Company of America v. International Control Services, filed in the Central District of Illinois in 2022, Travelers sought to rescind a cyber policy entirely after discovering that MFA had only been partially deployed, despite the attestation. The parties stipulated within two months and the court entered judgment declaring the policy void from its inception. No court ruled on the merits, so it set no precedent. That is exactly why it is worth knowing: the insurer never needed a trial to take the policy off the table.

So who filled out that questionnaire for your practice? In most single-IT-guy arrangements, the doctor answered from memory, or the IT guy answered with optimism, and nobody produced evidence. That is an unfunded liability sitting quietly in a filing cabinet.

Problem two: your IT guy probably is not insured either

Technology Errors and Omissions coverage is what pays when an IT provider’s mistake, whether a failed backup, a misconfigured firewall, or inadequate monitoring, causes a client financial harm. Serious master service agreements typically require meaningful Tech E&O limits plus separate cyber liability. In my experience solo operators often carry very little, and some carry nothing at all, because it is a real line item against a thin margin.

Which means if your IT guy configures your backup wrong and it silently fails for eight months, and you lose your practice’s data, your recourse is a lawsuit against a sole proprietor with a truck and a laptop.

You cannot transfer risk to someone who has no capacity to absorb it. You just think you did.

While you are at it: do you have a signed business associate agreement with him? He touches patient data on every service call. If he does not have one, that is not his compliance gap. It is yours.

What To Do About It (And It Is Not “Fire Dave”)

I want to be careful here, because the wrong takeaway is to torch a relationship that has been good to you.

The right takeaway is that you have concentrated too much risk in one person, and that is a business decision you can fix.

Some options, roughly in order of how much they disrupt your life.

Test the bus factor

Not rhetorically. Actually run the drill. Next time your IT guy is on vacation, call the number he gave you for emergencies. See what happens. That is your real disaster response, and you should know what it looks like before you need it.

Ask the ten questions

Any provider worth keeping will answer these without getting defensive.

1. Who covers when you are unavailable, and what is their name?
2. Where is our documentation stored, and can we get a copy today?
3. When was our last restore test? Not a backup report, a restore. What did it say?
4. Do you carry Tech E&O and cyber liability? What limits? Can we see the certificate?
5. Do we have a signed business associate agreement on file?
6. Where is our written asset inventory and network map?
7. When was our last vulnerability scan, and what came back?
8. Is MFA enforced, not enabled, enforced, on every human account touching patient data, and how are service accounts controlled instead?
9. If all our locations went down simultaneously at 6 a.m., what happens in the first hour?
10. What did you recommend to us this year that you had to learn something new to recommend?

That last one is the tell. If no recommendation has been reassessed in five years, you are not being served. You are being maintained.

Split the roles

Keep the relationship for what it is genuinely good at, meaning hands-on, same-day, knows-your-practice support, and add specialized capability alongside it for security, compliance, and backup. Plenty of good IT guys are relieved to have that weight lifted. The ones who fight it are telling you something.

Or make the move

If you are at multiple locations, or growing toward them, the single-provider model is usually already straining and you just have not received the invoice yet. We wrote up how the models actually compare on cost in outsourced IT versus in-house versus break-fix.

The Thing I Wish Someone Had Told Me At 26

I loved being the IT guy. It was the most useful I have ever felt. There is a particular satisfaction in walking into a panicked office and walking out an hour later having made everything work again.

But the reason I built a team was not ambition. It was fear.

It was the slow realization that if something happened to me, a car accident, an illness, a bad week, dozens of practices would wake up to an infrastructure that only I understood, with no one to call. That the thing they valued most about me, that I was always there, was precisely the thing that made me dangerous to depend on.

Depth of relationship is not the same as depth of resources. Availability is not the same as redundancy.

Your IT guy is probably a good person doing his honest best with the hours he has. That is exactly the problem. His honest best has a hard ceiling, and the threat landscape stopped respecting that ceiling years ago.

You would not put your entire retirement in a single stock because you like the CEO. Do not put your entire practice on a single person because you like the guy.

Dental IT Guy FAQs

When should a dental practice switch from one IT guy to a managed provider?

The clearest triggers are an acquisition, a cyber-insurance renewal that asks for MFA and EDR attestations, or a restore test that fails. Location count matters less than people assume. A tightly run two-location group with documentation and a real backup can be fine, while a single practice with everything in one person’s head is already exposed. What actually forces the decision is the first event that requires two things to happen at once.

How do I get our documentation and passwords without blowing up the relationship?

Ask for it as routine business continuity rather than as an accusation, because that is what it is. A reasonable request is a current asset inventory, a network diagram, and credentials placed in a password manager your practice owns, not one his company owns. The distinction that matters is ownership of the vault. If the credentials live in a system you cannot access without him, you have documentation in name only.

What does an acceptable backup test actually look like?

A backup report saying “completed successfully” is not a test. An acceptable test restores real data to a separate environment, confirms the practice management database opens and the imaging attaches to the right patients, and produces a dated report naming who ran it and how long it took. That last number is the one to write down, because it is your actual downtime estimate.

Can we keep our current IT guy and still fix this?

Usually yes, and it is often the better outcome. The split that tends to work is leaving day-to-day and on-site support where it is, then adding a second party accountable for backup verification, security posture, and compliance documentation. The relationship survives, the single point of failure does not. Providers who are genuinely good at support are frequently relieved by this. The ones who resist it are answering a different question for you.

Can a cyber insurance claim be denied over MFA?

Yes, and the sharper risk is not denial of a single claim but rescission of the policy itself, which is a different and worse outcome. Denial disputes one incident. Rescission treats the policy as though it never existed. In Travelers v. International Control Services, the insurer pursued rescission after finding MFA had only been partially deployed, and the parties stipulated to a judgment voiding the policy from inception. No court ruled on the merits, so it set no precedent, but the exposure it illustrates is real. Your protection is evidence that the controls you attested to were actually running.

Posted in Dental Cybersecurity