Law & Regulation

Your Vendor Decides When Your 72 Hours Start

CareCloud's records system was hit on 16 March. It determined on 24 June that data was taken. Letters went out from 30 July. Your GDPR clock is 72 hours.

Law & RegulationBy Servola Tech Desk2026-07-316 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

Your Vendor Decides When Your 72 Hours Start

Key takeaways

CareCloud's electronic health record environment was disrupted on 16 March and the company determined on 24 June, one hundred days later, that personal, financial and medical information had been taken; under GDPR your own notification clock is 72 hours from awareness, so a vendor's investigation calendar can consume your entire compliance window before anyone tells you a thing.
The US 60-day notification rule runs from discovery of a breach, and the reading that makes this timeline work is the one where discovery means the day the investigation concluded protected information was involved rather than the day the intrusion was found.
The picture kept expanding while the clock was deferred: CareCloud's own March account described roughly eight hours of unauthorised access on 16 March, later state filings put the window at 10 to 16 March, and the count reached at least 350,000 people, with some records including full payment card data down to the security code.
Article 33(2) of the GDPR says a processor notifies the controller without undue delay and attaches no number to it, so the number has to come from your contract: hours measured from the vendor detecting a security incident, not from the vendor deciding what was in it.

One hundred days between the intrusion and the decision

Letters began reaching people on 30 July 2026, telling them that their name, address, date of birth, Social Security number, driving licence, government identity documents, bank account details, payment card numbers and medical records may have been taken. For some of those people the stolen card data included the security code printed on the back. The company sending the letters was CareCloud, a healthcare software firm whose systems hold records on behalf of medical practices.

The intrusion was in March. Attackers were inside one of CareCloud's six electronic health record environments, hosted on Amazon Web Services, between 10 and 16 March 2026. The environment was disrupted on 16 March and restored the same evening. The company disclosed the incident publicly at the end of that month, while saying the investigation into what had actually been accessed was still running.

That investigation reached its conclusion on 24 June, when CareCloud determined that personal, financial and medical information had been compromised. From 16 March to 24 June is one hundred days exactly. From 16 March to the first letters is one hundred and thirty-six.

The clock does not start where you assume it starts

American healthcare breach notification runs on a sixty-day rule: notify affected individuals without unreasonable delay and no later than sixty calendar days after discovery of a breach. Read plainly, discovery sounds like the day you find out you have been broken into, which here was 16 March. On that reading the letters are more than two months late.

The reading that makes this timeline work is a different one. It treats discovery as the day the investigation concludes that protected information was actually involved, which was 24 June. Count sixty days from there and letters going out on 30 July land comfortably inside the window. That is the reading widely relied on in practice, and it is why this timeline can be defended in every state where CareCloud filed - California, Massachusetts, New Hampshire, Texas and Maine among them.

Whichever reading is correct, notice what the second one does. It makes the start of the clock an output of the investigation, and no rule sets a deadline for finishing an investigation. A duty that begins when you decide it begins is a duty you control the timing of.

Europe wrote the rule the other way round

Article 33 of the GDPR requires a controller to notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. Awareness is not the completion of a forensic report. It is the point at which you have a reasonable degree of certainty that a security incident has compromised personal data, which usually arrives long before you know whose data or how much.

The drafters anticipated exactly the gap CareCloud spent a hundred days inside. Article 33(4) says that where the information is not available all at once, it may be provided in phases without undue further delay. The design assumption is that you will file while still ignorant and supplement as you learn. The American design lets you wait until you know; the European design tells you to report before you know and keep reporting.

The consequence for an operator is not abstract. The same incident, on the same infrastructure, produces a filing in 72 hours on one side of the Atlantic and a determination in one hundred days on the other. If your supplier's instincts were formed on the second timetable, they are the instincts now sitting between you and your own deadline.

The picture kept growing while the clock was deferred

Deferring the start of the clock would be a smaller matter if the early account had held up. It did not. CareCloud's own description in March put the unauthorised access at roughly eight hours on 16 March, contained in a single environment, with no other business systems involved. Later state filings describe attackers in that environment from 10 to 16 March, which is six days rather than eight hours.

The affected population grew too. Filings put the number at at least 345,000 people, and the figure has since been reported as more than 350,000, with further state submissions expected to move it again. The company has said a hacker claimed to have exfiltrated data from its databases, that external specialists secured the environment and confirmed no persistent unauthorised access remained, and that it has no evidence the stolen data has been misused. Its chief executive, Stephen Snyder, declined to comment when approached by reporters.

Every one of those revisions moved in the same direction, and every one of them arrived after the first public account. An investigation that is still enlarging its own estimate is not a reason to keep the affected parties waiting. It is the reason to tell them early and correct upward in public.

The missing number belongs in your contract

If a supplier processes personal data on your behalf, you are the controller and the 72 hours are yours. Article 33(2) requires the processor to notify the controller without undue delay, and it attaches no figure to that phrase. Article 28 requires your contract to bind the processor to assist you with your Article 33 duties. Between those two provisions there is a number-shaped hole, and if you do not fill it, you inherit whatever timetable your supplier's own regulator tolerates.

Fill it with two clauses rather than one. The first sets a fixed period, counted in hours, running from the moment the supplier detects a security incident affecting an environment that holds your data - not from the moment it establishes which data were involved, because that second event is the one with no deadline. The second entitles you to the facts as they emerge, including the environments touched, the access window and the categories at risk, rather than a single finished report at the end.

Then test it the way you would test a backup. Ask your three largest processors, in writing, when they last had a security incident in an environment holding your data, on what date they detected it, and on what date they told a customer. A supplier that cannot separate those two dates for you on request will not separate them under pressure either. In Europe the notification lands with your national supervisory authority, and that authority will be asking you, not your vendor, why the filing was late.

Frequently asked questions

Did CareCloud break the notification rules?

That is not established, and the timeline can be defended. On the widely used reading where the sixty-day clock runs from the determination that protected information was involved, a determination on 24 June and letters from 30 July fall inside the window. The point of this piece is that a lawful date and a useful date are not the same date.

Why does a US healthcare breach matter to a European business?

Because the mechanism travels even when the sector does not. Any processor that treats its notification duty as beginning when its investigation ends can absorb your entire 72-hour window before contacting you, and the exposure exists wherever a supplier outside the EU holds personal data you are the controller for.

What exactly does the 72-hour rule require?

Article 33 of the GDPR requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, with Article 33(4) permitting the information to be supplied in phases. Article 34 separately requires communication to the individuals concerned without undue delay where the breach is likely to result in a high risk to their rights and freedoms.

A compliant date and a useful date are not the same date. One hundred days passed between the intrusion at CareCloud and the conclusion that anything had been taken, and every one of those days would have been spent inside somebody else's 72 hours if the records had been European.

CareCloudGDPRBreach notificationProcessor contractsHealthcare dataAWS

Nothing Crashed, and It Cost $1.8 Million

An Amazon AI job ran five months, cost 1.8 million dollars and never shipped. Two months earlier the company killed a leaderboard for the same underlying reason.

5 min read

Infrastructure

Your DR Plan Assumes the Region Comes Back

AWS estimated at least a day to restore its UAE region after drone strikes in March. On 30 April it said the region could not reliably support applications.