GDPR breach reports are still due in 72 hours. The 96-hour change is not law yet.

Someone on your sales team hands in their notice and, on the way out, exports your customer contact list from the CRM. A few months later they use it to pitch their new business to your customers. Under the GDPR as it stands, that is a breach you report to your data protection regulator within 72 hours. The European Data Protection Board (EDPB), where the EU's national regulators work together, walks through this case in its breach guidance and says so 3.

On 21 October 2026, EU governments agreed a text that would change that answer. You would report a breach to the regulator only if it is likely to result in a high risk to the people affected, and you would have 96 hours instead of 72 2. The departing employee would go into your own breach log and nowhere else.

None of it is law yet. The European Parliament has not voted on it, and the text delays the change for 18 months after it is adopted, so a breach in 2027 will almost certainly still fall under the 72-hour rule. If the change does pass, the regulator stops seeing your borderline breaches, and your own written record becomes the only proof that not reporting one was the right call. And if you sell software that holds your customers' data, one duty does not change at all: you still tell each customer about every breach.

What would change in the GDPR's breach rule?

The change is part of the Digital Omnibus, an EU package to simplify several digital laws, which the member states agreed their position on in the Council on 21 October 2. It rewrites Article 33(1), the GDPR rule on reporting a breach to the regulator:

• Which breaches. The current GDPR requires a report for every breach that carries some risk to people 1. The new text requires one only for breaches "likely to result in a high risk to the rights and freedoms of natural persons" 2.
• How fast. The limit moves from 72 to 96 hours. The rest of the rule stays as it is: report without undue delay, within the limit where feasible, and give reasons if the report comes later 1.
• Guidance. The EDPB would publish one list of situations that are likely to be high risk and one of situations that are not.

High risk is the test Article 34 already uses for telling the affected people themselves 1, so after the change both the regulator and the users would be told only about high-risk breaches. The aim is fewer reports: DLA Piper's annual GDPR survey counted an average of 443 a day across Europe in the year to 27 January 2026. The regulators back this part: the EDPB and the EU's own data protection supervisor backed both the higher threshold and the longer deadline in a joint opinion in February 2026 4. My guess is that this makes it likely to survive the negotiations with Parliament.

Which breaches would no longer be reported to a regulator?

The ones in the middle: breaches that carry some risk to people, but not a high one. Under the current GDPR those go to the regulator. Under the new text they would go only into the company's own breach log.

The EDPB's breach guidance works through 18 example breaches and says, for each one, who has to be told 3. Four of them show the line. One moves, one might, and two stay where they are. "Regulator" means a report to the regulator, "users" means telling the people affected, and every breach goes in the company's own log either way:

For the departing employee, the EDPB's answer is that the breach "will not result in a high risk", so a report to the regulator is enough and the customers need not be told 3. Under the new text, that same reasoning means no report at all. The Council column is my reading of the EDPB's own risk calls against the new threshold, and no regulator has applied the new text yet.

The hard cases are the ones the EDPB itself cannot settle. In another example, ransomware hits a company with no electronic backup, and restoring the data from paper delays payments and deliveries. The EDPB calls the breach risky but not high risk, then adds that "one could also argue" it is high risk, because the delays could cost people money 3. Under the current rule, both answers lead to a report, so the disagreement does not matter. Under a high-risk threshold, it decides whether the regulator hears about the breach at all.

That is the change I think matters most for a small company. Under the current rule, the regulator sees the borderline cases and can disagree with you. Under the new text, nobody outside the company sees them unless something goes wrong later, and the company's own written reasoning is what it would have to show.

What stays the same for a software company?

Most of the work around a breach stays the same:

• The breach log. Article 33(5) requires a company to document every breach: the facts, the effects and what it did about it 1. The new text leaves that untouched, and its explanatory part says the higher threshold does not affect "the controller's obligation to carry out an individual risk assessment and to maintain complete documentation" 2.
• Telling the people affected. Article 34 is unchanged. A high-risk breach still has to be communicated to the people it affects without undue delay 1.
• The vendor's duty to its customers. Article 33(2) says "the processor shall notify the controller without undue delay after becoming aware of a personal data breach" 1. It has no risk threshold, and the new text does not change it 2. For a SaaS product that holds its customers' data, that means every breach goes to every affected customer, and the customer decides whether it is high risk. I would not treat this as a formality. The customer cannot assess, report or warn its own users about a breach it has not heard of, and a vendor that holds back while it judges the risk itself breaks Article 33(2). Vendors are fined over breaches of customer data too, as the Swedish fine against a software vendor shows, in that case under the GDPR's security rule.
• NIS2. A company covered by NIS2, the EU's cybersecurity law, has its own incident reports with their own deadlines, and the GDPR changes do not touch them. I covered those in the post on NIS2's 24-hour report.

When would the 96-hour rule apply?

No earlier than 18 months after a final text is published, because the Council text delays the new Article 33 rules by that long 2. Parliament's committees have not voted on it yet 5, and Parliament can change any of the breach rules in the negotiations that follow. So I would not plan around a date until Parliament has voted.

If you run a product that holds personal data, what should you do now?

1. Write the risk call down for every incident, starting now. Any dated record you could hand to a regulator counts as the breach log: a spreadsheet, or a field in your incident tracker. If you have none, start one. One short paragraph per breach: whose data, what could happen to them, how likely that is, and why you reported it or did not. Article 33(5) already requires the record, and if the change passes, it is what you would show a regulator that asks why a breach was not reported.
2. Change nothing in your runbook or your customer DPA. The rule in force is a report within 72 hours for any breach that carries some risk to people, and a notice to each customer about every breach in their data. A missing report, or a late one without reasons, breaks Article 33, with fines of up to 10 million euros or 2% of worldwide turnover 1.

If you want to see how much a regulator may ask for once you do file a report, I wrote about the EDPB's draft breach report form and its 100 fields.