GDPR Data Breach Notification for eCommerce: 2026 Guide

Key Takeaways

• GDPR Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach — not 72 hours after you have fully investigated it.
• Not every breach triggers notification: the threshold is whether the breach is "likely to result in a risk to the rights and freedoms of natural persons" (Article 33, GDPR).
• On June 10, 2026, the EDPB adopted a standardised Article 33 notification template — public consultation closes August 5, 2026, after which all 27 EU/EEA supervisory authorities must adopt it.
• Customer notification (Article 34) applies only when breach risk is "high" — a meaningfully stricter bar than the DPA notification threshold.
• Under Article 33(5), you must document every breach internally, including those you decide not to report.

---

Introduction

It is 3 p.m. on a Tuesday when your developer flags an anomaly in the logs: a misconfigured cloud storage bucket has been publicly readable for 11 days. Customer email addresses, order histories, and in one case billing details — exposed. The first question every eCommerce owner asks at that moment is not "what does GDPR say?" It is: "How bad is this, and what do I do right now?"

GDPR's data breach rules give you exactly 72 hours to make the first call. But what counts as a breach that triggers that clock? Who do you tell — your DPA, your customers, or both? And what will the process look like once the EDPB's new standardised notification template, adopted June 10, 2026, becomes mandatory across all 27 EU/EEA supervisory authorities?

This guide answers all three questions, with a checklist you can act on today.

This article contains general information only, not legal advice. Consult a qualified legal professional for guidance specific to your situation.

---

What Counts as a GDPR Data Breach for eCommerce Stores?

A personal data breach is any incident — not just a hack — that leads to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, personal data you process. For an online retailer, the range is wide: a ransomware attack encrypting your order database, a developer accidentally making a cloud storage bucket public, a staff member emailing a customer list to the wrong recipient, or a third-party processor going offline in a way that destroys records you are required to keep.

Common eCommerce breach scenarios:

• Customer email or password database exposed via a misconfigured server
• Order fulfilment data (name, address, phone) disclosed to a third-party logistics provider without a proper [data processing agreement](/resources/blog/gdpr-data-processing-agreements-ecommerce-guide)
• Accidental deletion of transaction records (destruction is a breach, even without external disclosure)
• Phishing attack leading to an employee's inbox — containing customer correspondence — being accessed by an unauthorised party

The starting point is your [record of processing activities](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities). If you cannot quickly identify which categories of data were exposed, how many individuals are affected, and which processors had access, your first 72 hours will be spent finding answers instead of acting on them.

---

The Two-Tier Notification System: DPA vs Data Subjects

GDPR creates two separate — and deliberately calibrated — notification obligations. Conflating them is the single most common source of confusion when a breach occurs.

When Must You Notify Your DPA? (Article 33)

Article 33 of GDPR requires controllers to notify their supervisory authority "without undue delay and, where feasible, not later than 72 hours" after becoming aware of a personal data breach — unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons."

The 72-hour clock starts when you have "become aware" — not when you have completed your investigation. Article 33(4) expressly permits phased reporting: file within 72 hours with what you know, then provide additional information without undue further delay.

When you do notify, Article 33(3) specifies the minimum content your DPA needs:

One obligation that applies regardless of whether you notify: Article 33(5) requires you to document every breach internally — including those you assess as not requiring DPA notification — recording the facts, effects, and remedial actions taken. If your DPA ever conducts an audit of your breach-management process, this log is your evidence that a functioning process exists.

When Must You Notify Affected Customers? (Article 34)

Article 34 sets a higher threshold: you must communicate a breach to affected individuals only when it is "likely to result in a high risk to the rights and freedoms of natural persons." The European Commission explicitly confirms the distinction: Article 33 uses "risk," Article 34 uses "high risk."

A breach that meets the DPA notification threshold may therefore not require customer notification — though the decision requires careful, documented reasoning either way.

Article 34(3) provides three circumstances where customer notification is not required even when high risk is present:

1. Encryption or pseudonymisation: If the compromised data was rendered unintelligible to any unauthorised party through appropriate technical measures, direct notification to data subjects may be unnecessary.
2. Risk subsequently eliminated: If you took measures after the breach that ensure the high risk is no longer likely to materialise.
3. Disproportionate effort: If notifying each individual individually would be disproportionate — in which case a public communication that effectively reaches data subjects is required instead.

The high-risk determination is a judgment call with real consequences. Under-assess the risk and skip notifying customers when you should have — and your DPA can require you to do it anyway, and may treat the failure as a separate infringement.

---

The EDPB's New Standardised Template: What's Changing

Prior to June 2026, Article 33 notifications were a patchwork across the EU. Each of the 27 national DPAs had its own format, fields, and submission portal. A retailer operating across several EU member states under the one-stop-shop mechanism might file the same incident in formats that looked entirely different depending on the lead DPA.

On June 10, 2026, the EDPB adopted a common Article 33 notification template at a meeting with EU Commissioner McGrath. In the EDPB's own words, it is designed to "help save time and costs, particularly for smaller organisations lacking dedicated Data Protection Officers (DPOs) or legal resources." The template provides "predefined options to choose from, and further guidance on how to fill in the fields," making notifications more consistent across all EU/EEA DPAs.

The template is currently in public consultation, open until August 5, 2026. After that deadline, the EDPB will determine the implementation timeline for mandatory adoption by all EU/EEA supervisory authorities.

For eCommerce operators, the practical implication is straightforward: the days of needing separate documentation structures for the Garante, the CNIL, the BfDI, and other EU DPAs are ending. That is a genuine operational simplification — especially for cross-border retailers who have historically maintained different breach reporting workflows per country.

The conservative recommendation: begin structuring your internal breach records now using the four Article 33(3) elements. Whatever the final template looks like, those four fields will be in it.

---

Your 72-Hour Checklist: First Steps After a Breach

Say you run a mid-size apparel retailer shipping to Germany, France, and the Netherlands. At 3 p.m. on a Thursday, your platform provider informs you that an API misconfiguration has exposed customer email addresses and order histories. You have until 3 p.m. Saturday — 72 hours — to decide whether to notify your lead DPA.

Hour 0–4: Contain and inventory

1. Activate your incident response procedure (if it does not exist, note that separately)
2. Identify the data involved: categories, approximate number of records, time period of exposure
3. Check your [data processing agreements](/resources/blog/gdpr-data-processing-agreements-ecommerce-guide) — which processors had access to the affected data?
4. Determine whether the exposure is ongoing; stopping it is always the first operational priority

Hour 4–24: Assess the risk

1. Could the exposed data be used to harm individuals? Consider: identity theft, fraud, discrimination, reputational damage
2. Is the data encrypted or pseudonymised? If yes, risk is significantly lower — potentially below the Art. 33 notification threshold
3. How many individuals are affected? How sensitive are the data categories?
4. Is this breach "likely to result in a risk" triggering Article 33?

Hour 24–48: Prepare the notification (if required)

1. Draft the four Article 33(3) elements (nature, contact, consequences, remedial measures)
2. Confirm your DPO or designated contact's details
3. Identify your lead supervisory authority (where your EU main establishment is located — UK operations go to the ICO separately under post-Brexit rules)
4. Assess the Art. 34 "high risk" threshold for customer notification

Hour 48–72: File and document

1. Submit to your DPA — or record your reasoned decision not to, with the factors considered
2. If Art. 34 high risk is present: begin drafting customer notifications in plain language
3. Log the incident in your internal breach register under Article 33(5) regardless of outcome

---

The Biggest Mistakes Organisations Make

The most costly error is treating the 72-hour deadline as a target for completing the investigation, rather than for beginning to notify. GDPR's clock starts when you become aware — not when you have answers. Filing a partial notification with a follow-up is explicitly permitted under Article 33(4); filing nothing because you wanted to be thorough is not.

Four other patterns that have attracted regulatory action:

1. No internal breach log. Article 33(5) applies to every breach — including the low-risk ones you correctly decided not to report. Failing to maintain any breach register leaves you unable to demonstrate a functioning process when your DPA asks. The log is your evidence, not an optional administrative exercise.

2. Processor contracts without breach clauses. Under Article 33(2), your processor must notify you "without undue delay" of any breach affecting data they process on your behalf. The processor does not notify the DPA — that is your responsibility as controller. Agreements without an explicit breach notification obligation create a gap that regulators have noticed. In 2019, Dutch Employee Insurance (UWV) was fined €900,000 by the Dutch DPA for Article 32/33 violations spanning security failures and breach notification deficiencies in the controller-processor chain.

3. Conflating the two thresholds. Sending customer emails for every low-risk incident is over-notification — not what GDPR requires, and potentially anxiety-inducing for data subjects with no good reason. Missing high-risk incidents is under-notification, which can result in regulatory requirements to notify retroactively and additional enforcement scrutiny. Hamburg's transport authority was fined €20,000 in 2019 for failing to implement adequate notification procedures under Articles 33 and 34.

4. No data map, no speed. The faster you can answer "what data was affected, how many people, which categories?", the faster and more accurately you can file. For retailers whose customer data spans an eCommerce platform, an email marketing tool, a loyalty system, and a fulfilment partner, that question can take days without prior preparation. Your [record of processing activities](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities) is what makes the 72-hour window workable.

---

How PrivacyForge Helps

PrivacyForge's compliance tools address the two weakest points in most eCommerce operators' breach response: knowing what data you hold before an incident occurs, and documenting the response after.

Data mapping: PrivacyForge's data mapping module gives you a live inventory of the personal data your store processes — categories, legal bases, processors, and [retention schedules](/resources/blog/gdpr-data-retention-how-long-keep-customer-data). When a breach occurs, you can immediately pull the affected data categories and approximate record counts — exactly what Article 33(3)(a) requires in the notification.

Compliance scoring: Breach notification procedures form part of PrivacyForge's overall compliance score. Gaps in your incident response documentation appear in your dashboard before regulators find them in an audit.

Notifications: PrivacyForge's internal notification system can be configured to alert your DPO or compliance lead when a potential breach-triggering event is flagged — starting your 72-hour window with a documented, timestamped record.

---

Frequently Asked Questions

What counts as a personal data breach under GDPR?

A personal data breach is any incident that results in the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, personal data you process. This includes cyberattacks, accidental data exposure, ransomware, and accidental deletion. Not every breach requires DPA notification — only those "likely to result in a risk" to affected individuals.

Do I have to report every breach to my DPA?

No. Article 33 requires notification only when the breach is "likely to result in a risk to the rights and freedoms of natural persons." Low-risk breaches do not require DPA notification, but must still be documented in your internal breach register under Article 33(5). The documented reasoning for not notifying is just as important as the notification itself.

What is the 72-hour rule and when does it start?

Under GDPR Article 33(1), you must notify your supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware" of the breach. The clock starts when you become aware — not when your investigation is complete. If full details are unavailable, file an initial notification and follow up with additional information without undue further delay.

When do I need to notify affected customers about a data breach?

Under Article 34, you must communicate directly with affected customers only when the breach is "likely to result in a high risk" — a higher threshold than the DPA notification test under Article 33. If the data was properly encrypted, if you have eliminated the risk, or if direct individual notification would involve disproportionate effort, you may be exempt from direct customer notification under Article 34(3).

What is the EDPB's new breach notification template?

On June 10, 2026, the EDPB adopted a standardised template for Article 33 GDPR data breach notifications. It provides predefined fields and guidance to make notifications consistent across all 27 EU/EEA supervisory authorities. The template is in public consultation until August 5, 2026, after which the EDPB will set the mandatory adoption timeline for all national DPAs.

What happens if I miss the 72-hour deadline?

If you notify after 72 hours, you must explain the delay to your supervisory authority. Regulators can accept late notifications when the justification is adequate; the more serious failure is no notification at all for a reportable breach. Violations of Articles 33 and 34 fall within the scope of Article 83(4) GDPR, which sets maximum administrative fines of up to €10,000,000 or 2% of total worldwide annual turnover, whichever is higher.

---

Conclusion

The EDPB's new standardised template is not merely a paperwork update — it signals that breach notification is becoming more systematised and more consistently enforced across all 27 EU/EEA supervisory authorities. The consultation window closing August 5, 2026 is the right moment for eCommerce operators to review whether their breach response procedures are aligned with what the finalised template will require.

The fundamentals do not change: 72 hours from awareness, document everything, report when the risk threshold is met, tell customers only when the risk is high. The difficulty is in the speed and the substance of the risk assessment. That is where preparation pays off — and where operators who have done the groundwork separate themselves from those who have not.

Start with your data map. If you cannot identify what personal data you hold and where within two hours of a breach, the 72-hour window will feel very short indeed.

---

Sources

• [GDPR Article 33 — Notification of a Personal Data Breach to the Supervisory Authority](https://gdpr-info.eu/art-33-gdpr/)
• [GDPR Article 34 — Communication of a Personal Data Breach to the Data Subject](https://gdpr-info.eu/art-34-gdpr/)
• [GDPR Article 83 — General conditions for imposing administrative fines](https://gdpr-info.eu/art-83-gdpr/)
• [EDPB news: EDPB meets with EU Commissioner McGrath and adopts common data breach notification template (June 10, 2026)](https://edpb.europa.eu/news/news/2026/edpb-meets-eu-commissioner-mcgrath-and-adopts-common-data-breach-notification-template_en)
• [European Commission: Data protection — your rights](https://commission.europa.eu/law/law-topic/data-protection/reform/rights-citizens/my-rights_en)
• [GDPR Enforcement Tracker](https://www.enforcementtracker.com/)