...

Ekim IT Solutions

Blog / How to Build a Dental IT Disaster Recovery Plan for a DSO
All

How to Build a Dental IT Disaster Recovery Plan for a DSO

Guide to building a dental IT disaster recovery plan covering every location in a DSO

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.

$8K-$15K per day in lost production

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.

Why DSO Disaster Recovery Is Different

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.

The Four Components of a DSO Disaster Recovery Plan

A complete DSO disaster recovery plan covers:

1
Backup Architecture

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.

2
Recovery Time and Recovery Point Objectives

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.

3
Incident Response and Communication

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.

4
Recovery Sequencing

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.

Need a tested disaster recovery plan across every DSO location? Find out in 15 minutes if we are the right fit.
Schedule a Discovery Call →

Backup Architecture for Multi-Location DSOs

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.

Level 1: Local Backup at Each Location

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.

Level 2: Central Database Backup

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.

Level 3: Offsite or Cloud Copy

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 Sequencing Across Locations

When multiple locations are affected by the same incident, recovery sequencing determines which office comes back online first and how the others operate in the interim. Without a documented sequence, recovery becomes a reactive process driven by whoever is loudest rather than where recovery has the most impact.
Define Before an Incident

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

Document for Non-Priority Locations

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

Testing the Plan

A disaster recovery plan that has never been tested is a document, not a plan. Check each testing requirement your DSO has completed within the past 12 months.

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.

DR testing requirements completed 0 / 5

Your DSO’s disaster recovery plan is tested and current.

All five testing requirements are complete. The most important next step is scheduling the next annual tabletop exercise before 12 months pass and confirming that any gaps identified in the last exercise have been fully resolved. A tested plan that is not updated becomes an untested plan over time.

Disaster recovery testing is partially complete.

The unchecked items are the difference between a recovery plan and a tested recovery plan. Each one represents a scenario that has not been validated under controlled conditions. An incident that hits one of those untested scenarios costs significantly more in recovery time and data loss than one where the response is already practiced.

Your DSO’s disaster recovery plan has not been tested.

Most or all of the testing requirements are not complete. A plan that has never been tested is a document, not a plan. The most important first step is scheduling a tabletop exercise with your IT provider. This does not require a full restore test to start. A tabletop exercise identifies the most critical gaps in the documented response and prioritizes what needs to be fixed before a full test is attempted.

Talk to Ekim about DSO disaster recovery planning →

Frequently Asked Questions

A single-practice plan focuses on restoring one office. A DSO plan must account for shared infrastructure failures that affect multiple locations simultaneously, cross-location data dependencies, recovery sequencing across offices, and organization-wide communication during an active incident. The technical steps may be similar but the scope and coordination requirements are significantly more complex.
Tabletop exercises at least annually and after any significant infrastructure change. Full restore tests at each location and at the central infrastructure level at least once per year. Practices that have experienced an incident or made significant platform changes should test more frequently.
A recovery time objective is the maximum amount of time the organization can tolerate being offline before the impact becomes unacceptable. For a DSO, this number may differ by location and by type of failure. Defining it in advance forces the organization to make decisions about backup frequency, infrastructure redundancy, and IT provider response time before an incident rather than during one.
No. Cyber insurance covers financial losses after an incident. A disaster recovery plan determines how quickly and completely the organization recovers operationally. Insurance does not restore your data, rebuild your servers, or get your practice management software running again. It pays some of the cost after you do. Both are necessary and neither substitutes for the other.
Does your DSO have a disaster recovery plan that actually accounts for what happens across every location when one goes down?

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.

A failure at one DSO location rarely stays there. Find out if your recovery plan is built for the full scope of that risk.
Build your DSO recovery plan →