Compliance
Why DSO and multi-location dental groups inherit the worst cybersecurity posture of their weakest practice — and the 4-quarter program that fixes it without slowing down acquisitions.
A dental service organization inherits the worst cybersecurity posture of its weakest practice. That is the sentence I open every DSO conversation with, and most of the leadership team has already nodded by the time I finish saying it. They have seen the acquired single-location office with shared FrontDesk credentials, the port-forwarded RDP into the front-desk PC, the USB drive that someone swaps out on Fridays for backup, and the practice's "IT guy" who is also the owner's brother-in-law. They just have not had a clean way to talk about how that one office becomes the breach path for the entire group.
This article is the framework I use with DSO leadership. It assumes you are growing through acquisition, cannot pause the deal pipeline to fix security, and need a program that runs alongside M&A rather than blocking it.
Attackers do not target the polished corporate office or the consolidated cloud PMS. They target the recently acquired solo practice that has not been integrated yet — likely running an unpatched on-premise PMS server, with a shared front-desk Windows login and a local MSP whose admin credentials are cached on a workstation. They also know that once they are inside, the parent group has often already established a trust path — a VPN, a domain trust, a shared file server, or shared M365 admin accounts — that lets them move laterally to every other location.
The pattern scales with acquisition velocity. A group adding four practices a year is creating four new attack surfaces a year, each of which has to be brought to the parent's baseline before a real adversary finds them.
Before we talk about fixing the problem, you have to know which architecture you are starting from. Almost every multi-location dental group I work with falls into one of three buckets.
In this model, every acquired location keeps its existing MSP, its existing PMS server, its existing network gear, and often its existing email tenant. The parent organization has finance and HR centralization, but technology is still local. The PMS server in practice number seven looks nothing like the PMS server in practice number eleven. Some have working backups. Some do not. The MSP relationships range from excellent to non-existent.
This model is cheap to acquire — you do not pay integration costs — but expensive to defend. You have no standard image, no central identity, no consistent endpoint coverage, and no way to answer the question "are all our offices patched?" without calling each MSP individually.
In this model, one MSP services every location, usually with a shared Remote Monitoring and Management platform. There is a single help-desk phone number, a single ticket queue, and a single set of admin credentials that work across the group.
The shared RMM is the security story and the security problem in one sentence. It gives you consistency, which is good. It also gives an attacker who compromises that RMM credential a one-stop lateral-movement path into every practice the MSP touches. The MSP-supply-chain compromise pattern is well-documented across the industry — when the management plane is shared, the blast radius is the entire customer base. Hub-and-spoke is better than decentralized, but it concentrates risk rather than eliminating it.
In this model, the PMS is cloud-hosted — Denticon, Curve, Dentrix Ascend, or similar — every workstation is joined to Microsoft Entra ID, every endpoint runs the same managed image, and identity, email, and file storage all live in one consolidated tenant. There is one network template, one wireless policy, one endpoint detection deployment, and one set of admin accounts.
This is the highest upfront cost and, by a wide margin, the most defensible posture. Acquisitions get migrated to the standard, not absorbed as-is. It is where most growing DSOs end up by the time they cross fifteen to twenty-five locations.
Most DSOs cannot jump from architecture A or B to architecture C in a single project. They need a sequenced program that fits inside one fiscal year, runs alongside acquisitions, and produces evidence the board can see. Here is the version we deliver.
You cannot defend what you cannot count. Quarter one is inventory: every endpoint, every PMS instance, every domain, every M365 or Google tenant, every cloud account, every line-of-business application, every BAA, every MSP relationship.
Most DSOs cannot tell me how many M365 tenants they have. The honest answer is usually somewhere between four and twelve, accumulated through acquisitions where nobody collapsed the seller's tenant after the deal. Discovery surfaces this and lets you make a real plan rather than a hopeful one.
Identity is where attackers actually win, so identity is where consolidation has to start. Quarter two collapses multiple M365 or Google tenants into a target tenant — or accepts a small number of tenants with an explicit governance plan and central detection. We centralize IT-admin accounts into a tiered model, enforce MFA everywhere with no exceptions, and deploy Managed ITDR across the consolidated identity layer so an Entra ID compromise is detected the moment it happens rather than thirty days later.
Quarter three puts Managed MDR on every endpoint and every PMS server across every location. We standardize the backup architecture so every site has the same immutable, tested backup pattern — not seven different MSPs running seven different products with seven different test cadences. We roll out a chain-wide security awareness training program so the dental assistant in practice number nineteen sees the same phishing simulations as the front desk at headquarters. And we standardize remote access through Entra ID Conditional Access or a single SASE solution, retiring port-forwarded RDP and per-site VPNs.
Quarter four turns the controls into evidence. We produce a HIPAA risk analysis per covered-entity location, a group-level incident response plan, a tabletop exercise with the executive team, a cyber insurance renewal package, and a complete BAA inventory across every vendor that touches PHI for any location in the group. By the end of Q4, the DSO has a defensible posture, board-level documentation, and an insurance application that does not require apologies.
The cheapest moment to fix a practice's security is before you own it. Whatever you do not negotiate into the LOI and SPA, you will pay for after close. The minimum cyber diligence list I recommend for every dental acquisition:
A seller who cannot produce these is not necessarily a bad acquisition. They are a more expensive acquisition. Price the remediation into the deal or walk.
More damage gets done in the first ninety days after a dental acquisition than in any other period. The patterns that hurt groups most:
Treat every acquired environment as untrusted until proven otherwise. The forensic posture is unfashionable but right: you do not know what you bought until you have looked.
This is the question every DSO leadership team eventually has to answer: do we migrate every location to one practice management system, or do we accept a heterogeneous environment?
Standardization is better for security, reporting, analytics, training, and acquisition speed. A heterogeneous environment is cheaper to inherit but expensive to operate — every reporting question becomes a custom integration, every security control has to be retested per platform, and your training program multiplies.
The honest cost picture: PMS migrations run roughly $25,000 to $75,000 per location depending on data volume, custom workflows, and integration count, and they take six to twelve months per location. Most growing DSOs run heterogeneous until they cross fifteen to twenty-five locations, then standardize — usually on a cloud platform like Denticon or Curve — because the operational drag of running four PMS products simultaneously exceeds the migration cost. There is no single right answer. There is only a clear-eyed conversation about when standardization pays for itself.
Should a DSO build a NOC or SOC internally or outsource it? This is one of the most important strategic decisions in the security program, and the answer is mostly a function of scale.
The mistake to avoid is the in-between version: a single internal "security person" carrying a pager 24/7. That role does not survive contact with reality, and the person you hire into it does not stay.
Each dental location is typically its own covered entity. That means each location needs its own Notice of Privacy Practices, its own risk analysis, its own breach notification readiness, and its own BAAs with vendors that touch its PHI. The group can centralize the program — one risk-analysis methodology, one IR plan, one BAA template, one training curriculum — but the legal responsibility lives at the entity.
There is a useful construct here called an Organized Health Care Arrangement, or OHCA, which lets clinically integrated covered entities share PHI for joint operations and present a joint Notice of Privacy Practices. It does not eliminate per-entity obligations, but it simplifies some of them and clarifies how shared services across a group can operate without creating disclosure problems. Whether OHCA fits a given group depends on the operating model, and the determination should be made with healthcare counsel, not assumed.
The most expensive insurance mistake I see in DSOs is buying a group cyber policy that names only the parent management entity. When the breach happens at a subsidiary practice — which is where breaches actually happen — the carrier scopes coverage to the named insured and disclaims the subsidiary loss. The fix is unglamorous: confirm in writing that every covered-entity location is a named insured on the policy.
Sublimits matter as well. A single ransomware event in a DSO can hit eight or ten locations simultaneously. A group policy with a small per-event business interruption sublimit can be exhausted before the second location has even called the help desk. Read the sublimits, model a multi-site event, and renegotiate at renewal if the math does not work.
We run the Huntress Managed MDR, ITDR, and SAT program for the entire group from one console with per-location reporting. Per-entity HIPAA evidence, group-level incident response, quarterly executive briefing for the DSO leadership, and a single point of accountability for the detection-and-response function across every location.
We are not an MSP. We do not compete with the IT firm that handles help desk, Wi-Fi, imaging, or PMS support. We sit alongside that team and own the security operations function so the IT firm can focus on uptime and the leadership team can focus on growth.
If you are leading a multi-location dental group or DSO and you want to see what a consolidated security posture looks like specifically for your architecture and your acquisition pipeline, book a private executive briefing. Bring your COO, your CFO, and your director of operations. We will walk through your current state, your acquisition diligence, and a sequenced program your board can read in one sitting.
Last updated
May 14, 2026. We refresh this content as the threat landscape and tools evolve.
FAQ
At minimum: confirmation of MFA on M365 or Google, a 24-month breach history disclosure, evidence of active EDR or MDR coverage on every endpoint, backup test evidence from the last 90 days, a HIPAA risk analysis on file from the last 12 months, a complete BAA inventory, and reps and warranties on undisclosed breaches in the SPA. If a seller cannot produce these, assume the worst and price the remediation into the deal.
Standardization is better for security, reporting, and analytics — but PMS migrations cost roughly twenty-five to seventy-five thousand dollars per location and take six to twelve months. Most growing groups run heterogeneous until they hit fifteen to twenty-five locations and then standardize, often on a cloud platform like Denticon or Curve. There is no single right answer, only a clear-eyed cost-benefit conversation.
The end state most DSOs need is one identity tenant — usually Microsoft Entra ID — with MFA enforced everywhere and a clear admin tier separation. Getting there often means collapsing four to twelve M365 tenants accumulated through acquisitions. If full consolidation is not feasible, you can run multiple tenants with a documented governance model, but you must centralize admin accounts and detection coverage either way.
Each location is typically its own covered entity, which means each needs its own Notice of Privacy Practices, risk analysis, breach notification readiness, and BAAs. The group can centralize the program, the documentation, and the controls, but the legal responsibility lives at the entity. The Organized Health Care Arrangement construct can simplify some of this for groups that meet the criteria.
Below thirty locations, outsource — building a 24/7 internal security operation is hard to staff and harder to retain. Between thirty and one hundred locations, most groups land in a hybrid model with an internal IT or security director plus an outsourced 24/7 SOC. Above one hundred locations, you typically need a dedicated CISO and either a fully internal SOC or a co-managed arrangement.
The most common error is buying a group policy that names only the parent entity, leaving subsidiary locations technically uninsured for a HIPAA event at that practice. Confirm every covered-entity location is a named insured. Also pay attention to group sublimits — one ransomware event can hit multiple locations simultaneously and exhaust the policy faster than a single-site practice ever would.
Day one network connection. Plugging a newly acquired practice's unhardened network into the parent network, or establishing trust between domains before forensic review, has caused more incidents than any other single action. Treat every acquired environment as untrusted until it has been inventoried, scanned, and brought to baseline.
We are not an MSP and do not compete with the IT firm that handles help desk, Wi-Fi, and PMS support. We run the Huntress Managed MDR, ITDR, and SAT program for the entire group from one console with per-location reporting, plus a quarterly executive briefing for DSO leadership and per-entity HIPAA evidence.
Related reading
What dental cyber insurance actually covers in 2026, the underwriting questionnaire controls that move premiums, and how to pass the application without overspending.
Read articleWhat the HIPAA Security Rule actually requires of dental practices in 2026 — risk analysis, administrative safeguards, MFA, encryption, breach response, and where most practices get it wrong.
Read articleA practical guide to SOC 2 readiness for small businesses, including what founders should do first, what to avoid, and how to prepare without wasting money.
Read article