Business Continuity, Disaster Recovery, and Backup
Business continuity questions test impact analysis, recovery objectives, and proof that backups restore. eHealth systems are clinical safety systems: downtime can harm patients, so manual procedures matter.
Core rules
A business impact analysis identifies critical services, dependencies, and maximum tolerable downtime. Set RTO, time to restore, and RPO, acceptable data loss, per system. ISO 22301 provides the BCMS structure. HIPAA contingency planning requires a data backup plan, disaster recovery plan, emergency-mode operations plan, and testing and revision. Use 3-2-1 backups: three copies, two media types, one offsite or immutable. Protect backups from ransomware with offline or immutably locked copies and separate credentials. Test restores, not just backups. Document manual downtime workflows and crisis communications.
Worked example
The EHR has an RTO of 4 hours and an RPO of 15 minutes. Design: a high-availability pair in two zones, asynchronous replication with a 15-minute lag, hourly snapshots, and nightly immutable backups. Quarterly restore tests prove a full recovery in 3 hours 20 minutes. A ransomware tabletop reveals that the backup console uses the same domain admin account; the team splits credentials and enables MFA. Reasoning: RTO and RPO drive architecture; restore testing proves the control; credential separation closes a ransomware path.
Traps
Confusing RTO and RPO. Backups that are never restored. Assuming the SaaS vendor covers all recovery. Storing backups on the same domain. No manual downtime procedures. Testing only the plan document, not the recovery.