GDPR Data Breach: What You Need to Know

According to a survey done by DLA Piper, European data protection authorities receive about 443 breach notifications on average daily. And that number has been increasing in the last couple of years, last year alone going up about 20%. This means that right now, as you read this, organizations across the continent are wary, while others are filing reports, scrambling for lawyers, and learning the hard way what GDPR actually costs when something goes wrong.

The survey went on to state that the cumulative fine total since the GDPR came into effect in 2018 has exceeded €7.1 billion. But the truth is: the fine is often the least of it. The real exposure today is civil litigation from affected individuals, operational paralysis during investigations, reputational damage that tanks customer retention, and, in regulated sectors, the secondary consequences from financial or health regulators piling on after the ICO or CNIL has already moved. One breach. Multiple simultaneous fires.

This guide covers what the breach landscape looks like under GDPR and what you need to know to steer clear of these risks and remain compliant.

What Actually Counts as a GDPR Data Breach?

Most people hear “data breach“ and picture a hacker. A hoodie, a dark room, lines of code. That mental image is both the most common starting point and the most dangerous one. This is because it leads controllers to build their entire incident response around external attack scenarios, while the breaches that actually trigger regulatory scrutiny are often far more mundane and far closer to home.

The legal definition

Under Article 4(12) of the GDPR, a personal data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure or access to personal data. That definition covers three distinct failure types that regulators group under the CIA triad:

• Confidentiality breach — This happens when personal data ends up in front of someone who has no business seeing it, whether through malice, negligence, or a simple mistake. The data still exists; it hasn’t been changed or deleted, but the wrong eyes have accessed it.
• Integrity breach — This is about the trustworthiness of the data itself being compromised. Personal data has been changed, manipulated, or corrupted in a way that wasn’t authorized — and the damage is that you can no longer be certain the records reflect reality.
• Availability breach — This occurs when personal data exists but can no longer be accessed by the people or systems that need it, either temporarily or permanently. No one may have stolen anything. Nothing may have been altered. But if individuals or organizations are locked out of data they depend on — especially in time-sensitive contexts like healthcare, banking, or public services — the harm is real and immediate.

Examples of GDPR data breach scenarios in practice

ENISA’s threat landscape data consistently shows that the most common breach categories aren’t sophisticated intrusions — they’re:

• Misdirected emails. An employee sends a spreadsheet containing customer names, emails, or account details to the wrong recipient. Simple. Happens dozens of times a day across organizations of every size. Fully reportable.
• Stolen or lost devices. An unencrypted laptop goes missing. A phone with unprotected access to a corporate email account is left in a taxi. If personal data was accessible on that device, you likely have a breach.
• Rogue or departing employees. Someone downloads a CRM export before their last day. A disgruntled employee accesses records they have no business reason to view. The access was “authorized” in a technical sense — their credentials still worked — but the purpose was unauthorized, and that’s enough.
• Misconfigured cloud storage. An S3 bucket or Azure Blob container is left publicly accessible during a migration or setup process. No one may have accessed it externally. It doesn’t matter — the exposure itself is the breach.
• Third-party incidents. Your processor gets hit. Their systems go down, or their data is compromised. As the controller, the breach is yours to report, even though it happened entirely within a vendor’s environment.
• Ransomware. Even if you restore from backups and confirm nothing was exfiltrated, a ransomware attack typically constitutes an availability breach, and depending on the attacker’s known behavior, regulators may treat exfiltration as presumed unless you can demonstrate otherwise.

What does NOT count as a GDPR breach

This matters as much as what does. GDPR only applies where personal data — information relating to an identified or identifiable natural person — is involved. Which means:

• A breach affecting only corporate financial records, internal business strategy documents, or proprietary technical data, with no personal data in scope, does not trigger GDPR obligations. It may trigger other legal or regulatory consequences, but not this one.
• A system outage affecting an internal tool that holds no personal data is an IT incident, not a data breach under GDPR.
• Anonymized data — genuinely anonymized, not just pseudonymized — falls outside the regulation entirely. If you can demonstrate that re-identification is not reasonably possible, GDPR breach obligations don’t apply.

Does every breach need to be reported?

Not automatically — but the burden of proof sits firmly with the controller. Article 33 requires notification to the supervisory authority within 72 hours unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. That exception sounds generous. However, regulators interpret it narrowly, and the documentation requirement applies regardless. Even if you decide not to report, you must record why, with enough detail to withstand scrutiny if an authority later disagrees with your assessment.

The working assumption that keeps organizations out of trouble is this: when in doubt, it’s a breach. The question is never just “did something go wrong?” It’s “Did something go wrong that touched personal data?” If the answer to the second question is yes, your 72-hour clock may already be running.

The 72-Hour Clock — And Why It’s About to Change

If there is one number every organization operating under GDPR knows, it is 72. Seventy-two hours to notify the supervisory authority after becoming aware of a personal data breach. While it sounds straightforward, this is one of the most consistently misunderstood and misapplied obligations in the entire regulation — and it is currently in the middle of a proposed overhaul that could change the calculus entirely.

When does the clock actually start?

The trigger is not when the breach happened. It is not when the IT team first noticed something unusual. It is not when the investigation is complete. The clock starts when the organization has become “aware” of the breach — and that word, ‘aware’, carries far more weight than it appears to.

Regulators and the European Data Protection Board (EDPB) have addressed this in Guidelines 9/2022 on Personal Data Breach Notification, stating that awareness does not require absolute certainty. You do not need to have confirmed every detail, identified every affected individual, or fully scoped the damage before the clock begins. Awareness kicks in when there is a reasonable degree of certainty that a security incident has occurred and that personal data is involved. The moment a credible internal alert after an initial assessment, a third-party notification, or a system anomaly gives you that reasonable basis, the 72 hours begin.

Many organizations frequently burn significant time in an internal “we’re still investigating, we don’t know enough yet” holding pattern, genuinely believing the clock hasn’t started. Regulators see it differently. If your security team flagged a suspicious export on Monday and you didn’t notify until Friday because you were waiting for a full forensic report, you may already be in violation — regardless of how thorough your investigation was.

Therefore, the moment your team has enough information to reasonably believe personal data has been compromised, treat the clock as running. Investigate and notify in parallel, not sequentially.

What notification to the supervisory authority must actually contain

Article 33(3) sets out the minimum content required in a breach notification. It must include:

• The nature of the breach — what happened, what type of breach it was, which categories of personal data were affected, and an approximate number of individuals involved. You don’t need exact figures, but “we don’t know” with no further detail is not acceptable.
• The contact details of the Data Protection Officer (or whoever is the designated point of contact for the incident).
• A description of the likely consequences of the breach — what harm could realistically result for affected individuals. This requires the controller to actually think through the downstream risk, not just describe the technical event.
• The measures taken or proposed to address the breach and mitigate its effects. Regulators want to see that the controller has responded, not just reported.

Critically, Article 33(4) allows for phased notification. If you cannot provide all of this information within 72 hours — because the investigation is still ongoing — you can submit an initial notification with what is already known, and follow up with additional information as it becomes available. This provision exists precisely because complete information is rarely available within three days. What it does not allow is using incomplete information as a reason to delay the initial notification entirely.

When you must also notify the individuals affected

Notifying the supervisory authority and notifying the affected individuals are two separate obligations with two different thresholds. Not every breach that requires authority notification also requires individual notification.

Under Article 34, you must notify affected individuals directly — in clear, plain language — when the breach is likely to result in a high risk to their rights and freedoms. The bar here is higher than for authority notification, but it is also less forgiving in terms of content. The communication to individuals must tell them what happened, what data was affected, what the likely consequences are for them personally, and what steps they can take to protect themselves.

High risk typically applies where the breach could lead to serious impacts such as identity theft, financial loss, discrimination, reputational damage, or other significant real-world harm. A breach of encrypted data where the key was not compromised may not meet this threshold. A breach exposing unencrypted health records, financial credentials, or data belonging to vulnerable individuals almost certainly does.

There are three exemptions that lift the obligation to notify individuals even when high risk is present:

• If appropriate technical protections that render the data unintelligible (strong encryption being the clearest example) have been applied,
• If subsequent measures that eliminate the high risk have been taken, or
• If individual notification would involve disproportionate effort, in which case a public communication is required instead.

These exemptions are interpreted narrowly. Do not rely on them without documented justification.

The proposed overhaul: what the EU’s Digital Omnibus means for the 72-hour rule

As part of the European Commission’s broader Digital Omnibus package — a set of proposals aimed at simplifying and harmonizing digital regulation across the EU — the Commission has put forward amendments to GDPR’s breach notification framework that would represent the most significant change to these obligations since the regulation came into force in 2018.

The key proposals on the table:

• Extension of the notification window from 72 hours to 96 hours. An additional 24 hours sounds modest. For organizations dealing with complex, cross-border incidents or weekend discoveries, it is operationally meaningful. The argument for it is that 72 hours consistently produces incomplete, low-quality notifications because organizations are forced to report before they have enough information. The argument against is that it weakens a deadline that has been one of GDPR’s more effective enforcement levers.
• A raised threshold for what triggers mandatory notification. The current framework requires notification unless the risk to individuals is unlikely. The proposed revision would raise that threshold, meaning a broader category of lower-risk breaches would fall below the reporting line. Proponents argue this would reduce the volume of low-value notifications drowning supervisory authorities. Critics — including several data protection authorities and civil society organizations — argue it creates a gap that bad actors and negligent organizations could exploit.
• A centralized ENISA reporting portal for cross-border breaches. Currently, organizations operating across multiple EU member states navigate a fragmented landscape: different authorities, different national forms, different procedural expectations. The proposal would route cross-border breach notifications through a single European Union Agency for Cybersecurity portal, with ENISA coordinating across relevant national authorities. This is arguably the least controversial element of the package and addresses a genuine operational pain point for multinational organizations.

What’s controversial: the raised notification threshold has drawn the sharpest pushback. Data protection authorities in several member states have signalled resistance, arguing that the current framework — despite its compliance burden — generates the kind of transparency that enables meaningful regulatory oversight. Consumer and privacy advocacy groups have been more direct, framing the raised threshold as a regression dressed up as simplification.

When could this take effect: the Digital Omnibus proposals were advanced in November 2025 and are currently moving through the EU legislative process. Given the typical timeline for EU legislative procedure — negotiation between the Commission, Parliament, and Council, followed by a transition period — any changes are unlikely to apply before 2027 at the earliest. Some elements may be amended significantly or dropped before the final text is agreed.

What this means for your response plan right now

The temptation when legislative change is on the horizon is to wait and see — to delay updating internal procedures until the new rules are confirmed. That is the wrong call, for two reasons.

First, until any amendment is formally adopted and in force, the existing 72-hour obligation remains fully enforceable. Regulators are not softening enforcement in anticipation of a law that hasn’t passed. Second, the organizations that handle breaches best are not the ones that optimize for the minimum legal requirement — they are the ones that have built a response infrastructure capable of moving fast regardless of what the deadline technically is.

Build your incident response plan around the stricter standard. Design your internal escalation paths so that the right people are notified within hours, not days. Prepare notification templates in advance so that the 72-hour window is spent on investigation and decision-making, not drafting from scratch. Establish a clear internal definition of “awareness” so that your team knows exactly when the clock starts — and doesn’t spend critical hours debating it.

If the window extends to 96 hours, you lose nothing by being prepared to move in 72. If it stays at 72 and you’ve been operating on a 96-hour assumption, the cost of that miscalculation lands directly on your regulatory record.

The Real Causes of Breaches

The cybersecurity industry has a storytelling problem. Breach coverage tends to gravitate toward the dramatic — nation-state actors, zero-day exploits, sophisticated intrusion campaigns. It makes for compelling reading. It also badly misrepresents where most breaches actually come from, which means organizations build response plans for the threat they’ve heard about rather than the one most likely to hit them. With that said, here are the most common causes of GDPR data breaches:

a) Human error

According to IBM’s Cost of a Data Breach Report 2025, human error caused 26% of breaches, with IT failures accounting for a further 23%. Put those two together, and you’re looking at nearly half of all breaches originating from mistakes made inside the organization.

Zoom out further, and the picture gets starker. Mimecast’s State of Human Risk Report found that human error contributed to 95% of data breaches in 2025, driven by insider threats, credential misuse, and user-driven errors. The methodologies differ — IBM isolates human error as a primary cause, while Mimecast counts any breach where human behavior was a contributing factor — but the direction of travel is the same regardless of which lens you use. A small fraction of employees contributed disproportionately to these incidents, with just 8% of staff accounting for 80% of security events.

What does human error look like in practice? It is an employee forwarding a spreadsheet containing customer data to their personal email to finish work over the weekend. It is a developer pushing code to a public repository with credentials embedded in it. It is a finance team member wiring funds after receiving a convincing email impersonating the CFO. None of these requires an attacker with sophisticated tools. They require only ordinary human behavior under ordinary working conditions — distraction, pressure, convenience, and the reasonable assumption that someone else has already considered the security implications.

This is crucial for breach response planning because an incident response plan built around “detect and repel the external attacker” does not help the controller when the breach originates with their own staff. The detection logic is different, the containment steps are different, and the regulatory conversation with the supervisory authority looks very different when the threat actor turns out to be on their payroll.

b) Compromised credentials

Of all the breach vectors, stolen or compromised credentials deserve particular attention — not because they are the most dramatic, but because they are the most patient. Verizon’s 2025 Data Breach Investigations Report found that 22% of breaches began with stolen credentials, the highest of any single attack vector. Phishing, also one of the most common, accounted for 16%.

The reason credentials are so dangerous is what happens after the attacker has them. They don’t announce themselves. They log in. The traffic looks normal. The access patterns, at least initially, resemble legitimate user behavior. Your monitoring tools, which are largely built to detect anomalies, have little to flag. IBM’s data shows that breaches initiated with stolen credentials have a mean time to identify and contain of around 246 days — nearly eight months of undetected, invisible access for the attacker. Other IBM reporting has placed this figure as high as 292 days, depending on methodology and breach type.

Eight months. During that window, an attacker with valid credentials can move laterally through the controller’s systems, escalate privileges, identify where the most sensitive personal data lives, and exfiltrate it in quantities and at a pace that looks nothing like an obvious intrusion. By the time detection happens — often because of an unrelated alert, a tip-off from a third party, or the attacker’s own mistake — the damage is already extensive, and the 72-hour GDPR clock starts running against an organization that has no clear picture of what was accessed or when.

Credential-based attacks are rising, driven by poor password hygiene and credential reuse across platforms. One set of stolen credentials from a low-stakes breach at one service becomes the key to a high-value system at an entirely different organization, because people reuse passwords and attackers know it.

c) Cloud misconfigurations and SaaS sprawl

The migration to cloud infrastructure has created an entirely new category of breach risk that sits awkwardly between technical failure and human error. According to Exabeam, some 82% of data breaches now involve cloud-stored data, and 23% of cloud security incidents stem directly from misconfigurations. But the more telling statistic is this: 82% of those misconfigurations are caused by human error, not software flaws. The cloud provider’s infrastructure is not failing. The settings controlling who can access what are simply wrong — and often have been wrong since the environment was first set up.

The problem compounds significantly with SaaS sprawl, according to the latest industry data from Zylo’s 2025 and 2026 SaaS Management Index reports. Large enterprises now average 275 SaaS applications, with only around 26% of SaaS spending centrally managed by IT — the rest emerges from departmental or individual purchasing decisions. Each of those applications carries its own access permissions, its own integration touchpoints with other systems, and its own default settings — which are almost universally optimized for ease of use rather than security.

According to the AppOmni State of SaaS Security 2025 report, three-quarters of organizations experienced a SaaS-related security incident in 2025, despite 86% of those same organizations saying SaaS security was a top priority. That gap between stated priority and actual outcome is precisely where breaches live.

When attackers land in environments with shadow infrastructure or unmanaged SaaS connections, containment becomes a time problem — and time is what drives cost. The breach that starts in a forgotten integration between a marketing tool and a CRM, where permissions were never reviewed after an employee left, is indistinguishable from a sophisticated attack until you start pulling the thread.

For GDPR purposes, the source of the misconfiguration is irrelevant. Whether a cloud storage bucket was left publicly accessible because of a rushed migration, an untrained developer, or a vendor’s default settings, the controller is responsible for what was exposed and for notifying the appropriate authority within the required window.

d) The insider threat: negligence versus malice

“Insider threat” tends to conjure images of a disgruntled employee deliberately exfiltrating data on their way out the door. That scenario exists, but it accounts for a minority of insider incidents. The larger and more pervasive problem is the negligent insider — the employee who is not trying to cause harm and has no idea they already have.

According to Ponemon research, 55% of insider threat incidents are caused by careless or negligent employees, not malicious actors. The negligent insider clicks on a phishing link. Shares a document containing personal data via an unsecured channel because it was faster. Leaves a laptop unlocked in a public space. Responds to a request that appeared to come from a senior colleague without verifying it. Malicious insider threats, by contrast, took the second longest of any attack vector to resolve — an average of 260 days — and carried an average annual cost of $17.4 million across organizations.

Both types present distinct challenges for breach response. The negligent insider is often genuinely unaware that a breach has occurred, which delays detection and internal reporting. The malicious insider, by definition, is actively concealing their activity, which is why detection timelines stretch so long. In either case, the GDPR obligation is the same: once your organization becomes aware that personal data has been compromised through an internal actor, the 72-hour clock applies exactly as it would for an external attack.

Between 2023 and 2024, insider-driven data exposure events increased by 28%, and 76% of organizations reported detecting increased insider threat activity over a five-year period — yet fewer than 30% believed they had the right tools to handle it. This is according to the 2024 Data Exposure Report by Code42 (now a Mimecast company) and is supported by broader industry research from the Ponemon Institute

e) AI as an attack vector

This is no longer a future risk to monitor. According to IBM’s Cost of a Data Breach Report 2025, 16% of breaches involved attackers using AI, with AI-generated phishing accounting for 37% of those incidents and deepfake-based attacks for 35%.

What AI changes about the threat landscape is speed and scale. A human-crafted phishing email takes an average of 16 hours to create. AI can generate a deceptive, personalized phishing message in five minutes. At that speed, the volume of targeted, convincing attacks that can be launched against an organization’s employees is no longer limited by attacker capacity. Every employee becomes a viable individual target rather than a mass-campaign recipient, and the markers that trained users look for — awkward phrasing, generic salutations, implausible context — are disappearing.

The governance gap is severe. IBM’s 2025 report found that 97% of organizations that experienced an AI-related security incident lacked proper AI access controls. A further 63% of breached organizations had no AI governance policy or were still in the process of developing one. Organizations are deploying AI tools internally, their employees are using AI platforms on corporate devices, and the data flowing through those systems frequently includes personal data that falls squarely within GDPR’s scope — yet the controls that would apply to any other data processing activity are simply absent.

Your Vendor Got Breached — Are You on the Hook?

Short answer: probably yes. Longer answer: It depends on what your contracts say, what due diligence you conducted before signing them, and whether you can demonstrate to a regulator that you took the question seriously before the incident happened rather than after. Most organizations cannot. That gap is one of the fastest-growing sources of GDPR non-compliance, and regulators are increasingly making it the centerpiece of enforcement decisions.

The controller vs. processor distinction under GDPR

GDPR draws a clear line between two categories of organization. A data controller is the entity that determines the purpose and means of processing personal data. A data processor is any third party that handles personal data on the controller’s behalf and under their instructions.

Under early data protection laws, only data controllers were held accountable for data breaches. Since 2018, however, data processors have faced direct regulatory obligations under GDPR and can be fined or required to pay compensation for data breaches either in their own right or concurrently with data controllers. That direct liability for processors was a significant shift — but it has not reduced the controller’s exposure in the way many organizations assumed it would.

The controller is primarily responsible for its own compliance and ensuring the compliance of its processors. This means that regardless of the terms of the contract with a processor, the controller may be subject to corrective measures and sanctions — including orders to bring processing into compliance, compensation claims from data subjects, and administrative fines.

The existence of a data processing agreement does not insulate the controller from liability if the processor suffers a breach. It may affect how liability is apportioned between them, but it does not transfer the regulatory risk away from the controller entirely.

Who reports the breach?

When a processor is breached, the notification obligation to the supervisory authority within 72 hours, and to affected individuals if high risk is present, belongs to the controller – not the vendor. The processor’s obligation under Article 33(2) is to notify the controller without undue delay, so that they can meet the notification deadline. Many vendor contracts currently specify 72 hours for processor-to-controller notification, which leaves no margin for error by the time the alert reaches the controller.

If a partner, vendor, or cloud provider causes a breach, the primary data controller still holds liability unless explicit technical safeguards and processor agreements are in place. And even where agreements are in place, a controller can still be held liable for its processor’s wrongdoing — unless the processor acted entirely outside of the controller’s instructions. The practical implication is that your exposure does not neatly disappear the moment your vendor acknowledges fault. You remain the entity that must notify the authority, manage the investigation, communicate with affected individuals, and demonstrate that your vendor selection and oversight processes were adequate.

Real-world enforcement cases

The clearest signal of where regulatory attention is heading on third-party risk came from the ICO’s action against Advanced Computer Software Group, a major IT and software provider to NHS and social care organizations in the UK. In 2025, the ICO announced its decision to impose a £3.07 million fine on Advanced following a 2022 ransomware attack that severely disrupted NHS and social care services. The ransomware incident exploited a customer account that lacked multi-factor authentication, resulting in the exfiltration of personal data for 79,404 individuals. The ICO concluded that Advanced had failed to adequately secure its healthcare systems.

What made this case significant was not the fine itself — it was the precedent. Advanced was fined as a processor, not a controller. Despite the surge in supply chain cyber attacks in recent years — affecting CTS, MOVEit, SolarWinds, and others — there had been little clarity on the ICO’s approach to the data processor’s role in these incidents. The Advanced decision changed that. Regulators are now demonstrably willing to pursue processors directly, which changes the risk landscape for vendors — but it does not reduce controller liability.

Germany’s federal commissioner for data protection fined Vodafone GmbH €15 million in 2025 specifically because the firm had failed to properly oversee contracts drawn up by third-party agencies. Not because Vodafone itself caused the underlying violation — but because it could not demonstrate adequate oversight of its vendors. That is exactly the kind of case that should concentrate minds at the procurement and legal level. The fine followed the oversight failure, not just the breach.

The MOVEit supply chain attack, which exposed the data of tens of millions of individuals across hundreds of organizations globally, illustrated the scale at which third-party processor failures cascade. Cross-border breaches of that type now face multi-jurisdictional enforcement, requiring simultaneous compliance with GDPR and other frameworks. Organizations that were users of MOVEit’s file transfer platform faced notification obligations even where they had no direct involvement in the vulnerability, because the personal data processed through that platform was theirs to protect.

What vendor contracts need to actually say

A data processing agreement that satisfies GDPR’s minimum requirements under Article 28 is a legal prerequisite for any arrangement where a third party processes personal data on the controller’s behalf. But what regulators are increasingly scrutinizing is not simply whether a DPA exists, but whether its terms are operationally meaningful.

At a minimum, a contract with a data processor should address:

Breach notification timelines. Article 33(2) requires processors to notify controllers “without undue delay.” This means the contract should specify a maximum notification window — many controllers now require 24 to 48 hours, not the 72-hour regulatory deadline, precisely to preserve their own notification window. If the vendor’s contract says “without undue delay” with no defined timeframe, that is a gap. Push for a specific number.

Scope of processing. The contract must document exactly what data is being processed, for what purpose, and under what instructions. If the vendor processes data beyond what is documented, they may have become a controller in their own right — carrying different liability implications.

Sub-processor obligations. Most vendors use sub-processors to deliver their services. The processor should notify the controller before appointing or changing sub-processors, and the contract should give the controller the right to object. Failure to address this creates a chain of processing activity that you are ultimately responsible for but have no visibility into.

Audit rights. The processor should make available all information necessary to demonstrate compliance and allow audits by the controller or an authorized third party. A vendor that resists meaningful audit rights is signalling that they do not expect scrutiny — which is precisely when scrutiny is most warranted.

Indemnification. If a serious breach is ultimately the processor’s fault, the controller should ensure the contract features an indemnity from the supplier for any data protection breaches which lead to regulatory fines, compensation claims, and other losses. Liability caps should anticipate the controller potentially absorbing the entire fine imposed by the regulator, so the cap should be suitably high, not just a low multiple of contract value, which is what suppliers typically offer by default.

Appropriate diligence before onboarding a processor

The ICO’s guidance on this is explicit: the controller is responsible for assessing that its processor is competent to process personal data in line with GDPR’s requirements, taking into account the nature of the processing and the risks to the data subjects. In addition, Article 28(1) requires a controller to use only a processor that can provide “sufficient guarantees” — in terms of expert knowledge, resources, and reliability — to implement appropriate technical and organizational measures.

In practice, demonstrating that assessment means more than requesting a vendor’s security questionnaire and filing it. It means:

Pre-contract security assessment. Review the vendor’s ISO 27001 certification or SOC 2 report if available — and read it, rather than simply confirming its existence. Understand what it covers and what it does not. Certifications scope to specific systems; they do not cover the vendor’s entire infrastructure by default.

Data mapping. Before onboarding, understand exactly which personal data will flow to the vendor, where it will be stored, who within the vendor’s organization will have access, and whether any of it will be transferred outside the EEA. Each of these questions has direct GDPR implications.

Ongoing monitoring. Due diligence is not a one-time event. According to a 2025 Verizon Data Breach Investigations Report, third-party involvement in breaches doubled year-over-year in 2025, now accounting for 30% of all incidents. Many of those incidents involved integrations, permissions, and access configurations that were never reviewed after initial setup. Vendor relationships change — staff change, systems change, sub-processors change — and your oversight needs to keep pace.

Incident response testing. Ask your critical vendors whether they have a documented incident response plan and whether they test it. If a vendor cannot tell you how they would detect a breach within their systems, how they would contain it, and how they would notify you, that is a red flag that warrants either remediation or a different vendor.

The organizations that will be in the most defensible position when a vendor breach occurs are not necessarily those with the most sophisticated vendors — they are those with documented evidence that they asked the right questions, required meaningful contractual protections, and maintained active oversight throughout the relationship. Regulators are not asking whether a vendor had a breach. They are asking whether you, the controller, created the conditions for it to be handled well.

The Full Cost of a Breach — Beyond the Fine

When executives think about the cost of a data breach, they think about the fine. That is understandable — GDPR fines make headlines, and the numbers are large enough to focus attention. But the fine, in many breach scenarios, is not the most expensive part. It is not even close. Organizations that build their risk calculus around avoiding a regulatory penalty while underestimating the full exposure are routinely blindsided by what comes after.

The regulatory fine structure

GDPR’s fine framework operates on a two-tier structure. The lower tier — up to €10 million or 2% of global annual turnover, whichever is higher — applies to procedural and organizational failures: not having adequate data processing agreements in place, failing to appoint a Data Protection Officer when required, and not conducting a Data Protection Impact Assessment for high-risk processing. The upper tier — up to €20 million or 4% of global annual turnover, whichever is higher — applies to substantive violations: unlawful processing, breaches of the core data protection principles, failures of security that result in unauthorized access to personal data.

The “whichever is higher” construction is what makes these figures genuinely consequential. For a mid-sized technology company with €500 million in global revenue, 4% is €20 million — and that cap is per violation, not per investigation. For a large multinational, the exposure scales accordingly.

The enforcement record makes clear that these are not theoretical maximums. In 2025, Ireland’s Data Protection Commission fined TikTok €530 million for transferring the personal data of European users to servers in China, after TikTok’s own assessment of Chinese law revealed it didn’t provide equivalent protection to GDPR — a fact the regulator said TikTok had failed to properly assess before deploying safeguards. That single fine represents one of the three largest in GDPR history. By January 2025, the cumulative total of GDPR fines since 2018 had reached approximately €5.88 billion.

Smaller organizations are not exempt from this trajectory. Estonia’s Data Protection Inspectorate fined Allium UPI OÜ €3 million after a breach compromised the personal data of 750,000 individuals — including sensitive health-related purchase histories — finding that the firm had failed to implement even basic cybersecurity measures such as MFA, continuous monitoring, and properly secured database backups. The lesson there was not about scale. It was about basics, and the regulator’s willingness to pursue them rigorously regardless of organization size.

The civil litigation wave

Regulatory fines are one thing. Civil compensation claims are another, and they represent a dimension of breach liability that most organizations still dramatically underestimate. Under Article 82 of the GDPR, any individual who suffers material or non-material damage as a result of a GDPR infringement has the right to claim compensation directly from the controller or processor. The right is not new. What is new is the jurisprudence that is now shaping how broadly it can be used — and it has been moving consistently in claimants’ favor.

The most significant development in recent years concerns what kinds of harm qualify for compensation. In May 2023, the Court of Justice of the European Union (CJEU) ruled that the mere infringement of the GDPR is not sufficient to confer a right to compensation, but that EU member states are precluded from imposing rules that require claims for compensation based on non-material damage to reach a certain degree of seriousness. In practical terms, you cannot bat away compensation claims on the grounds that the harm was minor or trivial. If there is real damage, a causal link, and a GDPR infringement, the claim is viable.

Then, in a judgment dated 20 June 2024, the CJEU went further. The Court ruled that it is sufficient for a claim under Article 82 if a data subject can demonstrate that they genuinely fear their personal data has been disclosed to third parties as a result of a GDPR infringement, along with the negative consequences of that fear. It is not necessary to prove that the feared disclosure actually took place. Yes, fear of a breach — not a confirmed breach — can ground a compensation claim, provided that fear is objectively well-founded based on the circumstances.

The same judgment also addressed the severity question directly. The CJEU stated that damage caused by a breach of personal data protection is, by its nature, no less serious than bodily injury, and that Article 82 GDPR contains no threshold of seriousness or minimum threshold that damage must exceed before it qualifies for compensation.

The UK courts have moved in the same direction. The Court of Appeal ruled in 2024 that distress is an umbrella term encompassing various forms of emotional harm, including stress and anxiety, and that such harm is recoverable in principle. It also held that compensation could be recovered for fear of the consequences of a data protection infringement, provided that the fear is objectively well-founded, and rejected the imposition of a threshold of seriousness for data protection claims entirely.

Companies should therefore revisit their data breach response plans to ensure that the risks of triggering private claims are considered before issuing data breach notifications to individuals — and to ensure that their responses to data breaches will support the company’s defense in any eventual litigation. That last point is subtle but important. The act of notifying affected individuals — which GDPR requires when high risk is present — can, as the Sussex Police pension case demonstrated, directly trigger class action claims. Organizations issuing notifications “out of an abundance of caution” in borderline cases need to weigh that risk explicitly.

What does this mean in aggregate terms? Germany’s Federal Court of Justice ruled in November 2024 that the mere loss of control over personal data could constitute non-material damage — without the need to prove additional noticeable negative consequences — effectively opening the door to standardized mass actions. While individual awards are modest — the EU General Court awarded €400 in one case, Irish courts have suggested figures below €500 for distress-only claims — the math becomes significant only when multiplied across the thousands or millions of individuals a single breach may affect. A breach affecting 500,000 individuals, with even a fraction pursuing low-value compensation claims, produces a cumulative civil liability figure that dwarfs many regulatory fines.

Operational and reputational costs

The fine and the litigation are the visible costs. What organizations consistently underestimate — often because these costs don’t appear on a single invoice — are the operational costs that accumulate from the moment a breach is discovered until the organization has fully recovered. Which, for most, takes far longer than anyone anticipated.

According to the IBM Cost of a Data Breach Report 2025, the global average cost of a data breach dropped to $4.44 million in 2025 — a 9% decrease from the all-time high in 2024 — but that figure masks significant variation. The mean time organizations took to identify and contain a breach fell to 241 days in 2025, and more than half of all breaches involve customer personal identifiable information.

Also, the costliest initial attack vectors in 2025 were malicious insider attacks at $4.92 million per breach, supply chain compromises at $4.73 million, and stolen or compromised credentials at $4.50 million. These are average total costs — encompassing detection and escalation, notification, post-breach response, and lost business — not just the regulatory penalty.

The U.S. vs EU legal landscape

The United States does not operate under GDPR, but it offers the clearest available benchmark for what breach costs look like in a high-enforcement, high-litigation environment — which is increasingly what Europe is becoming.

The average cost of a data breach in the United States was $10.22 million in 2025, an all-time high for any region. The gap between the $4.44 million global average and the $10.22 million U.S. figure is not primarily explained by differences in fine levels. It is explained by the cost of civil litigation, class action settlements, regulatory penalties across multiple jurisdictions simultaneously, reputational damage driving customer attrition, and the operational cost of running an investigation and response under sustained legal scrutiny.

In 2024 alone, over 1,488 data breach class actions were filed in the U.S., nearly tripling since 2022, with settlements exceeding $593 million that year alone. Europe’s litigation infrastructure for mass claims is less developed than the U.S. system, but the CJEU’s jurisprudential direction, Germany’s Federal Court of Justice decisions on loss of control, and the UK Court of Appeal’s lowered threshold for distress claims are all pointing toward a future where EU breach litigation looks considerably more like the U.S. model than it does today.

Organizations operating in Europe that assume the regulatory fine is their ceiling are modelling a risk environment that no longer exists.

Recovering from a data breach

According to an IBM report, recovery from a breach took more than 100 days for most of the small number — 12% — of breached organizations that were able to fully recover at all in the short term. The other 88% carry the consequences into subsequent years: ongoing legal proceedings, regulatory monitoring orders requiring demonstrable remediation, reputational damage affecting customer acquisition and retention, elevated cyber insurance premiums, and the internal cost of rebuilding systems and trust.

The reason recovery is so protracted is that a significant breach triggers simultaneous, compounding pressures. The investigation is running. The regulatory authority is corresponding. The lawyers are managing civil claims or class actions. The press is covering it. The customer service team is fielding complaints. The board is demanding answers. The IT team is rebuilding affected systems. None of these processes concludes at the same time, and none of them can be fully delegated. Each one demands leadership attention, legal resources, and a budget that wasn’t allocated because nobody budgeted for a breach.

The average annual cost of insider-led cyber incidents has steadily increased over the past four years, reaching $17.4 million in 2025. For organizations that experience a breach originating internally — whether through negligence or malice — the recovery is typically longer and more complex, because the investigation involves your own people and your own systems in ways that external breach investigations do not.

The honest takeaway is this: a breach is not an event. It is a condition that an organization enters and must work its way out of over months or years. The fine, if it comes, may be the most legible single number — but it is rarely the largest, and almost never the last.

GDPR Data Breach: The Violations Organizations Don’t See Coming

The obvious breach violations — missing the 72-hour deadline, failing to notify individuals — get covered in every article. Organizations that commit them generally know they have, even if they made a judgment call they’re now defending. What is far more interesting, and far more dangerous, are the violations that organizations walk into without realizing they’ve created a problem. These are the ones that show up in investigations as secondary findings, that convert a manageable incident into a compounded enforcement outcome, and that regulators are increasingly treating as evidence of systemic failure rather than isolated error.

a) Notifying a low-risk breach can itself trigger a lawsuit

This is perhaps the most counterintuitive dynamic in GDPR’s breach framework, and it is one that has caught controllers completely off guard. The instinct when a breach occurs — particularly for organizations that take compliance seriously — is to notify broadly and err on the side of transparency. Notify the authority. Notify the individuals. Document everything. What many organizations do not anticipate is that the act of notifying individuals, even in a low-risk scenario, can become the direct trigger for civil litigation.

Companies should revisit their data breach response plans to ensure that the risks of triggering private claims are considered before issuing breach notifications to individuals. As the Sussex Police pension case showed, the force notified pension scheme members despite determining there was a low risk of harm — and that notification directly triggered a class action claim from hundreds of affected individuals.

The mechanics here are worth understanding. The UK Court of Appeal has ruled that distress is an umbrella term encompassing various forms of emotional harm, and that compensation could be recovered for the mere fear of consequences following a data protection infringement — provided that fear is objectively well-founded. No minimum threshold of seriousness applies. So an organization that notifies individuals of a low-risk breach — in good faith, out of caution — hands those individuals exactly the evidence they need to establish that a breach occurred and that their data was involved. The notification letter becomes the foundation of the claim.

This does not mean controllers should suppress notifications to avoid litigation. It means that the risk of civil claims must be explicitly weighed when assessing whether individual notification is actually required, and that communications to affected individuals need to be drafted with litigation risk in mind, not just regulatory compliance. The two considerations are not always aligned.

b) A breach investigation exposes the processing that preceded it

When a regulator investigates a breach, they do not look only at the incident. They look at what the organization was doing with personal data before the incident occurred. If that processing was unlawful — wrong legal basis, excessive data collection, missing documentation — the breach notification has just delivered the regulator a detailed map of where to look.

When the Irish DPC investigated Meta’s 2018 breach affecting 29 million Facebook users, it found violations that went well beyond the security failure itself. The DPC identified inadequate breach notification, failure to document the breach, and lapses in data protection by design and by default. Meta was fined separately for each: €8 million for improper notification, €3 million for inadequate documentation, €130 million for poor system design, and €110 million for not processing only necessary data by default. The breach opened the door. What was found inside it produced four separate fine categories.

This is the pattern that most controllers are not prepared for. They treat the breach as the problem to be managed, without considering that the breach investigation is also an audit of everything around it. An organization that was retaining data longer than necessary, processing more categories of data than its privacy notice described, or operating on a questionable legal basis is not just facing a breach fine — it is facing regulatory scrutiny of its entire data processing architecture at precisely the moment when it has the least capacity to respond.

c) Backup systems and legacy environments are in scope

One of the most consistently underestimated breach exposures involves data that organizations have technically “forgotten” — old backups, archived systems, legacy databases from acquisitions or migrations that were never decommissioned. When a breach occurs, the scope assessment covers all personal data that was accessible during the incident, not just the data the organization was actively using.

In the Apotheka pharmacy loyalty program breach, investigators found that attackers had accessed a backup database covering data from 2014 to 2020. The compromised system lacked appropriate security measures, and repeated unauthorized access had occurred before detection. The Estonian regulator found the vulnerable system architecture violated the principle of security-by-design under Article 25. The organization had data it had collected years earlier sitting in a backup system it had not secured to any meaningful standard, and when that system was breached, every record in it became part of the notification scope.

Controllers routinely discover during a breach response that their actual data footprint is substantially larger than their active processing records suggested. The personal data that was supposed to have been deleted under retention policies is still there. The test environment that was spun up two years ago still contains real customer data. The acquisition target’s legacy CRM was migrated but never cleaned. Each of these expands the breach scope, expands the number of individuals requiring notification assessment, and creates additional regulatory exposure for failing to apply data minimization and retention principles in practice.

d) The breach your staff witnessed but never reported internally

GDPR’s breach notification obligation runs from the moment the organization becomes aware of a breach — but “the organization” in regulatory terms is not just the DPO or the security team. It includes any member of staff acting within the scope of their employment. If a customer service representative noticed a misconfiguration that exposed customer records and mentioned it to their manager, who noted it and moved on, the organization may already be treated as having been aware of the breach from that moment — even if the information never reached the privacy function for weeks.

In the S-Pankki case in Finland, which resulted in a €1.8 million fine, the breach was linked not only to inadequate security but specifically to delayed responses to customer complaints. Customers had already flagged the issue before the organization’s internal response reflected appropriate urgency. The regulatory finding was that the signals were there — they simply were not treated as signals. Customer complaints about unauthorized access to their accounts constitute organizational awareness. An employee flagging an unusual system behaviour in a helpdesk ticket constitutes organizational awareness. These are breach indicators, and if they are not routed to the people with authority and obligation to act on them, the clock has been running while the organization was unaware it had started.

Most organizations have no systematic mechanism for escalating potential breach indicators from frontline staff — support tickets, sales calls, customer complaints — to the privacy or legal function. That gap is invisible until a regulator asks when the organization first had reason to believe something had gone wrong.

e) Thinking “nothing was stolen” closes the investigation

Organizations that experience a security incident — particularly a ransomware attack — frequently conduct an investigation, conclude that no data was exfiltrated, and treat the matter as resolved without a notification obligation. This reasoning is increasingly rejected by regulators, and the organizations applying it are often creating a violation they did not know they had.

As previously mentioned, availability breaches — where personal data is rendered inaccessible — are fully reportable under GDPR regardless of whether any data was taken. A ransomware attack that encrypts systems and locks users out of personal data for any meaningful period is a breach. The question of whether data was exfiltrated affects the risk assessment, not the notification threshold. And on the exfiltration question itself, regulators increasingly treat exfiltration as presumed in ransomware incidents unless the organization can demonstrate otherwise — a burden of proof that most incident investigations cannot actually meet to the standard required.

The dangerous assumption here is that “nothing was stolen” is a factual conclusion an organization can confidently reach within 72 hours of a ransomware attack. In most cases, it is not. What organizations typically have is an absence of confirmed exfiltration evidence, which is not the same thing, and regulators understand the difference.

f) The breach was real, but the wrong supervisory authority was notified

For organizations operating across multiple EU member states, determining which supervisory authority to notify is a substantive legal question — and getting it wrong is a breach violation in itself. The one-stop-shop mechanism means that cross-border processing should be reported to the lead supervisory authority in the member state of the organization’s main establishment. But “main establishment” is not always obvious, particularly for organizations whose operational center and registered headquarters are in different countries, or whose data processing activities are distributed across multiple EU locations.

The GDPR Enforcement Rules Regulation, published in December 2025, was introduced specifically to address the procedural inconsistencies in how supervisory authorities handle cross-border cases — a signal that the existing framework has produced enough divergence and confusion to require legislative correction. Organizations that notified a national authority in good faith, based on a reasonable interpretation of their main establishment, may subsequently find that a different authority asserts jurisdiction and that the notification timeline runs from a different starting point than the one they used.

This is a violation that requires no bad faith whatsoever to commit. It requires only a cross-border organizational structure and an ambiguous main establishment — both of which describe the majority of mid-sized to large European organizations.

What Good Breach Preparedness Looks Like in 2026

The honest truth is that breach preparedness is not primarily a technology problem. The organizations that manage incidents most effectively going forward are not necessarily those with the most sophisticated detection tools. They are the ones that made a series of deliberate, documented choices before any incident occurred — and also treated those choices as infrastructure rather than paperwork.

a) Write the plan before you need it — and make sure it actually works

Regulators do not expect a breach response plan to prevent all incidents. They view it as evidence that the organization can translate legal obligations into a coordinated, timely, and defensible response when a real incident occurs. In enforcement actions, the absence of a plan — or the presence of one that was clearly unusable in practice — is often treated as a sign of poor organizational measures under Articles 24 and 32, even where the breach itself was not intentional.

That distinction — “unusable in practice” — is the critical one. Most organizations that have experienced a significant breach had some form of incident response documentation. What they did not have was a plan that had been tested under conditions resembling reality. A document that specifies the DPO should be notified within two hours means nothing if there is no defined escalation path from the person who discovers the incident to the DPO, no after-hours contact details, and no agreed definition of what kind of event triggers the escalation in the first place.

A functional plan needs to have:

• Specific, named owners for each role — not job titles, but individuals with deputies identified for when the primary contact is unavailable.
• A clear internal definition of “awareness”, so the 72-hour clock can be started without a committee meeting.
• Pre-drafted notification templates, built to meet Article 33(3)’s content requirements, with placeholders for incident-specific details rather than blank pages.
• And has been tested — not by reading it in a meeting, but by running a tabletop simulation that forces the team to work through real decisions in real time: who calls the authority, what information is included, what gets logged and when.

Simulation exercises should cover a range of scenarios, including phishing attacks, employee errors, and technical failures, ensuring the team is prepared for diverse threats, not just the breach type they consider most likely. The scenario organizations almost never simulate is the one they most need to: a breach discovered on a Friday evening by a junior member of staff who cannot reach their manager, where the 72-hour window begins ticking before anyone in a decision-making role is aware.

b) Set breach detection SLAs with every vendor that touches personal data

The previous section on vendor liability established why your processor’s breach is your notification obligation. The practical implication that follows is that your 72-hour window begins not when your vendor notifies you, but potentially when the breach actually occurred — if awareness can be attributed to your organization through any channel. A vendor who takes 48 hours to notify you leaves you with 24 hours to assess, document, and notify the supervisory authority. A vendor whose contract says “without undue delay” with no defined timeframe leaves you with whatever time remains after they decide they’ve investigated sufficiently.

Every data processing agreement with a vendor handling personal data should specify a maximum processor-to-controller notification window — and it should be shorter than 72 hours. Many organizations now set this at 24 hours as a contractual requirement, specifically to preserve operational time within their own window. Beyond the timeline, the agreement should specify what the initial notification must contain: the nature of the incident, the systems and data categories affected, and the vendor’s point of contact for ongoing updates. A notification that arrives in 24 hours saying “we may have experienced an incident” is not operationally useful. A notification that arrives in 36 hours with scope, affected data categories, and initial containment steps is.

Organizations should verify that third-party vendors handling personal data have robust breach response plans and regularly assess their compliance with privacy standards. This means actually reviewing those plans — not accepting a vendor’s assertion that they exist. Ask to see the plan. Ask when it was last tested. Ask who the 24/7 contact is for incident notification. A vendor that cannot answer these questions fluently is a vendor whose breach will land in your notification without warning.

c) 24/7 coverage is not optional — the 72-hour clock doesn’t observe weekends

In 2025 alone, European data protection authorities received an average of 443 GDPR breach notifications every single day. Breaches do not disproportionately occur during business hours. Ransomware attacks are frequently timed for weekends and public holidays precisely because response capacity is reduced. A breach discovered at 6 pm on a Friday gives an organization until 6 pm on Monday to notify — a window that spans the entirety of a weekend during which key personnel may be unreachable, and systems for accessing regulatory notification portals may require VPN access that nobody has documented how to set up at home.

Good breach preparedness means the response capability is genuinely available around the clock in practice. This requires: an on-call rota that includes not just technical staff but someone with the legal authority and regulatory knowledge to make the notification decision; defined after-hours contact details for the supervisory authority’s notification portal and emergency lines; and a communication cascade that doesn’t depend on a single person being reachable. The data breach response team should be capable of responding to suspected or actual data breaches 24/7. In smaller organizations where a dedicated team is not feasible, this means explicitly contracting for out-of-hours breach response support with a specialist provider — the cost of which is a fraction of the fine exposure created by a breach discovered at 11 pm on a Saturday that doesn’t reach anyone who can act until Monday morning.

d) Data minimization is your most underused breach prevention strategy

Every piece of personal data your organization holds is personal data that can be breached. The corollary is equally true: data you never collected, data you deleted at the end of its retention period, and data you anonymized rather than stored in identifiable form cannot be included in a breach notification, cannot be the basis for individual notification obligations, and cannot form the foundation of civil compensation claims.

Data minimization — collecting only what is necessary for a specified purpose, retaining it only as long as necessary, and disposing of it securely at the end of that period — is framed in GDPR as a data protection principle. Its practical effect in a breach scenario is to limit scope. An organization that operates disciplined data minimization discovers, when a breach occurs, that the affected data set is smaller than it might otherwise have been, that fewer individuals require notification assessment, and that the high-risk threshold for individual notification is less likely to be crossed. The principle of data minimization means that a data controller is required to limit the collection of personal information to what is directly relevant and necessary to accomplish a specified purpose, retaining the data only for as long as is necessary to fulfil that purpose.

Operationally, this means conducting regular data audits and actually deleting what retention schedules say should be deleted, not simply noting that the retention period has passed. It means questioning whether a new system or process genuinely requires the personal data categories it has been designed to collect, before deployment, rather than after. It means treating legacy data — old backups, historical databases, archived CRM exports — as active risk rather than inactive storage. The Apotheka case, in which attackers accessed a backup database covering data from 2014 to 2020, is a precise illustration of what happens when retention discipline breaks down: the breach scope stretches back a decade, and the organization must account for every individual in that archive.

e) Privacy maturity is now a commercial differentiator, not just a compliance cost

The final argument for investment in breach preparedness is not regulatory. It is commercial, and the data behind it has become difficult to ignore.

A Deloitte’s 2025 Connected Consumer Survey found that only 14% of consumers feel confident that their data is being handled responsibly by the companies they share it with. Nearly 7 in 10 customers have abandoned a transaction due to distrust — walking away from a purchase or sign-up because a site or service did not feel safe. Additionally, in the 2025 IBM Cost of a Data Breach Report, 63% of consumers said they would stop doing business with a company that experienced a data breach. And 88% of consumers are more likely to engage with businesses that are transparent about their data usage policies, according to PwC’s 2025 Trust in Business Survey.

These numbers describe a customer base that is making active decisions based on perceived privacy practice — not just in regulated sectors like healthcare and finance, but across retail, technology, professional services, and beyond. The Cisco 2024 Consumer Privacy Survey found that 76% of consumers say they would not buy from an organization they didn’t trust with their data. Trust, once lost through a badly handled breach, is extraordinarily difficult to rebuild. Also, research from Thales and PwC in 2025 found that 59% of consumers stated that a single data breach would negatively impact their likelihood of purchasing from a company — and that figure describes people who heard about a breach, not people who experienced one directly.

The competitive case is this: the organizations that invest in genuine breach preparedness — in tested incident response plans, in disciplined data minimization, in vendor oversight that actually works, in 24/7 response capability — are building an infrastructure that simultaneously reduces their regulatory exposure, compresses their breach costs when incidents do occur, and makes them materially more trustworthy to customers who are actively evaluating that question before they spend money.

Compliance has historically been framed as a cost center. The data increasingly support framing it differently: as the operational foundation of a business that survives its inevitable breach better than its competitors, retains its customers’ trust through the process, and emerges on the other side with a regulatory record that demonstrates it took the obligations seriously. That is a business argument — and going forward, it is one that boards should be hearing.

Final thought

GDPR does not expect organizations to prevent every breach. It expects them to have taken the question seriously before one occurs – to have mapped their data, tested their response plan, governed their vendors, and built the organizational muscle to move decisively when something goes wrong. The organizations that face the worst regulatory outcomes are rarely those that were breached. They are those who were unprepared and for whom the breach simply made that visible.

If there is one action this article should prompt, it is this: pull out your breach response plan today and ask honestly whether it would work under pressure. Not whether it exists, but whether it would actually work. The Digital Omnibus is worth watching in the months ahead. But the organizations best positioned to adapt to whatever comes next are those that have already built the foundations. Start there.