A critical vulnerability sitting unpatched in a backlog is a risk register entry. The same vulnerability with a confirmed injection payload against a customer table in your access logs is, under the GDPR, a legal deadline. Article 33 gives a controller 72 hours from the moment it becomes aware of a personal data breach to notify its lead supervisory authority, and a substantial share of the breaches EU regulators handle each year trace back to an unpatched or actively exploited technical flaw rather than a lost laptop or a misaddressed email. The gap between “we found a vulnerability” and “we have a notifiable breach” is where security and legal teams either coordinate well or burn the clock arguing about definitions.
Article 33 Trigger: When a Vulnerability Becomes a Notifiable Personal Data Breach
The GDPR does not regulate vulnerabilities. It regulates personal data breaches, defined in Article 4(12) as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A CVE in your stack is not, by itself, a breach. The question that starts the legal clock is narrower: did someone access, exfiltrate, alter, or destroy personal data through that flaw, or is there a reasonable basis to suspect they did?
Two facts decide the answer, and both should come out of the same triage a security team already runs on any confirmed exploitation event.
- Data scope of the vulnerable asset. Check whether the affected component touches personal data at all. A remote code execution flaw in an internal build server with no customer data is a severe security incident but not automatically a GDPR event. The same flaw in an API endpoint that reads from a customer table changes the analysis immediately.
- Evidence of exploitation, not just exposure. A WAF block on an SQL injection attempt is exposure without access. A 200 response to a UNION-based query against the users table, a successful authentication bypass, or outbound traffic matching the size of a database export is access. The European Data Protection Board’s breach guidance (WP250 rev.01) treats unauthorised access as a breach even without confirmed exfiltration when the controller cannot rule out that access occurred, so an unresolved “we can’t tell if they read the table” finding on a system holding personal data should default to breach status until forensics says otherwise.
In practice this means vulnerability data needs a data-classification tag attached at the asset level, not bolted on during an incident. If your asset inventory already flags which hosts process personal data, a critical finding against a tagged asset routes straight into breach triage instead of sitting in the general remediation queue while someone works out what the server does.
Starting the 72-Hour Clock: What “Awareness” Means and Phased Notification
Article 33(1) requires notification “without undue delay and, where feasible, not later than 72 hours after having become aware of it.” The word doing the legal work is “awareness,” and it does not mean the timestamp on the first intrusion detection alert. The EDPB’s position is that a controller is aware once it has a reasonable degree of certainty that a security incident has occurred and that it compromised personal data. A raw alert that later turns out to be a false positive does not start the clock. A short, focused investigation to confirm what happened is acceptable, but “short” means hours, not the multi-week internal reviews that show up in enforcement decisions as an aggravating factor.
A realistic timeline for a confirmed exploit against a customer-facing application looks like this:
- T+0. SIEM or WAF fires an alert on anomalous request patterns against an authenticated endpoint.
- T+2 hours. SOC triage confirms the requests correspond to a known CVE in the application framework and that the exploit attempt succeeded against a production instance.
- T+6 hours. Log review shows query patterns consistent with a bulk read of the customer table, and egress logs show an outbound transfer matching that volume.
- T+6 hours is your awareness point. The 72-hour clock runs from here, meaning notification is due by roughly T+78 hours, not from T+0.
Article 33(4) allows phased notification when you do not have every fact within the window: you notify what you know at T+78 hours (nature of the breach, approximate categories and number of data subjects and records, DPO or contact point, likely consequences, and measures taken or proposed) and supplement later as forensics completes. Regulators generally accept an initial notification with placeholders like “investigation ongoing, updated numbers to follow within X days” far better than they accept silence while you wait for a complete picture. Missing the 72-hour mark to get a perfect number is a worse outcome than hitting it with a documented estimate.
Article 34 Notification to Data Subjects and the Exemptions
Article 34 has a higher trigger than Article 33: notification to affected individuals is required only when the breach is “likely to result in a high risk to the rights and freedoms of natural persons,” compared to the plain “risk” threshold for notifying the supervisory authority. There is no fixed hour count in Article 34, only “without undue delay,” but a breach involving financial data, credentials, or special category data under Article 9 pushes the expected response time down toward the same order of magnitude as the regulator notification.
Article 34(3) gives three ways to avoid or narrow the individual notification obligation, and each maps to a concrete technical fact you should already have from the incident:
- (a) Prior protective measures. If the exposed data was encrypted with keys that were not compromised, or hashed with a modern, salted algorithm, the data is unintelligible to whoever accessed it. A dump of bcrypt or Argon2 password hashes without the application secret is a materially different risk than a dump of plaintext credentials, and this distinction is the difference between needing individual notices and not.
- (b) Subsequent measures. If you can show that follow-up action, such as forcing a password reset, revoking the exposed tokens, or closing the exploited path before any misuse occurred, means the high risk no longer materialises, that closes the gap.
- (c) Disproportionate effort. When individual contact is impractical, a public communication (a notice on your site, a press statement) can substitute, though this is the exemption regulators scrutinise hardest and it should not be the default choice.
The practical lesson is that the remediation you run in the hours after detection is not just security hygiene, it is the evidence that determines whether Article 34 applies at all.
Documenting the Detection-to-Notification Timeline as Evidence
Regulators ask not only what happened but when you knew and what you did in between, because Article 33(1) carries its own enforcement track record separate from the underlying security failure. The timeline of detection, triage, decision, and notification is the artifact a DPA reviews to decide whether you met the deadline and, if not, whether the delay was reasonable.
A record that holds up under review needs, at minimum: the exact timestamp of the first alert, the ticket or case ID it generated, who made the triage call and on what evidence, the forensic findings that confirmed data access (hashes or log excerpts, not summaries), the timestamp and rationale for classifying the event as a notifiable breach, and the submission timestamp and confirmation reference from the supervisory authority’s portal.
The weak point in most organisations is the handoff between the vulnerability finding and the incident record: the scanner or pentest report that first flagged the flaw often lives in a different system than the incident ticket, with no shared identifier connecting them. Platforms that manage the full vulnerability lifecycle in one place, SITEY among them, keep the original finding ID, the validation evidence, the patch action, and the retest confirmation on a single timestamped record, the chain a DPA asks for when it wants to see how long the flaw existed before exploitation and how long remediation took after.
The Internal Breach Register: Required Even When You Don’t Notify
Article 33(5) requires the controller to document every breach, including facts, effects, and remedial action, regardless of whether it met the threshold for notifying a supervisory authority. This register is not optional paperwork for the events you do report; it is mandatory for every event you decide not to report, and a DPA can request it during any audit without a breach having prompted the visit.
A defensible register entry includes:
| Field | What it must show |
|---|---|
| Detection timestamp | When the underlying flaw or exploitation was first observed |
| Description | Root cause, exploited vulnerability identifier, affected system |
| Data categories and volume | Approximate number of data subjects and records, and category (basic, financial, special category) |
| Consequences | Assessed impact, including whether encryption or hashing limited it |
| Remedial action | Patch or configuration change applied, and confirmation it closed the exploited path |
| Notify or not, and why | Named decision-maker, risk assessment used, DPO sign-off |
The last row is where organisations get caught out. A pattern of “not notifiable” decisions against objectively serious findings, such as confirmed database access repeatedly logged as low risk, is itself a red flag in an audit, because it suggests the risk assessment step is being used to avoid the notification obligation rather than to apply it honestly. Cross-referencing the register against your compliance mapping for the relevant framework (GDPR, and for many EU-adjacent organisations also ISO 27001 Annex A or SOC 2 CC7) keeps the notify or don’t-notify decisions consistent with how the same incident is classified for other obligations, instead of getting a different answer depending on which team writes the assessment.
Enforcement Examples Where Notification Speed and Remediation Shaped the Fine
Public enforcement decisions from EU and UK data protection authorities give a reasonably consistent picture of what regulators weigh once a technical flaw becomes a breach.
| Case | Underlying issue | Regulator finding relevant to timing |
|---|---|---|
| British Airways (ICO, 2018 incident) | Payment page compromised via injected script, credentials and card data skimmed | Fine reduced on appeal, but the decision specifically criticised inadequate monitoring that let the compromise run before detection |
| Marriott / Starwood (ICO, 2018 discovery) | Intrusion into the reservation system present for years before discovery | ICO cited insufficient monitoring and inadequate due diligence during the acquisition as reasons the exploitation went undetected for so long |
| Booking.com (Dutch DPA, 2021 decision) | Phishing of a hotel partner exposed guest data including passport numbers | Fined specifically for notifying the Dutch DPA about three weeks late, not for the underlying phishing incident itself |
The Booking.com decision is the cleanest illustration of the point this article opened with: the fine there was not for having a breach, it was for missing the 72-hour obligation on a breach the company had already identified internally. The British Airways and Marriott cases show the other failure mode, where slow detection (not slow notification) meant an exploited weakness sat active for a long time, which regulators treated as evidence of inadequate security measures under Article 32 as much as a breach-notification issue.
The operational takeaway is to treat detection speed and notification speed as two separate metrics with two separate owners, and to rehearse the handoff between them before an incident forces it. A tabletop exercise that walks a confirmed critical finding from initial alert through data-scope triage, risk classification, register entry, and (if needed) the regulator notification draft, run once a quarter against a hypothetical scenario, exposes the gaps in your logging and ownership long before a real exploit does. Platforms that automate retest and closure, SITEY among them, add a specific piece of evidence to that record: a timestamped confirmation that the patch actually closed the exploited path, rather than an assumption based on a deployment ticket, which is precisely the “subsequent measures” evidence Article 34(3)(b) asks for.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.