NIS2 Telecommunications Compliance Checklist: The 12 Controls EECC Art.40 Didn’t Require

When the EU repealed EECC Articles 40 and 41 with the entry into force of NIS2, the security standard for electronic communications providers shifted from open-ended proportionality to a defined list of mandatory controls. EECC Article 40 required “appropriate and proportionate technical and organisational measures” — language flexible enough to accommodate an informal risk review or a full ISO 27001 certification at the operator’s discretion. NIS2 closes that discretion with 10 specific mandatory categories under Article 21(2), personal management liability under Article 20, and a three-stage incident reporting cascade under Article 23. Together, these 12 distinct obligation areas define compliance for every public electronic communications network (ECN) and electronic communications service (ECS) provider in the EU, regardless of company size.

This checklist maps each of the 12 controls against what EECC Article 40 required, identifies the evidence an NCA auditor will expect, and addresses three areas where telecoms face NIS2 obligations that most compliance guides overlook: 5G core network slicing per-slice incident detection, national roaming activation as a documented business continuity mechanism, and the specific incident significance threshold that applies to ECN/ECS providers in the absence of a sector-specific Commission implementing regulation.

Who Qualifies as an ECN or ECS Provider Under NIS2

NIS2 Article 2(2)(a)(i) captures providers of public electronic communications networks or publicly available electronic communications services regardless of company size. The 50-employee and €10 million turnover thresholds that determine NIS2 scope for most sectors do not apply here — a fixed-line ISP with 15 employees serving public subscribers is in scope from the moment it provides that public service.

Covered entities include mobile network operators (MNOs) and mobile virtual network operators (MVNOs), fixed-line and fibre-broadband operators, internet service providers offering publicly available access services, public VoIP and over-the-top messaging providers, and wholesale telecommunications network operators where the network is publicly accessible. Cloud providers, CDN operators, and managed service providers operating alongside a telecom function are separately captured by Commission Implementing Regulation (EU) 2024/2690 for those specific services.

Under NIS2 Annex I, providers of public electronic communications networks are classified as digital infrastructure entities in the essential entity tier. Essential classification means proactive, ex-ante supervision by national competent authorities (NCAs), annual management accountability cycles, and the higher penalty ceiling. There is no Important entity option for core ECN/ECS providers — the directive places them in the highest supervisory tier from day one.

BEREC confirmed that EECC Articles 40 and 41 — which previously governed telecom security obligations — were repealed when NIS2 came into force. Security requirements now flow exclusively through NIS2 Articles 20, 21, and 23. The ENISA ECASEC expert group has replaced the NRA-led telecom security supervision framework that existed under the EECC, supporting harmonised oversight across EU member states.

The 12 NIS2 Controls EECC Art.40 Didn’t Require

EECC Article 40 directed member states to require providers to take “appropriate and proportionate” security measures with regard to the state of the art. The ENISA guidelines on EECC security measures grouped requirements into 29 objectives within 8 security domains, but these remained guidance — not prescriptive mandatory obligations with documentary evidence requirements. BEREC noted explicitly that NIS2 introduces “a minimum list of basic security elements to be applied”, replacing the EECC’s principle-based approach with an enumerated control set.

Two EECC obligations survive the transition in modified form: risk management measures (now formalised as a written policy under Art.21(2)(a)) and incident notification to the competent authority (now restructured as a three-stage cascade under Art.23). The remaining 10 controls are new obligations with no direct EECC equivalent.

#	Control	EECC Art.40 Status	NIS2 Requirement	Evidence Required
1	Cybersecurity risk analysis and written security policy	Implicit — no documentation required	Written policy mandatory, Art.21(2)(a)	Approved risk management policy
2	Formal incident response procedure	Notification to NRA required	Documented detection, containment, eradication, and recovery process, Art.21(2)(b)	Incident response plan and CSIRT contact register
3	Business continuity plan with tested backup and disaster recovery	Not specified	BCP, backup management, disaster recovery, and crisis management, Art.21(2)(c)	Tested BCP with documented RTO/RPO
4	Supply chain security assessment for all direct suppliers	Not covered	Mandatory assessment of all direct suppliers and service providers, Art.21(2)(d)	Supplier security register and contractual security clauses
5	Vulnerability disclosure and patch management policy	Not covered	Mandatory, including coordinated vulnerability disclosure procedures, Art.21(2)(e)	VDP document and patch SLA table
6	Formal security effectiveness measurement	Not specified	Procedures to assess and measure effectiveness of cybersecurity measures, Art.21(2)(f)	KPI framework and measurement schedule
7	Cyber hygiene training programme for all staff	Not specified	Basic cyber hygiene practices and cybersecurity training, Art.21(2)(g)	Training records and awareness programme schedule
8	Cryptography and encryption policy	Not covered	Written cryptography policy mandatory, Art.21(2)(h)	Cryptography policy and key management procedure
9	Human resources security procedures and asset inventory	Not specified	HR security, access control policies, and asset management, Art.21(2)(i)	Asset register and HR offboarding procedure
10	Multi-factor authentication for privileged access	Not covered	MFA mandatory for network management interfaces, secured voice, video, text systems, Art.21(2)(j)	MFA deployment evidence and exception register
11	Management board approval and mandatory director training	Not covered	Board must formally approve Art.21 measures and oversee implementation; directors must complete cybersecurity training, Art.20	Board resolution, training completion records
12	24h/72h/1-month incident cascade reporting to CSIRT and NCA	Single notification to NRA	Three-stage cascade with specific content requirements at each stage, Art.23	Escalation procedure, CSIRT and NCA contact details

Three controls deserve particular attention for telecoms operators making the EECC transition.

Control 4 — supply chain — is the largest operational gap. ECN/ECS providers rely on a complex supply chain: radio access network equipment vendors, core network software suppliers, transmission infrastructure providers, and cloud-hosted network functions. NIS2 requires a documented security assessment of each direct supplier, including contractual clauses covering incident notification obligations and vulnerability disclosure. Operators with hundreds of suppliers will need a risk-tiering framework to make this manageable — typically categorising vendors by criticality to network continuity before applying full assessment effort to Tier A suppliers first. For a structured approach to NIS2 supplier risk tiers in telecoms, see the telecom supply chain security guide.

Control 10 — MFA — is architecturally complex for telecoms. Network management interfaces — OSS/BSS platforms, RAN element management systems, core network function orchestrators — often run on legacy protocols incompatible with modern MFA solutions. NIS2 does not grant exemptions for legacy architecture. Operators must remediate, implement compensating controls, or document accepted risk with management board sign-off under Article 20.

Control 11 — management liability — is structurally new. Under Article 20, the management body must formally approve the cybersecurity risk-management measures and oversee their implementation. If an incident reveals those measures were inadequate, the directors who approved them face personal liability exposure — including temporary bans from management functions under national transposition laws. This is not a process that can be retrospectively documented after an incident occurs.

5G Core Network Slicing: The Per-Slice Incident Detection Obligation

5G network architectures virtualise the physical network into isolated logical slices, each carrying a distinct traffic type: enhanced mobile broadband (eMBB) for consumer data, ultra-reliable low-latency communications (URLLC) for industrial IoT and connected vehicles, and massive machine-type communications (mMTC) for smart meters and large-scale sensor deployments. Each slice presents an independent attack surface with different criticality levels.

The compliance challenge is that NIS2 Article 21(2)(b) requires incident handling that covers detection, analysis, containment, eradication, and recovery. For 5G operators, this obligation must function at the slice level. A ransomware event that targets and disrupts a mission-critical URLLC slice — without affecting the eMBB consumer slice sharing the same physical infrastructure — still triggers Article 23 reporting for the URLLC service. Your incident detection system must be capable of identifying and characterising incidents per slice, not only at the aggregated network layer.

The isolation risk compounds this. Poor slice isolation enables cross-slice contamination: if a threat actor exploits a hypervisor vulnerability in the virtualisation layer, they can move laterally from a compromised consumer slice into a higher-value enterprise or IoT slice. Research on 5G/6G network slice security identifies nine distinct attack categories — including DoS, backdoors, and exploits — that operate across the RAN-to-core interface, with cross-contamination accelerating once slice boundaries fail. A slice-level incident can therefore rapidly become a network-level Article 23 notification covering multiple service types.

Practical per-slice monitoring requirements for NIS2 compliance:

• Slice-specific baseline profiles — define normal traffic and session patterns per slice type so anomaly detection can flag deviations without correlation delays across the full network
• Independent slice quarantine capability — the ability to isolate an affected slice without disrupting services on other slices running on the same physical infrastructure
• Slice-attributed incident logs — your 24-hour early warning to the national CSIRT must identify which service category or slice type is affected, not just the physical network element
• URSP access-control monitoring — the User Routing Selection Policy allows device applications to independently request access to specific slices; malware exploiting URSP represents a lateral movement vector that slice-agnostic monitoring will miss

MNOs deploying 5G Standalone (SA) architectures face these requirements today. Operators running 5G Non-Standalone (NSA) have more time, but per-slice detection capabilities should be included in SA migration planning rather than treated as a post-launch retrofit.

National Roaming Activation as a NIS2 Business Continuity Mechanism

Article 21(2)(c) requires business continuity plans covering backup management, disaster recovery, and crisis management. For mobile network operators, one of the most effective — and most underdocumented — BCP mechanisms is emergency national roaming: temporarily routing subscriber traffic through a competitor’s network when your own infrastructure is compromised, physically damaged, or experiencing sustained service disruption.

This is not a theoretical scenario. Prolonged network outages from cyberattacks, extreme weather events affecting cell tower infrastructure, or deliberate physical attacks have triggered emergency roaming activations coordinated through national telecoms regulators in several EU member states. Under NIS2, the BCP obligation means this must be pre-planned — with evidence that the plan was tested and approved at board level.

For national roaming to form a credible Article 21(2)(c) mechanism, four elements should be documented in the BCP:

• Pre-negotiated roaming agreements — emergency roaming cannot be negotiated during an active incident. Commercial and technical interconnect agreements with one or more alternative MNOs or MVNOs must exist before an incident occurs, with parameters covering subscriber authentication, traffic routing, and capacity limits.
• Documented trigger criteria — the BCP must specify the conditions that initiate roaming activation (for example: loss of core network function affecting more than a defined percentage of geographic coverage, or confirmed cyberattack causing sustained outage exceeding a defined threshold duration).
• Recovery Time Objective — the RTO for activating emergency roaming must be defined, documented, and tested in a tabletop exercise at minimum. NCAs are increasingly requesting evidence of BCP testing as part of supervisory assessments.
• NCA coordination procedure — most member states require the affected MNO to notify the national telecom authority before or immediately upon emergency roaming activation. This procedure must be documented in the BCP with named contact points and escalation timelines.

This element is absent from most generic NIS2 compliance templates. Operators who import a horizontal BCP framework built for enterprise IT into their telecoms compliance programme will miss it entirely. The supply chain of network continuity — roaming partners, NCA liaisons, interconnect vendors — is a telecommunications-specific BCP dimension with no equivalent in other sectors.

Enforcement, Director Liability, and Penalty Exposure

ECN/ECS providers are essential entities under NIS2 Annex I, placing them under the higher penalty ceiling in Article 34(4): administrative fines up to €10 million or 2% of total worldwide annual turnover, whichever is higher, for violations of Articles 21 or 23. For a mid-sized national operator with €500 million annual revenue, the 2% ceiling reaches €10 million before the absolute cap even applies. The directive requires fines to be “effective, proportionate and dissuasive” — meaning national authorities are expected to use the full range, not treat the maximum as a ceiling they never approach.

The personal liability provision in Article 20 is the control that most compliance programmes underweight. The management body must not only approve cybersecurity risk-management measures — it must actively oversee their implementation. If a significant incident subsequently reveals that the approved measures were inadequate or that implementation was not monitored, the directors who signed the approval are personally exposed. Several member state transpositions include provisions for temporary management bans for directors found to have been negligent in their Article 20 oversight role. NCAs have made clear in public guidance that management body accountability will be an active supervision priority — not an enforcement mechanism reserved for egregious cases.

The practical implication is that Article 20 compliance is not satisfied by a single board resolution. It requires a recurring governance cycle: the management body approves measures, receives progress updates on implementation, reviews incident reports, and approves material changes to the control framework. This cycle must generate documented evidence — board minutes, management reports, training completion records — that survives an NCA audit.

Directors at ECN/ECS providers who have not yet completed cybersecurity training as required by Article 20 are in breach of the directive’s governance requirements regardless of the technical maturity of their operator’s security controls. The training obligation applies to board-level executives, not only to CISO-level technical staff.

Article 23: The Three-Stage Incident Reporting Cascade

NIS2 Article 23 replaces the single notification to the NRA that EECC Article 40 required with a structured three-stage cascade. For ECN/ECS providers, understanding what constitutes a reportable significant incident is the first operational challenge, because no sector-specific Commission implementing regulation sets numerical significance thresholds for telecoms (as exists for DNS providers, cloud operators, and CDN providers). Telecom operators apply the general Article 23(3) criteria: number of users affected, duration of disruption, geographic spread, and impact on economic or societal activities.

As a practical rule, a network outage affecting a material proportion of subscribers in a geographic region for more than 30 minutes is likely to cross the significance threshold. Operators should not wait for certainty — the 24-hour clock starts at the moment of becoming aware of a potential significant incident, not when significance is confirmed.

Stage	Deadline	Required Content	Recipient
Early warning	24 hours from awareness	Nature of incident; whether malicious act suspected; potential cross-border impact	National CSIRT or NCA
Incident notification	72 hours from awareness	Updated information; initial severity and impact assessment; indicators of compromise (where available)	National CSIRT or NCA
Final report	1 month after 72h notification	Detailed description; root cause or threat type; applied and ongoing mitigations; cross-border impact	National CSIRT or NCA

For multinational operators with infrastructure in multiple member states, a single incident may require parallel reporting to each national competent authority where the disruption is felt. The early warning submitted to one NCA does not satisfy reporting obligations in another jurisdiction. Incident response procedures must include a cross-border assessment step — completed within the first hour of incident declaration — to identify all affected jurisdictions and initiate simultaneous reporting.

Operators should also note that the 24-hour clock is triggered by awareness of a potential significant incident, not confirmation. An automated monitoring alert flagging unusual network behaviour constitutes awareness. Deferring the clock to the point where technical teams have confirmed root cause is a common misinterpretation of Article 23(4) — and the misinterpretation NCAs are most likely to scrutinise in enforcement proceedings.

90-Day Implementation Roadmap

For ECN/ECS providers completing the EECC-to-NIS2 transition, the following sequence prioritises controls by risk exposure and implementation dependency.

Days 1–30: Governance and scope
Convene a board resolution formally approving the cybersecurity risk management programme under Article 20. Complete director cybersecurity training — this establishes the governance record that all subsequent compliance evidence sits beneath. Conduct the initial gap assessment against the 12 controls above, prioritising Controls 1, 4, 10, and 11 as the areas with no EECC legacy documentation to build on. Register with the national competent authority; most member states have opened self-registration portals, and some impose early registration deadlines that precede the full compliance timeline.

Days 31–60: Policy documentation
Draft the six priority policies: cybersecurity risk management policy, incident response plan, business continuity plan (including national roaming trigger criteria), supply chain security policy, cryptography policy, and access control policy including MFA standards. Initiate the asset inventory for network infrastructure, prioritising network management interfaces that require MFA remediation. Begin supplier security assessments for Tier A (critical) suppliers. Establish the KPI framework for Article 21(2)(f) effectiveness measurement.

Days 61–90: Technical controls and incident readiness
Deploy MFA for network management interfaces starting with the highest-risk access paths (core network orchestrators, OSS/BSS administration). Configure 5G slice-specific monitoring and document slice-attributed alert procedures. Conduct a tabletop exercise testing the 24-hour early warning cascade — confirm CSIRT contact details, test the cross-border jurisdiction assessment step. Document and test the national roaming activation procedure. Submit registration confirmation to NCA and file initial compliance posture documentation.

Frequently Asked Questions

Does Commission Implementing Regulation 2024/2690 apply to telecom operators?
Not directly, unless the telecom entity also operates services covered by the CIR: DNS providers, TLD registries, cloud computing services, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines, social networks, or trust service providers. ECN/ECS providers follow NIS2 Article 21 directly. Telecoms that additionally operate CDN or MSP services face CIR obligations for those services.

Are mobile virtual network operators (MVNOs) in scope?
Yes. MVNOs provide publicly available electronic communications services regardless of whether they own the underlying network. An MVNO is an ECS provider under NIS2 Article 2(2)(a)(i) and carries the same compliance obligations as an MNO, including all 12 controls in this checklist.

What counts as a “significant incident” for an ECN/ECS provider?
Unlike digital infrastructure entities (DNS, cloud, CDN), ECN/ECS providers have no sector-specific CIR significance thresholds. Operators apply the general Article 23(3) criteria: number of users affected, duration, geographic spread, and economic/societal impact. In practice, an outage affecting a substantial subscriber base for more than 30 minutes in a defined geographic area is likely to be significant. The 24-hour reporting clock runs from awareness, not from significance confirmation.

Does NIS2 compliance replace ISO 27001 certification?
No. NIS2 and ISO 27001 coexist. ISO 27001 certification can serve as evidence supporting several NIS2 Art.21 controls, and the Complete Toolkit maps all 76 templates to ISO 27001:2022 controls to support both frameworks from a single document set. However, NIS2 adds obligations (Art.20 management body accountability, Art.23 reporting cascade) that fall outside the ISO 27001 scope. Certification alone does not satisfy NIS2.

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. NIS 2 Directive (EU) 2022/2555, Article 2: Scope — nis-2-directive.com [linked inline above]
2. NIS 2 Directive, Article 21: Cybersecurity Risk-Management Measures — nis-2-directive.com
3. NIS 2 Directive, Article 20: Governance — nis-2-directive.com
4. NIS 2 Directive, Article 23: Reporting Obligations — nis-2-directive.com
5. NIS 2 Directive, Article 34: Administrative Fines — nis-2-directive.com [linked inline above]
6. BEREC Opinion on NIS2 and Electronic Communications (BoR 21/60) — berec.europa.eu
7. Telecom Sector and Digital Infrastructure — ENISA
8. Cross-Layer Security for 5G/6G Network Slices: SDN, NFV, and AI-Based Framework — PMC [linked inline above]