NIS2 Implementing Regulation (CIR 2024/2690): Complete Guide to Technical Requirements

Most NIS2 guides explain what the Directive requires. Very few explain the regulation that specifies, precisely and in legally binding terms, what those requirements mean technically for digital infrastructure providers. Commission Implementing Regulation (EU) 2024/2690 — the CIR — is that regulation.

In force since 7 November 2024, the CIR applies to eleven categories of entities: DNS providers, TLD registries, cloud computing providers, data centres, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines, social networks, and trust service providers. For these organisations, compliance with NIS2’s Article 21 means compliance with the CIR’s Annex — thirteen sections of specific, auditable technical requirements that go substantially deeper than the Directive’s general provisions.

This guide covers the complete CIR framework: what it is, why it exists, how each of the 13 Annex sections works, the entity-specific incident thresholds that determine when you must report, and what getting compliant actually involves.

What Is CIR 2024/2690 and Why Does It Exist?

Commission Implementing Regulation (EU) 2024/2690 is a directly applicable EU regulation — unlike a directive, it requires no national transposition. From its application date of 7 November 2024, it is binding in full across all EU Member States. No domestic legislation is needed; no Member State can modify or delay its requirements.

The Commission adopted the CIR under Article 21(5) and Article 23(11) of the NIS2 Directive (Directive (EU) 2022/2555). Those provisions specifically mandate the Commission to issue implementing acts that set technical and methodological requirements for cybersecurity risk-management measures and specify when incidents are “significant” for certain entity types.

The rationale matters for understanding what the CIR actually requires. The NIS2 Directive applies to a wide range of sectors — energy, transport, healthcare, banking, digital infrastructure — and deliberately uses proportionate, principles-based language. That flexibility suits most sectors, where a manufacturing company and a hospital have radically different technical environments. But for digital infrastructure and service providers, greater specificity is both feasible and necessary. These entities are technically sophisticated, operate across borders, and their outages tend to cascade across other sectors. Harmonised technical standards eliminate the fragmentation that made NIS1 enforcement inconsistent across Member States.

The CIR also replaces Commission Implementing Regulation (EU) 2018/151, which had governed digital service providers under the original NIS Directive. The 2018 regulation covered only three entity types — online marketplaces, online search engines, and cloud computing services — and set relatively high-level requirements. CIR 2024/2690 expands coverage to eleven entity types and specifies technical requirements at a granularity the earlier regulation never attempted.

Who Does CIR 2024/2690 Apply To?

The CIR applies to a defined subset of the NIS2 scope — eleven categories of digital infrastructure and service providers listed in Annex I (essential entities) and Annex II (important entities) of the NIS2 Directive. If your organisation is in energy, manufacturing, healthcare, banking, or any other NIS2 sector but is not one of the eleven types below, the CIR does not apply to you directly. Article 21 of the NIS2 Directive still does.

Entity Type	NIS2 Classification	Typical Examples
DNS service providers	Essential	Authoritative DNS operators, recursive resolvers serving third parties
TLD name registries	Essential	Country-code and generic TLD registry operators (.de, .nl, .eu)
Cloud computing service providers	Important	IaaS, PaaS, SaaS providers with EU customers
Data centre service providers	Important	Colocation facilities, managed hosting providers
Content delivery network providers	Important	CDN operators distributing content for EU users
Managed service providers (MSPs)	Important	IT outsourcing, managed infrastructure providers
Managed security service providers (MSSPs)	Important	Outsourced SOC, managed SIEM and threat detection providers
Providers of online marketplaces	Important	E-commerce platforms, digital storefronts serving EU consumers
Providers of online search engines	Important	Search platforms with significant EU user base
Providers of social networking services	Important	Social media platforms meeting NIS2 size thresholds
Trust service providers	Essential	Qualified certificate authorities, timestamp authorities under eIDAS

One practical clarification: NIS2’s general size threshold (medium-sized entities: 50+ employees or €10M+ annual turnover) applies to most of the above categories. But DNS providers, TLD registries, and trust service providers are in scope regardless of size. If you operate in those categories — even as a small specialist provider — the CIR applies.

Medical device manufacturers and electrical equipment producers are explicitly outside the CIR’s scope, even where their products intersect with digital networks, as confirmed in the regulation’s recitals. For the full NIS2 applicability picture, use our NIS2 scope guide, which covers all essential and important entity classifications.

CIR vs Article 21: How They Work Together

Article 21 of the NIS2 Directive requires all essential and important entities to implement “appropriate and proportionate technical, operational and organisational measures” across ten specified categories — measures (a) through (j). The language is deliberately flexible: “appropriate measures,” “considering the state of the art,” “proportionate to the risk.”

The CIR converts that general obligation into technical specifications for the eleven covered entity types. Where Article 21(2)(a) requires “policies on risk analysis and information system security,” the CIR’s Annex specifies what those policies must contain, what roles they must assign, and how frequently they must be reviewed. Where Article 21(2)(j) requires “the use of multi-factor authentication,” the CIR specifies the contexts in which MFA is mandatory and what authentication mechanisms are considered adequate.

The relationship is hierarchical and sequential. The Directive sets the obligation. The CIR defines what compliance looks like for these specific entity types. National competent authorities will assess CIR-covered entities against the Annex’s specific requirements — not just against Article 21’s general provisions. “We follow the spirit of Article 21” is not an adequate response to a supervisory audit for a cloud provider or MSP.

This precision cuts both ways. It creates compliance certainty — you either meet the specific requirement or you don’t, which makes gap assessment more straightforward than interpreting proportionality language alone. It also raises the floor: proportionality under the CIR reduces the scale of implementation, not the scope. All thirteen Annex sections are required; smaller entities can implement them at simpler scale, but cannot omit them.

For a full breakdown of all ten Article 21(2) measures and what each requires across all NIS2 entities, see our NIS2 requirements guide.

The 13 Technical Annex Sections — Complete Breakdown

The CIR’s Annex — titled “Technical and methodological requirements referred to in Article 2” — contains 13 sections. Each section corresponds to one or more of Article 21(2)’s ten cybersecurity risk-management measures. Where a single Article 21 measure generates particularly complex requirements, the CIR breaks it into two or three Annex sections. Article 21(2)(i) — covering human resources security, access control, and asset management — becomes three distinct sections in the Annex (Sections 10, 11, and 12).

The following table maps each section to its Article 21 measure and provides an indicative implementation effort for a mid-sized entity. Effort reflects the gap most organisations face, not the absolute volume of work.

Section	Title	Art. 21(2)	Implementation Effort
1	Policies on the Security of Network and Information Systems	(a)	Medium
2	Risk Management Policies and Procedures	(a)	High
3	Incident Handling	(b)	High
4	Business Continuity Management	(c)	High
5	Supply Chain Security	(d)	Medium–High
6	Security in NIS Acquisition, Development and Maintenance	(e)	Medium–High
7	Assessing Effectiveness of Cybersecurity Risk Management	(f)	Medium
8	Basic Cyber Hygiene and Training	(g)	Low–Medium
9	Policies and Procedures on Cryptography and Encryption	(h)	Medium
10	Human Resources Security	(i)	Low–Medium
11	Access Control	(i)	Medium–High
12	Asset Management	(i)	Medium
13	Multi-Factor Authentication and Secure Communications	(j)	Medium

Section 1: Policies on the Security of Network and Information Systems

Section 1 requires a top-level security policy explicitly approved by the management body — not a document written by the IT team and filed away. The policy must define security objectives, assign named roles with specific responsibilities, allocate security resources, and establish a review schedule (at minimum annually, and whenever significant changes occur to the threat environment or the entity’s services).

For organisations already holding ISO 27001 certification, Section 1 maps closely to ISO’s Information Security Policy (clause 5.2) and Roles, Responsibilities and Authorities (clause 5.3). The CIR adds one non-negotiable element that ISO allows to be implicit: the management body’s ongoing, documented involvement is mandatory, not optional. Management approval must be evidenced — meeting minutes, formal sign-off, a dated policy header with named approver.

Section 2: Risk Management Policies and Procedures

Section 2 establishes the risk management framework — the methodology used to identify, assess, and treat cybersecurity risks. Where many organisations treat risk assessment as a periodic project, the CIR requires an ongoing process: assessments must be repeated when the risk environment changes significantly, and a risk treatment plan with documented management acceptance of residual risks must be maintained continuously.

The Annex does not prescribe a specific methodology (ISO 27005, NIST RMF, and OCTAVE all remain valid), but the methodology must be documented and consistently applied. Our NIS2 risk assessment guide provides a practical step-by-step framework aligned with Section 2 requirements, including a worked example for a mid-sized MSP.

Section 3: Incident Handling

Section 3 covers the full incident lifecycle: detection, classification, containment, eradication, recovery, and post-incident review. Procedures must be documented for each phase, with defined escalation paths, communication protocols, and specific criteria for determining whether an incident meets the “significant” threshold that triggers regulatory notification.

Section 3 must be read alongside Articles 3–14 of the CIR, which set entity-specific incident thresholds (detailed below). Your incident handling policy must explicitly reference these thresholds and document the workflow for meeting the 24-hour early warning, 72-hour notification, and one-month final report obligations under Article 23 of the NIS2 Directive. See our incident reporting guide for the complete Article 23 timeline and notification content requirements.

Section 4: Business Continuity Management

Section 4 requires a business impact analysis (BIA), a business continuity strategy, and documented business continuity and disaster recovery plans. The critical word is “documented and tested” — the CIR does not accept untested plans as compliance evidence. Crisis management procedures must be defined separately and include communication protocols with regulators and key stakeholders during significant incidents.

Recovery time objectives (RTOs) and recovery point objectives (RPOs) must be explicit and validated through exercises. For cloud providers and data centre operators, these targets will be scrutinised against the incident thresholds in Article 7 and Article 8 respectively.

For data centre operators, Section 4’s redundancy requirements connect directly to the physical infrastructure layer. Our guide to data centre compliance under CIR 2024/2690 covers how UPS, cooling, and perimeter controls map to Section 4, Section 11, and Section 13 obligations — including the Article 8 thresholds that make a power or cooling failure a reportable incident.

Section 5: Supply Chain Security

Section 5 requires entities to assess the cybersecurity practices of direct suppliers and service providers, and to include contractual security requirements in supplier agreements. The assessment must be proportionate to the supplier’s criticality — a supplier with privileged access to production systems requires thorough assessment; a commodity stationery supplier does not.

This section carries particular weight for MSPs and MSSPs, who operate simultaneously as CIR-regulated entities and as suppliers to their own clients — clients who may themselves be subject to NIS2 obligations. An MSSP’s security posture is both a compliance obligation and a product feature. Weaknesses in Section 5 implementation create cascading liability exposure across the supply chain.

Section 6: Security in NIS Acquisition, Development and Maintenance

Section 6 covers the full lifecycle of network and information systems from procurement through development, change management, and decommissioning. Security requirements must be embedded in procurement specifications — not added as an afterthought after a system is live. Secure development practices (including, where applicable, SAST/DAST testing) are required for entities that develop their own systems or services.

Vulnerability management is a core component of Section 6: entities must have structured processes for discovering, assessing, and remediating vulnerabilities, including regular security testing such as penetration tests and vulnerability scans. Patch management must be documented, with clear procedures for emergency patching and formal exception handling when patches cannot be applied immediately.

Section 7: Assessing Effectiveness of Cybersecurity Risk Management

Section 7 requires entities to measure whether their security controls actually work. This goes beyond periodic audits — it requires defined metrics, key performance indicators (KPIs), and key risk indicators (KRIs) tracked continuously. Effectiveness reviews must feed back into the risk management process: if performance metrics reveal that a control is failing, the risk register must be updated and corrective action documented.

This is the section most often underestimated in early compliance projects. Many organisations implement the controls in Sections 1–6 and 8–13 but have no systematic way to demonstrate their effectiveness to an auditor. Section 7 closes that gap — and is the mechanism behind what the ENISA Technical Implementation Guidance describes as NIS2’s “continuous improvement” obligation.

Section 8: Basic Cyber Hygiene and Training

Section 8 requires documented cyber hygiene practices — patch schedules, email security configurations, secure configuration baselines, removable media controls — and a training programme that covers the full organisation. Article 20 of the NIS2 Directive requires management bodies to complete cybersecurity training, and Section 8 extends this to role-based training for staff in security-sensitive positions. Training records must be retained as audit evidence.

One practical point on scope: Section 8 requires training for the entity’s own staff. But for MSPs and cloud providers whose services include managing customer security environments, the training obligation also extends to ensuring that customer-facing personnel understand the security implications of their role — a requirement that goes beyond standard annual awareness courses.

Section 9: Policies and Procedures on Cryptography and Encryption

Section 9 requires a documented cryptography policy specifying: which data classifications require encryption (at rest and in transit), which algorithms and key lengths are approved (aligned with current state-of-the-art recommendations), and how cryptographic keys are managed, rotated, and revoked. The policy must be reviewed when cryptographic standards evolve — a live concern, given EU-level and national guidance on post-quantum cryptography preparing for migration timelines in the late 2020s.

The Annex does not mandate specific algorithms, but phrases like “state of the art” in EU regulation are interpreted by supervisory authorities in light of ENISA guidance and ETSI standards. At the time of writing, AES-256 for symmetric encryption, RSA-3072+ or elliptic curve equivalents for asymmetric encryption, and TLS 1.2 minimum (TLS 1.3 preferred) for transport security align with current expectations.

Section 10: Human Resources Security

Section 10 covers the employee lifecycle as a security control. Before employment: background verification proportionate to the access level the role grants (privileged access roles warrant deeper screening than general staff). During employment: security responsibilities in employment contracts, awareness of the entity’s security policies, and procedures for managing security incidents caused by employees. After employment: prompt revocation of access, return of assets, and offboarding checklists. Disciplinary processes for security violations must exist and be documented.

Section 11: Access Control

Section 11 requires documented access control policies covering both logical and physical access. The least-privilege principle must be applied systematically: access rights granted based on business need, reviewed regularly (at least annually, and whenever role changes occur), and revoked promptly when no longer required. Privileged accounts — system administrators, database administrators, root access — require additional controls, including separate accounts for privileged versus standard activity, and enhanced monitoring or session recording where technically feasible.

Authentication mechanisms must be documented and justified. The CIR does not repeat the specific MFA requirements here (those appear in Section 13) but does require that authentication controls across all systems are defined, maintained, and periodically reviewed for adequacy.

Section 12: Asset Management

Section 12 requires a complete, maintained inventory of all assets in scope: hardware, software, data assets, and network components. Assets must be classified by criticality and confidentiality requirements, and the protection measures applied to each asset must be proportionate to its classification. The asset register is a living document — it must reflect the current state of the environment, not a point-in-time snapshot taken during a compliance project and never updated.

For cloud providers and data centre operators with large, dynamic environments, this section is operationally demanding. Automated asset discovery and configuration management tooling are not mandated by name, but maintaining a current manual inventory in a hyperscale environment is practically infeasible — the Section 12 requirement is a strong driver for investment in infrastructure visibility tooling.

Section 13: Multi-Factor Authentication and Secure Communications

Section 13 implements Article 21(2)(j) of NIS2, requiring MFA for remote access, administrative access, and access to systems handling sensitive or critical data. The CIR does not enumerate an exhaustive list of acceptable MFA methods, but ENISA guidance treats hardware security tokens (FIDO2), software TOTP authenticators, and push notification applications as adequate. SMS-based OTP is discouraged due to SIM-swapping vulnerabilities and is increasingly rejected by supervisory authorities in high-risk access scenarios.

Secure communications requirements under Section 13 cover encrypted channels for sensitive business communications — including emergency communication systems that must remain operational during incidents when standard channels may be unavailable or compromised. For trust service providers and DNS operators in particular, the integrity of emergency communications is operationally critical during the exact scenarios that trigger reporting obligations.

Significant Incident Thresholds by Entity Type (Articles 3–14)

Articles 3 through 14 of the CIR define precisely when an incident crosses the “significant” threshold for each entity type — triggering the Article 23 notification obligations. These entity-specific thresholds are operationally critical and are rarely explained in detail in standard NIS2 commentary.

All entities share a horizontal baseline under Article 3: an incident is significant if it causes or is capable of causing direct financial loss exceeding €500,000 or 5% of annual global turnover (whichever is lower), exfiltration of trade secrets, death or serious health damage to a natural person, or severe operational disruption resulting from successful unauthorised access. Article 4 adds a recurring-incidents rule: two or more incidents within six months sharing the same apparent root cause can collectively meet the financial loss threshold even if individually they do not.

The entity-specific thresholds (Articles 5–14) are cumulative — either the horizontal threshold or the entity-specific threshold triggers reporting. The specific thresholds below allow precise operationalisation of your incident classification procedure.

Entity Type	Key Incident Thresholds
DNS service providers	Complete service unavailability exceeding 30 minutes; query response time above 10 seconds for more than 1 hour; integrity or confidentiality compromise affecting more than 1,000 domain names or more than 1% of records served
TLD name registries	Complete authoritative service unavailability for any duration; response time above 10 seconds for more than 1 hour; integrity, authenticity, or confidentiality compromise of zone data
Cloud computing providers	Complete service unavailability exceeding 30 minutes; partial unavailability affecting more than 5% of EU users or more than 1 million EU users for more than 1 hour; data compromise affecting more than 5% of EU users or more than 1 million EU users
Data centre providers	Complete service unavailability for any duration; partial unavailability exceeding 1 hour; physical access compromise to the facility; any malicious data compromise
CDN providers	Complete service unavailability exceeding 30 minutes; partial unavailability affecting more than 5% of EU users or more than 1 million users for more than 1 hour; data compromise affecting more than 5% of EU users or more than 1 million users
MSPs and MSSPs	Complete service unavailability exceeding 30 minutes; partial unavailability affecting more than 5% of EU users or more than 1 million users for more than 1 hour; any malicious data compromise; data compromise affecting more than 5% of EU users or more than 1 million users
Online marketplace providers	Complete or partial unavailability affecting more than 5% of EU users or more than 1 million EU users; any malicious data compromise; data compromise affecting more than 5% of EU users or more than 1 million users
Online search engine providers	Complete or partial unavailability affecting more than 5% of EU users or more than 1 million EU users; any malicious data compromise; data compromise affecting more than 5% of EU users or more than 1 million users
Social networking platform providers	Complete or partial unavailability affecting more than 5% of EU users or more than 1 million EU users; any malicious data compromise; data compromise affecting more than 5% of EU users or more than 1 million users
Trust service providers	Complete service unavailability exceeding 20 minutes; service unavailability to any user or relying party exceeding 1 hour per calendar week; partial unavailability affecting more than 1% of users/relying parties or more than 200,000 users; data compromise affecting more than 0.1% of users/relying parties or more than 100 users; physical access compromise to facilities

Two observations are worth emphasising. Trust service providers face the strictest thresholds of any entity type: a 20-minute outage triggers reporting (versus 30 minutes for most others), and data compromise affecting just 100 users constitutes a significant incident. This reflects the role qualified trust service providers play in EU digital identity infrastructure — their failures have disproportionate knock-on effects across the digital economy.

For MSPs and MSSPs, the absence of a minimum unavailability threshold for malicious data compromise is particularly significant. Any malicious compromise of customer data — regardless of duration or scale — is significant and reportable. An MSSP whose monitoring platform is infiltrated and customer telemetry accessed, even briefly, must report. Incident response plans must be calibrated to this lower bar.

For exact threshold definitions applicable to your entity type, refer to the relevant article in the CIR full text on EUR-Lex. The thresholds above are accurate as of publication but the primary source is authoritative.

Documentation Requirements for CIR Compliance

The CIR’s requirements are evidence-based. Supervisory authorities will not accept verbal assurances of compliance — they need documented policies, records, test results, and management approvals. The following categories represent the audit evidence portfolio required by the Annex.

Governance documentation: Top-level security policy with management-body approval evidence (Section 1); role and responsibility assignments with named owners; risk management framework document; management acceptance records for residual risks (Section 2).

Risk management records: Documented risk assessment methodology; completed risk assessment results (with threat, vulnerability, impact, and likelihood assessments); risk treatment plan; evidence of periodic review including dates and approver signatures.

Incident management: Incident handling procedures covering all lifecycle phases (Section 3); incident log with classification outcomes; notification workflow documentation showing how the entity will meet 24-hour, 72-hour, and 1-month reporting deadlines; post-incident review reports.

Business continuity: Business impact analysis; BC strategy document; business continuity and disaster recovery plans; crisis management procedures; test results and exercise evidence with corrective action tracking (Section 4).

Supply chain: Supplier criticality assessment framework; completed supplier security assessments; contracts containing mandatory security clauses; supplier directory with security assessment status (Section 5).

Technical security: Asset register with classification and ownership (Section 12); access control policy with review evidence (Section 11); privileged access management records; training records with completion dates and assessment scores (Section 8); vulnerability scan reports and penetration test results (Section 6); patch management log including exceptions.

Cryptography: Cryptography policy with approved algorithm register and justification; key management procedures including rotation schedules and revocation processes (Section 9).

Our complete NIS2 compliance template library includes pre-built documents mapped to each of these categories, formatted for audit readiness and aligned with the CIR Annex requirements.

Who Needs to Act — A Role-by-Role View

The CIR places obligations on different parts of your organisation for different reasons. The right response is not a single project owned by IT — it requires coordinated action across technical, legal, and governance functions.

CISO and IT Security Manager: The Annex is your technical specification. Sections 1–13 map directly onto controls you need to implement, test, and evidence. Near-term priorities: document your risk assessment framework (Section 2), define incident classification criteria against the entity-specific thresholds in Articles 5–14 (Section 3), and close any gaps in access control and MFA implementation (Sections 11 and 13). Section 7 — effectiveness assessment — is the mechanism that holds the whole framework together and is typically implemented last but should be scoped early.

Compliance Officer and Legal: The CIR is directly applicable law, not guidance. Non-compliance is assessed against its specific Annex requirements. Your focus is twofold: first, build the documentation portfolio listed above — an incomplete evidence base will not survive a supervisory audit. Second, embed the incident reporting workflow into your incident response procedures before you face a real incident. The thresholds in Articles 3–14 must be pre-mapped to your classification criteria so that the “is this significant?” question is answered by procedure, not by judgment under pressure.

Board and C-Suite: Article 20 of NIS2 holds management personally liable for cybersecurity failures. The CIR’s requirements define what “adequate security” means for your entity type — management cannot delegate this definition to the IT team and remain insulated from liability. Two Section 1 requirements land directly at board level: the security policy requires explicit management-body approval, and security resource allocation is a management decision. Both generate direct evidence of board engagement — or its absence.

SME owners operating covered entity types: If you run a managed service provider, cloud service, CDN, or any of the other covered types, the CIR applies regardless of whether you have a dedicated security team. Proportionality reduces implementation scale, not scope — all 13 sections must be addressed. Where implementing a specific control is technically infeasible for your environment, the CIR requires you to document that infeasibility and apply compensating controls. Undocumented gaps are not proportionate implementation; they are non-compliance.

The ENISA Technical Implementation Guidance: What It Adds

In June 2025, the European Union Agency for Cybersecurity (ENISA) published its Technical Implementation Guidance on cybersecurity risk management measures under CIR 2024/2690. The guidance addresses entities in digital infrastructure, ICT service management, and digital provider sectors — the same population as the CIR itself.

The ENISA guidance is not legally binding; the CIR is. But in practice, ENISA’s examples will shape how national competent authorities interpret “adequate” implementation. Where ENISA indicates that a particular control (for example, a specific MFA mechanism or a particular risk assessment approach) meets a given Annex section’s requirements, that standard is likely to inform supervisory expectations during audits and incident investigations.

The accompanying mapping table (v1.2) connects each CIR Annex requirement to specific implementation steps and, in many cases, to corresponding ISO 27001 controls — making it useful for organisations approaching CIR compliance from an existing ISO 27001 foundation. Note that ISO 27001 certification does not automatically demonstrate CIR compliance: the CIR includes entity-specific incident thresholds, supply chain requirements, and proportionality documentation obligations that fall outside ISO’s scope.

See our ENISA guidance explainer for a full summary of what the guidance covers and how to use it alongside your CIR compliance programme.

Frequently Asked Questions

Does CIR 2024/2690 apply to all NIS2 entities?

No. The CIR applies specifically to eleven categories of digital infrastructure and service providers: DNS providers, TLD registries, cloud computing providers, data centre providers, CDN providers, MSPs, MSSPs, online marketplace providers, online search engine providers, social networking platform providers, and trust service providers. All other NIS2 entities — manufacturers, energy companies, healthcare providers, transport operators, and so on — must comply with Article 21 of the NIS2 Directive, but are governed by the Directive’s proportionality principle rather than the CIR’s specific technical requirements.

When did CIR 2024/2690 enter into force?

The regulation was adopted on 17 October 2024, published in the EU Official Journal on 18 October 2024, and entered into force on 7 November 2024 — twenty days after publication, as specified in Article 16. It is directly applicable across all Member States from that date without requiring national transposition legislation. It applies to incidents and compliance obligations arising after its entry into force date.

What regulation did CIR 2024/2690 replace?

The CIR repeals Commission Implementing Regulation (EU) 2018/151, which governed digital service providers — specifically cloud computing services, online marketplaces, and online search engines — under the original NIS Directive (Directive (EU) 2016/1148). The 2018 regulation covered three entity types with relatively high-level requirements. CIR 2024/2690 expands coverage to eleven entity types and specifies technical requirements in substantially greater detail across 13 Annex sections. Entities that operated under 2018/151 should treat the transition as a gap assessment exercise, not a like-for-like update.

Does ISO 27001 certification satisfy CIR requirements?

ISO 27001 provides a strong foundation but does not fully satisfy the CIR. Significant gaps remain in three areas. First, entity-specific incident thresholds (Articles 5–14) have no ISO 27001 equivalent — your incident classification procedure must explicitly incorporate the CIR’s numeric thresholds. Second, the supply chain security requirements in Section 5 are more prescriptive than ISO 27001’s supplier relationship controls. Third, the proportionality documentation obligation — where implementing a specific control is infeasible, entities must document the reasoning and apply compensating controls — is a CIR-specific audit evidence requirement. Organisations approaching CIR from an ISO 27001 base should focus their gap analysis on these three areas.

What is the penalty for failing to comply with the CIR?

The CIR does not create separate penalty provisions. Non-compliance with the CIR’s Annex constitutes non-compliance with Article 21 of the NIS2 Directive, which carries the Directive’s full penalty regime. For essential entities (including DNS providers, TLD registries, and trust service providers), fines can reach €10 million or 2% of global annual turnover, whichever is higher. For important entities (cloud providers, data centres, CDNs, MSPs, MSSPs, online marketplace, search engine, and social network providers), the ceiling is €7 million or 1.4% of global turnover. Personal liability for management bodies under Article 20 applies in both categories. See our NIS2 penalties guide for the full enforcement framework.

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. European Union. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024. Official Journal of the European Union, 18 October 2024.
2. ENISA. Technical Implementation Guidance on Cybersecurity Risk Management Measures under CIR 2024/2690, Version 1.0. European Union Agency for Cybersecurity, June 2025.
3. European Commission. NIS2: Commission Implementing Regulation on Critical Entities and Networks. Shaping Europe’s Digital Future, 2024.
4. Hunton Andrews Kurth. Implementing Regulation Developing NIS2 Rules for Certain Digital Service Providers Enters into Force. Privacy and Information Security Law Blog, November 2024.