Telecom suppliers: the two ways NIS2 reaches you, and the one people miss

Most suppliers to telecom operators assume NIS2 reaches them only through their customer's contract. For managed service providers, cloud, data centre, DNS and trust services, there is a second route, and it is more prescriptive than the first.

Daniel Grigorovich
Daniel Grigorovich
Founder · 10 Sept 2026 · 6 min read
TelecomNIS2Supply chain
Telecom suppliers: the two ways NIS2 reaches you, and the one people miss

Who should read this: a company that sells connectivity, network software, managed services, ground segment equipment or field engineering into telecom or satellite operators, and has started receiving security clauses in contract renewals.

There are two separate routes by which NIS2 can reach you. Most suppliers know about the first and assume it is the only one. The second is more specific, more prescriptive, and it applies whether or not any customer ever asks.

Route one: your customer’s obligation, passed to you

Providers of public electronic communications networks and services are named in NIS2 Annex I. Operators are essential entities. That part is well understood.

What follows is Article 21(2)(d), which requires in-scope entities to manage security risks in their supply chain and in their relationships with direct suppliers. The operator cannot discharge that by hoping. They discharge it by putting terms in your contract, sending you questionnaires, and reserving audit rights.

So the obligation is legally theirs and commercially yours. You are not regulated, you are assessed. The mechanism is described in supply chain security under NIS2, and the practical shape of what arrives is covered in the security questionnaire you cannot answer.

This route has one useful property: it is negotiable. What you must do is satisfy a commercial counterparty, not a regulator, and the standard they apply is their own risk assessment.

Route two: you are in scope yourself, and more specifically than they are

Here is the part that surprises people.

NIS2 Annex I does not only cover telecom operators. It also covers digital infrastructure and ICT service management, and several of the categories in there describe ordinary supplier businesses:

  • Cloud computing service providers
  • Data centre service providers
  • Content delivery network providers
  • DNS service providers and TLD name registries
  • Managed service providers
  • Managed security service providers
  • Trust service providers

Read that list against what a telecom supplier actually does. A company that runs network operations for an operator is a managed service provider. A company that hosts a platform component is likely a cloud service provider. A company operating a teleport or a data centre is named outright. The categories are set out in essential and important entities compared, and the managed service case specifically in MSPs and MSSPs under NIS2.

If you land in one of those categories and meet the size thresholds, you are an entity in your own right. Nobody has to send you a contract clause for the obligation to exist.

The instrument that makes route two different

This is the detail worth knowing, because it changes how much interpretation you get to do.

For those digital infrastructure and ICT service management categories, the Commission adopted Implementing Regulation (EU) 2024/2690, in force since October 2024. It sets out the technical and methodological requirements in detail, across thirteen sections in its annex: security policy, risk management, incident handling, business continuity, supply chain security, acquisition and maintenance of systems, effectiveness assessment, cyber hygiene and training, cryptography, human resources security, access control, asset management and physical security.

It also defines what counts as a significant incident for each category, which matters because that is what triggers the reporting clock described in the NIS2 incident reporting timeline.

The practical consequence is a reversal of the usual pattern. General NIS2 gives you Article 21’s ten measures and leaves the detail to you, which is why the ten measures read as principles. If you are inside 2024/2690, you get a specification instead. Less room to interpret, and less room to under-do it.

There is a mirror-image benefit. A specification is something you can build against and demonstrate against, rather than arguing about proportionality with an authority after the fact.

Which route are you on

Three questions settle it in most cases.

Do you operate or manage systems for your customer, or do you sell them a product? Operating and managing points toward managed service provider. Selling a box or a licence generally does not.

Where is your main establishment, and where do you provide the service? For most of these categories jurisdiction follows the main establishment, which matters if you operate across several countries. That is set out in which NIS2 jurisdiction applies.

What is your headcount and turnover? The size thresholds do real work here. Many suppliers in the 20 to 250 band sit below the direct threshold and are reached only by route one. Many do not.

If you are unsure, the NIS2 scope checker takes a couple of minutes, and the wider test is in the NIS2 scope and applicability guide.

What operators actually ask for

Independently of which route applies, the questions arriving from operator procurement are consistent enough to prepare for.

Evidence, not assertions. Increasingly the clause asks for a certificate or an audit report rather than a completed questionnaire. ISO 27001 is what is usually named.

Incident notification to them, on a clock. Because their own clock starts when they learn, and they learn from you. Agree the notification path and the timescale in the contract rather than during an incident.

Sub-supplier visibility. Article 21 pushes them to consider dependencies behind their direct suppliers, so they push you to name yours. The mechanics are in supply chain risk assessment.

Encryption and access specifics. Telecom procurement asks harder technical questions than most sectors, particularly on encryption in transit and administrative access to systems carrying customer traffic, an area covered in encryption in telecom under NIS2.

What to build

The efficient answer is the same whichever route applies, which is the useful part.

Build an ISO 27001 aligned management system, scoped to the services you provide to regulated customers, and map both NIS2 and the implementing regulation onto the same control set. Doing that once rather than twice is the argument in doing ISO 27001 and NIS2 once instead of twice, and it holds even more strongly here because 2024/2690 is prescriptive enough to map cleanly.

Three additions specific to this position:

  1. Decide your route explicitly and write down why. Whether you are directly in scope is a question you will be asked by customers, by insurers and possibly by an authority. Having a reasoned answer on file is worth an afternoon.
  2. Treat the notification path as a control. Who tells the customer, how fast, through which channel, with what information. Most suppliers have this nowhere.
  3. Keep the sub-supplier register current. It is the question you cannot answer quickly if you have not maintained it, and it is now asked routinely.

For companies whose main business is running IT and software services, the IT and software page covers the wider position, and an independent security audit is the cheapest way to see how far you are from what the next contract renewal will ask.

The technical reality: a specification still stops short of working

2024/2690 is more detailed than anything else in NIS2, and it is still a specification of what must exist rather than a test of whether it works.

Its annex asks for vulnerability handling, logging, monitoring and backup. Each of those can be satisfied by a documented procedure and a record that it ran. A scanner producing monthly reports satisfies the vulnerability requirement while critical findings age. Log retention satisfies the logging requirement while nobody queries the logs. A tested backup satisfies the continuity requirement while nobody has timed a full restore against the recovery objective in the contract.

That gap matters more for a telecom supplier than for most businesses, because the thing on the other side of your interface is a network that other companies depend on, and because the operator’s own regulator judges them on outcomes rather than on your paperwork. If a problem in your systems reaches theirs, the question afterwards is how long it was there before anyone noticed.

Which means the investment that pays is not a thicker compliance file. It is detection and exposure management running continuously on the systems that touch your customer’s, producing findings that carry an owner and a deadline, and evidence that accumulates as it happens. That is the same argument as certified is not secure, pointed at a sector where the consequences travel further.

Daniel Grigorovich

Daniel Grigorovich · Founder

I believe that no business should suffer from "compliance checklists" or navigating vague regulatory text. While I still stand by the principle that all software products should be reliable and secure, I want to give companies a way to overcome the challenges faced when implementing these requirements.