Your tracking provider sends an email: they’ve had a security incident. Customer conversion data — names, email addresses, order values — was exposed. They’re still investigating. They’ll update you when they know more. Your 72-hour clock just started. Not when the investigation finishes. Right now.

Most WooCommerce store owners treat data breach response as someone else’s problem — the host’s, the plugin vendor’s, the tracking provider’s. Under GDPR Article 33, it is yours. You are the Data Controller. Your customers’ data is your responsibility. When that data is exposed — regardless of where in your stack the breach happened — the obligation to notify your supervisory authority falls on you, and the window is 72 hours from the moment you become aware.

What GDPR Article 33 Actually Requires#

GDPR Article 33 is the breach notification rule for Data Controllers. It requires that when a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, the Data Controller must notify their competent supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it.”

Three things in that sentence matter:

Without undue delay means you cannot wait until the investigation is complete. You notify with the information you have, note that the investigation is ongoing, and update the authority as you learn more. Regulators treat delayed notification as a separate violation from the breach itself.

Where feasible, 72 hours means the threshold is strict. If you miss it, you need to explain why. “We were still investigating” is not a sufficient reason. “We did not know about it” only works if you can demonstrate you had reasonable detection controls in place and the breach was genuinely undetectable within that window.

After having become aware is where most store owners miscalculate. Aware does not mean “after you have confirmed the full scope.” It means the moment you have reasonable belief that a breach has occurred. An email from your SST provider saying “we had an incident affecting customer data” constitutes awareness.

You may be interested in: One Server in Stockholm Tracks 1,000 Stores: The Security Risk Nobody Talks About

What WooCommerce Data Triggers the Notification Obligation#

The obligation applies to personal data as defined in GDPR Article 4(1): any information relating to an identified or identifiable natural person. Your WooCommerce store holds notifiable personal data by default:

• Customer names and email addresses — collected at checkout and account registration
• Billing and shipping addresses — including phone numbers where collected
• IP addresses — logged by WordPress, WooCommerce, and virtually every tracking plugin
• Order history — products purchased, amounts spent, dates
• Payment method metadata — last four digits, card type (not full card numbers if you’re using a compliant payment gateway)
• Behavioural data — session recordings, heatmap data, funnel events if you run Clarity, Hotjar, or equivalent tools

A breach that exposes any of this data to unauthorised access is a notifiable breach unless you can demonstrate the risk to individuals is unlikely. Encryption, pseudonymisation, and access controls affect the risk assessment — but they do not eliminate the obligation to assess and document.

The average data breach in 2024 costs $4.88 million — a 10% increase on the prior year and the highest ever recorded, according to IBM’s Cost of a Data Breach Report. Third-party involvement adds 10–15% to that figure. When your tracking provider is the breach point, your costs go up even though you were not the compromised party.

The Three Breach Scenarios WooCommerce Store Owners Face#

Understanding your notification obligation requires understanding which breach scenarios apply to you specifically. There are three common vectors for WooCommerce stores.

Your database or hosting is compromised

Someone gains unauthorised access to your WordPress database or hosting environment. Customer records, order data, and account credentials are exposed. This is the scenario most store owners imagine when they think about breaches. The notification obligation is clear and immediate. You are the Data Controller. You notify your supervisory authority within 72 hours of discovery and notify affected customers if the risk is high.

A plugin or theme has a vulnerability that exposed data

A security vulnerability in a WooCommerce plugin — a form builder, a booking system, a tracking integration — allows data to be accessed or exfiltrated. You may not discover this until the plugin vendor publishes a security advisory. The 72-hour clock starts when you read that advisory and assess that your store was affected. The fact that the plugin vendor caused the vulnerability does not transfer the notification obligation to them. You remain the Data Controller.

Your tracking provider or processor is breached

This is the scenario most store owners do not plan for. A centralised server-side tracking provider — one that processes conversion data from thousands of stores on shared infrastructure — has a breach. Your customers’ event data, which you passed to the provider as a Data Processor, is exposed. The provider notifies you. Your 72-hour window begins at that notification.

You cannot wait for the provider to complete their investigation before notifying your supervisory authority. You notify with what you know: the nature of the breach, the categories of data affected, the approximate number of records, the likely consequences, and the measures you are taking. The provider’s incomplete investigation is their problem. Your notification obligation is yours.

You may be interested in: GTM Compliance Debt Is Compounding

The Three-Step Notification Process#

When a breach occurs or is discovered, the process is specific and time-sensitive.

Step 1: Internal triage (Hours 0–6)

Establish what happened, what data was affected, and how many individuals are involved. You do not need complete answers — you need reasonable estimates. Document everything from this point: timestamps, who was informed internally, what actions were taken, what information you had at each decision point. This documentation is what supervisory authorities review when assessing whether your response was adequate.

Step 2: Supervisory authority notification (Before hour 72)

File a notification with your competent supervisory authority. In the UK this is the ICO (ico.org.uk/make-a-complaint/data-security-incident-trends). In Germany, your state DPA. In Ireland (where many large platforms are registered), the DPC. The notification must include: the nature of the breach, the categories and approximate number of data subjects affected, the categories and approximate number of records involved, the name and contact details of your Data Protection Officer or breach contact, the likely consequences, and the measures taken or proposed to address the breach.

If you cannot provide all of this within 72 hours — for example, the scope of the breach is still being determined — file what you have and note that further information will follow. This is explicitly permitted under Article 33(4) and is far better than filing late.

Step 3: Customer notification (If required under Article 34)

If the breach is likely to result in a high risk to the rights and freedoms of individuals — identity theft risk, financial risk, discrimination risk — you must also notify the affected customers directly. This is a separate obligation from notifying the supervisory authority and has no fixed 72-hour deadline, but “without undue delay” still applies. The notification must be in plain language and must describe the breach, its likely consequences, and what you are doing about it.

Why First-Party Architecture Changes Your Breach Response#

The provider-breach scenario above — where your SST provider’s incident starts your clock — is the one most WooCommerce stores are not prepared for. It exposes a structural risk in centralised tracking infrastructure: when a single provider processes data for thousands of stores on shared servers, a single breach creates a simultaneous notification obligation across all of those stores at once.

The Transmute Engine™ runs on your own first-party subdomain. Your event data does not flow through shared infrastructure. It processes on a server you control, on your subdomain, with access logs and audit trails that belong to you. When a breach occurs — on your server, not a provider’s — you know about it immediately. You control what data was affected. You control the response timeline. You are not waiting for a provider to tell you what happened to your customers’ data on their infrastructure.

That is not a compliance feature. It is a fundamental architectural benefit: the party with the notification obligation is also the party with complete information and complete control. Your 72 hours belongs to you.

You may be interested in: GDPR Legitimate Interest: Track WooCommerce Orders Without Cookie Consent

Key Takeaways#

• 72 hours starts when you become aware — not when you finish investigating. File what you know, flag that the investigation is ongoing, and update as you learn more.
• Three breach vectors apply to WooCommerce stores: your own database or hosting, a plugin vulnerability, or a third-party processor breach. All three trigger your notification obligation as Data Controller.
• Your tracking provider’s breach is your problem. Their notification to you starts your clock. You cannot delegate the notification obligation to them.
• Missing the 72-hour window carries fines up to €10 million or 2% of global turnover — separate from any fines for the breach itself, which escalate to €20 million or 4%.
• First-party architecture gives you breach response control. When your data processes on your own infrastructure, you own the timeline, the information, and the response — not a provider’s incident team working through a queue.