NIS2 Cross-Border Incident Notification: Why You File With One CSIRT, Not Five

Ransomware takes down your order-management platform. Customers in Germany, France and Poland lose service inside an hour. Your compliance officer asks the obvious question: do we now file with three CSIRTs?

Under Directive (EU) 2022/2555, no. Article 23(6) puts the job of informing the other affected Member States on the authority that received your notification – not on you. What decides how many filings you actually make is not how many countries the incident touched. It is how many Member States have jurisdiction over the legal entities involved, under Article 26. Those two questions get collapsed into one constantly, including by guides that tell you to report to the CSIRT in every affected country.

This guide separates them, then walks a multi-country incident hour by hour.

One Incident, One Filing: What Article 23(6) Puts on the Regulator

In plain terms: you notify one CSIRT – the one in the Member State whose jurisdiction your entity falls under. Everything that happens between countries after that is authority-to-authority work, and the Directive assigns it explicitly.

Article 23(1) sets the entity-side duty: essential and important entities notify "without undue delay" their CSIRT or, where applicable, their competent authority. The same paragraph adds the cross-border hook most readers miss – entities must report "inter alia, any information enabling the CSIRT or, where applicable, the competent authority to determine any cross-border impact of the incident." Note the verb: your job is to enable the determination, not to make the onward notifications.

Article 23(6) then says who does. Verbatim: "Where appropriate, and in particular where the significant incident concerns two or more Member States, the CSIRT, the competent authority or the single point of contact shall inform, without undue delay, the other affected Member States and ENISA of the significant incident."

Duty	Who owns it	Provision
Notify a significant incident at 24 hours, 72 hours and one month	The entity	Art. 23(1), 23(4)
Supply information enabling the authority to determine cross-border impact	The entity	Art. 23(1)
Inform the other affected Member States and ENISA	Your CSIRT, competent authority or single point of contact	Art. 23(6)
Forward the notification to other Member States’ single points of contact	Your single point of contact, at the CSIRT’s or competent authority’s request	Art. 23(8)
Cross-border liaison between national authorities generally	The single point of contact	Art. 8(4)
Coordinated technical response across borders	The CSIRTs network	Art. 15(3)(g), (h)

Two qualifiers cut against reading Article 23(6) as a guarantee. The duty opens with "where appropriate" – a cross-border incident is named as the paradigm case, not as an automatic trigger. And Article 23(8) makes single-point-of-contact forwarding conditional: "At the request of the CSIRT or the competent authority, the single point of contact shall forward notifications received pursuant to paragraph 1 to the single points of contact of other affected Member States." No request, no forwarding. Expect the mechanism to work; do not expect to evidence it in an audit file.

Affected Is Not the Same as Jurisdiction

This is the distinction that decides your filing count, and it is the one competitor guides skip. "Affected Member State" is an Article 23(6) concept describing where the incident lands. "Member State of jurisdiction" is an Article 26 concept describing where the entity sits. Only the second one creates a notification duty.

Article 26(1) sets the default: entities "shall be considered to fall under the jurisdiction of the Member State in which they are established," and then names three exceptions. The first one reverses the whole analysis for one sector: providers of public electronic communications networks and publicly available electronic communications services fall under the jurisdiction of "the Member State in which they provide their services" – plural, if they provide them in several. A pan-European telecom operator genuinely is under multiple jurisdictions, and the single-filing logic below does not hold for it. The second carve-out is the one most readers need. A defined list of digital providers – DNS service providers, TLD name registries, domain name registration services, cloud computing providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplaces, online search engines and social networking platforms – falls under the jurisdiction of its main establishment instead, which Article 26(2) locates in "the Member State where the decisions related to the cybersecurity risk-management measures are predominantly taken," with fallbacks to where cybersecurity operations are carried out and then to the establishment with the highest number of employees in the Union. Our Article 26 jurisdiction guide works through that three-tier test in detail.

The other half of the answer is Article 6(38), which defines an entity as "a natural or legal person created and recognised as such under the national law of its place of establishment." Obligations attach to the legal person, not the corporate group. Put those together and the filing count falls out:

Your situation	Filings	Why
One in-scope entity established in one Member State; customers in five Member States lose service	1	Art. 26(1) ties jurisdiction to establishment; Art. 23(6) hands onward notification to your authority
A group with separately in-scope subsidiaries established in three Member States, all three disrupted	3	Each subsidiary is its own entity under Art. 6(38) and falls under its own Member State’s jurisdiction
A cloud, DNS, CDN, MSP or MSSP provider operating across several Member States	1	Art. 26(1)(b) plus the main-establishment test in Art. 26(2)
A non-EU provider in that same category offering services in the Union	1	Art. 26(3) requires designating a representative in the Union
Only your Dutch subsidiary is in scope; the incident also hits an out-of-scope German sister company	1	Scope follows the entity, not the group perimeter
A provider of public electronic communications networks or services operating in several Member States	One per Member State of provision	Art. 26(1)(a) is the exception: jurisdiction follows service provision, not establishment

The commonly repeated advice – report to the CSIRT in each affected Member State – turns row one into a five-filing exercise the Directive never asked for, and sends staff into portals where the entity is not registered, without credentials, against deadlines that were never running.

A Cross-Border Incident, Hour by Hour

In plain terms: cross-border appears twice in the reporting sequence – as a yes / no / do-not-know flag at hour 24, and as a substantive assessment in the final report a month later. Nothing in between requires you to contact another country.

Hour 0 – awareness. The clock starts when you have reasonable grounds to treat the incident as significant under the Article 23(3) two-limb test: severe operational disruption or financial loss for your entity, or considerable material or non-material damage to others. Either limb alone is enough. Our significant incident threshold guide covers the judgement call.

Within 24 hours – the early warning. Article 23(4)(a) requires an early warning "which, where applicable, shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact." Those are the only two indications the provision names, and both are qualified. This is the moment cross-border enters the record – as a flag, not a report. See the 24-hour early warning guide for what belongs in that first filing.

Belgium’s form is the most explicit published example. The Centre for Cybersecurity Belgium’s notification guide documents field 13 – "Do you believe this incident might lead to cross-border issues?", mandatory – with the instruction: "If you do not know or are not sure, tick ‘Uncertain’." Field 14, the free-text description, appears only if you answered yes, and like every free-text field there it is capped at 500 characters. Two consequences follow: uncertainty is an instructed answer at hour 24, not a compliance gap; and whatever you write has to fit in a paragraph, so the narrative belongs in your own incident log, not the portal.

Within 72 hours – the incident notification. Article 23(4)(b) updates the early warning with an initial assessment of severity and impact, plus indicators of compromise where available. Article 23(5) meanwhile puts a clock on your regulator: it responds "without undue delay and where possible within 24 hours of receiving the early warning," with initial feedback and, on request, guidance on mitigation – so the early warning opens a support channel rather than closing a file. The 72-hour notification requirements break down what has to be assessed by then.

Within one month of the 72-hour notification – the final report. Article 23(4)(d) requires the final report "not later than one month after the submission of the incident notification under point (b)" – from your 72-hour filing, not from the incident. It must include, at point (iv), "where applicable, the cross-border impact of the incident." This is where an hour-24 "Uncertain" has to resolve into a documented answer. Where the incident is still running, Article 23(4)(e) substitutes a progress report at that point and a final report within one month of your handling of it.

What Travels Onward, and Three Things It Will Not Do for You

Article 23(6) specifies the payload: the information passed to other affected Member States "shall include the type of information received in accordance with paragraph 4" – the same 24-hour, 72-hour and final-report content you filed. It also imposes a protective duty on the authority, which must "preserve the entity’s security and commercial interests as well as the confidentiality of the information provided."

National law sharpens that further. Belgium’s guide states that information provided to the CCB "may be exchanged in an anonymised manner with authorities of other Member States of the European Union," limited to what is "relevant and proportionate." So what reaches a French or Polish authority is realistically a technical and impact summary, frequently anonymised – not a dossier naming you. That is reassuring for disclosure risk, and it is exactly why the mechanism does not substitute for your own obligations. Three gaps are worth planning around:

1. It does not discharge another in-scope entity’s filing. If your Polish subsidiary is separately in scope, Article 23(6) traffic between authorities is not its notification. Its own 24-hour clock runs independently.
2. It comes with no deadline you can rely on and no receipt you can file. Article 23(6) binds the authority to "without undue delay," and Article 23(8) forwarding happens only on the CSIRT’s or competent authority’s request. The Directive gives the notifying entity no confirmation, no reference number and no visibility into whether propagation occurred.
3. It widens the set of authorities that can go public. Under Article 23(7), a Member State’s CSIRT or competent authority – and "where appropriate, the CSIRTs or the competent authorities of other Member States concerned" – may inform the public after consulting you, or require you to do so. Every authority you are propagated to is a further party that may take that step, so build your incident communication plan on that assumption rather than on a single regulator.

EU-CyCLONe and the CSIRTs Network: Neither Is Your Reporting Channel

In plain terms: both are authority-side structures. You never register with them and you never file into them.

Article 16(1) establishes EU-CyCLONe "to support the coordinated management of large-scale cybersecurity incidents and crises at operational level and to ensure the regular exchange of relevant information among Member States and Union institutions, bodies, offices and agencies." Its members, under Article 16(2), are Member State cyber crisis management representatives and the Commission, with ENISA as secretariat. Nothing in Article 16 creates an entity-facing channel.

The threshold that activates it is a defined term. Article 6(7) defines a large-scale cybersecurity incident as "an incident which causes a level of disruption that exceeds a Member State’s capacity to respond to it or which has a significant impact on at least two Member States." An incident can therefore be significant under Article 23(3), cross-border under Article 23(6), and still fall well short of large-scale.

The CSIRTs network sits one layer down. Article 15(2) composes it of Member State CSIRTs and CERT-EU; its Article 15(3) tasks include exchanging information about incidents, near misses, cyber threats and vulnerabilities, discussing and where possible implementing a coordinated response, and assisting Member States with cross-border incidents. ENISA describes its work as touching "information exchange, coordination in incident response and assistance to Member States in times of cross-border incidents." Your CSIRT participates under Article 11(3)(f) – you do not.

The practical consequence: if your incident is large enough to reach either forum, you will experience it as sharper and more frequent questions from your own CSIRT, not as a new portal or a new deadline.

Who Owns What Before Your First Multi-Country Filing

The supervisory tail is where multi-country exposure bites, and it too runs through authorities rather than through you. Article 37(1) applies "where an entity provides services in more than one Member State, or provides services in one or more Member States and its network and information systems are located in one or more other Member States" – in which case the competent authorities concerned "shall cooperate with and assist each other as necessary." That includes consulting other Member States’ authorities via the single point of contact on supervisory measures taken, requesting another authority to act, and providing proportionate assistance on a substantiated request. Article 37(2) adds that authorities "may carry out joint supervisory actions" by common agreement.

Article 26(5) is narrower than it is often described: it applies only to the main-establishment category of entities in Article 26(1)(b), and only to a Member State that has received a request for mutual assistance, which may then act "within the limits of that request." It is not a free-standing right for any affected Member State to act.

Role	Owns	Effort
Compliance officer	Confirm the jurisdiction of every in-scope legal entity in the group and map each to its national CSIRT and portal; maintain registration credentials in each	Medium
CISO / IT security manager	Build the cross-border impact question into triage so the hour-24 flag is a decision, not a guess; own the technical content of the 72-hour update	Medium
Legal counsel	Decide who answers the Article 23(4)(d)(iv) cross-border assessment, and track Article 37 authority-to-authority contact once notified	Low
Board / C-suite	Approve the single-filing-plus-propagation model in writing so nobody improvises extra filings at hour 20	Low

Two preparation steps carry most of the value. First, identify the competent authority, single point of contact and CSIRT for each in-scope entity before you need them – the Commission publishes a per-Member-State implementation page naming them, and in Belgium all three roles sit with the Centre for Cybersecurity Belgium, with CERT.be as the national CSIRT. Second, rehearse the hour-24 cross-border flag specifically: it is the field most likely to be answered by whoever happens to hold the login. Our CSIRT notification forms guide covers portal access country by country.

Frequently Asked Questions

Do I have to notify the CSIRT in every country where customers were affected? Not under the Directive’s text, unless you are an electronic communications provider. Article 23(1) directs your notification to your own CSIRT or competent authority, and Article 23(6) places onward notification of the other affected Member States and ENISA on the authority side. For everyone outside the Article 26(1)(a) telecom carve-out, affected customers do not create jurisdiction. Article 5 does let Member States adopt "provisions ensuring a higher level of cybersecurity," so confirm the point against each national transposition rather than the Directive alone.

We are a group with in-scope subsidiaries in four Member States. How many notifications? Four, if all four are separately in scope and affected. Article 6(38) attaches obligations to the legal person and Article 26(1) attaches jurisdiction to establishment, so each subsidiary notifies its own national CSIRT on its own clock. This is the case where the "one filing" rule genuinely does not apply.

What if we still do not know at hour 23 whether there is cross-border impact? Say so. Article 23(4)(a) qualifies the cross-border indication with "where applicable," and Belgium’s national guide instructs entities to tick "Uncertain" if they do not know or are not sure. The obligation to give a substantive answer sits at the final report, under Article 23(4)(d)(iv).

Will another Member State’s authority contact us directly? The Directive does not provide for it as part of incident notification. Supervisory contact from another Member State runs through the Article 37 mutual-assistance route between competent authorities, or – for main-establishment entities only – through Article 26(5) within the limits of a received request.

Do we need to register with EU-CyCLONe? No. Article 16 constitutes EU-CyCLONe from Member State crisis representatives and the Commission, with ENISA as secretariat. There is no entity membership and no entity-facing notification channel.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Directive (EU) 2022/2555, Article 23 – Reporting obligations
• NIS2 Directive, Article 23 – reporting obligations (article text)
• Directive (EU) 2022/2555, Article 26 – Jurisdiction and territoriality
• NIS2 Directive, Article 26 – jurisdiction and territoriality (article text)
• NIS2 Directive, Article 5 – minimum harmonisation
• Directive (EU) 2022/2555, Article 8 – Competent authorities and single points of contact
• Directive (EU) 2022/2555, Article 6 – Definitions
• Directive (EU) 2022/2555, Article 15 – CSIRTs network
• Directive (EU) 2022/2555, Article 16 – European cyber crisis liaison organisation network (EU-CyCLONe)
• Directive (EU) 2022/2555, Article 11 – Requirements, technical capabilities and tasks of CSIRTs
• Directive (EU) 2022/2555, Article 37 – Mutual assistance
• Centre for Cybersecurity Belgium, NIS2 Notification Guide, version 1.2 (October 2024)
• European Commission, NIS2 Directive implementation in Belgium
• European Commission, NIS2 Directive: securing network and information systems
• ENISA, CSIRTs Network