GDPR Breach Notification Rules: Founder Guide

If you have EU user data and a breach is likely, you may have just 72 hours to tell a regulator. That clock runs on weekends and holidays too.

Here’s the short version: I need to confirm whether personal data was involved, log the moment I became aware, assess risk to people, and decide between no external notice, authority notice, or authority + user notice. If facts are still missing, I can send an initial report and follow up later.

• 72 hours starts when I have a reasonable basis to believe personal data was compromised
• GDPR can apply to a U.S. company if it serves or tracks people in the EU
• Missing notice rules can lead to fines up to €10 million or 2% of global annual turnover
• I should bring in legal, the DPO/privacy lead, engineering, and an executive decision-maker at once
• Even if I do not notify externally, I still need an internal breach record

A simple way to think about it:

This guide is about making those calls fast, with clear owners, clean records, and no delay.

Step 1: Start the 72-hour clock and confirm the facts

What 'becoming aware' means in practice

The 72-hour clock starts when you have a reasonable basis to believe a personal data breach happened, not when the incident first began.

"Awareness is having a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised." - EDPB Guidelines 9/2022 ^[1]

That means you shouldn't sit on the issue while waiting for a full forensic review. Once the person in charge confirms there's a likely breach, the 72-hour response window starts right then.

From the start, record two separate timestamps:

• the time of the first alert
• the awareness timestamp, meaning the exact moment someone confirmed the breach was real

If a third-party processor is involved, your clock starts when they notify you, not when the incident first took place.

First 24 hours: confirm scope, data, and affected systems

Your first job is to contain the issue and keep evidence intact. Isolate affected systems, shut down compromised accounts, rotate credentials, and preserve logs before they get overwritten.

At the same time, your team needs to answer one basic question: does this incident involve personal data? Check whether the affected systems held data like names, email addresses, health records, or financial identifiers.

Once you confirm personal data is involved, scope the incident. Identify which systems were accessed, what types of data are involved, and about how many records and data subjects may be affected. At this stage, the numbers do not need to be exact. A reasonable estimate is enough to keep moving.

Start the breach log right away and record each decision and timestamp as they happen. That early scope and evidence snapshot will shape the notification call in Step 2.

Hours 24 to 72: assess risk and prepare a staged notification

Between hour 24 and hour 72, the focus shifts from technical response to legal review. Use the GDPR threshold as written: no notice if risk is unlikely, authority notice if risk exists, and authority plus individual notice if the risk is high. That risk level tells you whether to notify the authority, affected individuals, or both.

If the forensic picture is still developing as the deadline gets close, don't wait. GDPR allows phased notifications. So you can submit an initial Article 33 notice with the facts you have, note what is still unknown, and send more information later as it comes in.

"Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay." - GDPR Article 33 ^[1]

sbb-itb-e766981

Step 2: Decide who must be notified and what to send

A three-part decision path: no notice, authority notice, or authority plus data-subject notice

Once you've scoped the breach, the next move is simple: decide who needs to hear about it. Write down each call in the breach log. That decision shapes both the notice path and the legal review in Step 3.

Use this three-step test:

• If the event did not involve personal data, stop there.
• If it did involve personal data, ask whether it's likely to create a risk to individuals' rights and freedoms. If not, log it internally and move on.
• If that risk is likely, notify the supervisory authority under Article 33. If the risk is high, you also need to notify affected individuals under Article 34.

If your team can't clearly show why the risk is low within the 72-hour window, treat the case as likely risk and notify the authority. That's usually the safer call. It's much easier to update a notice later than to explain to a regulator why you filed late.

Once the path is clear, move to the exact notice content and the escalation record.

What an Article 33 notice to the supervisory authority must include

An Article 33 notice doesn't need to be long. It does need to be complete. Regulators want facts, not a long story.

Your notice must cover five things: the nature of the breach, the categories and approximate number of data subjects and records affected, the contact details of your DPO or other named point of contact, the likely consequences of the breach, and the measures taken or proposed to contain and remediate it.

The word to focus on here is approximate. You do not need exact figures within the 72-hour period. A reasonable estimate is fine. If the facts are still coming in, send what you have and fill in the gaps in phases. Don't hold the first notice while waiting on a final forensic report.

When Article 34 requires notice to affected individuals

Article 34 applies when the breach creates a high risk to individuals. That can include ransomware attacks that exfiltrated health data, breaches that exposed plain-text financial identifiers, or incidents involving groups like children.

Notices to affected individuals must use plain language. Say what happened, what data was involved, what consequences people might face, what steps you've already taken, and where they can get more help.

There are three cases where you can skip direct notice to individuals even when the breach creates a high risk:

• The affected data was encrypted and the keys remain secure.
• You took immediate action that removed the high risk before it could happen.
• Direct contact would take disproportionate effort, in which case a public notice is required instead.

If notice is required, the next move is to route the facts through legal and leadership without delay.

Step 3: Run internal escalation, legal review, and documentation

Set a clear escalation path from detection to executive decision

Once Step 2 shows a notifiable breach, move it into a fixed internal escalation path.

Breaches often show up outside the privacy team first. A developer might spot odd log activity. A customer support agent might flag an unauthorized access complaint. That's exactly why the path needs to be set before an incident happens, not in the middle of one.

Assign three named roles:

• Incident Response Manager (IRM) to lead the process end to end
• Data Protection Officer (DPO) or privacy lead to handle the threshold analysis
• Executive sponsor to give final sign-off on any notification decision, including a decision not to notify

The moment someone flags a possible breach, open a pre-defined communication channel. A private Slack channel works well. It pulls engineering, legal, and leadership into one place right away. From there, legal tests the threshold while operations preserves evidence and scopes the incident.

Build legal review into the clock, not after it

Privacy counsel or your DPO should be in the room from Hour 0, not added after the investigation wraps up.

During the first 24 hours, legal should run the threshold analysis: does the breach create an Article 33 risk to individuals, or an Article 34 high risk? If a vendor caused the breach, your Data Processing Agreement should require them to notify you within 24 to 48 hours. That gives legal enough time to act within your own reporting window. If the facts are still shifting, file the notice on time and update it later.

Keep the breach record even when no external notice is required

Under Article 33, every breach must be documented - even the ones that don't cross the notification threshold.

Write down the facts, likely impact, remediation, awareness timestamp, and the written reason for the notification decision. That decision may be: not notifiable, notifiable, or notifiable with individual notice. That paper trail gives you something solid to point to in an audit.

GDPR Article 33 Explained: Personal Data Breach Notification | 72-Hour Rule

Step 4: Use finance and operations to support response and close the loop

Once the notification decision is clear, operations and finance turn the legal call into action.

How operations speeds up scoping, response, and remediation

When a breach hits, operations is the fastest way to get answers. Open a breach assessment record within the first hour, even if the facts are still messy ^[3].

Then start mapping the scope. Review support tools, analytics, CRM, backups, AI features, and vendor platforms. Check whether the exposed data connects to identifiable people by reviewing logs, attachments, exports, and AI prompts.

If a third-party vendor is involved, pull the Data Processing Agreement right away and confirm the vendor's notice deadline. Give each corrective action a clear owner, whether that's revoking access, patching the vulnerability, or wiping a device. Log each step in the breach register as it happens. That sounds basic, but in a live incident, small gaps turn into big problems fast.

How finance supports cost tracking, board reporting, and planning

Operations finds and contains the breach. Finance tracks what it costs.

During a breach, finance needs to track response costs and model exposure, often with the help of fractional CFO services. Capture costs across:

• Outside legal counsel
• Forensic investigation firms
• Notification delivery
• Customer remediation, such as credit monitoring
• Internal staff hours across IT, legal, HR, and the executive team

That last item is easy to miss. But it matters for cyber insurance claims and for the Article 33 accountability record.

If you're a U.S. company with EU users, model possible fine exposure in both EUR and USD. Contact your cyber insurance carrier within the first 24 hours to confirm coverage limits for forensics and legal fees ^[2]. If the breach is large, finance should prepare a short update for the board or investors that puts numbers around the impact and lays out the response timeline.

Conclusion: Turn GDPR breach rules into a repeatable founder playbook

These steps work best when they stop living as loose advice and become a checklist your team can actually use. Confirm the breach, start the 72-hour process, assess risk, bring in legal from Hour 0, and document each decision. Give each task a named owner and set escalation paths ahead of time.

Then pressure-test the playbook with a tabletop exercise at least once a year. Use a scenario that feels real: a lost unencrypted laptop, a misdirected bulk email, or a vendor breach. See whether the team can meet the 72-hour mark. Find the weak spots before a live incident does it for you. Run the playbook before you need it.

FAQs

What counts as awareness of a breach?

Under GDPR, you’re considered aware of a breach when there is a reasonable degree of certainty that a security incident happened and personal data was compromised.

You do not need full forensic proof or a finished investigation before that point. A short initial triage is allowed to rule out false alarms, but the 72-hour notification clock starts as soon as that reasonable certainty exists.

Which EU authority do I notify first?

Notify the lead supervisory authority: the data protection authority (DPA) in the EU Member State where your company has its main establishment.

If you don’t have an EU establishment, you’ll usually notify the DPA in the Member State where most affected people live. If that’s not clear, notify the local DPA where the breach happened at a minimum.

How do I judge whether risk is high?

Judge high risk based on how badly people could be harmed.

A breach that creates any risk to people’s rights and freedoms may mean you need to notify a supervisory authority. But high risk is a higher bar. It means you should also notify the people affected.

Look at things like:

• how sensitive the data is
• how easy it is to identify the people involved
• how likely the data could be misused, such as for identity theft or fraud
• whether the people affected are especially vulnerable
• whether safeguards like encryption actually worked

Related Blog Posts

• GDPR Risks in Cross-Border M&A Deals
• GDPR Checklist for Fintech Startups
• Checklist for Initial Breach Detection
• Breach Notification Trigger Thresholds: 20-State Chart