Five hours without the platform.

Picture the start of a Thursday for the operating team of a dental service organization with offices across California. The first stop is known: a hygienist is covering a clinic whose regular hygienist is out. Everything else is on a shared sheet: the rest of the day's assignments, who to call if a chair or a sterilizer fails, a note that one office has its spore test due. The sheet lives in the collaboration suite, and at 7:44 a.m. Pacific the suite stops loading. The team and the sheet are invented for this dispatch. The time is not.

Microsoft says that on July 23, from 14:44 to 19:41 UTC, just under five hours, customers had connectivity problems with resources in its West US region. A defect widened the scope of a network repair, so more routes were withdrawn than intended. The impact was on traffic entering or leaving the region; traffic that stayed inside it was not affected. Azure Virtual Desktop, which many organizations use to deliver applications to their staff, was among the services hit.¹ The window is the incident, not every customer's outage; companies running on Azure reported recovery at different times.²

My argument is that provider recovery and practice continuity are different plans with different owners. The provider restores its services and reports their condition. The practice decides which work continues, safely, until it does. Relying on one platform can remain a sound choice, provided the practice funds and rehearses a limited way of working through the failures it has chosen to accept. This is not a claim that Microsoft was careless, that any particular practice was harmed, or that clinical work should push through five hours regardless. Some work should stop. The plan's job is to say which.

Keep the platform, change the failure plan

The tempting response is a second office suite, a second chat system, a second everything. For an organization like the one in this example, I think that is usually the wrong trade. Two suites mean two sets of licenses, training, security settings and places where data can leak, bought to cover a few hours a year. That is a judgment about one kind of operator, not a cost study, and some will reasonably decide otherwise.

A better question comes from federal contingency planning. NIST's guide asks first how long each business process can tolerate being disrupted, and only then how quickly the systems behind it must come back, a recovery target that should normally be shorter than the tolerable outage. Separately, it asks how much recent data the process can afford to lose.³ It was written for federal systems, but the order of the questions transfers to a clinic day. The supplier's restoration time is a fact about the supplier. How long the morning's assignments can be out of reach is a fact about the practice, and only the practice can set it.

Three layers of continuity

Here is what I would ask an operating team to design and test. These are proposals, not a description of any existing installation.

Recover selected workloads in a second region. For the applications the practice itself runs, and whose interruption costs most, arrange recovery in another Azure region. Scope it whole: the application, its data, its network paths, the sign-in it depends on, the capacity it needs and the person allowed to declare the move. Set the acceptable data loss and recovery time from the workflow, then prove them in a drill. Two limits belong in writing. A copy of your own application in another region does nothing for Microsoft 365, whose recovery stays with Microsoft. And two regions can still share sign-in or other dependencies, so the drill has to follow those paths too.

Keep the day's essential information usable without the suite. Prepare a small operating packet on approved, secured devices: the day's schedule and assignments, escalation contacts, the downtime procedures. Give it an owner, a visible refresh time, access limits and a disposal rule, and put in only what the defined downtime tasks need. Schedules and patient contacts are sensitive, so this is not permission for loose spreadsheets or printouts left on a counter. Nor is the packet a clinical record. Clinical leaders decide what information a procedure needs before it proceeds, and when a missing piece means deferring it. Changes made during the outage go in a log for reconciliation afterward, with a check against entering the same visit twice.

Reach the field team another way. Define a text-message or phone tree for operating instructions and acknowledgments, and confirm that starting it, the contact list it reads and the sign-in it needs all work when the collaboration platform does not. A different app icon is not evidence of independence. Ordinary fallback messages carry no patient details; if protected information has to move, it goes through an approved channel.

A drill tests the layers together: someone retrieves the packet, reaches a team, records a changed instruction, exercises the recovery path and reconciles the records. The gaps it finds, and the names of the people who own them, are the result.

The supplier map has a second job

July also showed a different way a supplier can fail. A notification letter from DentaQuest, which administers dental benefits, posted by Massachusetts in July, says someone had unauthorized access to its systems from May 17 to 20 and that personal information, including dental or vision diagnoses, treatments and billing, was accessed and posted on the internet.⁴ A health plan that used DentaQuest for dental benefits posted its own notice on July 16, noting that the information involved varied by person.⁵ This was a May intrusion disclosed in July, and nothing links it to Azure. On July 20, Craneware, which sells software to hospitals, announced that some employee data and a subset of customer and partner records had been accessed and taken, and that its customer services and operations were not disrupted.⁶ Uptime, in other words, is no evidence that data is safe.

So the practice's supplier register needs two views. One asks what work stops when a supplier is unavailable, and what the tested fallback is. The other asks what data the supplier holds, about whom, for what purpose and for how long, which subcontractors it uses, and whom to call when something goes wrong. A copy in a second region answers the first question and not the second. It cannot retrieve stolen records, and unless the design guards against it, it will faithfully copy a bad change.

Contracts help with the second view, within limits. Where a business associate agreement is required, it should match the actual service and data flow. HHS's sample provisions cover safeguards, reporting of security incidents and breaches, and binding subcontractors to the same restrictions.⁷ The rule requires a business associate to notify the covered entity of a breach of unsecured health information without unreasonable delay and no later than 60 days after discovering it.⁸ Sixty days is an outer limit, not an operating target. A practice can negotiate earlier escalation, named contacts who answer, an update schedule and help identifying affected records. None of that prevents a breach. Prevention is still restricted access, keeping less data and evidence that the supplier's controls work.

Objections, considered

Two regions are too expensive. For many workloads they are. Name the critical work first, then compare backup, standby and live deployment against the recovery it needs. Fund the outcome, not the topology.

A cached schedule is another privacy risk. It is. Keep it small, protect access, show its age, dispose of it on schedule, and give the fallback its own risk assessment.

Microsoft should simply be more reliable. The supplier's responsibility stands. The practice still has a morning to run before restoration, and a service credit does not run it.

Five hours is never merely inconvenient in healthcare. For some work, that is right. The aim is a bounded, tested way of operating with explicit conditions for stopping, not treatment at any cost.

The provider restores the platform; we must decide what happens until then.

Before the next outage

• Can a field team get the day's approved information without the normal collaboration service?
• Has the recovery and communication path been exercised, not just written down?
• Can we say which vendors hold which patient data, and reach the right incident contact today?

Back to the operating sheet. At 7:44 the question at the top of the gold column, when service will be restored, has no answer, and the answer is not the practice's to give. The blue column can be filled in: a packet refreshed at six, a phone tree, a drill from last quarter, a line that says which work stops. Whether that plan is real comes down to one test: whether someone can use it under the conditions it assumes.