NIS2 Art. 23 Telecom Reporting: When a Service Outage Triggers 24-Hour Notification for Mobile Network Operators

Most compliance officers at mobile network operators assume that Commission Implementing Regulation (EU) 2024/2690 sets their Art. 23 reporting benchmarks—the 30-minute outage threshold, the €500,000 financial loss floor, the 1-million-user impact gauge. It does not. Telecoms are explicitly excluded from that implementing regulation. The exclusion is not an oversight; it means your team must assess significance against Art. 23’s general criteria without a quantified safe harbour, and document its reasoning every time an incident approaches the line.

This guide sets out who falls under NIS2 reporting obligations in the telecom sector, how the three-stage notification clock works for network operators, what “significant impact” actually means when there is no implementing regulation to calibrate against, and what your compliance programme needs to have ready before the next major outage or security event.

Which Telecom Operators Are Essential Entities Under NIS2

NIS2 Annex I, Section 8 designates providers of public electronic communications networks—and separately, providers of publicly available electronic communications services—as essential entities. Unlike most NIS2 sectors, where the size threshold (50 or more employees, or €10 million or more in annual turnover) determines whether an entity is in scope, that carve-out does not apply to the electronic communications sector. Every operator of a public ECN or ECS is an essential entity regardless of headcount or revenue.

Service type	NIS2 classification	Size threshold?
Mobile network operator (MNO)	Essential entity — Annex I, Sector 8	None — all sizes in scope
Mobile virtual network operator (MVNO)	Essential entity — Annex I, Sector 8	None — all sizes in scope
Fixed-line broadband / cable ISP	Essential entity — Annex I, Sector 8	None — all sizes in scope
Internet access service provider	Essential entity — Annex I, Sector 8	None — all sizes in scope
Satellite broadband operator	Essential entity — Annex I, Sector 8	None — all sizes in scope
Number-independent ICS (OTT messaging, VoIP app)	Important entity — Annex II	Medium and large enterprises only

The practical impact is stark. A regional ISP with 40 employees providing publicly available broadband is an essential entity subject to full Art. 23 reporting obligations, proactive NCA supervision, and penalties up to €10 million or 2% of global turnover—the same regime as a national incumbent with 10,000 staff. This size-threshold exemption is the single most important scope feature distinguishing telecoms from the other 17 NIS2 sectors.

Jurisdiction for reporting purposes follows the service, not the operator’s corporate seat. Under Art. 26 of NIS2, providers of public electronic communications networks or services fall under the jurisdiction of the Member State in which they provide those services. An MNO operating in four EU countries must identify the competent CSIRT and NCA in each of those countries separately. Your establishment Member State is not your reporting jurisdiction unless that also happens to be where you provide services.

The Three-Stage Notification Clock for Mobile Network Operators

Article 23 [1] imposes a sequential notification obligation with three hard deadlines. Each deadline runs from the moment the entity becomes aware of a potentially significant incident—not from when significance is confirmed, and not from when the incident is resolved. The clock starts on awareness.

Stage	Deadline	Mandatory content	Telecom-specific inclusions
Early warning	24 hours from awareness	Suspected unlawful cause; cross-border potential	Service type, geographic scope, estimated subscriber impact, emergency services status
Incident notification	72 hours from awareness	Initial severity; indicators of compromise; updated impact	Network layer affected (RAN/core/backhaul), attack vector if security incident, resiliency measures activated
Final report	1 month from notification (or 1 month post-resolution if ongoing)	Full description, threat type, mitigation measures, cross-border impact	Root cause analysis, recurrence prevention, cross-carrier notification log, NRA coordination record

One practical complication: the 72-hour notification window falls inside a typical major incident’s active response phase. Network outages affecting hundreds of thousands of subscribers are rarely fully stable within three days. Art. 23 accounts for this: if the incident is still ongoing at the one-month mark, you submit a progress report and a final report within one month of resolution. What you cannot do is delay the 24-hour early warning while waiting for the incident to clarify itself. The early warning is designed to be submitted under uncertainty—its content requirements are intentionally limited to what you actually know within the first 24 hours.

The CSIRT must provide initial feedback to the reporting entity—where possible within 24 hours of the early warning—and inform other affected Member States and ENISA when cross-border impact is identified. Art. 23 also establishes that a notification submitted in good faith cannot be used to increase the entity’s liability exposure. Submitting the early warning is not an admission of significance, negligence, or breach.

Applying the Art. 23 Significance Threshold to Telecom Incidents

The general Art. 23 significance test has three independent prongs. An incident is significant if it has caused—or is capable of causing—any one of: severe operational disruption of the entity’s services; significant financial loss to the entity; or considerable material or non-material damage to other natural or legal persons. Meeting any one criterion is sufficient to trigger the reporting obligation.

For a mobile network operator, “severe operational disruption” is not defined by a specific outage duration or subscriber count in any EU-level implementing act. The assessment turns on the nature of the services disrupted. An outage preventing emergency voice calls (112 routing) reaches the significance threshold far faster than one affecting non-critical data services, even if the subscriber numbers are identical. A regional mobile blackout lasting 90 minutes that cuts first responders’ communications is significant; a brief degradation of a supplementary streaming service affecting the same number of users may not be.

NIS2 Recital 95 [2] states that existing national guidelines adopted for the transposition of EECC Arts. 40 and 41 “should be taken into account” when implementing NIS2 significance assessments. Before NIS2 absorbed telecom reporting, ENISA published annual telecom security incident reports using an absolute threshold approach: 1 million user-hours—the product of affected users and outage duration in hours—served as a working benchmark for what regulators treated as significant at EU level. A 2-hour outage affecting 500,000 subscribers produces 1 million user-hours and historically would have been reported under that framework. These figures are not binding NIS2 law, but they reflect the practical scale ENISA and NCAs have treated as material, and they can anchor your internal significance assessment documentation.

Three factors consistently amplify significance for telecom incidents regardless of subscriber count or duration:

• Emergency communications disruption: any impairment to 112 routing, Public Warning Systems, or first responder priority services is a strong significance indicator even for brief outages
• Cascade to other sectors: when the outage disrupts interconnected critical infrastructure—hospital data links, air traffic management communications, financial clearing systems—the “damage to other persons” prong is almost certainly met
• Evidence of malicious intent: a cyberattack causing the same disruption as an equipment fault carries greater regulatory weight; the early warning must specifically note suspected unlawful cause

Because no implementing act quantifies these criteria for telecoms, the compliance obligation is procedural as much as substantive: you must have a documented, reproducible significance assessment methodology, applied consistently across incidents, and available for review by your competent authority. What you cannot do is retroactively determine significance after a major incident has resolved.

Why CIR 2024/2690 Thresholds Are Not Your Safe Harbour

Commission Implementing Regulation (EU) 2024/2690 [3], adopted on 17 October 2024, sets quantified significance criteria under Art. 23 for the following entity types: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplace providers, online search engine providers, social networking service platforms, and trust service providers.

Public electronic communications networks and publicly available electronic communications services are absent from that list [4]. The CIR’s scope does not include traditional telecom operators—MNOs, MVNOs, fixed-line ISPs, or cable broadband providers. This exclusion is structural. The Commission chose not to extend the CIR to the electronic communications sector, directing telecoms instead toward EECC-era national guidance and future ENISA harmonisation work (Recital 95).

The practical risk is that compliance programmes using CIR thresholds as their telecom reporting trigger are operating without legal basis. For reference:

Entity type (CIR 2024/2690)	Significance threshold (availability)	Applies to telecoms?
Cloud computing service provider	Complete unavailability > 30 minutes OR > 5% of EU users / > 1 million users affected for > 1 hour	No
DNS service provider	Complete unavailability > 30 minutes OR average response time > 10 seconds for > 1 hour	No
CDN / MSP / MSSP	Complete unavailability > 30 minutes	No
Mobile network operator	No implementing act adopted (as of mid-2026)	Must use Art. 23 general threshold + national guidance

A network event that falls below the cloud-provider threshold—say, a 25-minute regional voice outage affecting 300,000 subscribers—may still meet Art. 23’s general significance criteria for an MNO if emergency services were impaired or if another critical sector depended on that network. Conversely, a prolonged data service degradation affecting millions of users may not be significant if the impact on essential communications and other persons was minimal. The thresholds in the CIR tell you nothing about your own significance exposure.

Until the Commission adopts a telecom-specific implementing act, MNOs must develop a written, internally approved significance assessment framework, anchored in Art. 23’s text and applicable national NCA guidance, and apply it consistently to every incident that approaches the line.

Outage vs. Security Incident: Two Trigger Types, One 24-Hour Clock

NIS2 Art. 23 applies equally to two distinct incident categories that require different internal detection and escalation paths, but share the same notification timeline once the significance threshold is crossed.

Availability incidents are the outages, degradations, and capacity failures that network operations centres manage routinely. The NIS2 question is whether the disruption crosses the significance threshold. Relevant factors: duration, geographic spread, subscriber count, services affected (voice, data, SMS, emergency priority), and whether other critical sectors are impacted downstream.

Security incidents are events compromising the confidentiality, integrity, or authenticity of stored, transmitted, or processed data or systems. For MNOs, this category includes: SS7 signalling protocol attacks enabling unauthorised interception of calls or location data; SIM-swapping operations conducted at scale through compromised internal systems; BGP route hijacking redirecting subscriber traffic through unauthorised networks; core network intrusions exposing subscriber metadata or authentication credentials; and ransomware affecting BSS/OSS infrastructure with downstream service impact.

Under the old EECC framework, national reporting concentrated almost entirely on availability. NIS2 explicitly expands the reporting obligation to security incidents affecting confidentiality and integrity [5]. A security breach may qualify as significant even with no service disruption visible to subscribers—if it caused or could cause considerable damage to affected persons through data exposure, targeted surveillance, or fraudulent use of communications infrastructure. “Capable of causing” is the operative language: you do not need to wait for harm to materialise.

Both incident types share the same 24-hour early warning deadline from the moment of awareness. The early warning for a suspected security incident must indicate whether unlawful or malicious acts are suspected—content that availability incidents do not require. Build separate escalation paths in your incident response plan for each type, even though both lead to the same CSIRT notification channel.

Penalties for Late or Missing Notifications

Essential entities that fail to meet Art. 23 notification obligations face enforcement action from their competent NCA. The penalty framework is materially more severe than the old EECC regime under which most national regulators operated.

Entity type	Maximum administrative fine	Enforcement basis
Essential entity (MNOs, all ECN/ECS providers)	€10,000,000 or 2% of global annual turnover (whichever is higher)	NIS2 Art. 34
Important entity	€7,000,000 or 1.4% of global annual turnover (whichever is higher)	NIS2 Art. 34
Management board member (personal liability)	Determined by Member State; may include prohibition on management functions	NIS2 Art. 20 + national transposition

Beyond financial penalties, Art. 20 places specific governance obligations on management bodies. Board members and senior management are required to approve cybersecurity risk management measures, oversee their implementation, and can be held personally liable for NIS2 infringements. Germany’s BSIG (§38) already allows NCAs to prohibit individuals responsible for governance failures from exercising management functions. Other Member States are transposing equivalent personal accountability provisions.

One important protection: Art. 23(9) states that notification under Art. 23 cannot, in itself, increase the reporting entity’s liability exposure. Submitting the early warning within 24 hours does not constitute an admission that the incident was significant or that the entity was negligent. The notification obligation and the liability question are assessed separately by the competent authority.

Multi-Jurisdiction Reporting: Operating in Multiple Member States

An MNO operating across multiple EU Member States faces overlapping Art. 23 obligations simultaneously. Article 26 establishes that providers of public electronic communications networks and services fall under the jurisdiction of each Member State where they provide those services. Unlike most NIS2 entities that report to the Member State of their main establishment, a transnational telecom operator may be legally required to report to two, three, or four separate CSIRTs and NCAs for the same incident.

When a major incident affects subscribers in more than one Member State—a roaming blackout, a cross-border backbone failure, or a DDoS attack on shared infrastructure—Art. 23(6) additionally requires the competent authority or CSIRT to notify other affected Member States and report to ENISA in anonymised aggregate form. As the reporting entity, you should flag cross-border impact explicitly in your 24-hour early warning so the CSIRT can activate the coordination chain immediately.

Practical steps for transnational operators:

• Map all jurisdictions where public ECN/ECS services are provided to identify all applicable CSIRTs and NCAs
• Establish a jurisdictional response matrix: who notifies which CSIRT, in which language, within what local transposition deadline (some Member States have transposed stricter timelines than the Art. 23 minimum)
• Designate a single internal incident coordinator per jurisdiction to prevent duplicated or conflicting submissions
• Identify national regulatory authorities (BEREC national members: BNetzA, Ofcom, ARCEP, AGCOM, etc.) that may require parallel notification under remaining national telecoms regulations not fully superseded by NIS2

Compliance Checklist: What Telecom Operators Must Have Ready

The following checklist addresses the minimum operational readiness requirements for NIS2 Art. 23 compliance at an MNO or public ECN/ECS provider. Items marked as urgent should be completed before any live incident occurs.

Item	Priority	NIS2 basis
Confirm essential entity classification under Annex I, Sector 8 for all operating jurisdictions	Urgent	Art. 3, Annex I
Register with competent NCA / CSIRT in each Member State where services are provided (Art. 26 jurisdiction)	Urgent	Art. 27, Art. 26
Document a written significance assessment methodology anchored in Art. 23’s three-prong threshold	Urgent	Art. 23(1)
Establish a 24-hour notification capability: internal escalation path and CSIRT submission channel in each jurisdiction	Urgent	Art. 23(4)(a)
Prepare Art. 23 notification form templates for all three stages (early warning / incident notification / final report)	Urgent	Art. 23(4)
Review national EECC transposition guidelines published by each NCA for EECC Arts. 40–41 (remain relevant per Recital 95)	High	NIS2 Recital 95
Build separate escalation paths for availability incidents vs. security incidents (different early-warning content required)	High	Art. 23(4)(a)
Train incident response and NOC teams on Art. 23 trigger criteria, especially the “capable of causing” forward-looking test	High	Art. 21(2)(b)
Coordinate with national regulatory authority (BEREC national member) for any parallel reporting obligations not absorbed by NIS2	Medium	Art. 26, national law
Brief management board on Art. 20 personal liability provisions and oversight responsibilities	Medium	Art. 20

Frequently Asked Questions

Our outage lasted under 30 minutes and affected fewer than 100,000 subscribers. Do we still need to assess significance?

Yes. There is no safe-harbour threshold for telecoms under NIS2. Unlike cloud providers under CIR 2024/2690, mobile network operators have no implementing act specifying minimum quantitative thresholds. You must assess significance against Art. 23’s criteria—severe operational disruption, financial loss, or damage to others—including any impact on emergency service routing. A brief, small-scale outage that impairs 112 calls may meet the significance threshold; a prolonged outage of non-critical data services affecting many more subscribers may not.

Is any disruption to emergency services automatically significant under NIS2?

NIS2 does not create an automatic significance trigger for emergency services disruption, but any impairment to 112 routing, Public Warning Systems, or public safety communications will typically meet at least one of the three Art. 23 significance prongs—most likely “considerable non-material damage to natural persons” through life-safety risk. Even a brief interruption warrants immediate significance assessment and, in most cases, a precautionary 24-hour early warning. Regulators in Member States with dense emergency use of commercial mobile networks will apply heightened scrutiny to incidents affecting those services.

We also process subscriber data. Do GDPR obligations apply in parallel to Art. 23?

Yes. NIS2 Art. 23 reporting and GDPR Art. 33 breach notification (72 hours to the supervisory authority) are parallel, independent obligations with separate reporting channels and separate authorities [6]. A cyberattack causing both a network outage and a subscriber data breach at your MNO may trigger both simultaneously. Neither notification replaces the other, and the thresholds—“significant impact” under NIS2 and “risk to the rights and freedoms of natural persons” under GDPR—are assessed independently.

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

1. NIS2 Directive Article 23: Reporting Obligations — nis-2-directive.com
2. NIS2 Directive Preamble: Recitals 91–100 — nis-2-directive.com (Recital 95)
3. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex
4. CIR 2024/2690 full text — easy-read format — Advisera
5. Defining the reporting threshold for a cybersecurity incident under NIS and NIS2 — Journal of Cybersecurity, Oxford Academic
6. NIS2: Understanding Cybersecurity Incident Notifications — William Fry
7. NIS2 Article 23 Incident Notification — nis-2-templates.com
8. NIS2 Incident Reporting — nis-2-templates.com