Your IT Company Is Not Your Security Team: What Dental Practices Actually Need

The practice runs on the schedule. When the practice-management server stops responding at 7:15 a.m. and the first hygiene appointment is at 8:00, the day does not compress — it collapses.

That single operational fact reshapes the entire question of what a dental IT firm covers versus what a security operation covers, because the failure mode for the practice is not a slow ticket queue. It is an empty schedule, a lobby of confused patients, and a doctor billing zero for the day.

Everything below sits inside that frame. The point is not that a dental IT firm is bad at its job. Most are excellent at the layer that keeps Dentrix, Eaglesoft, or Open Dental running, the imaging chain producing images, and the front desk on the phone.

The point is that the layer they run and the layer that keeps the schedule intact under attack are two different disciplines with two different sets of hours.

Downtime is revenue: the practice-management server as the whole business

A dental practice is a chair-hour business. A ten-operatory office with an average producing rate of $600 per operatory hour loses roughly $6,000 per hour of unavailable schedule.

Two days of a hard PMS outage is meaningful five-figure revenue plus the reputational cost of rescheduled patients and the operational cost of pulling paper charts (if they exist) or reconstructing the day by memory (if they do not).

That number changes how a practice should think about the difference between IT support and security operations. IT support is optimized for the eight-hour recovery of a slow workstation. A security operation is optimized so that the PMS server does not become the reason two days of the schedule disappears.

Both are legitimate and both matter. Confusing one for the other is what leaves the practice exposed on the day it costs the most.

What a dental IT firm was built to keep working

The good dental IT firms handle the layer that keeps the practice moving:

• The Dentrix, Eaglesoft, or Open Dental service pack that lands on a scheduled maintenance evening, along with the ancillary charge-slip printer that decided to renegotiate its network settings after the reboot.
• Imaging chain operations — the intraoral sensor driver that fell off after a Windows update, the 3D CBCT workstation that stopped talking to the PACS, the pan/ceph unit that needed a firmware push after the vendor visit.
• Hardware and workstation lifecycle — the operatory PCs that get sneezed on, the front-desk twin-monitor setup, the doctor's laptop that follows them between locations.
• Nightly backups of the PMS database, offsite rotation, the annual verification the IT firm does on the restore.
• Microsoft 365 or Google Workspace administration for the office manager, hygienist, and doctor mailboxes, and the shared inboxes for insurance verification and patient scheduling.
• Wi-Fi separation between the operatory subnet and the guest network, the perimeter firewall, the small on-prem file server that some Dentrix deployments still rely on.
• Vendor coordination with the imaging vendor, the PMS vendor's implementation team, the phone-system provider, the ISP.

None of that reads as security operations, and none of it should be asked to be. It is the layer the practice cannot function without on ordinary days. A security operation is what the practice cannot function without on the day someone is actively attacking it.

The three failure patterns that empty a dental schedule

The concrete incidents that pull the schedule apart share a pattern: the tool worked, the alert fired, nobody was watching it.

PMS server ransomware, staged from Tuesday, detonated Friday. The initial phish lands on an operatory workstation. The endpoint agent logs suspicious script activity into the IT firm's ticket queue. Nobody is on-call.

The intruder moves laterally through weak service-account credentials, encrypts the PMS database and the imaging archive over the weekend.

Monday morning, the front desk cannot look up an appointment, verify insurance, or produce a treatment plan. The recovery-without-preparation window is five to twenty-one days.

Imaging system compromise via an unpatched vendor console. Intraoral, panoramic, and CBCT capture stations often run on vendor-supplied Windows builds that have not been updated since the equipment was installed.

The vendor did the installation, wrote "do not update — will break integration" in an email, and left. An unpatched console with SMB exposed to the operatory LAN becomes the lateral-movement launch point.

The imaging chain is where a Security Rule risk analysis is supposed to look and rarely does.

BEC targeting the office manager's mailbox on payment day. An adversary-in-the-middle phishing kit captures the session token and defeats MFA. An inbox rule quietly routes anything containing the word "payment" or the vendor's name into a hidden folder.

The attacker replies from inside the thread with updated ACH instructions on the day the practice pays its lab bill or supply invoice. The five-figure loss is not the worst part; the mailbox now contains attachments with ePHI, and the disclosure obligation is the second act.

Each of these is stopped or bounded by the same thing: when the alert fires at 3 a.m. on a Saturday, somebody is actually watching it and able to contain the endpoint, instead of it sitting in a queue until the practice reopens.

The Security Rule is not the same as a running security operation

HIPAA is often shorthand for "we handle this" when in fact the Security Rule (45 CFR § 164.308 and § 164.312) is a set of principles-based obligations rather than a running service. It requires reasonable and appropriate administrative, physical, and technical safeguards.

It names audit controls, security incident procedures, and risk analysis by function. It does not name a product, does not name a monitoring cadence, and does not say who has to be awake at 2 a.m. That is the practice's decision to make.

The Breach Notification Rule (§ 164.404, § 164.406, and § 164.408) does prescribe something specific: for a breach of unsecured PHI, the practice must:

• Notify affected individuals without unreasonable delay and no later than sixty calendar days after discovery
• Notify HHS on that same clock for events affecting 500 or more individuals
• Notify prominent media in the state or jurisdiction on the same clock at that threshold

That obligation is triggered on the day of the incident and starts running before the practice knows the extent. Whether the extent is small or large depends heavily on whether someone was watching the endpoint and identity layers when the compromise began.

For a dental practice, satisfying the Security Rule as a documented reality — rather than as an unexamined assumption — is the reason to distinguish IT support from operated security in the first place.

The BAA the industry forgets is the one for the IT firm itself

A Business Associate under HIPAA is a person or entity that performs services on behalf of a covered entity involving the use or disclosure of protected health information. A managed-services IT firm with remote access to the PMS server, the imaging workstations, or Microsoft 365 mailboxes that touch chart data almost always meets that definition.

The signed BAA is not optional. It is the contractual instrument HIPAA § 164.502(e) requires and the artifact an OCR complaint investigator will ask for on the first request.

Two adjacent things matter here. First, the BAA needs the required contractual safeguards, breach-notification obligations back to the practice, and permitted-use limits — not a marketing paragraph that mentions HIPAA.

Second, a signed BAA is not a substitute for the IT firm actually operating the safeguards it obligates itself to. It is the paper. The operation is separate.

What a security operation covers, specifically for a practice

A security operation for a dental environment covers a distinct list, and the specifics matter:

• Managed detection and response running on every operatory workstation, every laptop, and the practice-management server itself — including whichever Windows Server generation is on the wall now. EDR on the workstations without EDR on the PMS server is not coverage of the PMS server.

• Identity threat detection on the Microsoft 365 or Google Workspace tenant — session-token replay, malicious inbox rules, OAuth consent, impossible-travel, MFA-fatigue — separate from the spam filter.

• Awareness training tuned to the actual dental attack surface: payment-redirect drills for the office manager, ePHI-handling refreshers for the front desk, imaging-vendor impersonation scenarios for the doctor.

• Incident-response coordination with the Breach Notification Rule clock in mind: forensics, the affected-individual notice, the HHS notification for 500+, the state AG timelines, the cyber-insurance claim.

• A HIPAA evidence packet built continuously: audit-control logs, MFA coverage across all mailboxes and the PMS admin, encryption-in-transit confirmation, training records, restore-test logs, the signed BAA inventory.

• For a DSO or a multi-location group: an identity story that survives multi-tenant sprawl.

  Practices consolidated from independent purchases arrive with three or four M365 tenants, a handful of legacy G Suite accounts, and no central identity view. Extending EDR without extending identity coverage across all of them leaves the entry the group is most likely to be attacked through.

None of the above is what a general IT firm was built to run. It is what a security operation runs alongside them.

What "the IT firm already covers this" looks like when it is true

A minority of dental IT firms have genuinely stood up a security practice. Whether the one on retainer is that firm is a question that produces specific artifacts:

• Managed EDR they operate, not just resell, on every operatory workstation and on the PMS server, with a security operations center staffed around the clock.
• A signed Business Associate Agreement with the required Security Rule safeguard language, and evidence that the IT firm carries cyber insurance and errors-and-omissions coverage on its own operation.
• An MFA coverage export, an audit-control log sample from the last month, and identity-anomaly evidence from the last week, produced on the day of the request.
• A documented incident-response process specific to the practice, with a named after-hours escalation and a written procedure for the Breach Notification Rule sixty-day clock, including who at the practice makes the individual-notice decision and who drafts the letter.
• A restore-test log showing an actual restore of the PMS database and imaging archive within the last quarter, not a green backup dashboard.

Anything unclear is not an accusation. It is an unowned function that will be assigned to someone in the middle of an event.

Six questions to bring to the next dental vendor review

Practical, evidence-oriented, no room for the answer that describes intent instead of operation.

1. "Do you operate a security operations center reading our endpoint and identity alerts around the clock, and can you name the team?"
2. "If the PMS server begins encrypting Friday at 8 p.m., what happens automatically in the first ninety seconds, and what does a human do after that?"
3. "Under HIPAA, are you our Business Associate, and can we see the signed BAA and evidence that you operate the safeguards it obligates you to?"
4. "Can you produce today the audit-control logs, MFA coverage across our mailboxes and PMS admin, and identity-anomaly evidence a cyber-insurance carrier or an OCR investigator would ask for?"
5. "Do you monitor our Microsoft 365 or Google Workspace tenant for identity-layer attacks — token replay, adversary-in-the-middle sign-ins, malicious inbox rules — separately from spam filtering, and can you show a report from last week?"
6. "When was the last time you performed and documented a restore test of the PMS database and the imaging archive?"

Any hesitant answer is an owned-by-nobody function to hand to someone on a defined date.

When downtime is minutes instead of days: the co-managed model

The single-vendor mental default is the shape a practice accretes when it grows one hire at a time. It is not the shape that keeps the schedule intact when someone actively tries to take the practice offline.

The co-managed shape splits the two functions to the specialists that operate them.

The IT firm keeps the practice-management system, the imaging chain, and the front-desk technology working. The security operation runs detection, response, identity monitoring, awareness training, the HIPAA evidence packet, and the Breach Notification Rule coordination.

When an incident touches both layers, the two coordinate. Total spend is closer than owners expect to a single generalist charging for equivalent depth, because each specialist runs its own layer more efficiently.

What Obsidian Ridge operates for dental practices and DSOs

We are a CISSP-led managed security practice. We do not replace the dental IT firm — we operate the security layer next to them.

The program is managed detection and response, identity threat detection, and security awareness training with the HIPAA evidence package, DSO-scale identity coverage, and cyber-insurance readiness attached.

The vertical deep dive lives on the dental cybersecurity page.

If the pressure point is a cyber-insurance renewal or a patient-data incident on the calendar, the Cyber Insurance Readiness Sprint is the fixed-scope engagement — from $1,500, delivered in seven business days — that turns the questionnaire into a paperwork step.

Next step

If this article named a gap the practice already suspected, the practical starting move is either the free carrier questionnaire to score the practice before an underwriter does, or the Readiness Sprint if a renewal or a post-incident cleanup is already on the calendar.

For the broader tool-and-service-model taxonomy, the MDR vs EDR vs MSSP vs SOC-as-a-service decision tree is the buyer-side companion piece.