What Multi-Location DSOs Get Wrong About Backup

Growing from one office to forty changes almost everything about how a dental group operates: scheduling, billing, hiring, compliance. Backup is the one system that usually does not change with it. Each location keeps doing what it did as an independent practice, and the result is a fleet of disconnected, unmonitored backups that look fine right up until the day one of them is tested by a real incident.

This matters more for a DSO than for a single practice because of scale. A breach at a solo office is a local emergency. A breach at a group practice can be an enterprise-wide event affecting every patient record the organization holds. Healthcare ransomware rose roughly 58% in 2025, with around 636 attacks recorded, and the dental and secondary-care segment accounted for about 26% of them . Recent dental breaches reached well over a million patients at a single organization — Absolute Dental in Nevada affected roughly 1.22 million people, and Chord Specialty Dental Partners around 173,000 — which is exactly the math a multi-site group should worry about.

Why does treating each office as its own backup project fail?

It fails because independence multiplies your weak points instead of containing them. When every location chooses its own approach, you do not get one backup strategy with forty deployments; you get forty different strategies, each with its own blind spots. One office runs nightly backups to a local NAS. Another copies files to a USB drive someone takes home. A third assumes the practice management vendor handles it. None of them is wrong in isolation, and together they are impossible to govern.

The deeper problem is that there is no single owner. Security staffing in healthcare is thin to begin with, and only about 14% of healthcare organizations report being fully staffed for security . A DSO spreading that thin coverage across many sites almost guarantees that no one is checking whether every office actually backed up last night.

What does "each office is a separate blast radius" actually mean?

It means a failure at one location is contained only by luck, not by design. In a well-architected fleet, an incident at one office stays at that office. In a typical DSO, the opposite is often true: shared logins, flat networks between sites, and a central server that holds data for multiple offices turn a single compromise into a group-wide one.

The danger compounds when backups live next to the data they protect. In one real case, a dental practice's server was encrypted by ransomware and the backups stored on that same server were encrypted too, leaving nothing clean to restore from — Tampa Bay Dental Implants, affecting roughly 6,400 patients . Multiply that pattern across a fleet where every office keeps its only copy on-site, and you have an organization with no real recovery path anywhere.

The fix: immutable, off-site copies for every site

The protection against this is the same at every location: keep at least one copy off-site, and make it immutable so that ransomware (or a careless admin) cannot alter or delete it during the retention window. Immutable off-site backups break the link between a local compromise and total data loss. The point is that this should not be a per-office decision at all; it should be the default the entire fleet inherits.

How does inconsistent software across locations hurt recovery?

It hurts because acquired offices arrive with different systems, and backups that ignore those differences may not restore cleanly. A DSO built through acquisition typically runs several practice management platforms and several imaging systems, sometimes a different combination at every site. A naive file-copy backup can capture a PMS database mid-write and produce a backup that restores into a corrupt, unusable state.

The answer is application-consistent backups: backups coordinated with each practice management and imaging application so the captured copy is internally consistent and actually restorable. Standardizing the backup layer does not require ripping out every office's software. It requires one platform that understands all of them and applies the same protection regardless of what each site happens to run.

Why isn't "we have backups" the same as "we can recover"?

Because a backup you have never restored is a hypothesis, not a safeguard. The only way to know a backup works is to perform a test restore and confirm the data comes back intact. Across a fleet, untested restores are the rule rather than the exception, because no one has the time to validate dozens of offices manually.

Tested restores need to be a scheduled, fleet-wide routine, not something you discover the state of during a crisis. This is also where backup meets insurance: carriers increasingly expect evidence that backups exist, are immutable, and are tested, and missing that evidence is a common reason claims get reduced or denied. We cover that in detail in why cyber insurance denies dental claims.

How should retention work across a multi-state DSO?

Retention should be governed centrally but aware of every state you operate in, because record-retention requirements differ by state and a DSO often spans several. When each office sets its own retention informally, some sites keep too little and fall out of compliance while others keep everything forever and inflate cost and risk. Neither is a strategy.

A fleet console lets you define retention policy once and apply the correct rule per location based on where that office operates, instead of trusting each manager to remember the law. The state-by-state differences are larger than most groups expect; see how long dental practices must keep patient records for the specifics. Retention policy is general guidance here, not legal advice; confirm requirements with counsel for the states you operate in.

What does a centralized, fleet-managed backup model look like?

It looks like managing one system instead of forty. The shift is from a pile of independent office backups to a single fleet with shared rules and shared visibility:

• One standardized policy defining schedule, retention, and immutability, inherited by every location rather than reinvented at each.
• A single console showing the backup status of every office, so a missed or failing job is visible immediately instead of discovered after an incident.
• Immutable, off-site copies for each site, so no single compromise can destroy the only good copy.
• Application-consistent backups of each PMS and imaging system, so restores actually work regardless of vendor mix.
• Scheduled, tested restores across the fleet, turning "we have backups" into proven recovery.
• MSP-managed operation, so a team that does this full time owns it, rather than overloaded local staff.

Most DSO backup mistakes trace back to a single root cause: backup was never re-architected for the scale of the organization. Standardize the policy, centralize the visibility, make the off-site copies immutable, and prove recovery with regular tested restores. At DSO scale, that is the difference between a contained incident at one office and a breach that touches every patient you serve.