ENISA's annual report on security incidents in the EU electronic communications sector recorded 188 major incidents in 2024. That number, on its own, tells you very little. What tells you a great deal is the pattern underneath: human error remained the dominant root cause, cascading failures accounted for a disproportionate share of impact, and incident reporting to national authorities was consistently slower than regulatory expectations. These are not telecom-specific problems. They are structural problems that NIS2 will expose in every regulated sector — energy, transport, health, digital infrastructure, financial services, public administration — as enforcement matures through 2026 and beyond.
If you are a CISO or board member in a non-telecom sector, the telecom incident data is your preview of what supervisory authorities will scrutinise, what enforcement actions will target, and what operational resilience standards will be expected. The lessons are transferable. The time to act on them is now.
What the Incident Data Actually Shows
ENISA's incident reporting framework for telecom operators under the European Electronic Communications Code (EECC) has been collecting structured incident data since 2012. The dataset is uniquely valuable because it covers a full decade of mandatory reporting, providing trend visibility that most sectors lack.
Human error dominates root causes. Across the 2024 reporting period, system failures and human errors — misconfigurations, flawed change management, process deviations — remained the most common root cause categories. This is consistent with the multi-year trend. Malicious attacks account for a meaningful but minority share of major incidents. The operational reality is that most significant disruptions originate from within the organisation or its immediate supplier ecosystem, not from external threat actors.
This finding has profound implications for security investment. Organisations that allocate the majority of their resilience budget to threat detection and response while under-investing in change management, configuration governance, and operational process discipline are misallocating resources relative to the actual risk distribution. Controls under NIS2 Article 21(2)(a) — requiring policies on risk analysis and information system security — must address this internal risk surface explicitly.
Cascading failures amplify impact. A disproportionate number of high-impact incidents involved cascading failures: an initial disruption in one system propagated to dependent systems, and the propagation path was either unknown or inadequately modelled. The cascading failure pattern is particularly dangerous because it defeats point-in-time risk assessments. An organisation can test each component in isolation and find acceptable resilience, while the interactions between components create failure modes that only manifest under stress.
For entities managing vendor risk under NIS2 Article 21(2)(d), cascading failures highlight the importance of understanding not just direct dependencies but transitive dependencies — what your vendor depends on, and what their vendors depend on. A vendor outage that propagates to your critical services because of an undocumented fourth-party dependency is a failure of supply chain risk management, not bad luck.
Reporting delays persist. Despite years of mandatory reporting under the EECC framework, a meaningful proportion of incidents were reported to national authorities later than required. The delays were not primarily caused by classification uncertainty — they were caused by inadequate operational readiness for reporting. Organisations lacked the pre-built communication channels, pre-approved notification templates, and pre-assigned reporting responsibilities needed to execute within the required timeframe.
This finding should alarm every entity that will be subject to NIS2 Article 23 incident reporting obligations. NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. The telecom data shows that even organisations with a decade of practice under a similar reporting regime struggle to meet reporting timelines consistently. Organisations encountering mandatory incident reporting for the first time under NIS2 should assume that their reporting capability is weaker than they believe.
NIS2 Article 23: What Changes for Incident Reporting
The EECC incident reporting framework that generated the telecom data is being superseded, for NIS2-regulated entities, by a more demanding reporting regime under Article 23.
Tighter timelines. The early warning requirement — within 24 hours of awareness — is aggressive by any standard. "Awareness" is the trigger, not classification. If your SOC identifies anomalous behaviour that could constitute a significant incident, the 24-hour clock starts at the point of awareness, not at the point when the incident is fully classified and its impact is fully understood.
Broader scope. NIS2's definition of "significant incident" encompasses incidents that have caused or are capable of causing severe operational disruption or financial loss, or that have affected or are capable of affecting other natural or legal persons by causing considerable material or non-material damage. The "capable of causing" language means that near-misses and contained incidents may trigger reporting obligations if they had the potential for significant impact.
Cross-sector coordination. NIS2 introduces cross-sector incident reporting through the CSIRTs network and, for large-scale incidents, through the EU-CyCLONe coordination framework. This means that an incident at your organisation may trigger information sharing across sectors and borders — a level of exposure that most organisations have not planned for.
Management body accountability. Under Article 20, the management body must approve and oversee the cybersecurity risk management measures, including incident response capabilities. If incident reporting fails, the question "did the board ensure adequate incident response preparation?" will be asked. The telecom data showing persistent reporting delays demonstrates that this is not a theoretical risk.
Lessons for Non-Telecom Sectors
The telecom sector has the longest track record of mandatory incident reporting in the EU. Other sectors are now entering the same regime under NIS2 with less experience, less institutional muscle memory, and often less operational maturity in incident management. The telecom data provides five specific lessons.
Lesson 1: Test your reporting workflow, not just your response workflow. Most organisations have an incident response plan that covers detection, containment, eradication, and recovery. Fewer have tested whether they can actually produce and submit a regulatory notification within 24 hours while simultaneously managing the incident itself. These are parallel workstreams that compete for the same senior personnel. Test them together. If your CISO is simultaneously managing incident response and drafting the regulatory notification, something will slip.
Lesson 2: Pre-build your notification templates. The telecom data shows that reporting delays often stem from the notification production process, not from the incident itself. Pre-build notification templates for your top incident scenarios, with pre-approved language for each field required by the national competent authority. When an incident occurs, your team should be completing a template, not drafting from scratch.
Lesson 3: Map your cascading failure paths. For each critical business service, map the complete dependency chain: internal systems, external providers, fourth parties, shared infrastructure. Then model the failure propagation: if component X fails, what else fails? How quickly? What is the blast radius? This mapping should be updated quarterly because dependency architectures evolve. Under NIS2 Article 21(2)(c), business continuity management must address these cascading failure scenarios explicitly.
Lesson 4: Address human error structurally, not culturally. The persistent dominance of human error as an incident root cause demonstrates that awareness training and "culture of security" initiatives are insufficient as primary controls. Human error requires structural controls: automated configuration validation, mandatory change approval workflows, immutable audit logging, and separation of duties. These are the controls that reduce the probability of human-initiated incidents rather than relying on humans to be infallible.
Lesson 5: Assume your reporting capability is weaker than you think. Organisations that have never been subject to mandatory incident reporting consistently overestimate their readiness. The telecom sector, with over a decade of practice, still exhibits reporting delays. First-time reporters should plan for their initial incident notification processes to be slower, more chaotic, and more resource-intensive than their plans anticipate. Build margin into your response timelines and staff your incident reporting function with redundancy.
Board-Level Actions
For boards of directors and management bodies accountable under NIS2 Article 20, the telecom incident data supports five specific governance actions.
Commission an incident reporting readiness assessment. Do not accept assurance that "we have an incident response plan." Ask specifically: can we produce a regulatory early warning within 24 hours of awareness? Have we tested this? What happened in the test? Where did we fail? This assessment should be conducted as a tabletop exercise at minimum, and ideally as a full simulation involving the CISO, legal counsel, communications, and the designated regulatory contact.
Review dependency mapping currency. Request the current dependency map for the organisation's top five critical business services. Ask when it was last updated. Ask whether it includes fourth-party dependencies. Ask whether cascading failure scenarios have been modelled. If the answers are vague, the board has identified a resilience gap that should be prioritised.
Evaluate the human error control portfolio. Ask for a breakdown of security controls by the risk they address. What percentage of controls address external threats versus internal operational errors? If the portfolio is heavily weighted toward external threat controls while the organisation's actual incident history (or the telecom sector's incident history) shows internal causes dominating, the control portfolio is misaligned.
Establish reporting delay as a board-level metric. Track the time from incident awareness to regulatory notification in every tabletop exercise and every real incident. Report this metric to the board alongside traditional incident metrics. A board that monitors reporting delay signals to the organisation that regulatory reporting is a first-order operational priority, not an afterthought.
Integrate incident lessons into risk management and compliance programmes. Incident post-mortems should feed directly into control improvement and compliance evidence updates. An incident caused by a configuration error should trigger a review of configuration management controls. An incident involving a third-party failure should trigger a review of the vendor's risk assessment. This feedback loop is required by NIS2 Article 21(2)(e), which mandates policies for the assessment of the effectiveness of cybersecurity risk management measures.
Why Telecom Incidents Are a Preview of NIS2 Enforcement
The EECC incident reporting framework was the prototype for NIS2's incident reporting regime. National competent authorities that supervised telecom incident reporting are now applying the lessons they learned — about common evasion tactics, about reporting quality issues, about the gap between documented capabilities and operational performance — to the broader NIS2 scope.
Supervisory authorities know what reporting delays look like. They know what vague notifications signal. They know the difference between an organisation with a tested incident reporting capability and one that is improvising in real time. The telecom data gave them a decade of calibration.
When NIS2 enforcement actions begin in earnest — and they will, with the first significant incidents in newly regulated sectors — the enforcement approach will be informed by telecom sector experience. Organisations that learn from the telecom data now will be better prepared than those that wait for their own sector's enforcement patterns to emerge.
The 188 incidents in 2024 are not a telecom problem. They are a rehearsal for what every regulated sector will face. The lessons are available. The question is whether your organisation will learn them proactively or discover them during your first supervisory engagement.
Key Takeaways
- Human error, not external attacks, remains the dominant root cause of major EU telecom incidents — organisations should rebalance their control portfolios toward structural controls (configuration validation, change approval workflows, separation of duties) rather than relying primarily on threat-facing defences.
- Cascading failures account for a disproportionate share of high-impact incidents — map your complete dependency chains including fourth parties and model failure propagation paths quarterly, not annually.
- Incident reporting delays persist even in the telecom sector after a decade of mandatory reporting — pre-build notification templates, test reporting workflows alongside response workflows, and track time-to-notification as a board-level metric.
- NIS2 Article 23 introduces tighter reporting timelines (24-hour early warning, 72-hour notification) with a broader incident scope — first-time reporters should assume their reporting capability is weaker than planned and build redundancy into the process.
- The telecom incident dataset is the best available preview of what NIS2 enforcement will look like across all regulated sectors — supervisory authorities are applying a decade of telecom enforcement experience to NIS2 oversight, and organisations that learn from this data now will face fewer surprises.