CareCloud told the SEC on March 27, 2026 that it had "experienced a temporary network disruption in its CareCloud Health division that partially impacted the functionality and data access to 1 of its 6 electronic health record environments for approximately 8 hours," and that "the incident was contained on the day it was discovered."
Four months later, the notification letter CareCloud filed with the California Attorney General put it differently: "The investigation determined that, between March 10 and March 16, 2026, an unauthorized third party accessed one of CareCloud's AWS environments and claimed to have exfiltrated data from databases within that environment." California's breach database lists the date of breach as March 10, 2026.
Both statements are accurate. The 8-K describes the disruption. The notice describes the intrusion. The disruption lasted eight hours; the access lasted six days before anyone noticed it.
The mechanism
Nothing here suggests the filing was evasive. On March 24 — the materiality determination, eight days after discovery — the outage was what the company knew about. Dwell time is a forensic output; it doesn't exist on day eight. Item 1.05 requires filing within four business days of the materiality call, which CareCloud met with three days to spare.
That's structural: a material-incident filing reports the detection window because the dwell window hasn't been computed yet. Reading an 8-K as a measure of severity means reading a document written before the answer existed.
The more useful question is why March 10 through March 16 passed unremarked. The intrusion surfaced on March 16 as an availability event — something broke, and breaking is what monitoring watches for. For the preceding six days every signal the company collected said the environment was fine. Requests were served. Latency was normal. Someone was reading the databases the entire time, and reading a database is not an outage.
This is the default posture for most cloud estates, not a lapse peculiar to CareCloud. Uptime monitoring, APM, and synthetic checks all measure the control plane and the application. None of them see the data plane. An attacker with valid access to a data store generates no errors, and CareCloud's letter is explicit that the second-order cost was steep: it took until June 24, 2026 — one hundred days after discovery — to determine what the affected data actually contained. That gap is not unique to cloud estates: at three Florida behavioral health providers, the same interval between detection and knowing ran 380 days.
The practice: log the data plane on the stores that hold regulated data
The gap that produced six days is the absence of read-level telemetry on the data stores themselves. Closing it is a scoping exercise before a tooling one.
In AWS, CloudTrail management events are on by default and record who changed configuration. They will not tell you a database was queried or objects retrieved. That requires CloudTrail data events, off by default and billed per event, plus database-native audit logging for RDS or Aurora. GuardDuty's S3 and RDS Protection features consume that telemetry and flag anomalous access patterns — unusual principals, unusual volumes, retrieval from unfamiliar networks.
The honest cost, and why this gets deferred: data events across every bucket and database in a busy estate produce a bill that gets the project cancelled by month two. They're priced per million, and a chatty application bucket can generate tens of millions a day.
The version that survives budget review scopes it to the stores holding regulated data — a much shorter list than the full inventory. Run Macie once to find where PHI or PII actually lives; that is a one-time cost. Then enable data events on that subset only. Two hours of scoping cuts the recurring bill by one to two orders of magnitude and still covers the stores that set your notification obligations.
If you can't fund even the scoped version this quarter, the fallback is coarser but not nothing: VPC Flow Logs on the subnets containing those data stores, with alerting on sustained egress volume to destinations outside your normal set. That won't tell you which records left. It would have surfaced six days of sustained reads.
What to check this week
- Which data stores hold PHI or PII? If answering requires a meeting, that's the finding — and it's what put a hundred days between CareCloud's discovery and its data determination.
- For each of those stores: are CloudTrail data events enabled, and are database audit logs on and shipped somewhere queryable?
- What is your log retention on those sources, in days? If it's shorter than a realistic forensic investigation, the logs will be gone when you need them.
- Could you currently answer "was this table read, and by whom, on a given day three months ago"? Try it for a date last quarter.
- For vendors holding regulated data: does the BAA trigger notification on their discovery or their determination of scope? Those were 100 days apart here, and the interval sets your clock — which is also where the 60-day HIPAA clock actually starts.
CareCloud has not disclosed how the AWS environment was accessed, and as of August 4, 2026 no ransomware or extortion group has publicly claimed the breach. The detection gap is independent of the entry point — whatever opened the door, six days of reads went unobserved because nothing was watching reads.
North InfoSec runs AI-assisted penetration testing and security assessments, including cloud data-store access and detection-coverage review of the kind described above. northinfosec.com