Plugin Vulnerability or GDPR Data Breach? How to Tell

Key Takeaways

• A disclosed vulnerability is not automatically a personal data breach. Article 4(12) GDPR defines one as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed" (emphasis added). A flaw nobody exploited has not led to any of those things.
• The EDPB says this in as many words. Guidelines 9/2022, Version 2.0, adopted 28 March 2023, paragraph 15: "whilst all personal data breaches are security incidents, not all security incidents are necessarily personal data breaches."
• The limb eCommerce teams forget is availability. The ICO fined Merseyside firm DPP Law £60,000 in April 2025 after finding the firm "did not consider that the loss of access to personal information constituted a personal data breach" — and so reported 43 days after becoming aware.
• Scoping comes before law. CVE-2026-18391 carries a CVSS v3.1 base score of 9.8 and describes stores "with High-Performance Order Storage enabled". Your first question is whether you were ever in scope, not whether to notify.
• The unpatched window is a separate exposure with its own enforcement record. Cyber Essentials requires critical updates to be installed within 14 days, and the ICO's 2022 penalty against Tuckers Solicitors found, as reported, that the firm "should not have been processing personal data on an infrastructure containing known critical vulnerabilities without appropriately addressing the risk."

Introduction

It is Wednesday morning and your WooCommerce dashboard has a red banner on it. A plugin you have run for three years shipped a critical vulnerability, and the vendor has already published the fix. Somewhere between the update button and the second coffee, a colder question arrives: does this count as a data breach, and did a 72-hour clock just start without anyone telling you?

On 5 and 6 August 2026, WooCommerce published two security advisories in as many days — one for WooCommerce Subscriptions, one for Stripe for WooCommerce. Both say something reassuring about exploitation. Each sits on a different side of the line that decides whether Article 33 applies at all. This guide works through where that line actually falls, and what you owe your regulator when it falls on the comfortable side.

This article is informational content, not legal advice. For organisation-specific guidance, consult a qualified legal professional.

Is a Plugin Vulnerability a GDPR Data Breach?

Usually not, on its own. Article 4(12) GDPR defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data…" (emphasis added). A vulnerability is a door that could be opened. A breach is a door that was.

That is not a lawyerly quibble — it is the EDPB's own reading. Guidelines 9/2022 on personal data breach notification (Version 2.0, adopted 28 March 2023) states at paragraph 15: "What should be clear is that a breach is a type of security incident. However, as indicated by Article 4(12), the GDPR only applies where there is a breach of personal data… whilst all personal data breaches are security incidents, not all security incidents are necessarily personal data breaches."

So the honest answer to "did a clock start?" is: not yet, and possibly not at all. The mirror case is worth holding beside it: a disclosure with no attacker anywhere, which is what a mis-keyed CDN cache produces when it serves one shopper's IP address and session identifier to the next visitor — there, no door was opened, because none was ever shut. What starts immediately is a different obligation, and we come to that below.

What the August 2026 WooCommerce advisories actually said

The two advisories are a useful pair precisely because they are not the same shape.

Neither was reported by an outsider. The Subscriptions advisory says "The vulnerabilities were identified through an internal security review"; for the Stripe plugin, Automattic "identified these issues during internal security testing".

The precondition most stores skip past

Before any legal question, answer a technical one: were you in scope? The National Vulnerability Database record for CVE-2026-18391, published 12 August 2026, is specific — the plugin "does not validate user input before unserializing it on stores with High-Performance Order Storage enabled, leading to a PHP Object Injection issue which unauthenticated users can escalate to Remote Code Execution via a gadget chain present in the bundled dependencies." The score is 9.8 (Critical).

Two conditions have to hold together: an affected version, and that storage mode switched on. A store that never enabled High-Performance Order Storage sits outside the described precondition, which changes the entire assessment that follows. Establish that first, from your own configuration, and write down how you established it. "We think we were fine" is not an assessment.

The Three Limbs — and the One eCommerce Teams Forget

Paragraph 17 of the EDPB guidelines, drawing on WP29 Opinion 03/2014, splits breaches into three: a "Confidentiality breach" ("an unauthorised or accidental disclosure of, or access to, personal data"), an "Integrity breach" ("an unauthorised or accidental alteration of personal data"), and an "Availability breach" ("an accidental or unauthorised loss of access to, or destruction of, personal data"). Paragraph 18 adds that one incident can hit all three at once.

Most incident plans are written as though only the first exists. That is the gap the Stripe advisory walks straight into: an issue whose described worst case is that the store stops working, with no suggestion that anyone read anything.

Does a store outage count as a personal data breach?

Yes, when the outage was not planned. EDPB paragraph 21 says "a security incident resulting in personal data being made unavailable for a period of time is also a type of breach". The same paragraph carves out routine work: data unavailable because of "planned system maintenance" is not a breach under Article 4(12).

The reason the guidelines give is that "the lack of access to the data can have a significant impact on the rights and freedoms of natural persons." Paragraph 19 concedes the difficulty — "whether there has been an availability breach may be less obvious" — and gives, as an example of loss of availability, "significant disruption to the normal service of an organisation, for example, experiencing a power failure or denial of service attack, rendering personal data unavailable."

Note what this does and does not mean for the Stripe advisory. The vendor described an issue that could cause stores to become unavailable under certain conditions. A capability is not an event. If your store never went down, there was no loss of availability and no breach. If it did go down, and the cause traces to that flaw, you are looking at an availability breach and the Article 33 risk assessment applies — even though nobody's data was read.

The £60,000 lesson in getting this wrong

In April 2025 the ICO fined Merseyside law firm DPP Law Ltd £60,000 over a June 2022 cyber attack. Attackers reached an infrequently used administrator account without multi-factor authentication, moved across the network and took over 32GB of data; DPP learned of the dark-web publication from the National Crime Agency. The reported finding on timing is the part to pin to your incident plan: the firm "did not consider that the loss of access to personal information constituted a personal data breach, so did not report the incident to the regulator until 43 days after they became aware of it." The penalty itself was for security failings under Article 5(1)(f) and Article 32 UK GDPR, with the delay an aggravating factor.

The transferable lesson is not "report everything". It is that a team which only recognises stolen data as a breach will misclassify the incident it is actually having.

When "We Have No Evidence" Is Not Good Enough

Two statements sound identical and are not. The vendor's "no evidence of exploitation" describes the vendor's testing across its own estate. Your assessment has to describe your store. Borrowing theirs and filing it as your finding is the most tempting shortcut here, and it is the one that will not survive a regulator asking how you know.

The threshold you are aiming at is set by EDPB paragraph 31: a controller "should be regarded as having become 'aware' when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised." Reasonable certainty is a positive finding, not an absence of curiosity.

Paragraph 34 gives you room to look: after being informed of a potential incident, "the controller may undertake a short period of investigation in order to establish whether or not a breach has in fact occurred. During this period of investigation the controller may not be regarded as being 'aware'." Paragraph 33 sets the tone for how that period should feel — "the emphasis should be on prompt action to investigate an incident to determine whether personal data have indeed been breached".

The log-retention problem nobody budgets for

Here the advisory stops being a legal question and becomes an infrastructure one. The WooCommerce advisory's own remediation guidance, for stores that suspect compromise, is to audit logs and files, review admin accounts for unauthorised users, remove suspicious files, reset passwords and rotate API keys. Every step assumes records exist to look at.

A vulnerability disclosed in August that has sat in shipped code for months needs logs going back months to rule out. If your retention is shorter than the exposure window, you cannot honestly reach "no evidence of compromise" — only "no evidence either way", which is a different sentence with different consequences.

The EDPB anticipated this. Paragraph 32 puts an affirmative duty on you: the GDPR "requires the controller to implement all appropriate technical protection and organisational measures to establish immediately whether a breach has taken place… This puts an obligation on the controller to ensure that they will be 'aware' of any breaches in a timely manner so that they can take appropriate action." Not being able to tell is not a neutral position. It is itself a finding about your Article 32 measures — and the fix is a retention setting, not a lawyer.

The Article 32 Exposure Is Separate — and It Has a Track Record

While you are deciding whether Article 33 was ever engaged, Article 32 has been running the whole time. Article 32(1)(b) requires "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services"; 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing". Running a known-vulnerable version after a patch exists is a live question under both, and it does not depend on anyone having been attacked.

The benchmark is not vague. Under Cyber Essentials, "all critical and high risk updates or updates with no details provided must be installed within 14 days of release by the vendor", where critical or high risk "can also be described as a CVSS v3 base score of 7 or above". CVE-2026-18391's 9.8 clears that threshold with room to spare.

Regulators have already fined on exactly this reasoning. Back in March 2022 the ICO issued a £98,000 penalty against Tuckers Solicitors LLP, finding infringements of Article 5(1)(f) and Article 32(1)(a) and (b) among others; a patch for a known critical vulnerability released in January 2020 had not been installed until June 2020. The ICO's line, as reported from the penalty notice, is blunt: "Tuckers should not have been processing personal data on an infrastructure containing known critical vulnerabilities without appropriately addressing the risk."

Our position: patch first and assess second, always. The patch decision has no genuine trade-off — the update is free, the vendor has tested it, and every hour it waits is an hour on the wrong side of that ICO sentence. The legal question can survive twenty minutes. The scope of testing before you deploy to production is a real judgement call; whether to deploy at all is not.

Your First 24 Hours After a Plugin Advisory

1. Establish scope from your own configuration. Which version were you running, and does the advisory's precondition apply to you? Record the version number and the check you ran, with a timestamp.
2. Patch, then verify the installed version. Confirm across production and staging, not just the site you happened to be looking at.
3. Freeze and extend logging before it rotates. This is the step with a deadline set by your host, not by you — if your access logs are on a 7-day window, the evidence you need to rule out exploitation is expiring while you read the advisory.
4. Run the vendor's own compromise checks. Audit logs and files, review admin accounts for unauthorised users, remove suspicious files, reset passwords, rotate API keys.
5. Ask the availability question separately. Did the store go down, or degrade, in the affected period? That is a distinct enquiry from "was anything read", and it is the one most likely to be skipped.
6. Reach a conclusion in writing and date it. One of three: no breach; breach, not notifiable; breach, notify. Each needs the evidence it rests on, and if the honest answer is "cannot determine", say that instead of rounding down to "no".
7. Start the 72 hours only when you have reasonable certainty that personal data was compromised — and if you get there, remember Article 33(4) lets you file in phases rather than wait for a complete picture.
8. Check your Article 30 record still matches reality. If the patch changed how or where order data is stored, the record of processing activities changed with it.

Common Mistakes eCommerce Teams Make

The worst one is treating the vendor's statement as your finding. "They said no evidence of exploitation" answers a question about the vendor's estate. Your supervisory authority will ask what you checked, on your store, and over what period.

Adopting the opposite error and notifying anyway. Article 33(1) requires notification of a personal data breach, and a patched, unexploited vulnerability is not one. Filing a defensive notification on facts that do not support it does not buy goodwill; it tells your regulator that your assessment process does not work in either direction.

Assuming "no breach" means "nothing to record". Article 33(5) requires that "the controller shall document any personal data breaches" — a duty the EDPB confirms applies "regardless of whether or not a breach needs to be notified" (paragraph 121), linked to the Article 5(2) accountability principle at paragraph 122. Strictly, that register covers breaches, so a genuine non-breach does not belong in it. Our recommendation is to keep a separate security-incident log for advisory assessments that concluded "no breach", and to be precise about which log an entry sits in. The trade-off is honest: Article 33(5) does not demand this. It is what turns "we assessed it" from an assertion into evidence, at the cost of a few minutes per advisory.

Only checking the storefront. Staging environments, a second brand on the same plugin licence, and the test site nobody has logged into for two years all run the same vulnerable code.

Letting the outage question go unasked. DPP Law's £60,000 penalty exists partly because loss of access did not register as a breach at all. If your incident template has no availability row, add one this week.

How PrivacyForge Helps

The work that decides how this goes happens before the advisory lands, and almost none of it is legal work.

A record of processing that answers "where does order data live". PrivacyForge's data mapping module keeps your Article 30 record with systems, data categories and retention periods attached — so "which of our stores ran that plugin, and what customer data sat behind it" is a lookup rather than an afternoon.

A breach workflow that records the decision, not just the notification. The valuable artefact from most advisories is a dated assessment concluding no breach, with the checks that support it. Capturing that at the time — alongside the Article 33(5) register for incidents that were breaches — makes the reasoning demonstrable months later.

Retention settings you can see. Knowing where log retention is shorter than a realistic exposure window is the difference between a defensible "no evidence of compromise" and an undefendable one.

For the controller-side obligations that apply once you have concluded a breach did occur, see our GDPR data breach notification guide for eCommerce, and for the scoping question our record of processing activities guide. Patching cadence sits alongside the other operational controls in our eCommerce GDPR compliance checklist.

Frequently Asked Questions

Is a plugin vulnerability a personal data breach under GDPR?

Not by itself. Article 4(12) GDPR defines a personal data breach as a breach of security "leading to" destruction, loss, alteration, unauthorised disclosure of, or access to personal data. A vulnerability that was disclosed and patched without being exploited has not led to any of those outcomes. The EDPB confirms that not all security incidents are personal data breaches.

Do I have to report a plugin vulnerability within 72 hours?

No. The 72-hour clock in Article 33(1) starts when you become aware of a personal data breach, and the EDPB treats awareness as having "a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised". Learning that a vulnerability exists is not that. Investigate first; notify if the investigation finds compromise.

Does a website outage count as a personal data breach?

An unplanned one can. The EDPB states that a security incident making personal data unavailable for a period of time is a type of breach, because lack of access can significantly affect people's rights. Planned maintenance is expressly excluded. If your store went down because of a security flaw, assess it as an availability breach even if nothing was read.

Do I still have to log an incident if I decide it is not reportable?

Yes, if it was a breach. Article 33(5) requires documenting any personal data breach with its facts, effects and remedial action, and the EDPB confirms this applies whether or not you notify. For an advisory you assessed and concluded was not a breach at all, keep a separate security-incident record — not required by Article 33(5), but it evidences that the assessment happened.

Can I rely on the vendor saying there is no evidence of exploitation?

Not as your own finding. A vendor statement describes what that vendor observed across its estate, not what happened on your store. Your assessment needs your own evidence: your version and configuration, your access logs over the exposure window, and your check of administrator accounts. If your log retention is shorter than that window, say so honestly.

Conclusion

The August 2026 WooCommerce advisories are worth keeping as a worked example, because they contain both answers. A confidentiality-and-integrity flaw with a stated precondition, no evidence of exploitation and a patch available is a security incident to assess and close out — not an Article 33 notification. An availability flaw that actually takes your store down is a breach, whether or not a single record was read.

The discipline that separates the two is unglamorous: know your version, know your scope, keep logs longer than your exposure window, and write down the conclusion with a date on it. Do that and the next red banner costs you an hour. Skip it and you are reconstructing, under time pressure, an answer you could have had on the day.

Start with the map. If you cannot say today which of your stores runs which plugin and where the order data behind it lives, build the record of processing activities that makes every future advisory a lookup instead of an investigation.

Sources

• WooCommerce security advisory: WooCommerce Subscriptions, 5 August 2026
• WooCommerce security advisory: Stripe for WooCommerce, 6 August 2026
• NVD record for CVE-2026-18391
• EDPB Guidelines 9/2022 on personal data breach notification under GDPR, Version 2.0
• GDPR Article 4 — Definitions
• GDPR Article 32 — Security of processing
• GDPR Article 33 — Notification of a personal data breach to the supervisory authority
• Infosecurity Magazine on the ICO's £60,000 fine for DPP Law
• Alston & Bird on the ICO's DPP Law penalty
• Orrick on the ICO's Tuckers Solicitors monetary penalty notice
• IASME: Cyber Essentials security update management