NIS2 digital infrastructure: what applies to cloud, data centre, DNS, CDN and IXP providers

NIS2 names nine types of digital infrastructure provider in Annex I, point 8. DNS service providers, TLD name registries, trust service providers and public telecom providers are covered at any size; cloud, data centre, CDN and IXP providers from medium size. Six of the nine must also meet the technical requirements and incident thresholds of Implementing Regulation (EU) 2024/2690.

This guide covers scope, definitions, size and status, jurisdiction, the implementing regulation, incident thresholds, DNS, telecom, what smaller providers must close, and a checklist.

Entity type (Annex I, point 8)	Size rule	Status	Jurisdiction (Art. 26)	CIR 2024/2690
Internet Exchange Point providers	Medium and above	Large: essential. Medium: important	Establishment	No
DNS service providers, excluding operators of root name servers	Any size	Essential	Main establishment	Yes
TLD name registries	Any size	Essential	Main establishment	Yes
Cloud computing service providers	Medium and above	Large: essential. Medium: important	Main establishment	Yes
Data centre service providers	Medium and above	Large: essential. Medium: important	Main establishment	Yes
Content delivery network providers	Medium and above	Large: essential. Medium: important	Main establishment	Yes
Trust service providers	Any size	Qualified or large: essential. Others: important	Establishment	Yes
Providers of public electronic communications networks	Any size	Medium or large: essential. Small: important	Where services are provided	No
Providers of publicly available electronic communications services	Any size	Medium or large: essential. Small: important	Where services are provided	No

Member States can also bring smaller entities into scope, for example a sole national provider of an essential service (Article 2(2)(b) to (e)).

Which digital infrastructure providers does NIS2 cover?

The table’s first column gives the nine types in the words of Annex I, which lists the sectors of high criticality. Three related groups sit elsewhere.

Managed service providers and managed security service providers are Annex I, point 9, covered in NIS2 for MSPs and MSSPs. Online marketplaces, search engines and social networks are Annex II digital providers. Domain registrars and resellers are in neither annex: Article 2(4) covers them regardless of size, and Article 3(3) lists them separately from essential and important entities.

How does NIS2 define cloud, data centre, DNS, CDN and IXP services?

Article 6 decides whether a service line is in scope.

• DNS, Art. 6(19): a hierarchical distributed naming system that identifies internet services and resources so that end-user devices can reach them.
• DNS service provider, Art. 6(20): an entity that provides “(a) publicly available recursive domain name resolution services for internet end-users; or (b) authoritative domain name resolution services for third-party use, with the exception of root name servers”.
• TLD name registry, Art. 6(21): an entity delegated a specific TLD that administers it, including registration and technical operation, in-house or outsourced, unless it uses the TLD names only for its own use.
• Cloud computing service, Art. 6(30): “a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources, including where such resources are distributed across several locations”.
• Data centre service, Art. 6(31): a service covering structures dedicated to the centralised accommodation, interconnection and operation of IT and network equipment for data storage, processing and transport, with the facilities for power distribution and environmental control.
• Content delivery network, Art. 6(32): geographically distributed servers that ensure high availability, accessibility or fast delivery of digital content and services to internet users, on behalf of content and service providers.
• Internet exchange point, Art. 6(18): a facility interconnecting more than two autonomous systems, mainly to exchange internet traffic, without requiring traffic between two participants to pass through a third, and without altering it.

Recital 35 excludes “in-house corporate data centres owned and operated by the entity concerned, for its own purposes”. On the wording of Article 6(20), a company running authoritative DNS only for its own domains is not a DNS service provider. A hosting company running it for customer domains is.

Does NIS2 apply to small cloud, data centre and DNS providers?

Article 2(1) covers entities that are medium-sized or larger under Recommendation 2003/361/EC: in practice 50 or more staff, or annual turnover and balance sheet total both above €10 million. Partner and linked enterprises count, so a 30-person subsidiary of a large group can be large.

Article 2(2)(a) removes the size test for three groups: (i) providers of public electronic communications networks or publicly available electronic communications services; (ii) trust service providers; (iii) TLD name registries and DNS service providers. A two-person company running authoritative DNS for customers is in scope.

Status follows Article 3(1). Annex I entities above the medium-sized ceilings (250 or more staff, or turnover above €50 million and balance sheet above €43 million) are essential. Qualified trust service providers, TLD name registries and DNS service providers are essential “regardless of their size”. Medium-sized telecom providers are essential too. Other Annex I entities in scope are important by default (Article 3(2)).

The label changes supervision, not obligations. Essential entities are supervised in advance, including on-site inspections and security audits (Article 32); important entities after the fact (Article 33). Maximum fines are at least €10 million or 2% of worldwide turnover for essential entities, €7 million or 1.4% for important ones, whichever is higher (Article 34).

Which country supervises a cloud, data centre or DNS provider?

By default, the Member State where the entity is established (Article 26(1)). Telecom providers fall under each Member State where they provide services. DNS service providers, TLD name registries, domain registration services, cloud, data centre and CDN providers, MSPs, MSSPs and the Annex II digital providers fall under the Member State of their main establishment, fixed in three steps (Article 26(2)):

1. where decisions on cybersecurity risk-management measures are predominantly taken in the EU;
2. if that cannot be determined, or they are not taken in the EU, where cybersecurity operations are carried out;
3. failing that, the establishment with the most employees in the EU.

Providers of those types based outside the EU must designate a representative in a Member State where they offer services, and fall under it (Article 26(3)). IXPs and trust service providers follow the general establishment rule. More in NIS2 jurisdiction and main establishment.

Article 27 adds an ENISA registry for the same types, important as well as essential: name, type, establishments or representative, contacts, Member States served and IP ranges, due by 17 January 2025, changes within three months.

What does Implementing Regulation (EU) 2024/2690 require?

Article 21(5) of NIS2 required the Commission to set technical and methodological requirements for the six types marked Yes in the table, plus MSPs, MSSPs, online marketplaces, search engines and social networks. Implementing Regulation (EU) 2024/2690 was adopted on 17 October 2024 and has applied directly in every Member State since 7 November 2024.

• The Annex turns the ten Article 21(2) measures into 13 sections, from security policy to environmental and physical security.
• Article 2(2) applies proportionality. Where the Annex says “where appropriate”, “where applicable” or “to the extent feasible” and you do not apply a requirement, you must document your reasoning “in a comprehensible manner”.

When is an incident significant for cloud, data centre, DNS and CDN providers?

Under Article 3(1) of the implementing regulation, an incident is significant if it meets any general criterion:

• it has caused or could cause direct financial loss above €500,000 or 5% of annual turnover, whichever is lower;
• it has caused or could cause exfiltration of trade secrets, a death, or considerable damage to health;
• successful, suspectedly malicious and unauthorised access occurred that is capable of causing severe operational disruption;
• incidents recur at least twice within six months with the same apparent root cause and together pass the financial threshold (Article 4);
• it meets an entity-specific criterion in Articles 5 to 14.

Scheduled maintenance does not count (Article 3(2)). Below, “data compromised” means the integrity, confidentiality or authenticity of data related to the service is compromised.

Entity type	Art.	Availability	Data and physical access
DNS service providers	5	Resolution completely unavailable for more than 30 minutes; average response time above 10 seconds for more than one hour	Authoritative data compromised, except misconfiguration of fewer than 1,000 domain names and no more than 1% of those managed
TLD name registries	6	Authoritative resolution completely unavailable, no minimum duration; average response above 10 seconds for more than one hour	Data on the TLD’s technical operation compromised
Cloud computing	7	Completely unavailable for more than 30 minutes; limited for more than 5% of EU users or more than 1 million, whichever is smaller, for more than one hour	Data compromised by suspected malicious action, or affecting more than 5% of EU users or 1 million, whichever is smaller
Data centre	8	Completely unavailable, no minimum duration; limited for more than one hour	Data compromised by suspected malicious action; physical access to a data centre compromised
Content delivery network	9	As cloud	As cloud
Trust services	14	Completely unavailable for more than 20 minutes; unavailable more than one hour per calendar week; limited for more than 1% of EU users or relying parties, or 200,000, whichever is smaller	Restricted physical access compromised; data compromised for more than 0.1% of users or relying parties, or 100, whichever is smaller

Reporting then follows Article 23 of NIS2: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month of the notification. Trust service providers send the incident notification within 24 hours.

What does NIS2 require of DNS service providers and TLD registries?

They apply the Article 21 measures at the depth of the implementing regulation, under essential-entity supervision whatever their size. Two points stand out.

• Integrity counts on its own. A hijacked record fixed in ten minutes can still meet the data criterion.
• DNSSEC is not named. Neither Article 21 nor Articles 5 and 6 of the implementing regulation mention it; its recital 8 says the Commission should support a multi-stakeholder forum to identify “best available standards” for DNS security. In practice, signing zones is a direct protection for authoritative data. It gives origin authentication and integrity, not confidentiality (RFC 4033).

Article 28 adds registration data duties for TLD registries and registrars: collect accurate and complete data with verification procedures, publish non-personal data without undue delay after registration, and answer lawful and duly substantiated access requests within 72 hours. Detail in WHOIS data under NIS2.

What about telecom and trust service providers?

NIS2 Article 43 deleted Articles 40 and 41 of the European Electronic Communications Code (Directive (EU) 2018/1972) with effect from 18 October 2024, so telecom providers’ security and incident rules now come from NIS2 as transposed nationally. See encryption under NIS2 and, for their suppliers, how NIS2 reaches telecom suppliers.

Trust service providers have the 24-hour notification above and their own thresholds in Article 14.

What do the rules leave open for a small cloud or hosting provider?

Which type you are. A VPS platform is most likely a cloud service, colocation a data centre service, and managed hosting on top can make you an MSP. One outage can trigger two sets of criteria. An authority will ask how you drew the map.

Who counts as a user. Article 3(3) counts contracted customers and the people associated with business customers who use the service. Most small providers know the first number, not the second. Fix the counting method before the incident.

What “limited” means. Complete unavailability is measurable. Limited has no number: doubled latency in one region, an API failing for some tenants. Monitoring has to separate complete from limited, per service, with timestamps, because 30 minutes and one hour decide whether you report.

Physical access. For a data centre service provider, compromised physical access is a significant incident in itself, so access logs are incident evidence.

The reasoning file. Under Article 2(2), every “where appropriate”, “where applicable” or “to the extent feasible” requirement you do not apply needs written reasons, and those go stale when the service changes.

A sensible starting point is one record per service line:

SERVICE LINE RECORD (NIS2 digital infrastructure)
Service line:          e.g. VPS / object storage / colocation / DNS
Entity type:           cloud | data centre | DNS | CDN | MSP | none
Art. 6 test met:       yes / no, one-line reasoning
Size (group figures):  micro | small | medium | large
Main establishment:    Member State, Art. 26(2) step 1, 2 or 3
Incident criteria:     CIR Art. 3, 4 and 5 to 9 or 14
User count method:     Art. 3(3) basis, last counted (date)
Outage evidence:       monitor that shows complete vs limited
Owner, last review:    name, date

Closing these gaps takes monitoring that measures what the thresholds measure, and evidence collected from the systems, not assembled before an audit. That is how the CloudSoul platform works: automated collection, with human-in-the-loop expertise for the judgement calls. The sector view is on the ICT sector page, the full programme on NIS2 compliance.

NIS2 digital infrastructure checklist

• Map every service line to an Annex I, point 8 type, or none, using Article 6.
• Record your main establishment and the Article 26(2) step that fixes it.
• Keep your Article 27 registry data current, including IP ranges.
• Write the implementing regulation’s thresholds and a user-counting method into your incident procedure.
• Make monitoring distinguish complete from limited unavailability.
• Document every “where appropriate” decision with reasons.
• Test the 24-hour early warning against a realistic outage.

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 6, 21, 23, 26, 27, 28, 32, 33, 34 and 43, recital 35, Annex I, EUR-Lex; article text at nis-2-directive.com.
• Commission Implementing Regulation (EU) 2024/2690, Articles 2 to 9, 14 and 16, recital 8 and Annex, EUR-Lex.
• Commission Recommendation 2003/361/EC on the definition of SMEs, EUR-Lex.
• RFC 4033, DNS Security Introduction and Requirements, RFC Editor.

Frequently asked questions