Breach Notification Clause

What is a breach notification clause?

A breach notification clause is the part of a vendor contract that says when and how the vendor must tell you about a security problem affecting your data. It usually sits in the data processing agreement (DPA) or a security addendum.

Under the GDPR, the EU privacy law, there are two different deadlines. People often mix them up:

1. Vendor to you. Your vendor, as the data processor, must notify you "without undue delay" after it becomes aware of a breach (Art. 33(2)). The law sets no number of hours for this step.
2. You to the regulator. You, as the data controller, must notify the data protection authority without undue delay and, where feasible, within 72 hours of becoming aware (Art. 33(1)). You can skip this only if the breach is unlikely to put people at risk.

The 72 hours is your deadline, not the vendor's. The EDPB, the body of EU privacy regulators, says you are generally considered aware once the vendor has told you. It also says the contract can require early notice from the vendor. That is why the hours in a DPA matter so much.

What it looks like in a vendor's terms

A typical clause reads like this:

We will notify you without undue delay, and where feasible within 72 hours, after becoming aware of a Security Incident affecting your personal data. We will share what we know about the incident and the steps we are taking, and update you as we learn more. Notice is not an admission of fault.

• "After becoming aware" starts the clock at discovery, not when the incident happened.
• "Where feasible within 72 hours" is a target, not a hard limit.
• "Security Incident" is a defined term. Its definition decides what triggers notice.
• "Update you as we learn more" allows notice in stages, which the EDPB also allows.
• "Not an admission of fault" protects the vendor in later disputes.

Real DPAs set different numbers. Here is what we found, as of October 2026:

• Atlassian: without undue delay and, where feasible, no later than 72 hours.
• HubSpot: without undue delay and no later than 72 hours.
• Stripe: without undue delay, and "no later than 48 hours" for data under the GDPR or UK GDPR.

Put the two deadlines together. If a vendor uses its full 72 hours, and your own 72 hours then start, up to six days can pass between the vendor finding the breach and the regulator hearing about it.

Data Breach

Read the full page on Data Breach

A data breach, in GDPR terms a personal data breach, is a security failure that leads to personal data being destroyed, lost, changed, disclosed or accessed without permission. The full definition is in Article 4(12), and it covers accidents as well as attacks.

The EDPB groups breaches into three types:

• Confidentiality: someone sees data they should not, such as a leaked export.
• Integrity: data is changed without permission.
• Availability: data is lost or you cannot reach it, such as deleted backups or ransomware.

One incident can be more than one type. A breach at a vendor is still your breach to manage when you are the controller, which is why the vendor's notice clause matters. In the US, state data breach notification laws add their own rules about who must be told.

Security Incident

A security incident is any event that threatens the security of systems or data, such as an attack, a malware infection or a lost laptop. Not every incident touches personal data.

The EDPB puts it this way: all personal data breaches are security incidents, but not all security incidents are personal data breaches. Only a breach of personal data triggers the GDPR notification duties.

Vendor contracts often use their own definition, and the label can mislead. Atlassian's DPA uses the term "Security Incident" but defines it much like the GDPR's breach definition. Stripe's DPA uses "Data Incident", meaning unauthorized or unlawful processing, use, access or loss of personal data.

So read the definition, not the heading. A narrow definition can mean you are never told about attempts, near misses or incidents that the vendor decides did not affect your data.

Why it matters to you

Your deadline depends on theirs. You cannot report what you do not know. A slow vendor shrinks the time you have to investigate, report and warn your customers.

Your customers expect fast notice from you. If you sell to businesses, your own DPA may promise them a number of hours. If your vendor promises more hours than you promised your customers, you have a gap.

Content matters as much as speed. A notice that arrives fast but says nothing useful does not help. Article 33(3) lists what you must tell the regulator, so you need the vendor to give you those facts.

What to check

• Find the notice deadline in the DPA and whether it is in hours or only "without undue delay".
• Read how "breach" or "incident" is defined and what it leaves out.
• Check what the notice will include: what happened, what data, how many people, what the vendor is doing.
• Check who receives the notice and make sure that contact is current.
• Compare the vendor's deadline with what you promise your own customers.
• Check whether the clause covers breaches at the vendor's subprocessors, which must take on the same duties under Article 28(4).

How Venpo helps

Venpo monitors your vendors' DPAs and security pages and emails you a plain-English alert when a breach notice deadline or incident definition changes. Each vendor keeps a change history, so you can see what the clause said before.