Back to Exposure Report
Healthcare IT / EHRAugust 2026United States

CareCloud

345,000. Then 3,756,469. Same eight-hour intrusion, in one of six environments, five months apart.

Social Security numbersNames and addressesDriver’s licence numbersDates of birthHealth insurance informationMedical and healthcare informationFull payment card data (limited subset)
1

What happened?

An unauthorized third party accessed one of CareCloud's six Amazon Web Services environments between March 10 and March 16, 2026. The intrusion caused an eight-hour disruption to one of the company's electronic health record environments before systems were restored the same evening. CareCloud detected the intrusion in mid-March and disclosed it in early July.

It was originally believed roughly 345,000 people were affected. The true scale emerged this month when the HHS breach tracker was updated to 3,756,469 individuals — now reported as the fifth-largest theft of health data in 2026.

2

What data was actually inside?

Names, addresses, Social Security numbers, driver's licence numbers, dates of birth, health insurance information, and medical and healthcare information. For a very limited subset of individuals, attackers also obtained full payment card information.

This is the complete set. Identity elements sufficient for financial fraud, government identifiers, clinical information, and — for some — live card data. There is no category of harm in this series that this dataset does not support.

3

Who gets hurt and how?

3.76 million patients of practices that use CareCloud, none of whom chose the vendor. They were patients of a medical practice; the EHR was a decision made above them and invisible to them.

Social Security numbers with dates of birth support fraudulent tax filings and new-account fraud. Driver's licence numbers support identity document fraud. Health insurance details support medical identity theft, where fraudulent claims attach to a real benefit record and must be unwound through the insurer rather than a credit bureau. Clinical information cannot be reissued at all.

The timing harm is specific and severe. Roughly 3.4 million people were outside the original estimate. For five months they had no reason to believe they were affected, and therefore no reason to place a fraud alert or watch their benefit statements.

4

What did they think they were doing right?

The infrastructure response was genuinely strong, and the detail in the disclosure proves it. CareCloud can state that one of six environments was affected, that access ran from March 10 to March 16, that the disruption lasted eight hours, and that systems were restored the same evening. That is precise incident response with good logging and effective segmentation — five of six environments were unaffected.

The assumption underneath is that a tightly bounded intrusion implies a tightly bounded exposure. Eight hours in one environment sounds small. It was small, in infrastructure terms. The question of how many patient records sat in that environment is a different question entirely, answered by a different map.

5

What did they not know about their own data?

This incident is the cleanest illustration in the entire series of the gap between an infrastructure map and a data map. CareCloud could describe its environments to the hour. It could not describe their contents to within a factor of ten.

Both maps are legitimate artifacts and most organisations have only the first. Infrastructure is countable — environments, instances, access logs, timestamps — and every security programme produces it. Content requires knowing which practices' records were provisioned into which environment, how many patients each practice serves, and which data elements were stored per patient. Nothing in a standard security programme generates that.

A revision from 345,000 to 3,756,469 is not a miscount. It is the difference between measuring the container and measuring what is in it.

If you handle patient data, could you identify within 24 hours exactly which records were accessed in a breach?

6

What does attribution look like the morning after?

CareCloud operates as a business associate under HIPAA, so it must notify each affected covered entity, and every client practice then runs its own patient notification analysis. One vendor incident becomes hundreds of parallel processes. The revised figure appears on the OCR breach portal, where the correction is publicly visible.

The five-month interval between detection and an accurate count is where regulatory attention will land. HIPAA's 60-day clock runs from discovery, and a scope revision of this magnitude raises whether the original notification population was adequately determined. Supplemental notification to the additional 3.4 million is now required, alongside filings under state statutes including California's 30-day rule. Plaintiffs' firms have an unusually clean narrative here, because the correction is in the public record.

7

What would have changed the outcome?

A record of which patient data lived in which environment — so the first public number and the final number would have matched.

Your first public figure becomes the headline, the basis for your notification programme, and the number a regulator later compares against the truth. It is worth asking where that figure would come from in your organisation today. If the honest answer is that it would be derived from which systems were touched rather than what was in them, you should expect to revise it — publicly, and by an order of magnitude. See also the DentaQuest notification update, where three different counts arrived across two months.

CareCloud found out the hard way.

Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.