Healthcare: The Most Expensive Sector to Get Wrong

For more than a decade, healthcare has been the most expensive industry in the world in which to suffer a data breach. The 2026 IBM Cost of a Data Breach Report, released in July, again places it top of every sector at an average of $6.64 million per incident - and that is after a 10.5% year-on-year fall from $7.42 million.

Context matters for that number. The same study puts the global average across all industries at $4.99 million, up 12% and the highest figure in the report's 21-year history. In the United States the average reached $11.5 million. Healthcare is not top of that table because it is careless. It is top because of what it holds, how care is delivered, what it is required to protect, and the consequences when critical systems are disrupted.

Why healthcare's cloud problem has a different shape

Three characteristics compound in a way they do not in most other verticals.

The data is unusually rich and unusually permanent.

A payment card can be reissued in a day. A medical history cannot. Protected health information carries diagnoses, identifiers, insurance details and family relationships, and it stays valuable to an attacker indefinitely.

The estate spans two very different worlds

Healthcare still depends on legacy clinical systems that can be difficult and risky to change, particularly when they support critical care delivery. At the same time, research, analytics, imaging and digital health initiatives are introducing modern cloud infrastructure at a much faster pace. Those newer environments increasingly need access to data and systems that were historically local, segmented or never designed for broad connectivity. Every new connection brings identities, permissions, storage configurations and network paths that have to be governed carefully.

Third-party access makes that complexity harder to govern

Healthcare depends on a broad ecosystem of researchers, universities, pharmaceutical companies, technology providers and business associates. Many need access to sensitive data, connected systems or cloud environments as part of research, care delivery and healthcare operations. The challenge is not simply granting that access. It is keeping everyone aligned as security requirements, architecture decisions and guardrails change.

Those changes are often communicated through documentation, email, onboarding sessions or internal guidance. But communicating a requirement does not guarantee that every external team has seen it, understood it or will apply it correctly when the next change is made. As the number of identities, partners and workflows grows, relying on awareness alone becomes increasingly difficult. That is where enforcement at the point of change matters: the policy travels with the environment, rather than depending on every person involved to remember the latest rule.

Put those together and you get an environment where a large amount of highly sensitive data is being placed into cloud resources quickly, by many parties, under a compliance regime that holds the covered entity responsible for all of it.

What the experts are saying

Three assessments worth reading together, because they describe the same problem from different angles.

HHS is framing this as clinical risk, not IT risk

‍Announcing the proposed Security Rule update, Deputy Secretary Andrea Palm stated that "the increasing frequency and sophistication of cyberattacks in the health care sector pose a direct and significant threat to patient safety." That framing - safety rather than privacy - is what drives regulatory urgency.

Gartner has been consistent on where cloud failures originate

‍Its assessment is that through 2027, 99% of records compromised in cloud environments will be the result of user misconfigurations rather than attacker sophistication or provider failure.

The Cloud Security Alliance points at the operating model

‍In its Top Threats to Cloud Computing 2026, published in August, working group chair Michael Roza observes that the most exposed organisations are "the ones whose governance, visibility, and change management have not kept pace with the complexity of their environments." The same report ranks Inadequate Identity and Access Management as the number one cloud threat.

Read them in sequence and the argument assembles itself. The regulator frames the issue as patient safety. The analyst points to configuration as a major source of cloud risk. The research body points to governance, visibility and change management struggling to keep pace with increasingly complex environments.

Healthcare offers a useful parallel. Medicine isn’t satisfied with better diagnosis alone. It works to stop illness before it develops, because treating illness only after it appears means always playing catch-up.

Cloud security has the same problem: when risky changes land faster than they can be detected, the backlog grows until something gets through. To be clear, detection and visibility still matter. But finding risk after it has been introduced is not enough. The stronger control is to govern change as it happens and prevent unsafe configurations from being created in the first place.

That distinction matters even more in healthcare. A payment card can be reissued in a day. A medical history cannot.

The regulatory picture, stated accurately

There is a lot of noise about HIPAA changes, so it is worth being precise, because vendors have been overstating this. OCR announced a Notice of Proposed Rulemaking on 27 December 2024, published in the Federal Register on 6 January 2025. The comment period closed on 7 March 2025 with several thousand submissions. It would be the first substantial overhaul of the Security Rule since 2003.

As of mid-2026 it remains proposed. No final rule has been issued. OCR's regulatory agenda originally indicated May 2026; that date passed, and OMB now shows final action targeted for July 2027. A coalition of more than 100 organisations led by CHIME wrote to HHS in December 2025 urging full withdrawal, citing cost - HHS's own regulatory impact analysis estimated roughly $9 billion in first-year industry cost.

So nothing has changed yet. What has not changed either is OCR's enforcement posture under the existing rule, which continues.

What the proposal would require is the more interesting part:

• Encryption of ePHI at rest and in transit, with limited exceptions
• Multi-factor authentication for systems accessing ePHI
• Network segmentation to limit access and prevent lateral movement
• A written technology asset inventory and network map, updated annually
• Vulnerability scanning at least every six months and annual penetration testing
• Incident response and restoration within 72 hours

And structurally, the proposal would remove the "required" versus "addressable" distinction. Today, some safeguards can be treated as addressable, allowing an organisation to document why an alternative measure is reasonable and appropriate. Under the proposal, nearly all specifications would become required.

That changes the operational question. If encryption, segmentation or another safeguard is required, detecting that a resource was deployed without it tells you there is a problem - but only after the non-compliant state already exists. The stronger model is to make the required configuration a condition of deployment, so the resource cannot be created in that state in the first place.

The observation worth taking from that list

Look again at what is being proposed. Encryption at rest. Encryption in transit. Network segmentation. Asset inventory. Access control. Almost every one of those is a configuration state, not an activity.

They are not asking for more monitoring. They are asking for resources to be in a particular condition - and to be able to demonstrate that they are, continuously, across an estate that is growing and changing.

That is a meaningful distinction for how you approach it. If encryption at rest is addressable, you can document a justification. If it is required, then a storage account deployed without it is a finding the moment it exists, and remains one until somebody fixes it. Multiply that across a hybrid estate with dozens of business associates provisioning resources and the remediation queue becomes the compliance risk.

The alternative is to make the non-compliant version undeployable. A resource that cannot be created without encryption enabled never appears in the gap analysis, never enters the remediation backlog, and never needs an exception documented. The same logic applies to the asset inventory requirement. An inventory is far easier to maintain when the estate cannot contain configurations you would not have approved.

The business associate problem

The third-party dimension deserves its own note, because it is where healthcare differs most sharply from other verticals.

The proposed rule increases verification and documentation obligations on business associates and makes subcontractors directly subject to requirements. But the practical exposure has always run ahead of the paperwork: a business associate operating in your cloud tenancy creates resources under your compliance obligation, using their own working practices, on their own timeline.

Questionnaires and BAAs establish what a vendor says. They do not observe what their infrastructure looks like on a Tuesday afternoon when someone needs a storage account quickly. This is CSA's number three threat for 2026 - Insecure Third-Party Resources, up from fifth - and in healthcare it is not an edge case. It is the operating model.

What a healthcare CISO told us

We asked a customer in this exact position what changed after deploying preventive enforcement.

“Being able to manage it all from a single place, including the exceptions, is a game changer. We used to struggle so much with blocking. Aryon makes it effortless.”

CISO, Healthcare, US”

The phrase worth noticing there is “we used to struggle so much with blocking.” That is the recognizable failure mode. Healthcare organizations rarely lack the policy - they know what should be enforced. The challenge is turning enforcement on across an estate that may already contain non-compliant or fragile systems without disrupting something clinicians depend on. Nobody wants a security control to interfere with a system supporting critical care.

The result is predictable: enforcement is postponed, risky configurations make it into the environment, and teams are left managing an ever-growing remediation backlog.

How Aryon helps

Aryon enforces cloud security policy at the moment of change, at the cloud control plane, so risky configurations can be stopped before they enter the environment.

For a regulated health system, that maps directly onto the constraints above:

Compliance requirements become deployment conditions

Encryption at rest and in transit, restricted public access, required private endpoints and permitted regions for data residency can be enforced as resources are created or changed, preventing a non-compliant configuration from becoming another finding to remediate.

You see the impact before you enforce

Aryon assesses how a policy would behave against the organisation’s real environment and shows what it would have prevented before enforcement is enabled. Security teams can understand the potential impact, tune the policy and introduce enforcement with far greater confidence.

Existing production infrastructure is not auto-remediated

Aryon does not modify running resources to bring them into compliance. Instead, enforcement applies at the point of change, addressing the concern that introducing stronger controls could unexpectedly alter systems clinicians already depend on.

Policy applies consistently at the point of change

Whether a change comes from an internal platform team, a researcher, an external collaborator or another authorised workflow, the security requirement does not depend on everyone remembering the latest document, email or architecture standard. The policy is evaluated when the change is attempted, with immediate feedback when it does not meet the organization’s requirements.

Evidence becomes continuous

Rather than relying only on a point-in-time assessment before an audit, teams can demonstrate which policies were applied and which risky configurations were prevented as the environment changed.

‍