The U.S. Department of Health and Human Services now lists 3,756,469 people in a CareCloud breach report. CareCloud’s Aug. 6 Form 10-Q adds the consequential finding: its forensic investigation determined that an unauthorized third party “exfiltrated patient-related information” from a cloud account supporting an electronic health record environment, including personally identifiable information and protected health information.
CareCloud says it contained the access on March 16, found no later unauthorized activity tied to the incident, and restored the affected systems. Its consumer notice also says the company knew of no identity fraud or improper use caused by the incident when the notice was issued. The August filing and the HHS count make the five-month-old incident actionable now: healthcare customers need to reconcile a confirmed data loss against the people, data categories, and notices in their own tenant populations.
Six days inside AWS
CareCloud dates the unauthorized access from March 10 through March 16. The consumer notice says the intruder reached one AWS environment and claimed to have taken database data. It does not name the intruder, describe an initial-access method, or identify a ransomware or extortion operation.
The access window lasted six days.
The company’s earlier Form 8-K, filed after the disruption, described temporary unauthorized access and an investigation that was still determining whether data had been accessed or exfiltrated. One of six electronic health record environments was partly disrupted for about eight hours, according to the filing. CareCloud said the affected systems were restored and the unauthorized party no longer had access.
The later records do not use one consistent formulation. The financial-statement note in CareCloud’s August 10-Q says the forensic investigation determined that patient-related information was exfiltrated, while the consumer notice and a risk-factor passage in the same 10-Q say the intruder claimed exfiltration. CareCloud’s strongest affirmative filing therefore confirms data loss, but the public record does not map every transferred field to every affected person.
Public notice leaves data fields blank
CareCloud’s California-hosted consumer-notice template says a recipient’s full name and one or more additional data elements may have been involved, but its data-elements field remains an unfilled placeholder. The template also leaves the duration of identity-protection services unresolved as either 12 or 24 months. The 10-Q identifies personally identifiable information and protected health information at a category level without mapping specific fields to individual recipients.
The public template omits those fields.
CareCloud offered credit and CyberScan monitoring, identity-recovery assistance, and a one-million-dollar insurance reimbursement policy through IDX. The notice gives December 17, 2026, as the enrollment deadline. It also recommends reviewing account statements and credit reports, reporting suspicious activity, and considering a fraud alert or security freeze.
The HHS breach portal supplies the national scale but does not break the 3,756,469 people down by CareCloud customer, care setting, or data field. Providers and health plans that used the affected environment need their own reconciliation rather than treating the national count as a customer-specific exposure list.
Response timeline and evidence
The response continued after restoration.
Figure details
The timeline begins with unauthorized access to one CareCloud AWS environment from March 10 through March 16. The consumer notice attributes an exfiltration claim to the intruder, while CareCloud’s later Form 10-Q says its forensic investigation determined that patient-related information was exfiltrated. On March 16, CareCloud contained the access and restored an electronic health record environment that had been partly disrupted for about eight hours. CareCloud determined the affected data scope on June 24. The California-hosted template leaves its individualized data-elements field blank. The final point is December 17, the deadline in the notice for enrolling in IDX protection services.
The sequence gives defenders two different events to recognize. The first is the technical incident: unusual access to an AWS environment, confirmed patient-data exfiltration, a short electronic health record disruption, containment, and restoration. The second is the notification process: data review, population mapping, address verification, and delivery of protection instructions. An incident record that captures only the eight-hour disruption will miss the longer evidence trail needed to support notification.
That distinction is especially important for healthcare organizations that receive services through a vendor. Their logs may show workflow impact while the vendor holds the cloud-control-plane evidence and database access history. A useful customer evidence request should name both layers: the affected CareCloud environment and tenant population, plus the AWS identities, sessions, database events, and export activity tied to the March 10–16 window.
Reconcile the affected population
Start with a tenant-level roster from CareCloud that identifies which customer environments and patient populations map to the affected AWS account. Reconcile that roster against admission, encounter, billing, portal, and identity records active during March 10–16. Record the source system, record count, applicable data fields, and notification disposition for every matched population. The expected result is a one-to-one trail from each affected record to a notice decision, including a documented reason for every exclusion.
Check that each roster entry names a source system. Confirm that every notice decision has a recorded disposition.
Ask CareCloud for the AWS account and region, affected database identifiers, relevant IAM principals, session times, source addresses, CloudTrail events, database audit records, snapshots, exports, and restoration evidence. Query customer-controlled identity and integration logs for the same period, including service-account authentications, API calls, bulk reads, export jobs, and unexpected credential changes. Preserve the query, time zone, result set, and collection timestamp so later reviews can reproduce the finding.
Run a second verification after the initial reconciliation. Compare the final notice population with the tenant roster and the HHS total, then sample both included and excluded records back to source evidence. The expected result is that included records map to the affected environment and excluded records have affirmative evidence placing them outside it. Any unexplained difference should remain an open reconciliation item with an owner and a due date.
The national count establishes the scale, while the filing establishes that patient-related PII and PHI left the environment. Neither provides a customer-level field map. Affected people deserve a specific answer about which data traveled with their record, and healthcare customers need evidence that every notice maps to the affected account.