GDPR incident response: what regulators actually check after a breach
Sienna VanceApril 29, 2026
Key takeaways
GDPR Article 33 requires breach notification within 72 hours of awareness — but Vulnox assessment data shows the average gap between initial exposure and confirmed awareness of a breach impacting EU residents is 17 days, meaning the deadline has already passed before most investigations begin.
German and Dutch DPAs during active investigations request structured, machine-readable log files with MITRE ATT&CK technique mappings — not the policy documents and dashboard screenshots that satisfy audit requirements.
Notifying a supervisory authority too early, with incomplete or inaccurate details, carries regulatory consequences comparable to late notification — a preliminary report with errors becomes a documented record of what you claimed at the time.
Article 30 Records of Processing Activities (RoPA) become the primary compliance evidence document during a breach investigation — organizations that treat RoPA as a checkbox exercise cannot demonstrate which data was affected, for what purpose, and under what lawful basis.
Article 34 data subject notification is triggered when a breach is likely to result in high risk to rights and freedoms — regulators interpret this threshold broadly, and financial loss, identity theft risk, and reputational damage all qualify.
Legitimate Interest Assessments (LIAs) are absent in most organizations that list Article 6(1)(f) as their lawful basis — DPAs consistently fine for this, and a breach investigation is when the absence becomes visible.
TL;DR
Most organizations prepare for the 72-hour notification window. Few prepare for the investigation that follows. Regulators do not evaluate your breach response in isolation — they use it as a lens into your entire compliance posture. The evidence you cannot produce after a breach is evidence you did not have before it. That is what gets organizations fined twice: once for the breach, once for the compliance program that could not demonstrate it was working.
When the clock starts is not when you think
A mid-size German SaaS company detected anomalous access to their user database on a Tuesday afternoon. They spent two days confirming the scope, engaged external forensics on Thursday, and submitted their Article 33 notification to the BayLDA the following Monday — six days after detection, four days past the deadline. Their explanation: the full scope of affected data subjects was not known until Friday. The BayLDA's response was that awareness of a breach does not require complete knowledge of its scope. Awareness of a probable breach triggers the clock. The company had been aware of a probable breach on Tuesday.
The fine was not the only consequence. The investigation that followed examined every layer of the compliance program — RoPA completeness, logging retention periods, the lawful basis documentation for each processing activity involved in the breach. The notification delay became the entry point for a review the company had no reason to expect. That is how GDPR enforcement actually works: the breach opens the door, and regulators walk through it.
How the 72-hour window actually works
Article 33 uses the phrase 'without undue delay and, where feasible, not later than 72 hours after having become aware.' The word 'aware' is doing significant regulatory work. European Data Protection Board guidance clarifies that awareness is reached when a controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. That standard does not require confirmation of the full scope, identification of all affected individuals, or completion of forensic analysis. It requires reasonable certainty that a breach occurred. The 72 hours starts there.
Example
In practice, this means organizations need two parallel processes running from the moment an incident is detected: containment and documentation of when they first had reasonable certainty. That second process is the one most incident response plans omit. The forensic timeline reconstructed after the fact — based on log entries and ticket timestamps — is what regulators examine to determine whether the 72-hour clock was honored. If the logs show an anomaly at 14:37 on Tuesday and the notification arrived Monday, the gap is documented in the organization's own systems.
Requesting an extension is explicitly contemplated in Article 33(1): organizations may notify in phases when complete information is not available. A phased notification submitted within 72 hours with a documented rationale for what is still being established is significantly better than a delayed single notification. Regulators evaluate whether the organization was moving with urgency, not whether they had perfect information.
What breach investigations actually surface
Assessment base: Findings drawn from Vulnox assessments and post-breach reviews of EU-operating organizations in logistics, SaaS, and financial services, 2023-2025.
RoPA used as an audit document, not an operational record
In Vulnox assessments of organizations that had experienced a breach or regulatory inquiry, the Records of Processing Activities required by Article 30 were consistently maintained as static documents updated annually, not as living records reflecting current data flows. When regulators requested the RoPA during investigation, it described processing activities as they existed 14 months ago — before a cloud migration, a new third-party processor, and two product features that introduced new data categories. The document existed. It was inaccurate.
An inaccurate RoPA during a breach investigation does not just fail Article 30 — it creates a conflict between what the organization claims to process and what the forensic evidence shows was affected. That conflict becomes an additional line of inquiry. Organizations that maintain RoPA as an audit artifact rather than an operational record are building a compliance gap that only becomes visible when it is most expensive to fix.
Lawful basis documentation absent for the specific processing activities involved in breaches
The most common pattern across breach investigations: the organization has a general privacy policy referencing Article 6 lawful bases, but no Legitimate Interest Assessment for the specific processing activities where the breach occurred. Article 6(1)(f) — legitimate interests — requires a three-part balancing test documented before the processing begins. DPAs consistently treat the absence of an LIA as a standalone violation, separate from the breach itself. In a German logistics company assessment following a supplier portal compromise, the absence of an LIA for the supplier data processing added a second enforcement action to the breach notification.
A breach investigation is a retrospective audit. Every processing activity touched by the breach will be examined for lawful basis documentation. Organizations that have listed 'legitimate interests' as a basis without an LIA are carrying a compliance debt that accrues silently until an investigation reveals it.
Evidence format mismatch between what organizations retain and what investigators request
German and Dutch DPAs conducting post-breach investigations have increasingly requested structured log exports with event correlation and, in complex cases, MITRE ATT&CK technique annotations showing how the attacker moved through the environment. Organizations retaining logs in proprietary SIEM formats that cannot be exported to structured formats, or retaining logs for only 30 days, cannot produce this evidence. The inability to reconstruct the attacker's path is treated as a logging adequacy failure under Article 32 — even if the organization had logging in place.
Compliance with Article 32 logging requirements is evaluated not by whether logs exist but by whether they are sufficient to support the incident timeline regulators need. A 30-day retention policy deletes the evidence that would show when a breach began before the investigation starts. That is not a logging gap — it is an Article 32 failure.
The notification obligations organizations misread
Article 34 high-risk threshold
Article 34 requires notifying affected data subjects when a breach is likely to result in high risk to their rights and freedoms. Most organizations interpret this as requiring a catastrophic breach — mass credential exposure, financial data theft at scale. Regulators interpret it more broadly. A breach affecting a small number of individuals where the exposed data could enable targeted fraud, discrimination, or identity theft meets the threshold. The test is potential impact to individuals, not volume of records. Organizations that make this determination internally without legal review are consistently underestimating when Article 34 applies.
The no harm, no notification assumption
Organizations that discover a breach and conclude that no data was actually exfiltrated — because they can find no evidence of exfiltration — routinely decide notification is unnecessary. That conclusion requires a forensic foundation most organizations do not have. The absence of exfiltration evidence is not the same as confirmed absence of exfiltration. DPAs have fined organizations for failing to notify supervisory authorities of breaches where exfiltration could not be ruled out. The standard is whether a breach of personal data security occurred, not whether harm resulted.
Cross-border notification obligations
Organizations with EU operations in multiple member states must notify the lead supervisory authority — typically the DPA in the country of their main establishment — but must also consider whether affected data subjects in other member states trigger additional notification obligations. The one-stop-shop mechanism under Article 56 does not eliminate all local DPA involvement in breach cases. A UK-headquartered organization with German and French customers affected by a breach may face parallel expectations from multiple authorities even when the ICO is the lead supervisory authority.
The response sequence that holds under regulatory review
- Step 1
Document the moment of probable awareness
Output:Timestamped incident record that can be produced to a regulator as evidence of when awareness was reached. This document should not be edited after the fact.
Purpose:Establish the start of the 72-hour clock with a timestamped internal record. This is the entry in the incident log, the ticket creation, the Slack message from the security analyst — whatever creates an auditable record of when the organization first had reasonable certainty a breach occurred.
- Step 2
Cross-reference the RoPA against affected systems
Output:List of affected processing activities mapped to Article 30 entries, with gaps identified. Gaps become immediate remediation priorities and must be disclosed to legal counsel before notification.
Purpose:Identify which processing activities, data categories, lawful bases, and data subjects are implicated by the breach. This step reveals whether the RoPA is current and whether lawful basis documentation exists for the affected activities.
- Step 3
Make a documented Article 34 determination
Output:Written Article 34 assessment with reasoning, signed off by DPO and legal counsel, retained as part of the incident record.
Purpose:Assess whether the breach is likely to result in high risk to the rights and freedoms of affected data subjects. This determination must be documented, must consider the nature of the data, the likely impact to individuals, and must involve legal input. An undocumented decision not to notify data subjects is a regulatory liability.
- Step 4
Submit phased Article 33 notification within 72 hours
Output:Submitted notification with DPA reference number. Internal record of submission timestamp.
Purpose:Notify the supervisory authority with available information. Explicitly state what is still being established and the expected timeline for a supplementary notification. A phased notification within the window is significantly better than a complete notification after it.
- Step 5
Preserve and structure forensic evidence
Output:Structured incident timeline that can be provided to a DPA investigator in a format they can work with directly.
Purpose:Export logs in structured formats, preserve system states, and document the attacker's path through the environment using available forensic data. Log retention beyond 90 days for affected systems. If MITRE ATT&CK mapping is feasible, annotate the timeline.
- Step 6
Conduct post-incident RoPA and LIA review
Output:Updated RoPA and completed LIAs for implicated processing activities, dated after the breach and retained as evidence of remediation.
Purpose:Use the breach as a forcing function for reviewing every processing activity implicated in the incident. Update the RoPA to reflect current data flows. Commission LIAs for any Article 6(1)(f) basis that lacks one. This step transforms the breach response into a compliance improvement exercise.
More information in a notification is not always safer
Common belief
Organizations preparing Article 33 notifications tend to include as much detail as possible on the assumption that transparency reduces regulatory risk. If the regulator knows everything upfront, there is less to discover later.
What we found
In post-breach reviews, we consistently find that the most damaging notifications were the ones submitted fastest with the least forensic foundation. The phased notification mechanism in Article 33(1) exists precisely for this situation. Use it. A notification that says 'we have identified a probable breach affecting user account data, the full scope of affected individuals is being established and we will supplement within five business days' is more defensible than one that claims to know the scope before the investigation is complete.
A notification is a formal record. Every factual claim in it will be compared against the forensic evidence that emerges from the investigation. An early notification stating that no financial data was affected, submitted before forensic analysis is complete, becomes a problem if financial data is later found in the exfiltrated dataset. The notification did not just undercount the impact — it created a documented discrepancy between what the organization told the regulator and what the evidence showed. That discrepancy is its own compliance issue, separate from the breach.
Where enforcement is heading
DPAs will begin treating log retention gaps as standalone Article 32 violations in breach investigations, separate from the breach itself, by end of 2026.
The current enforcement pattern uses log gaps as an aggravating factor in breach-related fines. The regulatory logic that a logging failure made it impossible to determine whether a breach occurred — and therefore impossible to meet Article 33 notification obligations — already supports treating log retention as an independent obligation. The EDPB guidance on Article 32 technical measures is moving in this direction. The first standalone fine for log retention failure will establish the precedent.
Confidence: mediumA DPA enforcement decision citing Article 32 log retention failure as the primary violation in a case where the breach itself was resolved without significant data exposure.Absent Legitimate Interest Assessments will become the most commonly cited standalone GDPR violation in breach investigations within 18 months.
DPAs already fine for absent LIAs. What has changed is the investigation trigger: breaches now prompt comprehensive review of lawful basis documentation for every affected processing activity. Most organizations using Article 6(1)(f) as a lawful basis across multiple processing activities have not completed LIAs for all of them. Each breach investigation that surfaces this pattern builds the enforcement precedent. The volume of organizations with this gap is large enough that the enforcement wave is structural.
Confidence: highEDPB enforcement statistics showing LIA-related violations not increasing as a share of breach investigation outcomes by end of 2026.
The DPO appointment that does not fix anything
Many organizations that have appointed a Data Protection Officer treat the appointment as the compliance program. The DPO exists, therefore GDPR is handled. What those organizations actually have is a single person responsible for a compliance function that requires engineering involvement, legal review, operational process changes, and board-level data governance decisions — none of which the DPO can implement unilaterally. The DPO's job is to advise, monitor, and liaise with regulators. The actual work of building a defensible compliance program belongs to the organization. Appointing a DPO and then underfunding the function they are supposed to oversee is one of the more reliable ways to fail an investigation while technically complying with Article 37.
Counterargument
The counterargument is that most organizations, particularly SMBs, do not have the resources to build a fully-resourced compliance function and that a DPO with limited support is better than no DPO at all. That is true. But the organizations that fail breach investigations most completely are not the ones with no DPO — they are the ones with a DPO who has been telling leadership for two years that the RoPA is outdated, that LIAs are missing, that log retention is insufficient, and whose recommendations were consistently deprioritized. The appointment satisfied the regulatory requirement. The compliance program did not.
One thing to do this week
Open your RoPA and find three processing activities that list Article 6(1)(f) — legitimate interests — as the lawful basis. For each one, locate the Legitimate Interest Assessment that documents the balancing test. If you cannot find it, you do not have one. Commission it before the next incident review. That gap will not close itself, and a breach investigation is a bad time to discover it.
Further Reading
Gap Analysis
gap analysis frameworksVulnerability Assessment
vulnerability assessment servicesEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
GDPR incident response steps for data professionalsGDPR Compliance Guidelines
official GDPR compliance guidelinesGDPR Legal Text Official
official GDPR legal textGDPR Compliance Requirements
GDPR compliance requirements
Frequently Asked Questions
When exactly does the GDPR 72-hour breach notification clock start?
The clock starts when the controller has a reasonable degree of certainty that a security incident has occurred that led to personal data being compromised — not when forensic analysis is complete or all affected individuals are identified. EDPB guidance is explicit that awareness does not require complete knowledge of scope. Vulnox post-breach reviews show the average gap between initial exposure and confirmed awareness is 17 days, meaning the 72-hour window has already passed before most investigations formally begin.
What happens if we notify the supervisory authority after the 72-hour deadline?
Late notification requires a documented justification for the delay under Article 33(1). Acceptable reasons include ongoing forensic analysis where scope was genuinely unclear and attacker obfuscation of evidence. Unacceptable reasons include insufficient staffing or underestimating severity. The notification itself also becomes a document regulators will compare against forensic evidence — any factual claim that contradicts later findings becomes an additional compliance issue. A phased notification within 72 hours, explicitly stating what is still being established, is significantly more defensible than a complete late notification.
When do we have to notify data subjects under GDPR Article 34?
Article 34 notification is required when a breach is likely to result in high risk to the rights and freedoms of natural persons. This threshold is broader than most organizations assume — financial loss risk, identity theft risk, and reputational damage all qualify. Volume of affected records is not the test; potential impact to individuals is. The determination must be documented and signed off by the DPO and legal counsel, regardless of whether the conclusion is to notify or not. An undocumented decision not to notify is a regulatory liability.
What evidence do German regulators request during a GDPR breach investigation?
German DPAs conducting post-breach investigations request the Records of Processing Activities for affected processing activities, lawful basis documentation including Legitimate Interest Assessments for any Article 6(1)(f) processing, structured log exports covering the incident period, and increasingly, incident timelines with MITRE ATT&CK technique annotations showing attacker movement through the environment. Dashboard screenshots and policy documents satisfy audit requirements. They do not satisfy investigative evidence standards. Organizations with 30-day log retention policies often cannot produce the timeline regulators need.
What is a Legitimate Interest Assessment and why does it matter in a breach investigation?
A Legitimate Interest Assessment (LIA) documents the three-part balancing test required before using Article 6(1)(f) as the lawful basis for processing: whether the legitimate interest is real, whether the processing is necessary to achieve it, and whether the individual's rights and interests override that legitimate interest. DPAs treat the absence of an LIA as a standalone violation, separate from any breach. In breach investigations, every processing activity implicated in the incident is examined for lawful basis documentation. Organizations using legitimate interests as a basis without completed LIAs are carrying a compliance debt that becomes visible only when the investigation starts.
How should we structure our GDPR incident response plan?
An effective GDPR incident response plan documents six things specifically: how and when awareness of a probable breach is recorded with a timestamp, how the RoPA is cross-referenced against affected systems to identify processing activities and data categories involved, how the Article 34 high-risk determination is made and documented, the process for phased Article 33 notification within 72 hours, how forensic evidence is preserved in a format DPA investigators can work with, and how post-incident RoPA and LIA gaps are remediated. Plans that address containment and recovery without addressing these regulatory steps will fail an investigation even if the technical response was sound.
Does GDPR apply to US companies processing EU resident data?
Yes. GDPR applies to any organization processing the personal data of EU residents, regardless of where the organization is established. A US SaaS company serving EU customers is subject to GDPR for that processing. A breach affecting EU customer data triggers Article 33 notification obligations to the relevant EU supervisory authority, Article 34 obligations to affected data subjects, and the full investigative scrutiny of the DPA with jurisdiction. The absence of an EU establishment does not reduce the notification obligation — it complicates identifying which supervisory authority has jurisdiction.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.