The decision to pay a ransomware demand is one of the most consequential choices a home health administrator will ever face — made under enormous time pressure, with incomplete information, while clinical operations are disrupted and staff are anxious. I have supported home health agencies through this decision many times. My recommendation is consistent: do not pay. Not primarily for ethical reasons, though those matter. For practical ones: paying does not reliably restore operations, does not prevent data publication if double extortion is involved, and funds the infrastructure that will be used to attack the next organisation.
The alternative to paying — recovery from clean backup — only works if the backup architecture was designed to survive a ransomware attack. Standard backups fail against ransomware for a predictable reason: they are connected to the production environment. When ransomware spreads through an agency's network, it finds and encrypts backup files alongside production files, because the backup location is mounted to the same network the ransomware traverses. The agencies that pay ransoms are almost always agencies whose backups were not immutable, not isolated, or not tested.
The Backup Architecture That Enables No-Pay Recovery
Immutability: The Non-Negotiable Requirement
An immutable backup is a backup that cannot be modified or deleted during a defined retention period — by any account, including administrator accounts. The immutability is enforced at the storage layer, not by software that can be disabled by an account with sufficient privileges. Cloud object storage with object lock enabled — AWS S3 with Object Lock in Compliance mode, Azure Blob Storage with immutability policies, Wasabi with object lock — provides genuine immutability. An attacker with full administrative credentials over the agency's environment cannot modify or delete an immutable backup during the lock period.
The retention period for immutable backups should be set to at least 35 days — which covers the typical ransomware dwell time of 14–28 days plus a buffer. This ensures that at least one backup copy predates the initial compromise, giving the recovery team a clean restore point that was captured before the attacker had any presence in the environment.
Isolation: Physical and Logical Separation
Immutability prevents modification of existing backup files. Isolation prevents the ransomware from reaching the backup location to attempt modification in the first place. True isolation means the backup storage is not accessible from the production network during normal operations — it is only connected during the backup window, and the connection is initiated by the backup process (not continuously mounted). For cloud-hosted home health environments, isolation is achieved through separate cloud accounts, separate authentication contexts, and backup processes that authenticate temporarily during the backup window without maintaining persistent connectivity.
Tested Restoration: The Difference Between Having a Backup and Being Able to Recover
A backup that has never been restored is an assumption. Backup software can fail silently, generating completed backup jobs while creating corrupted or incomplete backup sets. The only way to know your backup works is to restore from it and verify the restored data. Test quarterly: restore a sample of data from the backup to a non-production environment, verify the integrity of the restored files, and document the restoration time. The annual full restoration test — restoring all critical systems to a non-production environment and verifying operational function — provides the recovery time objective validation that business continuity planning requires.
The First 72 Hours of No-Pay Recovery
When ransomware is detected and the decision is made not to pay, the 72-hour recovery protocol begins:
• Hours 0–4: Forensic preservation. Before any recovery action, the forensic team preserves the evidence needed for insurance claims, OCR investigation, and law enforcement. Do not start the recovery until the forensic team clears you to do so.
• Hours 4–24: Recovery environment preparation. Restore from the most recent clean backup (before the earliest confirmed attacker activity) to a recovery environment — cloud-based if possible for speed. Verify restoration integrity before connecting recovery systems to the network.
• Hours 24–48: Clinical systems restoration. Bring the EHR and clinical communication systems live in the recovery environment. Activate clinical downtime procedures to bridge the gap between the attack and the clinical systems becoming available.
• Hours 48–72: Full operational recovery. Restore billing, scheduling, and administrative systems. Begin catching up on billing backlog with awareness of Medicare filing deadlines. Patch the vulnerability exploited in the attack before reconnecting any system to external networks.
Protecting your home health agency does not have to be complicated. It has to be done — completely, correctly, and documented in a way that holds up when it matters. ShieldForce makes that possible for organisations without IT departments, without compliance staff, and without the budget of a hospital system. Start with a free assessment.
→ Schedule Your Free HIPAA Risk Assessment — shieldforce.io/hipaa-assessment
→ Explore Home Healthcare Cybersecurity — shieldforce.io/home-healthcare
→ View Transparent Pricing from $35/user/month — shieldforce.io/pricing-comparison