NIS2 for telecom providers: scope and readiness

Does NIS2 apply to our telecom business, and what do we need to prepare?

NIS2 applies to providers of public electronic communications networks or services regardless of size, under Article 2 of Directive (EU) 2022/2555. Medium-sized and larger providers are essential entities under Article 3(1), which means they face ex ante supervision rather than the ex post model that applies to important entities. Smaller providers may still be in scope through the size-independent rules, so the first task is confirming which category your business falls into, not assuming it is exempt. The answer depends on your size under the SME definition, the Member State where you provide services, and whether you also run other in-scope services such as DNS or data center operations.

NIS2 creates no certificate of compliance. Your national competent authority oversees compliance through inspections, security audits, security scans and information requests, and can impose administrative fines. An independent auditor or assessor may produce a report you choose to commission, but that report is not a NIS2 certificate and the authority decides what it accepts. Confirm with your authority how it expects evidence to be presented, including whether it has published guidance or a notification process for your sector. Because the telecom security articles in the EECC were deleted with effect from 18 October 2024, your obligations now come from NIS2 and your national transposition law, so check that your legal team is working from the current text.

No cost or duration figures are supplied for this topic, so request them in writing. A fixed-scope quote should state which networks and services are covered, which Member State applies, the gap analysis method, the evidence to be produced, who performs the Article 23 reporting process, and what remains with your management and internal staff. Ask potential partners how their work maps to the Article 21 measures and to your authority's expectations. DeployOpen prepares systems, controls and evidence for assessments but does not issue reports or certificates. Before scoping, ask your legal counsel to confirm your entity classification and jurisdiction in writing, since both determine which obligations and fines apply.

How size and category decide essential or important status

For telecom providers, the first question is not whether NIS2 applies but how strictly. Four cases sort providers by category and size, and each one changes the supervision regime and the evidence a national authority can request. Confirm your position in each case before planning the program.

Telecom providers are in scope at any size

Under Article 2, providers of public electronic communications networks or services fall within NIS2 regardless of their size. A small provider cannot rely on the size cap to exit scope. Confirm that your network or service is offered to the public, not only used internally, because that distinction decides whether the entity is a telecom provider at all. Ask counsel to confirm how your national transposition law names these providers, since the wording of the national law governs your obligations.

Medium-sized and larger providers are essential

Under Article 3(1), medium-sized or larger public electronic communications providers are essential entities. Essential status brings ex ante supervision, meaning the authority can act before an failure occurs. Confirm headcount, annual turnover and balance sheet total against the thresholds in Recommendation 2003/361/EC, counting linked and partner enterprises as the Recommendation requires. A provider near the boundary should document its calculation, because the category it lands in sets its supervision intensity.

Small providers depend on national rules

Small telecom providers below the medium-sized ceilings are not automatically essential. Their status depends on the size ceilings in Recommendation 2003/361/EC and on how the Member State applies its national rules, which may bring them in as important entities. Confirm the entity's category in writing with the national competent authority or the transposition law, not from a secondary summary. Ask whether any national designation applies, because an important classification still carries reporting duties and fines.

Sole providers and critical entities

A telecom provider may also be a sole national provider of an essential service, or a critical entity under Directive (EU) 2022/2557, regardless of size. Either status places the entity in the essential category and can bring physical resilience duties alongside cyber duties. Confirm with the national authority whether you have been identified as a critical entity or as the sole provider of a service. Map both obligations into one program, since the authority may review them together and the same incident may trigger duties under both regimes.

Which Member State supervises a telecom provider under NIS2

For most entities, NIS2 jurisdiction follows the Member State where the entity is established. Providers of public electronic communications networks or services are the exception: under Article 26(1), they fall under the Member State where they provide their services. For a telecom provider, the question of which regulator oversees it therefore depends on where its customers are served, not only on where its headquarters sit. The first task is to map every Member State where the organization offers public electronic communications networks or services, and to record which legal entity or branch provides the service in each one.

The practical effect is that a provider operating in several Member States may face supervision in each of them. Each national authority can apply its own transposition law, its own registration or notification steps and its own supervisory approach, so a single group-wide security program is not automatically a single compliance file. Ask each country's competent authority, and check the national transposition law, how it expects in-scope providers to be identified, what it requires in registration and whether it adds obligations beyond the directive. The definition of a competent authority and its powers are set nationally, so this page does not list them. Confirm them directly with each national regulator and with the transposition text in force in each country.

Build the jurisdiction map into the NIS2 program before the first incident. For each country, record the service offered, the legal entity responsible, the competent authority, the incident reporting channel, the language and format of required filings, and the date the national rules applied to the provider. Review the map whenever a new market opens or a service is withdrawn, and keep it with the risk assessment so that a supervisor's first information request can be answered from one document. Where a telecom provider also falls under the telecom rules that were previously in the EECC, confirm with counsel which national authority handles which obligation.

What happens in the first 24 hours after a significant telecom incident

The sequence turns a suspected disruption into a documented decision, an early warning sent within the Article 23 window, and an evidence trail that a national authority can review. The organization makes each decision and files each report, while the implementation partner prepares the playbook, templates and logging that make those steps repeatable.

Detect and log the event
The network operations or security monitoring team identifies an anomaly, such as a service outage, a routing failure or signs of intrusion, and opens an entry in the incident log. The entry records the time of first detection, the detecting system or person, the affected services and the initial scope. The step is complete when the log entry exists with a unique identifier and a named incident owner. The incident owner is the organization's employee, not a supplier.
Triage and contain the incident
The on-duty team confirms whether the event is a genuine security or availability incident, limits its spread and preserves logs and configuration state before changes are made. Each action is timestamped in the incident log so the timeline can be reconstructed later. Containment is done when the affected services are isolated or stabilized and the log shows who approved each change. The partner's role is to have containment runbooks and log-preservation procedures ready before an incident occurs.
Assess whether the incident is significant
Management or the designated compliance lead compares the facts against the significance criteria that apply to the entity and records the outcome in a decision record. The record should state the criteria considered, the evidence used, the people consulted and the reasoning. Confirm with your national competent authority and the Implementing Regulation (EU) 2024/2690 criteria for public communications providers how significance is determined in your Member State. Ask your implementation partner to draft the decision template, but the determination remains yours.
Start the clock and alert the responsible executives
Once the organization is aware of a significant incident, the 24-hour early warning period under Article 23(4)(a) begins, so the time of awareness must be recorded precisely. The compliance lead notifies executives and the legal and data protection contacts, and confirms who will submit the report. The output is a timestamped awareness entry in the incident log. Be aware that the early warning is due without undue delay and in any event within 24 hours, so awareness timing is a legal question to confirm with counsel.
Prepare and submit the early warning
The compliance lead drafts the early warning using the authority's prescribed channel and format, covering whether the incident may be caused by unlawful or malicious acts or could have cross-border impact, based on the facts known at that time. The draft is reviewed by the incident owner and approved by an authorized signatory. The submission and its confirmation receipt are stored with the incident log. The organization owns the submission. The partner may prepare the template and the review checklist in advance.
Prepare the later notification and final report
Article 23 requires a further incident notification and a final report at later stages, which are covered in detail on the reporting obligations page. In the first 24 hours, the team should open a running evidence file, record every new fact and decision with timestamps, and assign owners for root cause analysis. The output is a structured evidence file that can feed the later notification without reconstruction from memory. Confirm the exact content and timing of each later stage with your national authority before relying on them.
Inform service recipients where required
Where the incident is likely to adversely affect the provision of services, Article 23 expects the entity to inform affected service recipients without undue delay, and to describe measures they can take in response. The communications lead prepares the notice, the legal reviewer checks it, and the record of who was informed and when is added to the incident log. Confirm with counsel how this duty interacts with any sector-specific rules and any GDPR breach notification obligations that may apply in parallel.

What encryption expectations mean for telecom networks and services

Recital 98 of NIS2 says that encryption, in particular end-to-end encryption, should be promoted and, where necessary, be mandatory for providers of public electronic communications networks or services. For a telecom provider, the practical question is what that expectation means for systems you run today, and the answer starts with a point of law: a recital guides how the Directive is read, but it does not itself impose a duty. The binding obligations come from the Article 21 risk-management measures, which include policies and procedures on the use of cryptography and encryption, and from the national law that transposes NIS2 in each Member State where you provide services. Treat the recital as a signal of where supervisors are likely to press, not as a standalone requirement you can cite or ignore.

A supervisor testing encryption will usually ask for documents and configuration evidence rather than a general assurance. Expect requests for a written encryption policy that states which data and communications are protected, at rest and in transit, and which algorithms and key lengths are approved. Key management records should show who generates, stores, rotates, escrows and revokes keys, and how that is logged. Transport settings for signaling, management interfaces, interconnection and customer-facing services, along with data-at-rest configuration for storage, databases and backups, should be provable from exports or configuration baselines. Every exception, such as a legacy element that cannot yet encrypt or a lawful interception interface, needs a documented risk acceptance, a named approver and an expiry date.

Confirm the national expectations before you design the program. Ask your competent authority, through a formal information request if needed, whether it expects end-to-end encryption for particular services, how it treats lawful interception obligations alongside encryption, and what format it wants exception records in. Ask your legal counsel to check how your national transposition law and any sector rules for electronic communications apply to your networks. An implementation partner can prepare the configuration exports, key management documentation and exception register, but the provider owns the policy decisions and the lawful interception position, and an independent assessor or the authority decides whether the evidence is sufficient.

What a telecom provider should have in place before a supervisory review

A supervisory review of a telecom provider tests whether the scope, governance, asset records, incident process and evidence agree with one another. The five areas below are the ones an authority is most likely to ask about first, and each one should be checkable on an ordinary working day rather than rebuilt the week before an inspection.

Documented scope and Member State

Record which of your networks and services are public electronic communications networks or services, whether you are medium-sized or larger, and whether you are essential or important under Article 3. Confirm the Member State where you provide services, since that determines the competent authority under Article 26(1). Re-check the classification when headcount or turnover changes, and keep the dated decision on file. Ask counsel to confirm how national transposition treats your entity type.

Management body oversight record

The management body must approve the Article 21 measures and oversee their implementation. In practice, keep minutes showing the approval, the risk findings presented, and the decisions taken on them. Check that named board members have completed the cybersecurity training NIS2 requires. An authority will often ask who approved the measures and when they were last reviewed, so the answer should come from a record, not from memory.

Network and service asset inventory

Maintain a current inventory of network elements, core and access systems, management interfaces, lawful interception and customer-facing services, with an owner, a location and a criticality rating for each. Reconcile it against configuration exports and the network management system at a set interval. Gaps between the inventory and the live network are the first thing a reviewer will test, because every Article 21 measure depends on knowing what must be protected.

Incident response plan with reporting clock

Your plan must let the team reach the 24-hour early warning, the 72-hour incident notification and the one-month final report under Article 23. Name the person who decides a significant incident, the contact route to the competent authority and the CSIRT, and the template for each report. Run a tabletop exercise against the clock at least once a year and record the times achieved. An untested clock is the most common gap in reporting evidence.

Evidence map for each Article 21 measure

Create one register that links each Article 21(2) measure to the policy, the control owner, the system or log that proves it, and the date it was last tested. Keep the register in a controlled repository with version history. Before a review, sample three or four measures and confirm that the evidence opens and matches the claim. Where ENISA guidance gives examples of evidence, use them as a starting checklist rather than a complete one.

Choosing how to deliver the NIS2 program for telecom operations

This table compares three ways to deliver a NIS2 program: fully in-house, with an implementation partner that prepares systems and evidence, and with a managed SOC covering monitoring and reporting deadlines. Read each row against your own team capacity, number of Member States, current maturity and 24-hour reporting coverage. In most telecom operations the decision is about who owns each obligation, because the organization remains accountable whichever model it chooses.

Decision factor	Fully in-house	Implementation partner	Managed SOC for reporting
When it fits	Mature security team already running Article 21 measures and a tested incident process	Team has capacity gaps or limited NIS2 experience, and needs systems and evidence prepared for supervisors	Limited 24-hour monitoring coverage, including nights and weekends, or no in-house incident triage
Team capacity needed	Dedicated staff for risk management, policies, monitoring, reporting and audits	Small internal team that owns decisions and reviews deliverables	Small team that handles escalations and decisions, with the provider monitoring alerts
Number of Member States	Usually workable for one jurisdiction; multi-country operators need clear national reporting routes	Useful where the same platform and evidence model must satisfy several national authorities	Confirm which national reporting channels and languages the provider can work with
What the organization must keep	Management body approval, risk decisions, supervisor contact, final reports and accountability	Management body approval, control ownership, sign-off on evidence, supervisor contact and reporting decisions	Incident classification authority, the decision to notify, supervisor contact, management oversight and GDPR decisions
Reporting deadline coverage	Depends on internal on-call design and tested escalation paths	Partner prepares playbooks and reporting templates; the organization still operates the process	Provider monitors and triages around the clock; confirm how the 24-hour early warning is triggered and who approves it
Evidence for supervisors	Produced and maintained by internal staff from day one	Prepared by the partner from your systems, reviewed and accepted by your staff	Monitoring logs and alert records only; policies and governance evidence still come from your organization
Questions for a written scope	Which controls are owned internally, which tools are used, and what training is funded	Which systems are in scope, who owns each evidence item, acceptance criteria and handover format	Coverage hours, escalation time targets, data retention, handling of telecom network data, and who approves notifications
Main risk to watch	Staff turnover and knowledge concentrated in a few people	Evidence that looks complete but reflects systems the team does not operate	Notification delays caused by unclear handover between the provider and internal decision makers

Who owns each part of NIS2 compliance for a telecom provider

The provider remains the legal owner of its NIS2 obligations. Under Article 20, the management body must approve and oversee the Article 21 cybersecurity risk-management measures, and its members can be held liable for infringements. Telecom providers that are public electronic communications networks or services fall within NIS2 regardless of size, so the duties sit with the provider itself, not with the vendors it hires.

Management body approval: Leadership approves the risk-management measures, the risk appetite and the budget, and records its oversight decisions.
Risk decisions: Internal owners accept, reduce or transfer risks identified in the risk assessment and decide which measures apply to which networks and services.
Incident reporting submissions: The provider makes the early warning, incident notification and final report to its competent authority within the Article 23 deadlines, and informs affected service recipients where required.
Operational ownership: Network, security and operations staff run monitoring, patching, access control and backups day to day.
Final accountability: Only the provider can answer to its authority for what its systems did and whether its evidence is accurate.

Check that your management body has documented training and approval records, and that named individuals hold each reporting duty.

What usually delays a telecom NIS2 program and how to avoid it

Most telecom NIS2 delays come from a small set of planning errors, not from missing technology. Each pitfall below pairs a common mistake with the step that prevents it and the evidence a supervisor will ask to see.

Relying on the repealed EECC rules

Articles 40 and 41 of the European Electronic Communications Code were deleted by NIS2 Article 43 with effect from 18 October 2024, so the security and incident rules for telecom providers now come from NIS2 and the national laws that transpose it. Programs built on the old telecom articles often cite the wrong legal basis in policies and reporting procedures. Check every policy, contract and incident procedure for references to the deleted articles and map each requirement to its NIS2 source. The evidence to show is a current legal-basis register that cites NIS2 and your national transposition law.

Mapping one Member State only

Under Article 26(1), electronic communications providers fall under the Member State where they provide services, so a provider serving customers in several countries can face several supervisors. Teams that map only their home country discover gaps when a second authority requests information. Inventory every Member State where services are provided, identify the national transposition law in each, and record which authority would supervise. The evidence to show is a jurisdiction matrix listing each country, its national rules and the competent authority contact.

No encryption evidence for in-scope services

Recital 98 says encryption, in particular end-to-end encryption, should be promoted and, where necessary, be mandatory for providers of public electronic communications networks or services. Many providers can describe encryption in design documents but cannot show which services, links and data stores it covers. Build an inventory of in-scope services with their encryption state in transit and at rest, and document where end-to-end encryption is used or why it is not. Keep configuration exports and key management records that prove the state. The evidence to show is a service-by-service encryption register with dated configuration evidence.

Incident reporting that depends on one person

Article 23(4)(a) requires an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident. If only one engineer or officer knows the reporting steps, the clock can run while that person is on leave or unreachable. Assign named alternates for each role, define who can decide significance, and keep the national authority contact details in the runbook. Test the chain with a timed exercise. The evidence to show is a reporting runbook with a role roster, alternates and records of exercises completed.

Supplier contracts that skip security duties

Telecom providers depend on hosting, managed network and support suppliers, and NIS2 obligations do not stop at the contract boundary. Standard supplier terms often lack incident notification timing, audit rights and encryption commitments, which leaves the provider unable to meet its own reporting deadlines. Review critical supplier agreements against the Article 21 measures, add notification and cooperation clauses, and classify suppliers by criticality. The evidence to show is a supplier register with risk tiers and signed clauses that pass duties down.

Common questions from telecom providers about NIS2

Are small telecom providers in scope of NIS2?

Yes. Providers of public electronic communications networks or services are covered regardless of size, so the small-enterprise ceilings that apply to most other sectors do not exclude them. Size still matters for classification. Under Article 3, medium-sized or larger public electronic communications providers are essential entities, while smaller providers are generally important entities. Before you classify your organization, confirm with your national competent authority or legal adviser how your Member State's transposition law applies the size thresholds to your service type, and check whether any sector-specific rule applies in addition. Ask for that confirmation in writing before you finalize your scope statement.

Do the telecom security articles of the EECC still apply?

No. NIS2 Article 43 deleted Articles 40 and 41 of the European Electronic Communications Code, Directive (EU) 2018/1972, with effect from 18 October 2024. The security and incident rules for telecom providers now come from NIS2 and its national transposition laws. Your existing obligations to notify security incidents and manage network security are therefore read against NIS2 Article 21 and Article 23. Review internal policies, incident playbooks and regulator correspondence that still cite the EECC articles, and confirm with your regulator which national measures replaced them.

Which Member State supervises a telecom provider that operates across borders?

For electronic communications providers, jurisdiction lies with the Member State where the provider offers its services, under Article 26(1). This differs from the general rule, which points to the Member State of establishment. A provider that serves customers in several Member States may therefore face supervision in more than one, so map every country where you provide services before assigning responsibility. Confirm with each relevant national authority how it treats cross-border service provision and whether any coordination arrangement applies to your group.

Is encryption mandatory for telecom providers under NIS2?

Not directly by the text of the Directive. Recital 98 says encryption, in particular end-to-end encryption, should be promoted and, where necessary, be mandatory for providers of public electronic communications networks or services. Encryption expectations therefore arrive through Article 21 risk management and through national transposition laws. Confirm with your national authority which encryption requirements apply to your networks and services, how they treat transport and signaling traffic, and what evidence they expect, such as key management records and configuration baselines.

What must a telecom provider do within 24 hours of a significant incident?

Under Article 23(4)(a), an entity must submit an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident. The early warning is an initial notice to the competent authority or CSIRT, not a full report. Prepare a short template, a named decision maker and a 24-hour clock in your incident playbook so the notice can go out before the facts are complete. Confirm with your national authority the exact content, the submission channel and whether a parallel notice is required for personal data breaches under GDPR.

Does NIS2 issue a certificate or audit report for telecom providers?

No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Essential entities face ex ante supervision and important entities face ex post supervision. Some customers or procurement teams may ask for an independent assessment or a certification such as ISO/IEC 27001, but that is a separate choice. Only an independent auditor or certification body can issue an assessment report or certificate. DeployOpen prepares systems, controls and evidence and does not issue reports or certificates.

Does the 2026 NIS2 proposal change telecom obligations?

The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), including a new small mid-cap category. These amendments are a proposal. They need approval by the European Parliament and the Council, and Commission pages updated through July 2026 still describe them that way. Until adoption, plan against the current Directive and its national transposition law. Monitor the proposal's progress and ask your national authority how any adopted changes would affect your classification, since the small mid-cap category could alter how some providers are treated.

How DeployOpen prepares a telecom provider's NIS2 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the telecom provider's own infrastructure, so the controls and evidence NIS2 asks for can be shown to the national authority. Our work prepares systems and evidence; the organization owns its controls and an independent assessor or the authority judges them.

How we scope

Written scope agreed before work starts, listing the networks, services and sites covered by the NIS2 program.
Mapping of in-scope systems, including core network, operations support and customer-facing services, to the Article 21 measures.
Confirmation with your legal team of the Member State where services are provided and which authority will supervise.

How we build

Deployment of self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks, with hardening baselines documented.
Encryption configuration for data in transit and at rest, including key management choices your team approves.
Logging, access control and backup routines set up so that incident timelines and recovery steps can be reconstructed.

How we hand over

Documentation of configurations, runbooks and control owners, written so your staff can operate and audit them without us.
Evidence packs organized by Article 21 measure, showing what each control does and where its records are kept.
Test results from security testing of applications, infrastructure and incident response exercises, with remediation tracked to closure.

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover.
Periodic review of evidence against changes in national transposition rules and the implementing regulation's requirements.
Support for your own reporting to the authority, while the 24-hour, 72-hour and one-month decisions stay with your management and incident team.

NIS2 for telecom providers