Cross-border GDPR breach notification: lead authority rules

Which authority must you notify when a breach crosses EU borders?

When a personal data breach touches customers or staff in several Member States, the 72-hour clock under Article 33 still starts once you become aware of the breach, and the first question is which supervisory authority receives the notification. A controller with a main or single establishment in the EU notifies its lead supervisory authority under the one-stop-shop, which then acts as the sole interlocutor for that cross-border processing (Article 56). A controller without an EU establishment, but subject to Article 3(2), must notify every supervisory authority in whose Member State affected people reside, because a representative does not trigger the one-stop-shop.

The answer depends on facts you need to establish before the clock runs out. Identify where decisions about the purposes and means of processing are actually taken, since that location usually determines the main establishment. Map where the processing physically happens, including hosting regions and any support access from outside the EU. Check whether a processor is involved, because the processor must notify you without undue delay, but the controller remains the party that notifies the authority. Confirm with counsel whether your EU entity is a real establishment and whether the lead authority can be identified on the facts. Document these findings in the breach file, since they determine who you must contact.

If the same incident is also reportable under NIS2, the picture gets more complicated. One incident can trigger NIS2 reporting to the CSIRT or competent authority and a personal data breach notification to the data protection authority under Article 33. Article 35 of NIS2 requires the competent authority to inform the data protection authority where an infringement may entail a personal data breach, but that does not replace your own notification. Plan separate reporting channels, separate content and separate deadlines, and confirm with your national authorities which NIS2 reporting timelines apply to your entity.

What changes for companies without an EU establishment

A company with no EU establishment that is subject to the GDPR under Article 3(2), because it offers goods or services to people in the EU or monitors their behavior, is a controller in its own right. Appointing an EU representative does not give it a lead authority. The EDPB's Guidelines 9/2022 (paragraph 73) state that a representative does not trigger the one-stop-shop, so the controller must notify every supervisory authority in whose Member State affected data subjects reside. A breach affecting people in five Member States therefore means five separate notifications, each with its own language and submission channel.

Map affected people by country: Count residents of each Member State within the breached data set, not only customers who signed up in the EU.
Build an authority register: For each relevant authority, record its submission channel, accepted languages and any national form or portal requirements.
Prepare a common core notice: Draft one factual description of the breach, then adapt the wording and language for each authority without changing the facts.
Keep the clock in one place: The 72-hour period under Article 33 runs from awareness, so all notices should go out within the same window.
Document the decision: Record why each authority was or was not notified, alongside the breach register entry.

Before an incident, confirm with counsel whether your Article 3(2) status and EU representative arrangement match what your customer records actually show.

How to sequence notices to several authorities within 72 hours

This sequence turns an unclear multi-country breach into a short set of filings, each with a documented basis, so the first notice reaches every authority that needs it before the Article 33 clock runs out.

Start the clock and open the breach register
Record the time the controller became aware of the breach, since the 72-hour period under Article 33 runs from that awareness rather than from the moment the investigation finished. The incident lead, with the data protection lead, opens a breach register entry the same day. The step is done when the entry shows the awareness time, the reporter, and a single owner for the notification workstream. Keep the timestamp in the register, not only in chat or ticket notes.
Confirm controller status and EU establishment
Legal or the DPO confirms whether your organization is the controller or a processor for the affected data, and whether it has a main or single establishment in the EU. This decides whether the lead authority under Article 56 applies at all. If you are a processor, your duty is to notify the controller without undue delay under Article 33(2), and the controller runs the authority filings. The output is a short decision memo that states the role, the establishment finding, and the source of each conclusion.
Map affected data subjects to Member States
Using the affected records, the technical team identifies where the people concerned reside, not where the servers sit or where the customer is incorporated. Group them by Member State and note any country where the count or data type is unknown. Where residence cannot yet be established, record that gap explicitly in the map. The output is a Member State map listing each country, the approximate number of data subjects, and the open questions for each.
Decide the lead authority or list every relevant authority
If your organization has a main establishment in the EU and the processing is cross-border, the lead authority under Article 56 is the sole interlocutor for that processing. If you are a controller without an EU establishment, the one-stop-shop does not apply, and you must list every supervisory authority in a Member State where affected data subjects reside. Record the chosen route and the reasoning in the decision memo, and have counsel check it before any filing goes out.
Prepare the initial notice and phasing plan
Draft the first notification using the content the GDPR requires, and state clearly which details are still being investigated. Article 33(4) allows information to be provided in phases where it cannot all be given at once, so the notice should commit to a follow-up date with each authority. Where several similar breaches share the same data type and method over a relatively short period, EDPB Guidelines 9/2022 allow a bundled notification. The output is an approved template per authority, with the same facts described consistently across all of them.
File each notice through the correct channel
Submit the notices through each authority's own reporting channel, in the language and format it accepts, and keep the copy of each one as filed. Send them within the 72-hour window and do not hold a filing back until every fact is known. Where a non-EU controller files with several authorities, the same record should go to each, with the Member State it covers identified. The output is a set of filings, each with its submission time and the authority's acknowledgement or reference number.
Log each filing with time and reference
Add every filing to the breach register with the authority, the submission time, the reference number returned, and the Member State it covers. Record any authority that has not yet acknowledged the filing. Note the phasing commitments and the date of each follow-up so the team can meet them. The step is complete when the register alone can show, for each relevant authority, what was filed, when, and what remains open.
Check parallel NIS2 reporting obligations
If the same incident may also be reportable under NIS2 to a CSIRT or competent authority, run that assessment in parallel, since Article 35 of NIS2 links the two regimes where an infringement can entail a personal data breach. Confirm whether your organization is in NIS2 scope under Article 2. Record the NIS2 decision and any separate filing in the same register, so the GDPR and NIS2 timelines can be compared in one place. Confirm the NIS2 reporting deadlines with your national competent authority and counsel.

When several similar breaches can go in one notification

The EDPB Guidelines 9/2022 allow a bundled notification when several similar personal data breaches occur. The bundle works only if the breaches involve the same type of personal data, were caused in the same way, and happened over a relatively short period. Your team decides whether the bundle fits, and the decision should be made per authority, not once for the whole incident. A cluster of misdirected emails containing the same data fields may qualify. Unrelated incidents that happen to fall in the same month do not.

A bundle has limits. Each notification must remain accurate for the authority receiving it, so the content, number of affected records and categories of people should be correct for the population that authority covers. A bundle also does not replace the duty to notify a new incident separately. If a later breach uses a different method, exposes different data, or reveals a new cause, treat it as a separate notification under Article 33 and start its own assessment of the 72-hour clock. Confirm with your counsel how the bundle interacts with any phased follow-up information you have already promised.

Record the reasoning for every bundling decision in your breach register, including the breaches grouped, the common factors you relied on, the time window and why you judged the bundle accurate. Where a non-EU controller must notify several supervisory authorities, a bundle still requires each authority's own filing through its own channel and language requirements, so confirm those formalities with each authority before you rely on a single document.

How NIS2 reporting runs alongside a GDPR breach notice

A single incident can open two separate reporting duties: a NIS2 incident report to a CSIRT or competent authority, and a GDPR notice to a data protection authority. The cards below set out what each duty is, how they connect, and what to confirm with counsel before the clock runs.

The NIS2 incident report

Where an entity falls within NIS2 scope, a significant incident must be reported to the CSIRT or competent authority under Article 23 of Directive (EU) 2022/2555. This is a separate duty from GDPR and is owned by the entity, not the data protection authority. Map who receives the report in each Member State where you operate before an incident occurs.

The GDPR notice to the authority

A personal data breach must be notified to the competent supervisory authority under Article 33 GDPR, generally without undue delay and within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. The GDPR notice describes personal data affected, not network impact. Keep the two reports consistent in facts and timing.

One incident, two triggers

The same intrusion or outage can be a significant NIS2 incident and a personal data breach at once. Neither report replaces the other. Your incident response plan should decide early which facts go to which authority, who signs each filing, and who keeps the single timeline both reports draw from.

Authority-to-authority referral

Under Article 35(1) of NIS2, where a competent authority finds an infringement of its Article 21 or 23 duties that can entail a personal data breach notifiable under Article 33 GDPR, it must inform the GDPR supervisory authority without undue delay. Expect regulators to compare your two filings, so inconsistencies in timing or scope will be visible.

Different scope tests

NIS2 applies by sector, size and entity classification, while GDPR applies to any processing of personal data within its territorial scope. An organization can be in GDPR scope and outside NIS2, or the reverse. Confirm NIS2 applicability for your entity and each subsidiary separately before deciding which reporting duties apply.

Confirm timelines and content with counsel

The reporting deadlines, required content and phasing differ between NIS2 and GDPR, and national transposition may add detail. Ask counsel to confirm the timeline and content for each regime in every Member State where you have affected people or entities. An implementation partner can prepare the templates and evidence, but the legal reading and the filing decisions stay with your organization.

Which notification route fits which company

This table compares who must be notified, who the authority deals with, and what to confirm for each common EU structure. Read the row that matches your legal position first, then check the confirmation column before your first notice. The main takeaway is that the one-stop-shop covers controllers with an EU establishment, while a non-EU controller usually notifies each affected country's authority separately.

Organization type	Authorities to notify	Point of contact	What to confirm
EU controller, single establishment	Supervisory authority of that establishment, which acts as lead authority	Lead authority is the sole interlocutor for cross-border processing	All processing sits in one establishment and the authority's breach form and channel
EU controller, several establishments	Lead authority of the main establishment for cross-border processing	Lead authority only, not each local authority	Which establishment makes decisions on purposes and means, recorded in your documentation
Non-EU controller with an EU representative	Each supervisory authority where affected people reside	Each authority separately, because the representative does not route notices	Country of residence for every affected group and each authority's accepted channel
Non-EU processor	Usually none directly, since the controller notifies the authorities	Your controller customer, under the processing agreement	Notice timing to the controller and which party files with each authority
Entity in scope of NIS2 and GDPR	GDPR supervisory authority plus the NIS2 CSIRT or competent authority	Two separate reporting channels with different content and timing	Your NIS2 scope under Article 2 and how your Member State transposed it
Bundled notices for similar breaches	Same authorities as your route, filed as one notice	Same contacts as the underlying route	Breaches involve the same data type, method and a short time window, per EDPB Guidelines 9/2022

Mistakes that cause late or wrong cross-border filings

Most late or misdirected breach notifications across the EU trace back to a few assumptions made before any incident happens. The cards below cover the mistakes we see most often in planning, contracts and records, and the check that prevents each one.

Assuming a representative sets the lead

Non-EU controllers often appoint an EU representative and assume that one authority becomes the lead for breaches. It does not. EDPB Guidelines 9/2022 state that a representative does not trigger the one-stop-shop, so the company must notify each supervisory authority in whose Member State affected people reside. Check in writing which authorities a breach would reach before an incident, not after it.

Missing a small affected group

A breach can reach a few people in a Member State where the company has few or no customers. Teams that count only their main markets miss that group and skip the authority that covers it. Build the affected-population query from the data itself, by residence of the data subjects, and re-run it when the scope of the breach changes.

No pre-agreed authority and language map

When a breach crosses borders, the notification must reach the right authority quickly, in a form it can act on. Without a prepared list of authorities, their submission channels and the languages they accept, teams lose hours at the point the 72-hour clock is running. Maintain this map as a controlled document, confirm each channel with the authority, and assign an owner to keep it current.

Unclear processor notice duties

When a processor suffers the breach, the controller's own clock depends on when the processor tells it. Contracts that say only that the processor will notify "promptly" leave the controller unable to show when it became aware. Specify the notice window, the content the processor must provide, and the contact route for out-of-hours incidents, then test that route with the processor before it is needed.

Treating NIS2 and GDPR as one filing

One incident can require a NIS2 report to the CSIRT or competent authority and a separate GDPR notification to the data protection authority. Article 35 of NIS2 covers the case where an infringement may entail a personal data breach, and the authorities share information, but neither filing replaces the other. Map both reporting clocks in the same runbook and name one owner for each filing.

Not recording decisions not to notify

A company may decide not to notify a particular authority, for example because no affected people reside in that Member State or because the breach is unlikely to result in risk there. Without a written record of that reasoning, the company cannot show the decision was made at the time. Log each authority considered, the facts relied on, the decision and the approver, and keep the record with the breach documentation.

Who decides, who prepares the filings and who regulators answer

The organization owns the notification decision and the filings themselves. Counsel advises on whether an establishment in the EU exists, which authority is the lead authority under Article 56, and whether the company must notify several supervisory authorities directly. An implementation partner such as DeployOpen can prepare the inputs those decisions depend on: a breach register that records each incident, an authority map that lists the Member States where affected people reside, an evidence pack with logs and timelines, and the logging configuration that lets the team establish when it became aware of a breach. No independent party issues a notification acceptance or certificate on the organization's behalf, and a supervisory authority's acknowledgment of receipt is not an approval of the organization's assessment. Confirm this split in writing before an incident, so the roles are not improvised during one.

Confirm three points with counsel before relying on the lead authority route. First, whether the company has a main or single establishment in the EU, since that establishment is what makes one authority the sole interlocutor under Article 56(6). Second, if the company is established outside the EU, the EDPB's Guidelines 9/2022 state that a representative does not trigger the one-stop-shop, so every supervisory authority in a Member State where affected people reside must receive the notification. Third, whether a bundled notification is available for a series of similar breaches over a short period. Record each answer with its date and the person who approved it, because those answers determine which authorities the team contacts and in what order.

Regulators' procedures may change. Regulation (EU) 2025/2518 lays down additional procedural rules for complaints and investigations in cross-border GDPR enforcement cases and applies from 2 April 2027, so procedure for cases opened after that date may differ from today's practice. The Digital Omnibus proposal (procedure 2025/0360(COD)) is still awaiting committee decision and could alter GDPR obligations if adopted. Assign someone to track both files through the Legislative Observatory) and to review the authority map and notification templates when either changes.

Questions buyers ask about cross-border breach notification

Who is the lead authority if we have no EU office?

If you have no establishment in the EU, there is no lead authority under the one-stop-shop, so you cannot file once with a single regulator. Under the EDPB's Guidelines 9/2022, a controller outside the EU that is subject to Article 3(2) must notify the supervisory authority of every Member State where affected people reside. Appointing an EU representative does not change this, because a representative does not trigger the one-stop-shop. Confirm with counsel whether you have any EU establishment at all, since a subsidiary, branch or processing carried out in the EU can change the answer. Ask counsel to map which Member States your affected data subjects live in before you need the map during an incident.

Can one filing cover all of Europe?

Only if you have a main or single establishment in the EU, in which case the lead authority of that establishment receives your notification for cross-border processing. Even then, the lead authority is your single point of contact for that processing, and it coordinates with other authorities concerned, so the first notice still needs complete facts. Companies without an EU establishment cannot rely on one filing. The EDPB guidelines do allow a bundled notification for several similar breaches involving the same type of data, breached in the same way, over a relatively short period, which reduces paperwork but not the number of authorities involved.

Do we notify the authority of every country where a customer lives?

Under the EDPB's guidance for non-EU controllers, yes: each supervisory authority in whose Member State affected data subjects reside must receive the notification. For an EU controller with a lead authority, the position is different, because the notification goes to the lead authority for the cross-border processing, and the authority then engages others. Your obligation is driven by where the data subjects are, not where your customers' headquarters sit or where your servers run. Ask your counsel to confirm how your establishments and your processing map onto Article 56 before an incident, and keep a register of residence by Member State that your incident team can query quickly.

Does NIS2 reporting replace GDPR notice?

No. NIS2 reporting and GDPR breach notification are separate obligations with separate recipients. An incident can trigger both: a report to the CSIRT or competent authority under NIS2, and a personal data breach notification to the data protection authority under Article 33 of the GDPR. Article 35 of NIS2 requires the competent authority to inform the data protection authority without undue delay when an infringement can entail a personal data breach. You still need your own GDPR notice, with its own content and its own clock. Build one incident workflow that produces both filings from the same facts, and confirm with your NIS2 authority and your data protection counsel whether your organization is in scope of NIS2 at all, since that depends on the scope rules in Article 2.

Can a processor notify on our behalf?

A processor must notify the controller of a personal data breach without undue delay, but the controller remains responsible for notifying the supervisory authority and the affected individuals where required. If you are the processor for customers across several Member States, your contracts should specify who files, which authorities are relevant, what information you must supply and in what timeframe. Where a processor files on behalf of a controller, the controller should still verify the content and confirm the filing was made. For a non-EU controller, a processor cannot change the one-stop-shop analysis, so your mapping of affected Member States still applies.

What does preparing for this cost and what drives it?

No public fee figure applies here, so treat any number from a vendor or consultant as a quote to test. The main cost drivers are the number of establishments and whether any is in the EU, the number of Member States where your affected people live, how many systems and data stores would be in scope of a breach, and how many processors and sub-processors would need to pass information to you quickly. One-time work includes the legal mapping, the notification templates, the contact registers and the tabletop exercise. Recurring work includes keeping the residence map and contacts current and rehearsing the process. Ask any provider for a written scope listing the establishments, Member States, systems and processors covered, and for the deliverables and timeline before you agree a price.

Can we do this in-house?

Yes, many organizations do, provided the right people and the right information are in place before an incident. The in-house team needs legal input on establishments and lead authority, a current register of data subjects by Member State, a tested notification process, and access to logs and system inventories to describe the breach. External help is most useful for preparing systems and evidence, such as building the system inventory, the logging needed to scope an incident, and the runbooks, rather than for deciding the legal position. An implementation partner such as DeployOpen can prepare and document these systems and controls inside your own infrastructure, but the filing decisions remain yours. Only the regulators themselves determine how they handle a notification.

What should we confirm with the regulator and counsel?

Confirm with counsel which supervisory authorities would be competent for your processing, whether you have an EU main or single establishment, and how Article 56 applies to your structure. Ask the relevant supervisory authorities for their breach notification channels, languages, and any national guidance, because each authority publishes its own forms and contact routes. Check how Regulation (EU) 2025/2518, which applies from 2 April 2027, will change procedures for cross-border cases. Also confirm the status of the Omnibus proposals, which could change parts of the framework, with counsel rather than assuming the current text will stay unchanged.

How DeployOpen prepares your breach notification readiness

DeployOpen prepares the systems, documentation and evidence an organization needs to work out its lead authority and notify every relevant supervisory authority across EU countries. The organization keeps ownership of its notification decisions, and an independent legal adviser or the supervisory authorities themselves remain the final reference for how the rules apply.

How we scope

Engagements are fixed-scope, with the written scope agreed before any work starts.
The scope records where the organization is established, which Member States its data subjects live in, and whether Article 3(2) applies.
We confirm which systems hold personal data for EU residents and which teams hold the decision to notify.

How we build

We document the lead authority analysis and the list of supervisory authorities to notify for each processing activity.
We build a notification register that tracks each authority, its language requirements, its portal and the deadline status.
We align the breach process with NIS2 reporting paths so one incident is handled consistently across both regimes.

How we hand over

Deliverables include the written analysis, the authority contact register, bundled notification templates and the runbook.
We test the runbook with a tabletop exercise covering a multi-country breach scenario, labeled as illustrative in the test plan.
All documentation is handed over in the organization's own environment so the team can maintain it after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can refresh the authority register when national procedures or the EDPB guidance change.
Ask any quote to name what is one-time work, what recurs, and who pays the independent counsel or auditor involved.

Notifying a breach across EU countries: lead authority and non-EU companies