Disaster Recovery for Hospitals: Designing for EHR Outages
RTO and RPO are commitments, not aspirations. Setting them per clinical service, designing replication that ransomware cannot follow, and sequencing a restore that actually works.
GuardsArm Team
Security Experts
Disaster recovery is the engineering problem: what infrastructure exists so that a failed clinical system can be brought back, how quickly, and losing how much data. It is distinct from continuity — covered in the 72-hour plan — and conflating the two is why hospitals end up with a replication design and no ability to treat patients during the outage.
Set objectives per clinical service
Asking "what is our RTO" produces a number nobody can honour. Ask it per service, with the clinical owner in the room:
| Service | Realistic RTO | RPO | Why |
|---|---|---|---|
| EHR read access | 1-4 hours | Near zero | Safe care needs allergies and medications |
| EHR write / ordering | 4-12 hours | Minutes | Paper can bridge, briefly |
| PACS / imaging | 4-12 hours | Near zero | Diagnostic dependency; images cannot be recreated |
| Laboratory system | 2-8 hours | Minutes | Results drive immediate decisions |
| Pharmacy | 2-8 hours | Minutes | Medication safety |
| Scheduling | 24 hours | Hours | Disruptive, not immediately unsafe |
| Payroll / finance | Days | Day | Genuinely tolerable |
The exercise of writing this table is most of the value. It forces the conversation about what the organisation will actually pay to protect, rather than asserting that everything is critical.
Replication copies your problems faithfully
Synchronous replication protects against hardware and site failure. It offers no protection at all against ransomware, corruption or a bad change, because it replicates those too — instantly, by design.
The distinction that matters: can an attacker holding domain administrator credentials destroy this copy? If yes, it is availability infrastructure, not recovery infrastructure. Immutability and separate credentials are what move a copy into the top tier.
Restore sequencing
Clinical systems have dependency chains, and the order is not obvious under pressure. Write it down before you need it.
What to verify annually
- Recovery of a domain controller, from backup, in isolation
- Database restore with a consistency check, not just a successful copy
- That the immutable copy genuinely cannot be deleted by an administrator
- That recovery credentials are available when the primary credential store is down
- That the documented sequence matches reality — run it and time it
- That interfaces come back and exchange real messages
Where to start
Pick your most critical clinical system and answer one question: if an attacker had domain administrator rights for an hour, which copy of its data would survive? If the answer is "none", that is the gap, and it is a funding conversation rather than a process one.
For whether those copies restore, see backup testing.
GuardsArm assesses clinical recovery architecture including immutability verification and restore sequencing. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “Disaster Recovery for Hospitals: Designing for EHR Outages”
Talk to the GuardsArm team about how these services apply to your environment.
