A cloud phone system is an internet application. When the circuit drops, the phones drop with it — and the FCC says so plainly in its own consumer guidance: VoIP service may not work during a power outage or when the internet connection fails or becomes overloaded. The fix is not a better provider. It is a failover plan configured in advance: a rule at the carrier that reroutes inbound calls to mobile numbers when your system stops registering, a written runbook the front desk can execute without IT, and a test you actually run. Most practices have none of the three, and discover it on the morning the fiber gets cut.
The failure nobody plans for
Practices plan for the EHR going down. They rarely plan for the phones going down — even though the phones are how patients reach a triage nurse, how the pharmacy calls back about a prescription, and how a hospital reaches the on-call provider. A phone outage during business hours is a clinical continuity problem wearing a telecom costume.
The reason it goes unplanned is that a cloud phone system feels like infrastructure. It is not. It is software riding on three fragile dependencies: power, internet, and the provider's own platform. Any one of them can take it out.
What actually breaks, in order
| Failure | What happens to calls | What saves you |
|---|---|---|
| Power outage at the practice | Switch, router, and desk phones go dark; extensions stop registering | UPS on the network stack; carrier-level failover; mobile apps on staff phones |
| Internet circuit down (fiber cut, ISP outage) | Same: nothing registers, inbound calls hit a dead endpoint | Failover rule at the carrier; a second circuit or LTE/5G backup |
| Bandwidth saturation, not a full outage | Calls connect but are unusable — choppy audio, one-way audio, drops | QoS, a dedicated voice VLAN, monitoring that alerts before patients complain |
| Provider platform outage | Your circuit is fine; the platform is not. Failover rules on that platform may fail with it | Failover configured upstream of the platform, at the number's carrier |
| Regional disaster | Site is unreachable; staff are displaced | Softphones on personal devices, a published alternate number, a documented recall tree |
The four layers of failover
Continuity for a clinic phone system is built in layers, cheapest first.
1. Keep the network alive
Put the modem, router, switch, and any on-prem gateway on a UPS sized to ride out short outages. Desk phones powered over Ethernet come back with the switch. This alone converts most brief blips into a non-event.
2. Keep the circuit alive
A cellular backup (LTE/5G failover on the router) or a second broadband circuit from a different physical path. Two providers over the same conduit is not redundancy — ask where the fiber actually enters the building.
3. Reroute the numbers
The critical control. Configure, in advance, a rule that reroutes each inbound number to a mobile phone or an answering service if the endpoint stops registering. This must be pre-configured; it is not something you want to be setting up during an outage, from a phone, on hold with support.
4. Keep the people reachable
Softphone apps installed and tested on staff mobiles, so a displaced front desk can still take calls with the practice's caller ID. Note the privacy question this raises — PHI on personal devices needs a policy before the emergency, not during it.
Why HIPAA makes this a requirement
If your phone system stores voicemail, call recordings, or messages containing PHI — and virtually every clinic's does — then it is a system that maintains electronic protected health information, and the HIPAA Security Rule's contingency plan standard applies to it. Under 45 CFR 164.308(a)(7), a covered entity must establish policies and procedures for responding to an emergency or other occurrence (the rule names fire, vandalism, system failure, and natural disaster) that damages systems containing ePHI. Three of its implementation specifications are required, not addressable:
- Data backup plan (Required) — procedures to create and maintain retrievable exact copies of ePHI.
- Disaster recovery plan (Required) — procedures to restore any loss of data.
- Emergency mode operation plan (Required) — procedures to enable continuation of critical business processes for protecting the security of ePHI while operating in emergency mode.
Two more are addressable: testing and revision procedures for the contingency plan, and an applications and data criticality analysis — assessing the relative criticality of specific applications and data. That criticality analysis is precisely the exercise that surfaces the phone system as a tier-one dependency. Most practices have never run it, and so the phones live in a blind spot between IT and the front office.
E911 during an outage
When the internet is down, 911 from a VoIP handset may not work. That is not an edge case — the FCC lists it explicitly among the risks of interconnected VoIP, alongside the possibility that a VoIP 911 call may not automatically transmit the caller's number or location. The FCC's own guidance to subscribers is to consider a backup power supply, or to maintain a wireless phone as a backup.
For a clinic, translate that into policy: a designated, charged mobile phone with a known number that staff know to use for emergencies during an outage. Put the number on the outage runbook and on a sticker at the front desk. This is a two-dollar control that nobody implements.
A continuity runbook for the front desk
One page. Laminated. At the desk, not in a shared drive that requires the internet you no longer have.
- Confirm the scope. Is it power, internet, or the provider? Check whether mobile data works on a phone in the building.
- Activate failover. Note whether it is automatic (endpoint deregistration triggers the reroute) or whether someone must call the carrier. Write down who, and the account number they will be asked for.
- Answer on mobile. Named staff, named numbers, in order.
- Tell patients. A pre-written message for the website and the practice's messaging channel: we are open, phones are affected, here is the number to call.
- Emergencies. Point staff and patients at 911 from a mobile phone, not the desk handset.
- Log it. Start time, symptoms, ticket number, restoration time. This is what you will need for the vendor conversation and for your next risk analysis.
- After restoration: check voicemail-to-email backlogs, missed-call reports, and any queue that silently absorbed calls during the outage. This is where the abandoned callback lives.
What to ask your provider
- Where is the failover rule executed — on your platform, or upstream at the number's carrier? What happens if your platform itself is the outage?
- What triggers failover, and how long does it take to engage after our endpoints stop registering?
- Can we set a different failover destination per number, per queue, and per time of day?
- Can our staff change the failover destination without opening a ticket — from a mobile phone, with no office network?
- What happens to voicemail left during an outage, and where does it land afterward?
- Do you support a cellular backup path for our on-prem gateway or router?
- What is your notification path when you have an outage, and can it reach us by SMS?
Then test it. Pick a Tuesday, unplug the WAN, and see what actually happens to a call placed to the main number. The result of that ten-minute test is worth more than every uptime claim in the contract.
Common questions
Will our cloud phones work during an internet outage?
No. The FCC states plainly that VoIP service may not work during a power outage or when the internet connection fails or becomes overloaded. What can keep working is call delivery — if you have pre-configured a failover rule that reroutes inbound numbers to mobile phones when your endpoints stop registering.
Does HIPAA require a phone-system continuity plan?
If the phone system maintains ePHI — voicemail, recordings, messages — then the Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) applies, and its data backup, disaster recovery, and emergency mode operation specifications are required, not optional.
Can we still call 911 if the internet is down?
Possibly not from a VoIP handset. Keep a charged mobile phone with a known number designated for emergencies during an outage, and make sure staff know to use it.
Is a second internet provider enough redundancy?
Only if it follows a different physical path into the building. Two providers riding the same conduit fail together when a backhoe finds it. Ask where the fiber enters, and consider a cellular backup as the truly independent path.
Common questions
Will our cloud phones work during an internet outage?
No. The FCC states that VoIP service may not work during a power outage or when the internet connection fails or becomes overloaded. What can keep working is call delivery, if you have pre-configured a failover rule that reroutes inbound numbers to mobile phones when your endpoints stop registering.
Does HIPAA require a phone-system continuity plan?
If the phone system maintains ePHI such as voicemail, call recordings, or messages, then the Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) applies to it. Its data backup plan, disaster recovery plan, and emergency mode operation plan specifications are required, not addressable.
Can we still call 911 if the internet is down?
Possibly not from a VoIP handset. The FCC advises maintaining a wireless phone or backup power. Designate a charged mobile phone with a known number for emergencies during an outage and make sure staff know to use it.
Is a second internet provider enough redundancy?
Only if it follows a different physical path into the building. Two providers riding the same conduit fail together. Ask where the fiber actually enters the building, and treat a cellular backup as the genuinely independent path.