Your healthcare data breach is not over when the letter arrives. That is when the damage gets personal.

I have lived a version of it.

An ex got access through a relative.

Not through some Hollywood cyberattack. Not through a genius hacker in a dark room. Through a human connection. Through trust misplaced, controls too loose, and a system that made deeply personal information accessible in ways it never should have been.

That is why I have very little patience for the polite corporate fiction that a healthcare data breach is mainly a privacy event, or a disclosure event, or a notification event.

It is a harm event.

It is a fraud event.

It is a “someone now has something intimate, useful, and hard to undo” event.

And that is the part too many organizations still glide past as if a year of credit monitoring and a templated apology somehow closes the file.

It does not.

Credit monitoring after a healthcare data breach is a bit like responding to a house fire with a discount on air fresheners. Nice gesture. Wrong emergency.

Because the real issue is not whether someone accessed the data.

The real issue is whether they can do anything with it.

Can they impersonate? Can they manipulate? Can they file false claims? Can they expose private details? Can they use medical, insurance, or benefits information as leverage, humiliation, or control?

If the answer is yes, then the breach is not the incident. The breach is the beginning of the incident.

That is what so much of this conversation still gets wrong. Organizations talk about containment, disclosure timelines, and regulatory obligations as though the problem ends when the report is filed. But for the person affected, that is often the moment the real problem starts.

And healthcare data is uniquely brutal that way.

You can change a password. You can cancel a card. You cannot exactly rotate your diagnosis, your treatment history, your prescriptions, or the deeply personal facts of your life that some system decided were convenient to centralize.

Once that kind of information is exposed, the harm is not theoretical. It is not abstract. It is not “consumer confidence risk.” It is invasive, durable, and personal. It follows people around long after the organization has moved on to its next quarterly update and its next reassuring sentence about taking privacy seriously.

We really need to stop pretending that breach response is the same thing as protection.

It is not protection if the data is still fully usable after it leaks. It is not protection if one insider, one family connection, one bad actor, or one sloppy access model can expose something whole and harmful. It is not protection if the victim is left carrying the consequences while the institution congratulates itself for mailing the notice on time.

That is not security.

That is administrative theatre.

And that is why the conversation has to move past “was there a breach?” to the much more uncomfortable question:

Once access happened, how much damage was still possible?

That is the real test of architecture. That is the real test of stewardship. That is the real test of whether an organization built for safety or just for optics.

Because once you have seen how access can be abused through something as ordinary as a relative, you stop being impressed by glossy language around trust, compliance, and care.

You start asking better questions.

Who can actually see this? Who can reconstruct it? Who can misuse it? Why is it concentrated like this? Why is it still so useful once exposed? And why, exactly, are we acting surprised when that goes badly?

Healthcare data breaches are still being treated like PR problems.

They are fraud problems. They are control problems. They are human damage problems.

And until organizations design for that reality, the breach letter is not a solution.

It is just the moment they formally hand the problem to you.

https://www.benefitnews.com/advisers/opinion/erisa-health-data-breaches-fuel-fraud-risk

Originally published by Ross Norrie, founder of SkyeConnex, on LinkedIn.

Published April 20, 2026 · More from the SkyeConnex blog