Two numbers explain most of what has gone wrong in healthcare data security, and neither of them is about the electronic health record.
American Hospital Association cyber analysts have found that more than 80 percent of stolen patient records in recent years came from third party vendors, business associates, and non hospital providers rather than from hospitals themselves. More than 90 percent of hacked records were held outside core EHR systems entirely, in cloud file shares, email accounts, and backup repositories.
Read those together. The record system is comparatively well defended, and the data has been leaving it for years, accumulating in places nobody drew on the architecture diagram.
This article is an audit rather than an argument. Set aside an afternoon, open your infrastructure, and work through the list. The locations are ordered by how frequently they are missed rather than by how much data they hold.
A disclosure before we start, because it is relevant. Woltrio builds software for healthcare organisations, which makes Woltrio a business associate. The category creating most of the current risk is the category we are in. That is a reason to be precise about this, not a reason to avoid writing it.
1. Application logs
The most commonly missed location, and the easiest to create.
Engineers instrument aggressively during a build. Request payloads get logged for debugging, error handlers capture full objects, and a log line written to diagnose a problem in week three is still running in production two years later. If the payload contained a patient record, the log store now holds protected health information, usually with broader access permissions and shorter retention discipline than the database it came from.
How to find it. Search your log aggregation platform for a known test patient identifier. If it returns anything, you have your answer, and probably more than one system to fix.
2. Message queues, dead letter stores, and integration middleware
Anything that failed to process is still sitting somewhere.
Integration layers hold data in transit by design, and the failure paths are the problem. A malformed message routed to a dead letter queue stays there indefinitely, because dead letter queues are monitored for volume rather than emptied. The same applies to retry buffers and replay stores.
How to find it. Ask what the retention policy is on every queue in the estate. If nobody can answer for a given queue, that queue is your finding.
3. Non-production environments
Staging populated with a copy of production data, refreshed periodically, protected considerably less.
This is well known and still ubiquitous, because synthetic test data is genuinely harder to work with and the shortcut always looks reasonable in the moment. The controls on non-production are almost always weaker, and access is almost always broader.
How to find it. Ask how staging was seeded. The phrase to listen for is a sanitised copy, then ask what sanitised meant and who verified it.
4. Cloud storage misconfiguration
Overly permissive buckets, mis-scoped identity roles, long lived access keys, and sharing links that were never governed.
Misconfiguration is the quiet multiplier in this category, because it exposes data with no malware event at all and typically surfaces after long dwell time, which inflates how much was exposed by the time anyone notices. Configuration drift does the rest, since permissions granted for a migration in 2023 are rarely revoked in 2026.
How to find it. Enumerate every storage bucket, then every identity with read access to each. The gap between that list and the list of people who should have access is your exposure. This is standard cloud engineering hygiene and it is skipped constantly.
5. Analytics and reporting copies
Every dashboard is fed by something, and that something is usually a copy.
Analytics pipelines extract from source systems into warehouses, marts, and extracts that then get exported to spreadsheets. Each hop is a new copy with new permissions, and the last hop frequently lands on a laptop.
How to find it. Follow one metric backwards from a dashboard to its source, listing every intermediate store. Most organisations find at least one they did not know about.
6. Backups, and the ones from the system you retired
Backups are protected as an availability asset and rarely reviewed as a confidentiality one.
The sharper version is legacy backups. When a system is decommissioned, its data usually is not. Old servers, archives from acquired practices, and snapshots taken before a migration sit outside the current control environment while remaining fully in scope for HIPAA.
How to find it. List every system retired in the past five years and ask where its data went. Silence is a finding.
7. Your vendors, and their vendors
Now the largest category, and the fastest growing.
The federal breach portal shows business associate involvement in healthcare breaches averaging 20 percent from 2009 to 2017, 34 percent from 2018 to 2026, and reaching 43 percent in the first half of 2026. Close to half of reported healthcare breaches now involve a third party, on a trend line that has pointed the same direction for a decade.
The attacker arithmetic is simple. Compromising one small practice yields one practice worth of records. Compromising a billing company serving three hundred practices yields all three hundred, along with the vendor's privileged access into each client's systems. The target moved because the economics moved.
Recent events show the shape. The Change Healthcare breach ultimately affected 192.7 million individuals, more than double the Anthem breach and approaching two thirds of the US population. On a smaller scale, a healthcare analytics vendor compromised through phishing in January 2026 reported 1.4 million individuals affected, cascading notifications across multiple unconnected health systems. Notably, that vendor uses AI in its platform and the breach had nothing to do with the AI. It was ordinary third party risk.
How to find it. Inventory every vendor with access to protected health information, then ask each one which subprocessors they use. The second question is the one that rarely gets asked and frequently surprises people.
What the pattern actually says
Look back at the seven locations. Almost none of them are exotic.
The recurring finding in breach analysis is that exposure usually begins with a control failure that was testable all along: weak identity controls, poor authorisation, misconfiguration, flat networks, unmanaged vendor access, or inadequate review of what is exposed to the internet. Policy describes these risks. Testing establishes whether they are currently exploitable, and those are different activities.
There is a second pattern worth naming. Every location above is created by ordinary engineering work done for good reasons. Nobody decides to put patient data in a log file. It arrives there because someone was debugging, and it stays because nothing in the process asks the question again.
That is why this belongs in backend development practice rather than in an annual assessment. The decisions that create these locations are made at architecture and during delivery, and reviewing for them afterwards means finding data that has already been sitting somewhere for two years.
Where Woltrio fits
Woltrio builds healthcare systems and integration layers, which means Woltrio creates several of the locations on this list in the course of any project. The useful commitment is not that it never happens. It is that logging policy, queue retention, environment seeding, and storage permissions are decided deliberately and written down, rather than emerging from delivery pressure.
For clients, the practical version usually starts with the audit above rather than with a build. The output is a data map: every place protected health information exists, who can reach it, and how long it stays. That document is also what makes a genuine risk analysis possible, and its absence is one of the more common findings in enforcement actions.
Where the estate is large or the integrations numerous, that work extends into custom EMR and EHR development and the systems around it. Where it is mostly configuration drift, it is a smaller engagement than most clients expect.
Start with a scoped assessment from Woltrio.