WordPress Security and GDPR: What a Breach Actually Requires

Why this applies to an "ordinary" WordPress site

GDPR doesn't only apply to sites that obviously handle sensitive data. It applies to any site processing personal data belonging to people in the EU — and a default WordPress install already does this in several places most owners don't think of as "data" at all:

• User accounts — names, emails, and (hashed) passwords for anyone with a login
• Commenter details — the name and email WordPress collects on every comment by default
• Contact form submissions — whatever a visitor typed into a Contact Form 7 or Gravity Forms entry, often sitting in a database table indefinitely
• WooCommerce customer and order records — names, addresses, order history, and sometimes partial payment details, depending on your gateway

If any of that belongs to someone in the EU, a breach involving it is a GDPR-relevant data breach — regardless of how small the site is or whether you think of yourself as "handling personal data" in the way a bank or hospital does.

The 72-hour rule, precisely

This is the part that gets misquoted constantly, so it's worth being exact. GDPR Article 33 requires that a controller notify the relevant supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware" of a personal data breach — unless the breach is unlikely to result in a risk to people's rights and freedoms.

Two details in that sentence matter more than the headline number:

• The clock starts at awareness, not at the breach itself. If an attacker was quietly inside your database for three weeks before you noticed, your 72 hours starts the moment you have a reasonable degree of certainty a breach happened — not three weeks ago.
• "Where feasible" is not a loophole to relax into. If you can notify sooner, you're expected to. And if you genuinely can't make the 72-hour window, Article 33 has a specific escape hatch: you can still notify late, but the notification has to be accompanied by reasons for the delay. Silence past 72 hours with no explanation is the actual violation, more than lateness alone.

When you do notify, Article 33 specifies what the notification needs to include: the nature of the breach, the categories and approximate number of people and records affected, the likely consequences, and the measures you've taken or plan to take to address it. You don't need every forensic detail nailed down to notify — you need enough to describe the shape of the problem honestly.

When you also have to tell the affected people directly

Notifying the supervisory authority (Article 33) and notifying the actual people affected (Article 34) are two separate obligations with two different thresholds. Article 34 only kicks in when the breach is likely to result in a high risk to people's rights and freedoms — a meaningfully higher bar than Article 33's "risk." There's no fixed 72-hour deadline for this one, but the same "without undue delay" standard applies — you can't sit on it.

In practical WordPress terms: a breach that exposed hashed passwords with no other data is a very different situation from one that exposed plaintext contact-form submissions containing sensitive details, or WooCommerce orders with customer addresses and partial payment information. The first might reasonably stay at "notify the authority, monitor for misuse." The second is much more likely to cross into "email every affected customer directly," because the potential for real harm — fraud, identity theft, targeted phishing using the leaked details — is concrete rather than theoretical.

A practical first-hours checklist

1. Confirm what was actually accessed, not what you're afraid was accessed. "A file was modified" and "customer records were exfiltrated" require very different responses. Check file integrity findings, database access logs, and outbound traffic before assuming the worst-case scenario — but also don't downplay it past what the evidence actually shows.
2. Start a timeline immediately, in writing. When you first noticed something was wrong, when you confirmed it was a breach, what you did at each step. Regulators explicitly expect this kind of documentation, and reconstructing it from memory two weeks later is much harder than logging it as you go.
3. Don't let "we need more information" become an excuse to blow past 72 hours silently. If your investigation is still ongoing at the deadline, that's fine — notify with what you know, note that the investigation is continuing, and follow up as you learn more. That's explicitly allowed; going quiet is not.
4. Close the actual entry point, not just the visible symptom. The same principle that applies to any WordPress compromise applies here — if the vulnerability or credential that let the attacker in is still open, the breach isn't actually over, and that affects both your remediation story and whether you're at risk of a second incident.
5. Loop in someone who can give you real legal guidance on whether Article 34's high-risk threshold is met, before you decide what to tell affected users. That's a judgment call with real consequences either way — under-notifying is a compliance risk, and over-notifying with alarming language you can't fully back up creates its own problems.

The record you have to keep even if you don't notify anyone

One requirement gets missed constantly because it doesn't involve telling anyone else anything: Article 33(5) requires you to document every personal data breach internally — including ones you correctly decide are unlikely to result in a risk and therefore don't report to the supervisory authority. The record needs to cover the facts of the breach, its effects, and the remedial action taken, plus your actual reasoning for whether or not you notified.

The point of this isn't paperwork for its own sake — it's so that if a regulator ever asks, you can show your reasoning at the time rather than reconstructing a justification after the fact. There's no fixed retention period written into GDPR itself, but supervisory authorities generally expect these records kept for at least three years, some longer. A simple dated log entry — what happened, what you found, what you decided, why — is enough; it doesn't need to be a formal report unless the breach is serious enough to warrant one anyway.

Where a security plugin actually helps here

None of this is about compliance software making GDPR obligations disappear — a plugin doesn't file your regulatory notification for you. What it changes is the beginning of the timeline: the sooner you have a reliable answer to "what actually happened and what was accessed," the sooner you can notify accurately instead of guessing, and the more of your 72 hours you have left to actually think it through rather than spending most of it just figuring out whether you were breached at all. File-integrity checks, login and privilege-change monitoring, and correlated incident timelines are exactly the kind of evidence a regulator's notification content requirements (nature of the breach, categories affected, measures taken) actually ask for.