Why Cyber Insurance Claims Get Denied: What Home Health Agencies Must Document
cyber insurance

Why Cyber Insurance Claims Get Denied: What Home Health Agencies Must Document

Cyber insurance claim denial rates in healthcare are rising. Here is why claims fail — and the documentation home health agencies must maintain to win claims when it matters most.

A home health administrator in Ohio told me about her cyber insurance experience in early 2025. Her agency had carried a $1 million cyber liability policy for three years. They experienced a ransomware attack, incurred $340,000 in forensic, legal, and notification costs, filed a claim — and received $0. The insurer denied the claim on the basis that the agency had misrepresented its security controls in the application. Specifically: the application had stated that MFA was enforced on all remote access. MFA was available but not enforced — staff who chose not to enrol could still log in without it. The attacker used a credential stolen through phishing and authenticated without MFA. The insurer argued that the control was not in place as represented.

I have seen this pattern many times. Agencies that purchased cyber insurance in good faith, that believed they had the controls their applications described, and that discovered in the worst possible moment that "available" and "enforced" are not the same thing to an insurance adjuster. The denial was not technically fraudulent on the agency's part — it was a good-faith misrepresentation of the implementation status of a control. But the outcome was the same: no coverage when coverage was needed most.

The Four Most Common Reasons Healthcare Cyber Insurance Claims Are Denied

Reason 1: MFA Was Available But Not Enforced

This is the single most common denial basis I encounter in healthcare cyber insurance claim disputes. Underwriting applications ask whether MFA is implemented. The honest answer for many home health agencies at the time of application is that MFA is available — it has been enabled in the system settings — but enforcement is inconsistent. Staff who complete enrollment have MFA; staff who skip enrollment bypass it with username and password alone. From the underwriter's perspective, this is not MFA enforcement — it is MFA availability, which is materially different and which was not what the application stated.

The correct documentation: a configuration report from your identity platform showing that MFA is enforced through conditional access policy for 100% of accounts with ePHI access, with no bypass exceptions. A report showing 94% MFA enrollment is a report showing 6% of accounts are unprotected. Confirm enforcement, not enrollment.

Reason 2: EDR Was Not Deployed on All Endpoints

Applications state that behavioral EDR is deployed on all endpoints. The adjuster's investigation reveals that EDR was deployed on office workstations but not on the field nurse tablets and personal smartphones that also access ePHI. The attack entered through one of the unprotected endpoints. The application's statement that EDR was deployed on "all endpoints" was technically inaccurate when "all endpoints" is defined to include every device that accesses ePHI.

Reason 3: Backup Was Not Isolated or Was Not Tested

Applications describe backup procedures. The incident reveals that the backup was encrypted alongside production systems because it was connected to the production network — it was not isolated. Or the backup existed but had never been tested for restoration, and the restoration process failed during recovery. Both situations allow the insurer to argue that the backup capability represented in the application did not exist in practice.

Reason 4: The Security Controls in Place Did Not Match the Application

This is the broadest category and the one that encompasses the others: the application described a security posture that the agency believed it had but that post-incident investigation revealed it did not. The gap is almost always between what the security programme document says and what is actually implemented.

The Documentation That Protects Your Claim

The documentation package that prevents these denial scenarios is the same documentation that HIPAA requires you to maintain: current configuration reports confirming each control is actually enforced (not just configured); MDM compliance reports showing device fleet status at the time of the claim period; penetration test and vulnerability scan results with remediation evidence; and training completion records. Maintain these as a standing, dated file — not assembled at application time and then forgotten.

Protecting your home health agency starts with understanding exactly where you stand today. ShieldForce delivers a free, no-obligation HIPAA Risk Assessment — thirty minutes with a healthcare cybersecurity expert who has spent three decades inside this industry. You will leave with a clear picture of your gaps, your priorities, and what a fully managed security programme looks like for an organisation exactly like yours.

Schedule Your Free HIPAA Risk Assessment — shieldforce.io/hipaa-assessment

View Transparent Pricing from $35/user/month — shieldforce.io/pricing-comparison

Share this post

Topics

#cyber insurance#home health#HIPAA compliance#documentation#MFA#EDR#Analysis
Free Security Assessment

Ready to Secure Your Business?

Don't let cyber threats put your business at risk. Discover how ShieldForce protects organizations like yours — 24/7.