A single-location dental practice needs a disaster recovery plan. A DSO needs one that accounts for how a failure at one location affects every other location in the organization.
Shared databases, centralized billing systems, and cross-location patient records mean that a ransomware attack, server failure, or data loss event at one office is rarely contained to that office. Here is how to build a recovery plan that reflects the actual scope of a multi-location dental group.
The average cost of dental practice downtime from a ransomware attack is $8,000 to $15,000 per day in lost production.
For a DSO with five locations, a centralized infrastructure failure that takes all locations offline simultaneously multiplies that figure across every office. DSOs without a tested recovery plan have no documented path back to operations when that scenario occurs.
A single-location recovery plan is straightforward: restore the backup, rebuild the server, get the software running again. A DSO recovery plan has to account for several additional failure modes that do not exist in a single office.
A shared database failure affects every location simultaneously
When the central database or cloud environment goes down, every location that depends on it loses access at the same time. A recovery plan that addresses only one location at a time cannot handle this scenario.
A ransomware attack at one location can spread across the network to others
If locations share a network or VPN, ransomware that enters through one office can propagate to shared drives, the central database, and other connected locations before it is contained. Network segmentation and isolation procedures must be part of the recovery plan.
Recovery sequencing matters: which location comes back online first, and how do others operate in the interim
When multiple locations are affected, the order of recovery has real financial consequences. The highest-production location typically comes first, but that decision and the interim workflows for other locations must be documented before an incident, not improvised during one.
Communication across the organization during an incident requires a plan that single-practice recovery documents do not address
Who notifies which locations, who communicates with patients, who coordinates with the IT provider, and who makes go/no-go decisions during recovery all require a documented chain of responsibility that scales to the size of the organization.
A complete DSO disaster recovery plan covers:
Where data is backed up, how often, and how quickly it can be restored at each location and at the organizational level
Every location needs a verified, tested backup independent of the central database. The central database or cloud environment needs its own backup with a recovery process that does not depend on any individual location being online. Both levels must be documented and tested separately.
How long the DSO can tolerate being down at one location versus all locations, and how much data loss is acceptable
These numbers drive every other decision in the plan. A DSO that can tolerate 4 hours of downtime at one location but only 30 minutes across all locations has different infrastructure requirements than one with identical tolerances everywhere. Define these before building the plan, not after.
Who is notified first, who makes decisions during an active incident, and how staff at affected and unaffected locations are kept informed during recovery
A documented decision tree that does not require improvisation under pressure. Who calls the IT provider, who notifies leadership, who communicates to staff at each location, and who authorizes the recovery sequence must all be defined before an incident occurs.
The documented priority order for bringing locations back online and the interim workflows for locations waiting for recovery
Which location comes back first, what the non-priority locations do while they wait (paper-based intake, appointment rescheduling, or temporary manual workflows), and how the sequence is communicated across the organization must all be written into the plan before they are needed.
A DSO backup strategy needs to operate at two levels. Each location needs its own local backup that can restore operations independently if the central infrastructure is unavailable. The central database or cloud environment needs its own backup with a recovery process that does not depend on any individual location being online.
On-site backup device or local cloud backup capturing location-level data daily
Tested for restore at least quarterly. Allows each location to restore independently if the central database is unavailable. This is the backup that keeps a single-location failure from becoming a full-practice loss.
Separate backup of the shared database or cloud environment with a retention policy allowing point-in-time recovery
Tested independently of location-level backups. This is what restores the organization after a centralized failure. The retention policy must be long enough to catch delayed ransomware discovery, where encrypted data is backed up before the encryption is detected.
At least one backup copy stored in a location physically and logically separate from the primary environment
This is the copy that survives a physical disaster at the primary site. A backup stored on the same network or in the same building as the primary data is not an offsite backup. Both physical separation and logical separation (separate credentials, separate cloud account) are required.
Recovery priority order for each location
Typically the highest-production location or the one with the most active patient schedule takes priority
The sequence must be documented and agreed upon before an incident, not decided during one
Every location manager must know the priority order and their location’s position in the sequence
Interim workflows while waiting for recovery
Paper-based intake: printed intake forms and a manual check-in process for walk-in patients
Appointment rescheduling: scripted communication for calling patients whose appointments must move
Temporary manual workflows for billing, scheduling, and clinical documentation until systems are restored
DSOs should conduct tabletop exercises at least annually where the IT provider and DSO leadership walk through a simulated incident scenario. Full restore tests should be conducted at least once per year at each location and at the central infrastructure level.
Ekim IT Solutions works exclusively with dental practices. We serve New England and New York with on-site support and dental practices nationwide with remote support. We build disaster recovery plans and backup infrastructure for DSOs that reflect the real scope of a multi-location dental group, not a single-office template applied across every site.