The HHS Office for Civil Rights publishes every healthcare data breach affecting 500+ people on a public portal. It's been running since 2009. Over 7,800 breaches. More than a billion records exposed.
I spent a few days going through recent entries. Reading the breach summaries, the OCR investigation outcomes, the settlement agreements. I wanted to see what actually causes these breaches. Not the broad categories the portal uses (it only has five: hacking, unauthorized access, theft, loss, improper disposal). The real causes underneath.
After about 50 entries, the pattern was obvious. The same seven things keep breaking. Repeatedly. Across hospitals, health apps, insurance companies, and every vendor in between.
The seven:
- Phishing emails that nobody caught
- Third-party vendors that nobody audited
- Website tracking pixels that nobody thought about
- Ransomware that encrypted everything including the backups
- Unencrypted devices that walked out the door
- Missing risk analysis (the OCR favourite)
- Unauthorised access from inside the building
1. Phishing emails that nobody caught
This one leads the list by a wide margin.
Phishing is the most common access vector in healthcare breaches, responsible for roughly 16% of all incidents. But the damage it causes is wildly disproportionate. The biggest healthcare breach in history, Change Healthcare at 192.7 million records, started with a phishing attack that gave attackers credentials to a portal that didn't have multi-factor authentication enabled.
That's worth reading again. 192.7 million patient records. One phishing email. No MFA on the entry point.
Numotion, a mobility equipment provider, reported in 2025 that attackers accessed employee email accounts through phishing between September and November 2024, compromising 529,000 patient records. Ascension Health, one of the largest health systems in the US, got hit in May 2024 after an employee downloaded a malicious email attachment.
The pattern: someone clicks a link or opens a file. The attacker gets credentials. They log in as a legitimate user. They sit in the mailbox for weeks or months, searching historical messages for PHI. Nobody notices.
A 2026 report from Paubox found that phishing-driven mailbox takeovers accounted for only 17% of healthcare email breaches but caused disproportionate harm, exposing over 630,000 patient records.
What this means for devs: if you're building a health app or platform, MFA isn't optional. It's the single control that would have prevented the largest healthcare breach in history. And if your app sends any PHI through email (appointment confirmations, test results, provider messages), your email handling needs encryption in transit at minimum.
2. Third-party vendors that nobody audited
This is the one that keeps getting worse.
In 2015, business associate breaches accounted for 5% of affected individuals. By 2025, that number was 65%. Two of the three largest healthcare breaches of all time happened at business associates: Change Healthcare (192.7M) and Conduent Business Services (62M+). Combined, those two incidents alone affected roughly 255 million people.
In the first half of 2026, 43% of healthcare breaches involved a business associate, up from a historical average of 34%.
The HHS portal entries tell the same story over and over. A clinic partners with an IT vendor. The vendor stores patient data on their own server. The server isn't encrypted. Or a health plan uses a third-party claims processor. The processor gets hacked. PHI from dozens of covered entities spills out simultaneously.
The MOVEit zero-day in 2023 is a textbook case. One vulnerability in a file-transfer tool cascaded through Welltok and downstream health plans, affecting millions.
What this means for devs: every third-party dependency in your health app is a potential breach vector. Your cloud host, your analytics provider, your email service, your payment processor. HIPAA requires a Business Associate Agreement with every vendor that touches PHI. But the BAA is a legal document. What actually prevents breaches is auditing what data those services can access and what they transmit. Most dev teams never do that audit.
3. Website tracking pixels that nobody thought about
This is the cause that blindsided the industry.
In 2022, a Markup investigation found that one-third of the top 100 US hospital websites had the Meta Pixel installed, including on patient portals and appointment scheduling pages. The pixel was transmitting data to Meta that included patient health information. Meta doesn't sign BAAs. Meta explicitly told healthcare organisations that Facebook is "not HIPPA [sic] compliant nor do we have a BAA."
Since then, the lawsuits and penalties have piled up. A consolidated analysis of tracking pixel cases from 2023 to 2025 found settlements and penalties totalling more than $100 million across 19 cases. Specific settlements include Inova Health ($3.1M), MarinHealth ($3M), University of Rochester Medical Center ($2.85M), and the GoodRx class action ($25M).
At least 664 hospital systems have been identified where Meta received patient data via the pixel.
OCR issued guidance in 2022 making it clear: using tracking technologies that result in PHI disclosure to third-party vendors is an impermissible disclosure under the Privacy Rule. Organisations that continue these practices risk being classified as "willful neglect."
What this means for devs: that Google Analytics snippet or Facebook pixel you add to every project? In a health app, it's a potential HIPAA violation. Any tracking code that sends identifiable data to a third party without a BAA and patient consent is a breach. Audit every script running on your health-related pages. If you can't document exactly what data each script transmits, remove it.
4. Ransomware that encrypted everything including the backups
Ransomware attacks on healthcare increased 278% between 2018 and 2023. By 2025, hacking and IT incidents accounted for more than 80% of all large healthcare breaches.
McLaren Health Care cancelled non-emergency appointments after a 2024 attack. Attackers had network access for over two weeks before detection. Frederick Health lost 900,000+ records to ransomware. Change Healthcare cost UnitedHealth Group over $872 million in recovery, disrupted billing across the entire US healthcare ecosystem for months, and left pharmacies unable to process claims.
What this means for devs: ransomware targets the infrastructure your app runs on. If your health app stores PHI on servers (and it does), your backup strategy needs to account for a scenario where the primary environment and its connected backups are both compromised. Isolated, tested, encrypted backups. Not just "we push to S3 nightly."
5. Unencrypted devices that walked out the door
This cause is declining. Only 6 endpoint-related breaches were reported in 2025, down from hundreds a decade ago. But the historical settlements explain why OCR takes it so seriously.
Advocate Health Care: four stolen unencrypted computers, 4 million patients, $5.55 million settlement. University of Rochester Medical Center: lost unencrypted flash drive and stolen unencrypted laptop, $3 million. Concentra Health: stolen unencrypted laptop, $1.7 million.
The URMC case is particularly painful. OCR had already investigated them in 2010 for a similar breach involving a lost unencrypted flash drive. They provided technical assistance. Seven years later, URMC reported another breach, same cause. Unencrypted mobile devices. The $3 million settlement reflected the fact that they knew encryption was a high risk and still didn't implement it.
What this means for devs: if your app stores any PHI locally (on a mobile device, in a desktop cache, in local storage) it needs to be encrypted at rest. AES-256. Not just the database. The local files, the cache, the logs. Everything. This is the easiest cause on the list to prevent, and the penalties for ignoring it are massive.
A minimal encryption config for local SQLite storage in a health app:
-- SQLCipher: AES-256 encryption for SQLite PRAGMA key = 'your-encryption-key'; PRAGMA cipher_page_size = 4096; PRAGMA kdf_iter = 256000; PRAGMA cipher_hmac_algorithm = HMAC_SHA512;If your local database doesn't require a key to open, it's not encrypted. That's the bar.
6. Missing risk analysis (the OCR favourite)
This one appears in almost every single OCR settlement. Not as the primary cause, but as the underlying failure that made the primary cause possible.
OCR's most common investigation finding is that the organisation failed to conduct "an accurate and thorough risk analysis that incorporates all IT equipment, applications, and data systems utilizing ePHI."
Triple-S Management settled for $3.5 million after OCR found failures including missing risk analysis, impermissible PHI disclosure, and lack of access controls. The Anthem breach ($16 million settlement, 78.8 million records) included "failure to conduct an enterprise-wide risk analysis" as a key finding.
The pattern: an organisation gets breached. OCR investigates. They find that the organisation never did a formal risk analysis, or did one years ago and never updated it. The risk analysis would have identified the exact vulnerability that got exploited. OCR treats this as evidence that the breach was preventable.
What this means for devs: if you're building a health app and you don't have a documented security risk analysis that covers every component touching PHI, you're already non-compliant before anything bad happens. This isn't a post-breach requirement. It's a pre-launch requirement. And it has to be updated whenever your architecture changes. New API, new vendor, new data flow, new risk analysis.
7. Unauthorised access from inside the building
Not every breach comes from outside. The HHS portal has a steady stream of "Unauthorized Access/Disclosure" entries that involve insiders: employees accessing records they had no reason to view, former employee credentials that were never deactivated, misdirected emails and faxes.
Memorial Healthcare System discovered that login credentials from a former employee of an affiliated physician's office were still active. They had been used for nearly a year without detection to access patient records. The scale was significant enough to require OCR investigation.
Hospital employees looking up celebrity patient records. Staff accessing an ex-partner's health information. A nurse checking a neighbour's diagnosis. These cases are smaller individually, typically affecting hundreds or thousands rather than millions. But they never stop. They appear on the portal every single month.
The OCR specifically noted that behavioural detection systems can now identify when employees access records without a legitimate work purpose. Organisations that don't have these controls are increasingly exposed.
What this means for devs: role-based access controls aren't enough. You also need audit logging on every PHI access event: who accessed what record, when, and from where. And you need someone (or something) actually reviewing those logs. An access log that nobody reads is the same as no log at all.
A proper PHI access log entry looks like this:
{ "timestamp": "2026-07-21T09:14:33Z", "user_id": "nurse_4421", "action": "VIEW", "resource": "patient_record:8837201", "patient_id": "8837201", "ip": "10.0.12.44", "reason_code": "TREATMENT", "session_id": "s-9f3a1b" }If your log doesn't include the user, the patient, and the reason, it won't hold up in an OCR investigation.
The pattern underneath the pattern
Seven causes. But if you zoom out, they share one root:
somebody knew the risk and didn't act on it.
URMC knew encryption was a high risk. They didn't encrypt. Change Healthcare knew MFA was essential. They didn't enable it on one portal. Hospitals knew the Meta Pixel transmitted data to Facebook. They kept it running.
The HHS portal isn't a list of sophisticated attacks defeating state-of-the-art defences. It's a list of known problems that nobody got around to fixing.
That's what makes it useful for developers. You don't need a threat intelligence feed to protect a health app. You need to address the seven things that have been causing breaches for 16 years and counting.
Healthcare QA and testing for healthcare applications specifically covers these failure modes. Every test plan accounts for the regulatory consequence, not just the functional outcome. But even without a formal testing program, running through these seven causes against your own architecture would catch most of what the HHS portal keeps recording.
Further reading
HHS OCR Breach Portal: the primary source. Search by entity name, state, breach type, or date range. Every breach affecting 500+ individuals since 2009 is here.
HIPAA Journal Breach Statistics (updated 2026): the best ongoing analysis of portal trends. Year-over-year breakdowns, breach type distribution, and penalty tracking. Updated monthly.
HealthcareBreaches.com: 7,804 breaches in a searchable database enriched with independent research. Easier to filter than the OCR portal. Data current through July 2026.
Has anyone else gone through the portal data? curious if you've spotted causes I missed, or if you've seen these same seven in your own work. would especially like to hear from anyone who's dealt with the tracking pixel issue. I'm still not sure most dev teams realise their analytics setup is a potential HIPAA violation.
Top comments (0)