Data Breach

What is a data breach?

A data breach is a security failure that leaves personal data seen by the wrong people, changed, lost or destroyed. The GDPR calls it a personal data breach. Article 4(12) defines it as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data".

Two points in that definition are easy to miss. It covers accidents as well as attacks, so personal data sent to the wrong customer by mistake counts. And it covers personal data only. A security incident that touches no personal data is not a personal data breach.

The EDPB's guidelines on breach notification (the EDPB is the board of EU privacy regulators) sort breaches into three types:

• Confidentiality: someone sees or gets personal data they should not, such as a leaked export or a file sent to the wrong person.
• Integrity: personal data is changed without permission.
• Availability: personal data is lost or cannot be reached, such as records deleted with no backup.

One incident can be more than one type, and ransomware shows how. If the data comes back from a backup, the loss of access was temporary, but the EDPB notes that an intrusion still happened. If the attacker accessed the data, it is also a confidentiality breach.

Who must tell whom under the GDPR

The controller (the company that decides why the data is used, usually you) carries the notice duties. The processor (a vendor that handles the data for you) must tell the controller.

• Vendor to you: under Article 33(2), a processor must notify the controller "without undue delay after becoming aware" of a breach. The GDPR sets no fixed number of hours for this step, and the EDPB says the vendor does not need to assess the risk before telling you.
• You to the regulator: under Article 33(1), the controller must notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to people. A late notice must give reasons for the delay.
• You to the people affected: under Article 34, when a breach is likely to result in a high risk to people, the controller must tell them without undue delay, in clear and plain language. This is not required if, for example, the data was encrypted so that it is unreadable to anyone not authorized to see it.
• Your own record: Article 33(5) requires the controller to document every breach, including the ones it did not have to report.

The 72 hours start when the controller is "aware". The EDPB reads that as having "a reasonable degree of certainty" that a security incident has compromised personal data. A short investigation is allowed first. When the breach happens at a vendor, the controller is in principle aware once the vendor tells it. Article 33(4) lets the details follow in phases.

A company outside the EU that is subject to the GDPR gets no single lead regulator just because it has an EU representative. The EDPB says such a breach must be notified to the authority of every EU country where affected people live. The UK GDPR has the same 72-hour rule for reports to the ICO.

A proposed change in the EU

In November 2025 the European Commission proposed the Digital Omnibus, a package of changes to EU digital laws. For breaches, it would require notice to the regulator only when a breach is likely to result in a high risk, and extend the deadline from 72 to 96 hours. The EDPB and the EDPS (the EU's own data protection supervisor) supported both changes in February 2026, and on 21 October 2026 the Council agreed its negotiating position, which keeps both. It is still only a proposal: as of October 2026 the European Parliament's file shows it awaiting a committee decision, so nothing has been adopted and the 72-hour rule applies.

In the US

The FTC's breach response guide notes that all states, the District of Columbia, Puerto Rico and the Virgin Islands have laws that require notice of security breaches involving personal information. See state data breach notification laws. Each sets its own definitions and deadlines.

New York's General Business Law 899-aa is one example. Its list of private information includes account numbers with the codes that open them, biometric data, and a username or email with its password. A business must notify affected New York residents within 30 days after the breach is discovered, unless law enforcement needs a delay. A business that holds data it does not own, such as a vendor storing your customers' records, must notify the owner immediately, and within 30 days following discovery.

What it looks like in a vendor's terms

The breach promise usually sits in the data processing agreement (DPA) or a security addendum. A typical clause reads:

Processor will notify Customer without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data. The notice will include the information reasonably available to Processor at that time. Notification is not an acknowledgment of fault. This section does not apply to unsuccessful attempts or activities that do not compromise the security of Customer Personal Data, such as pings, port scans or failed log-in attempts.

• "Without undue delay, and in any event within 72 hours": a fixed outer limit for the vendor. Under the EDPB's reading your own 72 hours usually start when the vendor tells you, but a slow vendor still delays everything you must do.
• "Information reasonably available ... at that time": the first notice may be thin. Look for a promise to send updates.
• "Not an acknowledgment of fault": the notice does not settle who pays. That is for the limitation of liability and indemnity clauses.
• "Unsuccessful attempts": blocked attacks are not reported. That is normal, but check that the carve-out is no wider than that.

Why it matters to you

When you are the controller, a breach at your vendor is your breach to manage. You decide whether to notify the regulator and the people affected, and you answer to your own customers. Your only source of facts may be the vendor's notice. A vendor can send notices for you if your contract authorizes it, but the EDPB says the legal duty stays with you.

Getting it wrong has a price. Under Article 83(4), a fine for failing to notify can reach 10 million euros or, for a company, 2% of worldwide annual turnover, whichever is higher. The EDPB adds that weak security can be fined as a separate infringement.

Your own promises depend on your vendors. If your DPA with your customers promises notice within a set time, you can only keep it if your vendors tell you sooner than that.

What to check

• Notice deadline: whether the DPA gives a fixed number of hours or only "without undue delay", and how that compares with what you promised your own customers.
• Trigger: whether notice is due when the vendor becomes aware of a breach, or only after it "confirms" one. A confirmation step can push notice later.
• Content and updates: whether the notice must say what data and how many people are affected, and whether the vendor will send updates as it learns more.
• Channel: where the notice goes. An email to a former account owner is easy to miss, so keep the security contact in the vendor's admin settings current.
• Subprocessors: whether a breach at one of the vendor's subprocessors is covered by the same promise.
• Help and cost: whether the vendor will help you notify regulators and people, and who pays for the notices.
• US data: whether the clause fits the state laws that apply to your customers' data, such as New York's 30-day limit for a business that holds data it does not own.

How Venpo helps

The breach promise lives in documents that change: the DPA, the security terms and the subprocessor list. Venpo watches your vendors' public legal documents and emails you a plain-English alert when one changes, for example when a notice period gets longer or a new subprocessor is added. Each vendor's change history, with a redline of every change, shows what the vendor promised on the day a breach happened.