Protecting Patient Data During Processing: What HIPAA Won’t Require (But You Should)

A healthcare provider looking at a tablet with symbols representing encryption and the HIPAA Act

Protecting patient data during processing is the part of the healthcare encryption conversation that regulators have been circling for years without landing on.

In January 2025, the Biden administration published proposed HIPAA Security Rule amendments that would have strengthened encryption requirements significantly. Two weeks later, a presidential transition and a regulatory freeze put those amendments in limbo. As of mid-2026, their fate is uncertain. The rule could finalize, be slimmed down, or be quietly withdrawn.

What is not uncertain: the breach landscape is not waiting for the regulatory calendar to sort itself out.

The Phrase That Created False Confidence

“End-to-end encryption” is a marketing phrase. It sounds comprehensive; it describes something much more narrow and incomplete.

It protects data at the two ends of its journey: at rest in storage and in transit between systems. What it does not protect is the middle; the moment data is actively being processed by an application. When a clinical system queries a patient record, runs an eligibility check, processes a claim, or trains a machine learning model, the data must decrypt for the application to function.

That window is when attackers with authenticated access find plain-text data they can read, select, and steal.

Every major healthcare breach in recent memory exploited this gap. The entry point varied. The vulnerability was the same. As we covered in The Encryption At Rest Myth, this is not a product deficiency unique to any one vendor. It is a fundamental characteristic of how standard encryption works.

What HIPAA Does and Doesn’t Require on Encryption

HIPAA’s encryption specification under 45 CFR §164.312 is an addressable control. Not required; addressable. It applies to data at rest and in transit. It says nothing about data during active processing. The rule was written before continuous encryption technology existed at enterprise scale; it reflects the threat model of 2003, not 2026.

The proposed 2025 amendments would have changed that. They would have eliminated the “addressable” flexibility, made all implementation specifications mandatory, and pointed toward stronger encryption standards throughout the data lifecycle. That was meaningful progress.

Those amendments are currently frozen. Industry associations pushed back hard; a coalition led by CHIME petitioned HHS to withdraw the rule entirely. The current administration’s regulatory posture has not been favorable to expanding compliance burdens. A slimmed-down version may still emerge in 2026. It may not. Healthcare organizations that have calibrated their encryption posture to the regulatory minimum have made a security decision based on a timeline no one can predict.

That is not a risk management strategy. It is a waiting game with patient data as the stake.

What Protecting Patient Data During Processing Actually Requires

Closing the processing gap requires encryption that stays in place while data is active. Not just at rest; not just in transit. During every query, every report, every analytics run, every AI inference call.

Continuous encryption keeps data encrypted throughout its entire lifecycle. Operations run against encrypted fields. Queries return ciphertext unless the authorized application transforms them. A clinician sees what they are authorized to see; an attacker with that same clinician’s credentials finds nothing readable.

This is not experimental architecture. It deploys within existing data systems without requiring application rewrites or infrastructure replacement. The cryptographic capabilities that make it practical at enterprise scale did not exist when HIPAA was written. They exist now.

The Medtronic Problem Is Every Healthcare Organization’s Problem

ShinyHunters lifted nine million records from Medtronic’s IT systems and is threatening public release unless Medtronic pays their extortion demand. The vulnerability was the decrypt-to-use gap; the same gap documented in the Anthem breach in 2015, the Change Healthcare disclosure in 2024, and every major healthcare breach in between. The variable was the entry point. The constant was the data in plain text at the application layer. The full case study is in Medtronic and the Healthcare Encryption In Use Gap.

Healthcare CISOs read disclosures like this with a particular kind of dread. HIPAA notification deadlines. State AG requirements that do not align with federal timelines. FDA attention for medical device manufacturers. Class-action plaintiff firms primed to respond. Every variable on the desk multiplies.

The question is not whether your organization is at risk. Every healthcare organization whose applications decrypt data during processing is at risk; which is virtually every organization running standard database infrastructure. The question is whether you close the gap before your name appears in the disclosure.

The Business Case Is Not Complicated

Organizations that have implemented processing-layer encryption are also presenting materially lower risk profiles to cyber insurers at renewal. Underwriters are increasingly asking about data-in-use protection; not just at rest and in transit. The organizations that can answer yes to that question are pricing differently than those that cannot.

For a full breakdown of what breach costs look like across the healthcare sector and what reduces them, see How Much Does a Data Breach Cost?.

The Question Worth Asking Your Security Team

Pull your most recent breach risk assessment and find the line item for encryption controls. Ask your security team, in writing, two questions.

When our application is reading patient data to serve a query, is that data decrypted at any point?
If it is, what would an authenticated but malicious actor be able to see?

If the answer to the first question is yes and the answer to the second is “the data,” your encryption posture is leaving you exposed at the moment that matters most. Regulation may or may not close that gap for you. The technology to close it yourself is available now.

The technology is ready. The business case is clear. The time for action is now.

If you are working on the encryption-in-use question for your healthcare environment and want to see how Donoma Seshat addresses it, book a no-obligation solution briefing today.

Frequently Asked Questions

What does protecting patient data during processing actually mean?

It means keeping patient data encrypted while a healthcare application is actively using it. Not just when it is sitting in a database at rest, and not just when it is moving between systems in transit. During the moments when clinical decision support is running, when billing systems are processing claims, when analytics pipelines are generating reports: the data stays encrypted. An attacker with authenticated access finds ciphertext. There is nothing readable to extract, nothing to ransom, no notification obligation triggered.

Why is “end-to-end encryption” a misleading term in healthcare?

“End-to-end encryption” is a marketing phrase that sounds comprehensive but describes something narrower than it implies. It protects data at the two ends of its journey: at rest in storage and in transit between systems. The middle is unprotected. The moment a healthcare application queries a patient record, generates a report, or processes a claim, the data must decrypt. That window is when attackers find usable plain-text data. Every major healthcare breach in recent memory exploited this same gap. The phrase sounds like total coverage. It is not.

Does HIPAA require encryption of data during processing?

No. HIPAA’s encryption specification under 45 CFR §164.312 is an addressable control that applies to data at rest and in transit. It does not address data during active processing. The proposed 2025 HIPAA Security Rule amendments would have strengthened encryption requirements, but those amendments entered regulatory limbo after the January 2025 presidential transition and their final status remains uncertain as of mid-2026. Healthcare organizations that wait for regulation to mandate processing-layer encryption are making a security decision based on a regulatory timeline they cannot predict.

What is the encryption gap and how does it apply to healthcare specifically?

The encryption gap is the window during which healthcare data exists in plain-text form because it must be decrypted for applications to function. In a hospital system running 24/7 operations, that window is effectively continuous. Clinical decision support, billing, telemetry, analytics, AI inference: all of these require data to be readable at the application layer. The gap is not a product deficiency; it is a fundamental characteristic of how standard encryption works. Healthcare carries extra exposure because the data profile combines permanent identifiers with clinical information that cannot be changed or cancelled after a breach.

How does continuous encryption affect clinical workflows?

It does not. Authorized clinicians, administrators, and systems work exactly as they always have. The encryption operates below the application layer. What changes is what an attacker finds if they breach the perimeter or if an insider with valid credentials attempts to extract data: encrypted ciphertext with no usable value. Medical device telemetry continues to flow. Clinical systems perform normally. Billing runs uninterrupted. The protection is invisible to legitimate users and absolute to anyone attempting to exploit access.

What is the cost case for continuous encryption in healthcare?

Healthcare breaches averaged $7.42 million per incident in 2025 according to IBM’s Cost of a Data Breach Report; the highest of any industry studied for fourteen consecutive years. That figure does not include multi-year reputational damage, lost patient trust, or the regulatory and litigation tail that follows a breach of clinical data. The cost of a continuous encryption deployment is a fraction of a single breach event. Organizations that have implemented it are also presenting materially lower risk profiles to cyber insurers at renewal, with corresponding premium implications.