The CIR 2024/2690 Compliance Checklist: What DNS Operators, IXPs, Data Centres, and CDN Providers Must Document Before Their NIS2 Audit

Most NIS2 digital infrastructure checklists commit the same error: they treat DNS operators and CDN providers identically, as though a 30-minute DNS outage and a one-hour CDN degradation affecting five percent of EU users trigger the same reporting clock. Under Commission Implementing Regulation (EU) 2024/2690, they do not.

CIR 2024/2690 is the binding rulebook for digital infrastructure compliance under NIS2. It assigns entity-specific incident thresholds to each provider type. A TLD registry faces a stricter outage threshold than a DNS operator — any complete unavailability is immediately significant, with no 30-minute grace period. A data centre triggers a significant incident the moment physical access is compromised, regardless of service availability. Internet exchange points have no dedicated threshold article in the CIR at all, a distinction most compliance guides fail to flag.

This checklist maps the mandatory requirements from CIR 2024/2690 and the recommended guidance from the ENISA Technical Implementation Guidance (June 2025) across the six digital infrastructure entity types covered by NIS2 Annex I. Each section distinguishes what is binding from what is recommended, so you know exactly what your national competent authority expects to find. For the broader CIR framework overview, see the guide to NIS2 digital infrastructure compliance.

Six Entity Types Under NIS2 — and Why Each Faces a Different Compliance Framework

NIS2 Directive (EU) 2022/2555 Annex I classifies six digital infrastructure entity types as in scope for its high-criticality sector obligations [8]. CIR 2024/2690 adds entity-specific incident thresholds for five of those six — IXPs are the exception, as the table below shows, and the entity-specific section explains why.

Entity Type	NIS2 Annex I Status	CIR 2024/2690 Incident Article	Default Tier
DNS service providers	Essential — regardless of size	Article 5	Essential
TLD name registries	Essential — regardless of size	Article 6	Essential
Content delivery network (CDN) providers	Annex I — size threshold applies	Article 9	Important or Essential
Internet exchange points (IXPs)	Annex I — size threshold applies	No dedicated CIR article — NIS2 Art. 23 general criteria apply	Important or Essential
Data centre service providers	Annex I — size threshold applies	Article 8	Important or Essential
Cloud computing service providers	Annex I — size threshold applies	Article 7	Important or Essential

DNS providers and TLD registries qualify as essential entities regardless of headcount or annual turnover — the highest NIS2 penalty ceiling applies from the first employee and the first day of operation in scope. CDN providers, IXPs, data centres, and cloud providers are classified by size: large enterprises (250+ employees or €50 million+ in annual turnover) reach essential entity status; medium enterprises (50–249 employees or €10 million–€50 million) are important entities.

The compliance obligations under NIS2 Article 21(2)(a)–(j) apply equally to all six entity types [8]. What differs is the incident significance threshold that triggers your Article 23 reporting clock, and that threshold varies substantially across entity types, as the table in the entity-specific section details. For the full Article 21 measure breakdown, see NIS2 requirements explained.

Mandatory vs. Recommended — CIR 2024/2690 and the ENISA TIG June 2025

Compliance for digital infrastructure operates on two levels. CIR 2024/2690 is legally binding — a directly applicable EU regulation that entered into force in November 2024 and requires no national transposition [7]. The ENISA Technical Implementation Guidance, published June 2025, is non-binding: it explains how to implement CIR requirements and provides examples of evidence that auditors may accept, but competent authorities assess compliance against the CIR Annex, not the ENISA document [6].

The practical difference matters when allocating implementation effort. The table below separates what the CIR mandates from what ENISA recommends as good practice:

Area	CIR 2024/2690 — Binding	ENISA TIG June 2025 — Recommended
Logging and monitoring	Event logs required (CIR Annex §3)	SIEM with centralised log collection
Backup and recovery	Documented recovery procedures (§4)	3-2-1 rule with at least one immutable copy
Access control and MFA	Appropriate authentication and access rights management (§11)	MFA mandatory for all privileged and remote access — “no exceptions”
Cryptography	Cryptographic policy and key lifecycle management (§9)	Post-quantum cryptography roadmap; cryptographic agility approach
Network and DNS security	Apply best practices for DNS and internet routing security (§6.7.2(l))	RPKI filtering with “reject INVALID, accept UNKNOWN” posture
Secure development	Secure development standards and configuration management (§6)	Automated SAST/DAST integrated into CI/CD pipeline
Effectiveness assessment	Measurement methodology documented (§7)	Quarterly KRI reviews plus annual independent audit

ENISA permits simplified independent review for smaller entities where full third-party audits are disproportionate — but the derogation requires documented justification. The key principle: ENISA alignment strengthens your supervisory position, but does not substitute for documented CIR compliance.

The Common Checklist — 13 CIR Annex Controls Every Digital Infrastructure Entity Must Implement

All six entity types in this article must implement the technical and methodological requirements in the CIR 2024/2690 Annex. The 13 sections apply proportionately — implementation depth scales with entity size and societal risk exposure — but no section is optional. For the full CIR 2024/2690 implementation guide, including section-by-section control detail, see the dedicated overview.

§1 — Security Policy

• Information security policy approved by senior management, with a defined review cycle (annual minimum)
• Policy hierarchy documented: top-level information security policy supported by domain-specific sub-policies
• Roles, responsibilities, and resources for security formally assigned in writing

§2 — Risk Management

• Risk assessment methodology documented with defined scope, criteria, and risk appetite
• Risk register maintained with treatment plan and residual risk acceptance records
• Review cycle defined — triggered by significant changes and post-incident events, not annual cycle alone

§3 — Incident Handling

• Incident detection, analysis, containment, and recovery procedures documented
• Post-incident review process with corrective action tracking
• Incident log maintained with significance classification for each entry
• Article 23 notification workflow documented — 24-hour early warning, 72-hour notification, 30-day final report. See Article 23 incident notification for the full three-phase procedure.

§4 — Business Continuity

• Business Impact Analysis (BIA) completed for all critical services
• Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) defined and tested
• Crisis management plan documented and exercised with results recorded
• Backup policy implemented — ENISA recommended: 3-2-1 approach with at least one immutable copy [6]. See NIS2 business continuity requirements.

§5 — Supply Chain Security

• Supplier directory maintained with classification by criticality and level of access to your systems
• Security requirements included in all supplier contracts, with right-to-audit clause for critical suppliers
• Ongoing supplier compliance monitoring documented with review cycle

§6 — System Acquisition and Maintenance

• Secure development lifecycle (SDLC) requirements documented for internally built systems
• Patching policy with SLAs defined by severity (critical, high, standard)
• Configuration management standards applied — hardened builds per CIS Benchmarks or equivalent
• Malware protection deployed on all applicable systems

§7 — Effectiveness Assessment

• Security measurement methodology documented with defined KPIs or KRIs per domain
• Assessment results feed into the risk management cycle
• Annual independent review of the security programme — ENISA recommends third-party audit; simplified review available for smaller entities with documented justification [6]

§8 — Cyber Hygiene and Training

• Role-based training programme for all staff with security-relevant responsibilities, with completion records
• General security awareness programme for all staff
• Management-specific cybersecurity training delivered and recorded

§9 — Cryptography

• Approved cryptographic algorithm list maintained with a defined review and update cycle
• Key lifecycle management documented — generation, storage, rotation, and revocation procedures
• Post-quantum cryptography roadmap under development (ENISA recommended — begin now). See cryptography requirements.

§10 — HR Security

• Background screening policy for roles with access to critical systems or sensitive data
• Joiner-Mover-Leaver process with prompt access revocation on departure or role change
• Security responsibilities included in employment terms for relevant roles

§11 — Access Control

• Access rights managed on least-privilege and need-to-know basis across all systems
• Privileged account inventory maintained with a documented quarterly review cadence (ENISA recommended)
• Multi-factor authentication required for all privileged and remote access — see MFA requirements. ENISA: no exceptions [6].

§12 — Asset Management

• Asset inventory covering all network and information systems — hardware, software, and cloud services
• Asset classification scheme applied with defined owners for each critical asset
• Removable media management controls in place

§13 — Physical and Environmental Security

• Physical perimeter controls at all facilities hosting critical systems
• Environmental monitoring — temperature, humidity, power continuity — with automated alerting
• Visitor access management with time-stamped entry and exit records

Entity-Specific Incident Thresholds Under CIR 2024/2690 Articles 5–9

The most operationally significant difference between entity types is not in the 13 Annex sections — those apply across all covered entities. It is in the incident thresholds that determine when your Article 23 reporting clock starts. The table below maps the binding threshold for each entity type from CIR 2024/2690 Articles 5–9.

Entity Type	CIR Article	Complete Outage Threshold	Partial Degradation Threshold	Data / Physical Integrity Trigger
DNS service providers	Art. 5 [1]	Complete unavailability > 30 minutes	Response time > 10 sec for > 1 hour	Integrity/confidentiality breach — exception: < 1,000 domains or < 1% of managed domains from misconfiguration
TLD name registries	Art. 6 [2]	Any complete unavailability — no 30-minute grace period	Response time > 10 sec for > 1 hour	Any integrity/confidentiality breach — no minimum threshold
Cloud computing	Art. 7 [3]	Complete unavailability > 30 minutes	> 5% of EU users OR > 1 million EU users (smaller number) for > 1 hour	Suspected malicious compromise (any scale) OR data breach > 5%/1M users
Data centre operators	Art. 8 [4]	Any complete unavailability — no time grace	Limited availability for > 1 hour	Suspected malicious data compromise; OR physical access breach (service can be fully available)
CDN providers	Art. 9 [5]	Complete unavailability > 30 minutes	> 5% of EU users OR > 1 million EU users (smaller number) for > 1 hour	Suspected malicious compromise (any scale) OR data breach > 5%/1M users
Internet exchange points	No dedicated CIR article [7]	NIS2 Art. 23 general significance criteria apply — no CIR entity-specific thresholds

Two thresholds carry the most operational weight. TLD registries face the strictest outage trigger: any complete unavailability is immediately significant, with no 30-minute assessment window before the Art. 23 clock starts [2]. Data centres carry a physical trigger that other entity types do not: a physical access breach is a significant incident under Article 8 even when service availability remains unaffected [4].

IXPs sit outside the CIR incident threshold framework. They are essential entities under NIS2 Annex I and must implement Article 21 measures. Because CIR 2024/2690 does not include a dedicated IXP incident article, significance is assessed under the general NIS2 Article 23(3) criteria — substantial disruption of services and financial loss. For BGP incidents specifically, the Article 23 awareness clock starts when a monitoring alert fires, not when root cause is confirmed. See IXP security compliance for BGP-specific controls including RPKI and MANRS filtering.

Under CIR Article 4, incidents individually below these thresholds can aggregate into a reportable event: multiple sub-threshold incidents within a six-month window are treated as a single significant incident if they collectively meet the significance criteria [7]. A complete incident log with impact data for every event is the minimum precondition for making this assessment correctly.

Entity-Specific Additional Controls

Beyond the 13 common sections, the CIR Annex and ENISA TIG identify controls with particular relevance to each infrastructure type. These reflect where the threat profile differs by entity type.

DNS service providers

• DNSSEC signing enabled for all authoritative zones under management — CIR Annex §6.7.2(l) requires applying “best practices for the security of the DNS”
• BGP/RPKI filtering implemented for internet routing security of traffic originating from and destined to the network (§6.7.2(l))
• Automated BGP monitoring alerts configured — the Art. 23 awareness clock starts when an alert fires, not at root-cause confirmation
• Recursive resolver abuse controls documented — DDoS reflection and DNS amplification defences

TLD name registries

• Registry lock service available for domain objects — an integrity breach triggers Art. 6 immediately with no minimum domain count
• Backup name server infrastructure with geographic distribution to prevent single points of failure
• Incident notification protocol prepared for any complete outage — no 30-minute threshold before the NCA notification clock starts [2]
• Domain registration data integrity monitoring with real-time alerting on abnormal write patterns

Internet exchange points

• Route filtering policy documented — IRR or RPKI-based filtering per MANRS requirements
• Anti-spoofing measures implemented at the peering layer
• BGP session monitoring with defined escalation chain from alert to NIS2 notification assessment
• Physical and environmental controls at colocation facilities — NIS2 Art. 21(2)(e) network security applies at the physical layer

Data centre service providers

• Time-stamped physical access log for all facilities — physical access breach is a standalone significant incident trigger under Art. 8, independent of service status [4]
• Power redundancy configuration documented with UPS and generator test records and results
• Cooling failure detection with automated alert and defined escalation to incident response
• Customer data segregation controls documented — suspected malicious compromise of stored data triggers Art. 8 regardless of availability

CDN providers

• DDoS mitigation capacity documented and tested against threshold scenarios (5%/1M EU users)
• Cache poisoning prevention controls in place with detection alerting
• User impact monitoring configured with alerting at the 5%/1 million EU user threshold — the Art. 9 partial-degradation trigger [5]
• Origin shield architecture documented for resilience in bypass scenarios

Cloud computing service providers

• Multi-tenancy incident boundary controls documented — demonstrating that an incident in one tenant environment does not propagate cross-tenant is a core Art. 7 audit expectation [3]
• Shared Responsibility Matrix defined per service model (IaaS / PaaS / SaaS) and available to customers
• Customer impact monitoring configured with alerting at the 5%/1 million EU user threshold
• Outage and incident communication to customers — SLA obligations and Art. 23 coordination procedures aligned

Evidence Requirements: What Competent Authorities Expect

The 13 CIR Annex sections describe what to implement. Supervisory audits test whether you can demonstrate implementation with documentary evidence. The following evidence types are most commonly requested across NCA audit programmes for digital infrastructure entities:

• Risk register and treatment plan — current version with management approval date, residual risk decisions, and review history
• Information security policy hierarchy — date of last review, senior management sign-off evidence, and distribution records
• Incident log with significance classification — all incidents classified with rationale; significant incidents cross-referenced to Art. 23 notifications submitted
• Training completion records — role-based training matrix with individual completion dates
• Access rights review output — periodic privileged account review evidence; MFA activation records for all remote access accounts
• Supplier assessment records — annual review of critical suppliers; security clauses visible in contracts
• Independent audit or penetration test report — remediation plan with status tracking against findings
• Business continuity test records — BIA, validated RTOs/RPOs, and exercise results with lessons learned

The NIS2 compliance checklist covers the full documentation framework mapped to each Art. 21(2) measure.

Penalty Exposure for Digital Infrastructure Entities

Administrative fines for NIS2 non-compliance are set in NIS2 Article 34(4) and (5) [9]. DNS providers and TLD registries qualify as essential entities regardless of size — the essential entity ceiling applies from the first employee. CDN providers, IXPs, data centres, and cloud providers reach essential entity status only above the standard size threshold (250+ employees or €50 million+ turnover).

Entity Classification	Maximum Fine (Art. 34)	Applies
Essential entities — DNS providers and TLD registries (regardless of size); CDN, IXP, data centres, and cloud above the size threshold	€10 million OR 2% of global annual turnover	Whichever is higher
Important entities — data centres and cloud below the 250-employee / €50M threshold	€7 million OR 1.4% of global annual turnover	Whichever is higher

These are maximum ceilings. Competent authorities apply proportionality, and first-time breaches for newly scoped entities typically trigger corrective orders before financial penalties. The more immediate risk is supervisory: NCA audit findings against digital infrastructure operators are frequently published, and enforcement has accelerated across the EU since mid-2025.

Frequently Asked Questions

Are IXPs subject to CIR 2024/2690?

IXPs are essential entities under NIS2 Annex I and must implement Article 21(2)(a)–(j) security measures. CIR 2024/2690 does not include a dedicated incident threshold article for IXPs — unlike DNS operators (Art. 5), data centres (Art. 8), and CDN providers (Art. 9) [7]. IXPs assess incident significance using the general NIS2 Article 23(3) criteria: substantial disruption of services and financial loss. Competent authorities have not issued sector-specific IXP incident threshold guidance as of June 2026.

When does a recurring sub-threshold incident become reportable?

Under CIR Article 4, incidents that individually fall below the significance threshold aggregate into a reportable event if, within a six-month window, they collectively meet the criteria for your entity type [7]. Maintain a complete incident log with timestamps, impact data, and significance assessment for every event — this record is what enables the aggregation analysis.

Does ENISA TIG compliance satisfy CIR 2024/2690?

No. The ENISA Technical Implementation Guidance (June 2025) is non-binding [6]. It explains implementation approaches and provides examples of evidence that auditors may accept. Competent authorities assess compliance against the CIR Annex itself. ENISA TIG alignment strengthens your supervisory position but does not substitute for documented CIR compliance.

When does the Article 23 clock start for digital infrastructure incidents?

Article 23(4) of the NIS2 Directive requires the initial early warning within 24 hours of “becoming aware” of a significant incident. For automated monitoring systems — BGP alert tools, availability dashboards, integrity monitoring — awareness begins when the alert fires, not when root cause is confirmed. For threshold-based incidents (DNS 30-minute outage, CDN 5% user degradation), the clock starts when the threshold condition is met and confirmed through your monitoring system.

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] Article 5: Significant Incidents — DNS Service Providers, CIR 2024/2690 — Advisera
• [2] Article 6: Significant Incidents — TLD Name Registries, CIR 2024/2690 — Springlex
• [3] Article 7: Significant Incidents — Cloud Computing, CIR 2024/2690 — Springlex
• [4] Article 8: Significant Incidents — Data Centre Service Providers, CIR 2024/2690 — Advisera
• [5] Article 9: Significant Incidents — CDN Providers, CIR 2024/2690 — Springlex
• [6] ENISA NIS2 Technical Implementation Guidance: A Practical Summary — NIS2-Templates.com
• [7] CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure — Advisera
• [8] NIS2 Directive Article 21 — Cybersecurity Risk-Management Measures — nis-2-directive.com
• [9] NIS2 Directive Article 34 — Administrative Fines — nis-2-directive.com