Kettering Health Refused to Pay the Ransom. The Data Leaked Anyway: What 1.7 Million Exposed Records Teach About Ransomware and HIPAA

There is a widespread assumption in healthcare that refusing to pay a ransom is the end of the story, that holding the line denies the attacker their payday and contains the damage. The Kettering Health breach is a hard correction to that assumption. Kettering refused to pay. The attackers leaked the data anyway. Roughly 1.7 million people had some of the most sensitive information they possess, including passport numbers and account credentials, published by a criminal group. And the organization's HIPAA obligations were exactly the same as they would have been if it had paid.

This case is worth understanding precisely because Kettering's decision not to pay was defensible, even commendable. The lesson is not that they made the wrong call. It is that the ransom decision and the breach obligations live in two separate worlds, and confusing them is dangerous.

What happened

Kettering Health is a health system based in Ohio. Its network was first breached in early April 2025. The intrusion went undetected for weeks. On May 20, 2025, the Interlock ransomware group deployed ransomware across the environment, the point at which the attack became visible.

By then, the attackers had already done the damage that mattered most. Interlock claimed to have exfiltrated a large volume of data, reported at hundreds of gigabytes. Kettering refused to pay the ransom. In response, Interlock did what ransomware groups now routinely do when payment is refused: it published the stolen data.

It took months to analyze the affected files and determine who was involved. A revised total provided to OCR in 2026 indicated that roughly 1.7 million individuals were affected.

The severity of what was exposed

Not all breaches are equal, and the Kettering data set sits at the severe end of the spectrum. The exposed information reportedly included names, Social Security numbers, financial account numbers, driver's license numbers, passport numbers, medical and treatment information, health insurance information, billing and claims data, and in some cases usernames with associated passwords.

Two elements stand out as unusually dangerous.

Passport numbers are rarely exposed in healthcare breaches, and they are durable, high-value identity documents that are difficult to reissue and useful for sophisticated identity fraud. Their presence raises the real-world harm well above a typical breach.

Exposed credentials are arguably worse. When usernames and passwords are leaked, the breach stops being purely a privacy event and becomes an active security threat. Attackers can use those credentials directly, and because password reuse is rampant, the exposure can cascade into other systems and services the affected individuals use. Credential exposure also creates a path back into the breached organization itself. This is data that demands forced resets and active monitoring, not just a notification letter.

The lesson covered entities miss: the ransom decision is separate from your obligations

Here is the point at the center of this case. Whether or not to pay a ransom is a complex operational, ethical, and financial decision. The FBI generally discourages payment, because it funds criminal enterprises and does not guarantee data recovery or deletion. Many organizations, like Kettering, decline to pay for exactly these reasons.

But that decision has no bearing on your obligations under the HIPAA Breach Notification Rule.

Once protected health information has been acquired or accessed without authorization, a breach has occurred under HIPAA.

OCR's guidance is explicit that a ransomware infection of a system containing electronic PHI is a presumed breach, because the data has been accessed by the malware in a manner the Privacy Rule does not permit. That presumption can only be overcome by a documented assessment showing a low probability that the PHI was compromised. And when data is not merely encrypted but exfiltrated and published, as it was here, there is no presumption to rebut. The breach is definitive.

This means the notification clock, the duty to notify affected individuals, the duty to notify HHS, and the duty to notify the media for breaches over 500 individuals, all run regardless of whether a ransom was paid. Refusing to pay does not pause the clock, reduce the obligation, or undo the exposure. A covered entity that believes declining to pay somehow contains the incident from a compliance standpoint is operating on a dangerous misunderstanding.

The other lesson: the weeks before the ransomware

The ransomware deployed on May 20. The network was breached in early April. That gap, several weeks of undetected access, is where the real damage happened. By the time the encryption made the attack visible, the data had already been taken.

This is the pattern in nearly every major healthcare breach: the visible event, the ransomware, is the end of the intrusion, not the beginning. The exfiltration that creates the breach happens quietly, in the dwell time before detection. Reducing that dwell time, through monitoring, segmentation, and detection capabilities identified in a thorough risk analysis, is what limits how much data leaves before an attacker is caught.

OCR has made the risk analysis the centerpiece of its enforcement posture for exactly this reason. The agency's consistent position is that the failure to identify and address vulnerabilities before an attacker exploits them is itself the violation. An organization that cannot show it assessed its risks and acted on them is exposed on two fronts at once: to the attacker and to the regulator.

What covered entities should take from this

Decouple your ransom planning from your breach planning. Have a position on ransom payment worked out in advance, but never let it bleed into your breach-notification analysis. The moment PHI is exfiltrated, your notification obligations are fixed, independent of the payment decision.

Treat exfiltration as the breach, not encryption. Build your incident response around the assumption that data left the building before you saw the ransomware. Your forensic priority is determining what was taken, because that is what defines your notification scope.

Treat exposed credentials as an active threat. If a breach involves usernames and passwords, force resets immediately, watch for account-takeover activity, and assume the credentials are being used elsewhere. This is incident response, not just disclosure.

Invest in shrinking dwell time. The weeks between intrusion and detection are where breaches are made. Monitoring, network segmentation, and the detection controls your risk analysis should identify are what limit how much data an attacker can take before you respond.

Keep your risk analysis current and documented. When OCR investigates a breach of this size, the first question is whether you conducted an accurate, organization-wide risk analysis and acted on it. That documentation is your position in both the security fight and the regulatory one.

The takeaway