Backup and Disaster Recovery Guide for Small Practices

Every small office has a backup story. Usually it goes something like this: "We have backups. There's a drive plugged into the server. Someone set it up years ago." Then a server dies, or a staff member clicks the wrong link and ransomware locks every file, and the office finds out the hard way that the drive filled up in 2023, or that it was encrypted right along with everything else because it was plugged in the whole time.

Backup and disaster recovery is not glamorous, but it is the one part of IT that decides whether a bad day stays a bad day or turns into a bad month. For a dental office it's the difference between seeing patients on Tuesday or rescheduling a week of appointments. For a medical practice it's whether you can pull up a medication list during an outage. For a CPA firm in March, it's whether you hit filing deadlines at all.

This guide explains, in plain English, what a modern backup setup looks like, how to decide how fast you need to recover, what Microsoft does and doesn't protect in Microsoft 365, what HIPAA actually requires, and how to write a disaster recovery plan you can follow when you're stressed. It ends with a template you can adapt, a testing schedule, and the questions to ask whoever handles your IT.

What is the difference between backup and disaster recovery?

Backup is the copy; disaster recovery is the plan for using it. A backup is a protected copy of your data. Disaster recovery (DR) is the set of steps, people and systems that get your office working again after something breaks, using those copies.

You need both. A perfect backup with no plan means you have the data but nobody knows how to restore it, where to restore it to, or in what order. A beautiful plan with a broken backup is a document describing something that won't happen.

A third term you'll hear is business continuity: keeping critical work going during the disruption, even in a degraded way. For a practice, that might be paper schedules and a printed list of today's patients while the server is being rebuilt. Disaster recovery gets the systems back; business continuity keeps the doors open while that happens. You can read more in our glossary entries for disaster recovery and business continuity.

Here's a quick way to think about the three layers:

What can actually go wrong?

Most data loss in small offices comes from ordinary events, not movie-plot disasters. Plan for the common ones first, and the rare ones get easier.

The realistic list for a 5–50 person office:

1. Hardware failure. Hard drives and solid-state drives fail. Servers fail. The older the machine, the more likely it is.
2. Human error. Someone deletes a folder, overwrites a spreadsheet, or empties a mailbox. In Microsoft 365, a departing employee's account gets deleted along with their mailbox and OneDrive.
3. Ransomware. Criminals encrypt your files and demand payment. Modern ransomware groups deliberately look for and destroy backups first. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) warns in its #StopRansomware Guide that "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups." See our ransomware protection guide for the prevention side.
4. Account compromise. An attacker who gets into an administrator account can delete data, change settings, or wipe backups that live in the same account.
5. Software problems. A bad update corrupts a database. A vendor migration goes wrong.
6. Physical events. Fire, water leaks, theft, and here in Florida, hurricanes and flooding. Our hurricane preparedness guide for Florida businesses covers storm-specific steps.
7. Vendor or cloud outages. Your cloud practice-management system or internet provider goes down. Your data is fine, but you can't reach it.

Notice that only a few of these involve the building being destroyed. Most involve a single server, a single account, or a single mistake. Your backup design needs to handle both the small "I need yesterday's version of this file" request and the large "everything is encrypted" event.

What is the 3-2-1 backup rule, and what is 3-2-1-1-0?

The 3-2-1 rule says keep three copies of your data, on two different types of storage, with one copy off-site. The modern extension, 3-2-1-1-0, adds one copy that is offline or immutable and zero errors when you test restores.

Let's break that down with a real office in mind.

• 3 copies. The live data (the copy you work on every day) counts as one. You need two more.
• 2 different types of storage. For example, a local backup appliance or network storage device, plus cloud storage. If one type has a systemic problem, the other doesn't share it.
• 1 off-site. At least one copy lives somewhere other than your office, so a fire, flood or theft doesn't take everything.
• 1 offline or immutable. At least one copy that ransomware, or someone with your admin password, cannot alter or delete.
• 0 errors. You've actually tested restoring from the backups, and the restores work.

The "3-2-1-1-0" label is an industry convention rather than a formal standard, but every piece of it lines up with official guidance. CISA's ransomware guide recommends maintaining "offline, encrypted backups of critical data" and regularly testing "the availability and integrity of backups in a disaster recovery scenario." The rule is just a memorable way to hit those points.

What does 3-2-1-1-0 look like in a real office?

The local copy is about speed: restoring 2 TB from a device on your network is far faster than downloading it over a 300 Mbps internet connection. The cloud copy is about survival: it's the one that's still there when the building isn't.

How much storage do you need?

Plan for your current data size, plus growth, plus retention history. A backup that keeps 90 days of daily versions takes more space than the data itself, though modern backup software only stores changes after the first full copy.

Imaging-heavy offices need the most. Dental cone-beam CT (CBCT) scans and intraoral images add up quickly, and medical practices that store scanned documents and images locally grow steadily. Rather than guess, put your numbers into our Backup Storage Calculator, which estimates storage needs from your data size, growth rate and how long you keep history.

What is an immutable backup, and why do insurers ask about it?

An immutable backup is a copy that cannot be changed or deleted for a set period, even by an administrator. It's your defense against an attacker who gets admin access and tries to destroy your backups before launching ransomware.

Older advice said "keep a backup offline," meaning a tape or disk physically unplugged and taken home. That still works, but it depends on someone remembering to rotate drives every week, and people stop doing it. Immutable storage gives you the same protection automatically:

• Retention lock (sometimes called object lock or WORM, "write once, read many"). The storage system itself refuses to delete or overwrite backups until a set date.
• Separate credentials. The backup system uses a different login from your everyday Microsoft 365 or Windows administrator accounts, protected by multi-factor authentication, so stealing one password doesn't unlock everything.
• Delayed deletion. Even if someone requests deletion, the provider holds the data for a grace period.

Cyber insurance applications now routinely ask whether backups are offline or immutable, whether they're protected by MFA, and when you last tested a restore. Answering "yes" when the honest answer is "sort of" can cause problems at claim time. Our cyber insurance requirements checklist covers those questions in detail.

Mistakes that defeat immutability

1. Backup console uses the same admin account as everything else, with no MFA.
2. Retention lock is turned on, but only for 7 days, and nobody notices an attack until day 10.
3. The "immutable" copy is on a network drive that's mapped on every PC (ransomware will find it).
4. Immutability is set on the cloud copy, but the cloud copy hasn't successfully updated in three months.
5. Nobody receives or reads the backup failure alerts.

RTO and RPO in plain English

RTO (recovery time objective) is how long you can be down. RPO (recovery point objective) is how much recent work you can afford to lose. Together they decide what kind of backup you need and what it costs.

Here's an everyday way to explain them to an office manager:

• RTO: "If the server died at 9 a.m., by what time do we absolutely need to be seeing patients normally again?" If the answer is "by lunch," your RTO is about 3 hours. If the answer is "tomorrow morning is survivable," it's about 24 hours.
• RPO: "If we lost everything since the last backup, how much re-entry could we live with?" If last night's backup is fine and you'd just re-enter this morning's appointments, your RPO is 24 hours. If losing even an hour of charting or claims is unacceptable, your RPO is 1 hour or less.

The U.S. government's Ready.gov IT disaster recovery guidance puts it well: "The recovery time for an IT resource should match the recovery time objective for the business function or process that depends on the IT resource." In other words, start with the business, not the technology.

How RTO and RPO drive your choices

Most small medical and dental offices land in the middle: backups every few hours during the business day, and a target of being back the same day or next morning. The faster you need to be back, the more you pay, so it's worth having an honest conversation about what's truly needed.

A quick worksheet

For each system, write down:

1. System: e.g., practice-management server, imaging PC, QuickBooks, Microsoft 365 email.
2. Who depends on it: front desk, clinicians, billing.
3. What happens if it's down for 1 hour / 1 day / 1 week: be specific ("can't check in patients," "can't submit claims," "can't file extensions").
4. Target RTO and RPO.
5. Workaround while it's down: paper forms, a read-only copy, a cloud portal.

This exercise is also what HIPAA calls an "applications and data criticality analysis," which we'll cover below. Our downtime cost calculator can help put a dollar figure on each hour of downtime, which makes the budget conversation much easier.

What needs to be backed up in a typical office?

Back up anything you'd need to rebuild the office: servers, databases, imaging, cloud data, and the configuration of the systems themselves. Most gaps we see come from things nobody thought of as "data."

The inventory checklist

• Practice-management or line-of-business database (Dentrix, Eaglesoft, Open Dental, a medical EHR running on a local server, QuickBooks Desktop, tax software data). These often need application-aware backups so the database isn't copied mid-write.
• Imaging data. X-rays, CBCT scans, intraoral camera images, scanned documents. Often stored in a separate folder or on a separate PC from the main database. Confirm the backup includes the actual image store, not just the database that points to it.
• File shares on a server or network storage device.
• Microsoft 365: Exchange Online mailboxes, OneDrive, SharePoint sites and Teams files (Teams files live in SharePoint and OneDrive).
• Line-of-business cloud applications: many cloud vendors back up their platform, but check whether you can export your data and how far back their restore goes.
• PCs that hold local data. Ideally nothing important lives only on a PC, but in reality the imaging acquisition workstation or the bookkeeper's PC often does.
• Configurations: firewall settings, switch configurations, phone system settings, Wi-Fi settings. Rebuilding these from memory under pressure is slow and error-prone.
• Licenses and installers: product keys, installation media, vendor support contacts for imaging software and sensors.
• Documentation: your network diagram, passwords (in a password manager with emergency access), and the DR plan itself. Keep a copy of the plan somewhere you can reach if your own systems are down.

Practice and imaging data deserves special attention

Dental and medical imaging is where backups most often fail quietly. Common problems:

1. The image store is on a different drive or PC from the database, and only the database is backed up.
2. The backup copies files while the database is in use, producing a copy that won't open. Use the backup method your software vendor supports (many provide a database export or a supported backup agent).
3. Image volume outgrows the backup plan. A CBCT unit can add a lot of data each year. Storage that was fine three years ago is now full, and the backup has been failing for weeks.
4. Restores have never been tested with the vendor's software. A folder of images is not useful if the practice-management system can't link them back to the right patients.

Ask your practice-software vendor three questions: what is the supported backup method, what exactly needs to be backed up (database, images, configuration), and what does a restore to new hardware involve? Write the answers into your DR plan. Our dental imaging network and computer guide goes deeper on imaging storage and workstations.

Does Microsoft 365 back up your data?

Microsoft keeps Microsoft 365 running and stores redundant copies of your data, but recovering from deletion, ransomware, or a compromised account is your responsibility. That's the shared responsibility model, and it surprises a lot of offices.

The shared responsibility model

Microsoft's own shared responsibility documentation is clear: "For all cloud deployment types, you own your data and identities." In its responsibility table, customer data, configuration, and identities and users are listed as the customer's responsibility even for software-as-a-service products like Microsoft 365. Microsoft handles the data centers, physical hardware, network and the software platform.

What that means in practice:

What's built in, and its limits

Microsoft 365 has useful built-in recovery features, and you should know them:

• Recycle bins for SharePoint and OneDrive, which hold deleted items for a limited time (93 days for work accounts by default).
• Version history for files in OneDrive and SharePoint.
• Deleted items retention in Exchange Online, which keeps deleted mail for 14 days by default (an administrator can raise this to 30).
• OneDrive "Restore your OneDrive," which rolls a whole OneDrive back to a point in the last 30 days.
• Retention policies in Microsoft Purview, which can keep content for compliance purposes.

These help with everyday mistakes. They are not a substitute for backup because they have time limits, they live inside the same account an attacker could control, and retention policies are designed for compliance, not for quickly restoring a whole site to how it looked last Tuesday.

Microsoft 365 Backup: Microsoft's own option

Microsoft now sells a dedicated product called Microsoft 365 Backup. According to Microsoft Learn (page updated September 2026):

• It backs up OneDrive accounts, SharePoint sites and Exchange Online mailboxes.
• The recovery window can be set to 3 months, 6 months, 1 year or 2 years.
• Restore points are available every 10 minutes for the prior two weeks for OneDrive and SharePoint (then weekly), and every 10 minutes for Exchange.
• Backups are stored in append-only storage, which Microsoft describes as "immutable unless expressly deleted by the Backup tool admin via product offboarding," with a 90-day grace period after offboarding.
• It's pay-as-you-go: $0.15 per GB per month of protected data (Microsoft's listed rate as of October 2026), and restores are free. Billing runs through an Azure subscription.
• Data stays inside the Microsoft 365 boundary, which makes restores fast.

The trade-off is that the backup lives within Microsoft's environment. Some offices want a copy completely outside Microsoft, which is where third-party Microsoft 365 backup services come in (several are built on Microsoft's backup storage platform; others store copies in their own clouds). Either approach is reasonable; what matters is that something independent of everyday user and admin actions exists, it covers all users, and you've tested it.

Practical Microsoft 365 backup checklist

1. Decide what to protect: all mailboxes, all OneDrives, and all SharePoint sites (including the ones behind each Team).
2. Choose Microsoft 365 Backup or a third-party product, and set retention to at least 1 year.
3. Protect the backup admin role with MFA and limit it to one or two people.
4. Make sure new users and new sites are added automatically, not manually.
5. When someone leaves, keep their data backed up (or convert their mailbox to a shared mailbox) before removing the license.
6. Test a restore of one mailbox folder and one SharePoint library every quarter.

For more on how Microsoft 365 fits into healthcare compliance, see Is Microsoft 365 HIPAA compliant?

Why isn't OneDrive sync a backup?

Sync copies every change everywhere, including mistakes and ransomware damage. A backup is a separate, protected copy from a point in time that you can go back to.

If a PC gets infected and its files are encrypted, OneDrive dutifully syncs the encrypted versions to the cloud. Version history and "Restore your OneDrive" can often reverse that within 30 days, which is genuinely helpful. But if the attacker has the user's credentials, they can delete versions too, and if nobody notices for 45 days, the clean versions may be gone.

The same applies to Dropbox, Google Drive, and "we copy everything to a shared drive." Useful for collaboration, not a backup on their own.

How should you back up servers and PCs?

Use image-based backups for servers and any PC that holds data you can't easily recreate, keep a local copy for speed, and replicate to an immutable cloud copy. For everything else, keep data off the PC entirely.

Image-level versus file-level backups

• File-level backup copies files and folders. Good for documents, but restoring a whole server this way means reinstalling Windows, applications and settings first.
• Image-level backup captures the entire machine: operating system, applications, settings and data. You can restore the whole thing to new hardware, or, with many products, run the backup as a virtual machine while you fix the original. That's what makes a same-day RTO realistic.

For a server running a practice-management database, image-level with application-aware processing (so the database is captured consistently) is the standard approach.

What about workstations?

Most workstations shouldn't need backup at all. With Intune managing settings and OneDrive holding documents, a replacement PC can be set up from scratch quickly. The exceptions are machines with special software or local data, such as an imaging acquisition PC tied to an X-ray sensor or panoramic unit, a lab instrument PC, or a bookkeeper running desktop accounting software. Image those.

Encryption and access

Backups contain everything sensitive you own, so treat them that way:

• Encrypt backups both in storage and while they travel over the internet (encryption at rest and in transit).
• Store the encryption key somewhere safe and separate. If you lose the key, the backup is useless.
• Make sure any backup vendor that stores patient data signs a business associate agreement (BAA). Our BAA guide explains what to look for.

What does HIPAA require for backup and disaster recovery?

HIPAA's Security Rule requires every covered entity and business associate to have a contingency plan, including a data backup plan, a disaster recovery plan and an emergency mode operation plan. Testing and criticality analysis are "addressable," which doesn't mean optional.

The requirement is in 45 CFR 164.308(a)(7). The standard says you must "establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information."

It then lists five implementation specifications:

"Addressable" doesn't mean optional. Under HIPAA, an addressable specification means you must implement it if it's reasonable and appropriate, or document why not and what you do instead. For testing backups and ranking critical systems, it's very hard to argue that a reasonable alternative exists.

What about the proposed HIPAA Security Rule changes?

In January 2025, the U.S. Department of Health and Human Services (HHS) published a proposed update to the Security Rule. Among many changes, it proposed stricter contingency planning, including procedures to restore critical systems and data within 72 hours and removing the distinction between "required" and "addressable." As of this writing (October 2026), that rule has not been finalized, and HHS's published regulatory agenda has pushed final action further out. Check HHS for the latest status. Our article on the proposed HIPAA Security Rule changes tracks it.

Practically, a well-built backup and DR program today, with tested restores and a realistic recovery target, will put you in good shape whatever the final rule says. It also feeds directly into your HIPAA security risk assessment, which should list backup failures and ransomware as risks and describe how you address them.

Documentation HIPAA reviewers expect to see

1. A written contingency plan covering backup, disaster recovery and emergency operations.
2. A list of systems containing ePHI and how each is backed up.
3. Your criticality ranking with recovery targets.
4. Records of restore tests: date, what was restored, result, who did it.
5. Evidence of plan reviews and updates (at least annually and after major changes).
6. BAAs with backup and cloud vendors.

The Security Rule requires keeping this kind of documentation for six years from when it was created or last in effect.

How do you test a backup restore?

Restore real data on a schedule, write down what happened, and fix anything that didn't work. A backup job that says "success" only means the copy was made, not that you can use it.

A testing schedule that works for small offices

What to record for each test

• Date and time
• What you restored, from which backup and which date
• How long it took (compare to your RTO)
• Whether data was complete and correct
• Problems found and what you did about them
• Who performed and who verified the test

Those records are your evidence for HIPAA, cyber insurance and client security reviews. They're also how you find out, on a calm Tuesday, that restoring the imaging database takes six hours rather than the two you assumed.

How do you write a disaster recovery plan?

A disaster recovery plan is a short, practical document listing what to do, who does it, and in what order when systems fail. Keep it short enough that someone will actually read it during a crisis.

NIST Special Publication 800-34, the federal government's contingency planning guide, is the standard reference and includes a business impact analysis template. For a small office, you don't need its full depth; you need the core.

Disaster recovery plan template

Copy this outline and fill it in. One to five pages is plenty for most small offices.

1. Purpose and scope

• What this plan covers (all systems at [office address], Microsoft 365 tenant, cloud applications).
• When it's activated (any outage expected to exceed [X hours], ransomware, loss of the building).

2. Contacts

• Plan owner (usually the practice or office manager) and backup person.
• IT provider: support portal, phone, after-hours escalation.
• Software vendors: practice management, imaging, phone system, internet provider, with account numbers.
• Insurance: cyber policy number and claims line. Many policies require you to call them before hiring outside help.
• Legal or compliance contact.

3. Critical systems and recovery targets

4. Activation and decision steps

1. Confirm the problem and its scope (one PC? one server? everything?).
2. If ransomware or a breach is suspected: disconnect affected machines from the network (don't power them off), call your IT provider and cyber insurer, and follow your incident response plan.
3. Decide whether to activate emergency operations (paper procedures, rescheduling).
4. Notify staff using a channel that doesn't depend on the affected systems (personal cell phones, group text).

5. Recovery steps for each critical system

• Step-by-step, in order. Where to find the backup, who restores it, how to verify it.

6. Emergency mode operations

• How to check patients in, take payments, look up allergies or medications, and protect paper records during the outage.
• How to keep ePHI secure while working in a degraded mode (no sticky notes with patient names on monitors, paper forms locked up).

7. Communication

• Script for front desk phones and patient messages.
• Who decides whether this is a reportable breach. Our HIPAA breach response plan covers that decision.

8. Return to normal

• Verify data, re-enter paper records, review what happened, update the plan.

9. Testing and maintenance

• Test schedule and the date of the last review.

Store copies in at least two places that don't depend on your own systems: a printed copy in a known location and a copy accessible from a phone.

Scenario walk-throughs

The best way to check a plan is to walk through a realistic bad day. Here are three, one for each type of office we work with most.

Dental office: the server dies on a Monday morning

A four-chair dental practice runs its practice-management system and imaging on one server in a closet. At 7:45 a.m. the server won't boot.

Without a plan: the front desk can't see today's schedule. Hygienists can't see prior X-rays. Someone calls the IT person, who orders a new server that arrives Thursday. The practice reschedules three days of patients, then discovers the backup drive stopped working months ago.

With a plan:

1. The office manager opens the printed day sheet that the system emails each evening (an easy continuity step) and starts seeing patients from paper.
2. The IT provider confirms hardware failure remotely and starts the latest server backup as a virtual machine on the local backup appliance. The practice-management software is reachable from workstations again within a few hours.
3. Clinicians work from the restored system for the rest of the week while replacement hardware is ordered.
4. That evening, the team re-enters the morning's paper notes.
5. When the new server arrives, the IT provider restores the image to it after hours.

The difference isn't magic; it's an image backup with a local appliance, a known RTO, and a small amount of paper preparation. Internet outages are a separate problem; our dental practice case study describes how automatic cellular failover kept one practice's front desk working when the internet dropped.

Medical office: ransomware on a Friday afternoon

A family medicine office uses a cloud EHR but keeps scanned documents, billing exports and shared files on a local file server and in SharePoint. A staff member opens a malicious attachment, and files across the file server start getting renamed with a strange extension.

With a plan:

1. Staff recognize the warning signs from training and call the IT provider immediately. The infected PC and the file server are disconnected from the network.
2. The office manager calls the cyber insurance claims line, as the policy requires.
3. Clinical work continues because the EHR is cloud-based and unaffected; the EHR downtime plan is there if it isn't.
4. The IT provider checks the immutable cloud backup: the attacker found and tried to delete the local backup, but the cloud copy has a retention lock and is intact.
5. Once the malware is removed and the infection is understood, the file server is restored from the last clean backup before the attack. SharePoint files that synced in encrypted form are rolled back with Microsoft 365 Backup.
6. The practice works through its breach risk assessment to decide whether notification is required.

The key moment is step 4. If the only backup had been on the network with the same credentials, this would be a very different story.

CPA firm: an employee deletes a client folder in March

A 12-person accounting firm stores client files in SharePoint. During tax season, a staff member reorganizing folders accidentally deletes a client's entire folder and doesn't notice. Three weeks later, a partner needs a workpaper from it.

With a plan:

1. The partner checks the SharePoint recycle bin, which still has it because it's within the retention window. Restored in minutes.
2. If it had been longer, or if the folder had been overwritten rather than deleted, the firm's Microsoft 365 backup (1-year recovery window) would bring back the folder exactly as it was on a chosen date.

Small incidents like this are the most common reason anyone touches a backup. Accounting firms also have specific obligations under the FTC Safeguards Rule, covered in our IT security guide for CPA firms.

What does backup and disaster recovery cost?

Costs depend on how much data you have and how fast you need it back. Most small offices spend more on the consequences of a failed restore than they ever would have on doing it properly.

Rough components:

• Microsoft 365 backup. Microsoft 365 Backup is listed at $0.15 per GB per month of protected data as of October 2026; third-party services are often priced per user per month. A small office with a modest amount of mail and files usually pays a manageable monthly amount, but heavy SharePoint use can grow it.
• Server and image backup software, typically licensed per server or workstation, plus cloud storage.
• Local backup appliance or network storage, a one-time hardware purchase (or leased as part of a managed service), replaced every few years.
• Cloud storage for off-site, immutable copies, priced by volume.
• Labor: setup, daily monitoring, test restores and plan maintenance. With a managed IT provider this is usually part of the monthly service; our managed IT services cost guide explains typical pricing models.

Use the Backup Storage Calculator to size storage, and the Downtime Cost Calculator to estimate what an hour of downtime costs your office. Comparing the two numbers usually settles the "is this worth it?" question.

Mistakes we see most often

Most backup failures are preventable and boring. Here are the ones that come up again and again:

1. No one watches the alerts. Backups fail silently for weeks.
2. Only the database is backed up, not the images.
3. The only copy is on the same network with the same admin password.
4. No Microsoft 365 backup, on the assumption Microsoft handles it.
5. Departed employees' accounts deleted before their data was preserved.
6. Never tested. The first restore attempt happens during the emergency.
7. The plan lives only on the server that just failed.
8. Retention too short to recover from an attack discovered weeks later.
9. Encryption key not stored anywhere safe, so the backup can't be opened.
10. Backup admin account without MFA.

Questions to ask your IT provider

If you outsource IT, these questions will tell you quickly whether your backups are real. Ask for answers in writing.

1. What exactly is backed up: which servers, PCs, databases, image folders, and Microsoft 365 services?
2. How often do backups run, and how long do we keep them?
3. Where are the copies stored? Which copy is off-site, and which is immutable or offline?
4. Is the backup system protected by separate credentials and MFA?
5. Who receives backup failure alerts, and how fast are they handled?
6. When was the last test restore, what was restored, and how long did it take? Can we see the record?
7. What are our RTO and RPO for each critical system, and has a test proven we can meet them?
8. If our server died today, what would happen, step by step?
9. Will you sign a BAA covering backup data that includes patient information?
10. Where is our written DR plan, and when was it last updated?

If the answers are vague, that's your answer. Our guide on how to choose a managed IT provider has more questions for evaluating providers in general.

A 30-day action plan

You can go from "we think we have backups" to "we've proven we can recover" in about a month. Here's a realistic sequence.

Week 1: Inventory

• List every system, where its data lives, and who depends on it.
• Confirm what is currently backed up, and when the last successful backup ran.

Week 2: Set targets and fix gaps

• Set RTO and RPO for each critical system with the practice owner or office manager.
• Turn on Microsoft 365 backup if you don't have it.
• Add an immutable off-site copy if you don't have one. Put MFA on the backup console.

Week 3: Test

• Restore files, a mailbox folder, and your most critical server (to a test location).
• Time it. Compare to your RTO.

Week 4: Document

• Fill in the DR plan template above.
• Print it, share it with key staff, and schedule the next test.
• Update your HIPAA risk assessment and HIPAA security checklist with what you've done.

The bottom line

Good backup and disaster recovery isn't complicated, but it does have to be deliberate. Keep three copies on two kinds of storage with one off-site and one immutable. Decide how fast you need each system back and how much work you can afford to lose. Back up Microsoft 365 as well as your servers. Test restores on a schedule and write down the results. And keep a short, printed plan that tells people what to do when things go wrong.

If you'd like a second set of eyes on your current backups, or help writing a disaster recovery plan that meets HIPAA's contingency plan requirements, our team can review your setup and walk through a test restore with you. Learn more about our managed IT services and healthcare IT support, or book a free consultation.