Does the CER Directive change NIS2 obligations for a critical entity?
An entity identified as a critical entity under the CER Directive should be treated as an essential NIS2 entity, regardless of its size. Recital 30 of NIS2 says so directly, which means NIS2 cybersecurity duties apply on top of the physical and organizational resilience duties in the CER Directive, not in place of them. The CER Directive, Directive (EU) 2022/2557, covers 11 sectors, and an identified entity must still meet its own resilience timetable: notification within one month of identification, resilience obligations 10 months after that notification, and a risk assessment within nine months of notification. The NIS2 obligations, including Article 21 risk management and Article 23 reporting, run alongside those dates, so the two compliance programs should be planned together rather than in sequence.
The answer is not the same for every critical entity. For banking, financial market infrastructure and digital infrastructure, Article 8 of the CER Directive disapplies its resilience measures, incident notification and supervision chapters, because DORA and NIS2 already cover those matters. An entity in those sectors should confirm with its national competent authority which regime governs each obligation. Member States must also transpose the two directives in a coordinated manner, so the national law and the authority's guidance determine how the duties are split and who supervises them. Whether an organization has been formally identified, or only expects to be, also changes the timing it must plan against.
The practical first step is to ask the national authority in writing which NIS2 and CER obligations apply to the entity, which authority supervises each one, and which dates from the notification letter it must meet. A single gap register covering physical protection, incident notification within 24 hours under CER Article 15(1), and the NIS2 reporting deadlines will show where one program satisfies both regimes and where separate evidence is needed.
Which CER sectors bring NIS2 duties with them
The CER Directive names 11 sectors, and a critical entity identified in any of them becomes an essential NIS2 entity regardless of size. The cards below group those sectors by what a reader should check first, and flag the carve-out where DORA and NIS2 take over resilience for banking, financial market infrastructure and digital infrastructure.
Energy and transport operators
Energy and transport entities are the sectors where physical disruption and cyber disruption are most likely to coincide, so NIS2 and CER duties apply to the same operator. Check first whether your organization has been, or is likely to be, identified as a critical entity by your Member State, because that identification triggers the NIS2 duties. Then map which operational technology and control systems sit inside the Article 21 risk-management scope.
Health and drinking water
Health providers and drinking water suppliers depend on continuous service, and their incidents often reach patients and the public quickly. Confirm with your national competent authority whether your facilities are on the critical entity list, since identification brings NIS2 cybersecurity obligations with it. Then check how physical protection of premises, backup supply and clinical or treatment systems are covered by both the CER measures and your NIS2 controls.
Waste water and food supply
Waste water treatment and food production, processing and distribution are sectors where operational technology often runs older equipment at remote sites. Check first which sites and process controls would count as essential services, and whether remote access to them is documented. Also confirm how supply chain dependencies, such as chemicals, power and logistics providers, feed into the CER risk assessment and the NIS2 supplier controls.
Public administration and space
Public administration and space operators are critical entities in sectors where NIS2 also reaches central government and ground infrastructure. Check first whether your entity falls under the public administration definition in the CER Directive and whether the NIS2 central government rules apply separately. For space, confirm which ground segment services are essential and where cyber and physical security responsibilities are split between teams.
Banking, financial markets and digital infrastructure
Under CER Article 8, these sectors are carved out of the CER resilience, incident notification and supervision chapters, because DORA and NIS2 cover their resilience instead. Check first whether your entity is a bank, financial market infrastructure or digital infrastructure provider, and then confirm which regime covers each obligation. A single incident may still need to be reported under more than one framework, so map the reporting paths before an event occurs.
Key CER and NIS2 deadlines for a critical entity
The sequence runs from national transposition to identification, notification, resilience obligations and risk assessment, and each phase produces a specific record that the entity and its authorities can point to. Exact dates for any one entity depend on when its national authority notifies it.
Confirm national transposition of both directives
Member States had to transpose the CER Directive by 17 October 2024, as set out in its Article 26, and NIS2 by 17 October 2024 under its Article 41. The entity's first task is to read the national laws that implement both directives, since these set the authority, the notification route and any stricter national rules. The output is a short written record of the applicable national laws and the competent authorities for cybersecurity and physical resilience. Confirm this with the national authority or legal counsel, not only with the EU text.
Await identification as a critical entity
Each Member State must identify its critical entities by 17 July 2026, under Article 6(1) of the CER Directive. Identification is a decision by the national authority, and the entity does not identify itself. The entity should expect the authority to use the sector list in the CER Directive Annex and its own criteria. The output is an identification decision, and the entity should ask the authority how it will confirm that the decision applies.
Receive the notification of identification
The critical entity must be notified within one month of its identification, as required by Article 6(3) of the CER Directive. The notification starts the clock for every later obligation, so the date of receipt is the single most important record to keep. The output is a dated notice that names the entity as a critical entity. Because NIS2's Recital 30 treats critical entities as essential entities, the entity should also check with its NIS2 authority how the notice affects its NIS2 status.
Complete the first risk assessment
Under Article 12(1) of the CER Directive, the entity must carry out a risk assessment within nine months of notification and repeat it at least every four years. The assessment should cover the natural and human-caused hazards that could disrupt the entity's essential services, including physical and cyber threats. The output is a documented risk assessment that informs the measures the entity must take next. Physical and cyber findings should be cross-referenced so that the NIS2 Article 21 risk analysis does not contradict the CER assessment.
Put resilience measures in place
The resilience obligations in Chapter III of the CER Directive apply 10 months after notification. From that date, Article 13 requires technical, security and organizational measures covering disaster prevention, physical protection, response and recovery, and employee security management. The entity owns these measures and must be able to show them to its authority. The output is a documented set of measures mapped to the risk assessment and tested against the entity's own plans. Ask the authority which evidence it expects before the date arrives.
Prepare the incident notification route
Under Article 15(1) of the CER Directive, a critical entity must send an initial notification within 24 hours of becoming aware of an incident that significantly disrupts or could disrupt essential services, followed where relevant by a detailed report within one month. The entity needs a way to make this notice on time, which includes named contacts, a decision path and a template agreed with the authority. The output is a tested notification procedure linked to the entity's incident response plan. Where the same event is also a NIS2 incident, the entity should align the two procedures in advance.
Repeat the cycle on the four-year rhythm
The risk assessment must be repeated at least every four years under Article 12(1) of the CER Directive, and the measures should be reviewed whenever risks or services change. The entity should keep a calendar that tracks the notification date, the assessment dates and any authority reviews. The output is a maintained compliance record that shows each phase was completed on time. The exact next dates depend on the entity's own notification and any change in its status.
What CER physical resilience measures ask for
CER Article 13 asks critical entities for technical, security and organisational measures that cover physical and people risks as well as cyber risks. NIS2 expects the cybersecurity controls that sit alongside those measures to be managed and evidenced together. DeployOpen does not run physical security; the organization and its physical security providers own those measures, and DeployOpen can help prepare the cyber and access records that support them.
Disaster prevention and preparedness
Article 13 expects critical entities to prevent disasters that could disrupt essential services, and to plan for them. On the cyber side, this means documenting which hazards are in scope, keeping an asset inventory that shows where critical systems run, and confirming that data centers, network links and power dependencies are recorded. Ask who owns the hazard register and how it links to your NIS2 risk assessment, so the two documents do not describe different environments.
Physical protection of premises
Article 13 covers physical protection of premises and critical infrastructure. Physical access controls such as badges, guards and CCTV are owned by the organization and its security providers, not by an implementation partner. The cyber side is the record of who holds access to network closets, server rooms and management consoles, and whether logs from access systems reach the monitoring platform. Confirm that physical access logs are retained and reviewed alongside system logs.
Response and recovery planning
Article 13 requires measures for responding to and recovering from disruption. For NIS2 this connects to the incident response plan, tested backups and recovery time objectives for essential services. Check that backups of critical systems are stored separately from the primary site, that restores are tested on a schedule, and that the plan names who decides on activation. These records are what an assessor will ask to see when they test whether recovery was planned, not only documented.
Employee security management and background checks
Article 13 covers employee security management, including background checks where Member States allow them. Confirm with your national authority and counsel whether background checks are permitted for your roles. On the cyber side, the controls are joiner, mover and leaver processes, role-based access to critical systems, and privileged account reviews. Ask for evidence that access is removed when staff leave and that privileged roles are reviewed at a set interval.
Shared cyber and physical records
Article 13 and NIS2 Article 21 are read together, so the same asset list, access records and incident log should support both. Physical and cyber incidents often share a timeline, which matters for the 24-hour notification under CER Article 15 and the NIS2 reporting stages. Ask whether one incident register covers both domains, who holds the authority to submit notifications, and how the register is kept consistent across the two regimes.
Notifying incidents under both regimes
This sequence lets one incident satisfy the CER initial notification and the NIS2 early warning, notification and final report from a single timeline, so the organization can show each clock was tracked and met. It also records which authority received each filing and when.
Confirm dual status and the notification route
Before an incident occurs, the compliance lead confirms whether the entity has been identified as a critical entity under the CER Directive, which makes it subject to NIS2 cybersecurity obligations as an essential entity. Confirm with the national competent authorities which authority receives CER notifications, which receives NIS2 reports, whether a single entry point applies, and the exact channel, format and recipients. Nothing in this step is set by the directives alone, so write the answers down and keep them in the response plan. The output is a dated contact and channel matrix signed off by the accountable manager.
Detect and classify the event
The security operations or operations team detects an event and records the moment the organization became aware of it, because both the CER 24-hour clock and the NIS2 early warning clock start from awareness. The team assesses whether the event significantly disrupts, or could disrupt, an essential service, and whether it is significant under the NIS2 criteria. Keep the awareness timestamp in the incident record and do not backdate it. The output is a classified incident record with the awareness time and a preliminary severity decision.
Open one incident record for both clocks
The incident manager opens a single case that tracks the CER and NIS2 obligations side by side, with one field for each deadline calculated from the awareness timestamp. Assign owners for each filing and for the legal and privacy review of personal data. Link the record to the GDPR breach assessment, because the same event may trigger several notices. The output is one case with separate, visible deadline tracks that the organization can show an assessor.
Send the CER initial notification
Where the incident significantly disrupts or could disrupt essential services, the entity sends the initial notification to the competent authority within 24 hours of becoming aware. The CER Directive allows a later notification only where the entity is operationally unable to meet the deadline, so record the reason and the time the entity became able to file. The notice should state what is known, even if incomplete. The output is a timestamped copy of the submission and the authority's acknowledgment, if issued.
File the NIS2 early warning and notification
For a significant incident under NIS2, the entity files an early warning within 24 hours of awareness, followed by a notification that updates the initial assessment with severity, impact and indicators of compromise. The same facts should appear in both filings, with any differences explained in the record. Confirm with the national CSIRT or competent authority whether these filings go through the same portal as the CER notice. The output is consistent, timestamped filings that the incident record links to.
Deliver the detailed reports on schedule
Where relevant, the CER detailed report is due within one month of the initial notification, and the NIS2 final report is due within one month of the incident notification, according to the Article 23 timeline. Track both dates in the case record, and update the root cause, mitigation and cross-border impact in each report. Where authorities request further information, log the request and the response. The output is the final reports and a closed deadline log for both regimes.
Review the sequence and test it
After closure, the incident manager reviews whether each clock was met, whether the notices agreed with each other, and whether the contact matrix worked. Update the response plan and contact list, then include the sequence in the next tabletop exercise. Ask the national authorities to confirm any changes to channels or recipients. The output is a post-incident review with dated corrections and a revised, signed-off contact matrix.
Who owns CER and NIS2 duties in practice
The management body carries the legal accountability for the cybersecurity risk-management measures under NIS2 and for the resilience plans an entity must maintain as a critical entity under the CER Directive. It approves the measures, oversees how they are carried out and must follow cybersecurity training. The compliance lead turns those decisions into a documented program, tracks obligations across both directives and reports to the board. Neither role can be delegated to a vendor in a way that removes accountability.
- Approval and oversight: Record board approval of the risk-management measures and review them at planned intervals.
- Critical entity obligations: Confirm the entity's CER identification status, the notification date and the risk assessment deadlines that follow from it.
- Single view of obligations: Keep one register that maps NIS2 duties, CER duties and any sector rules such as DORA where they overlap.
- Evidence owner: Name who holds approvals, minutes and training records that a competent authority may request.
- Budget and resourcing decisions: Document the funding choices that determine what the technical teams can deliver.
Check that the board minutes, risk register and obligation register name the same owners and dates.
The internal security and operations teams own the controls themselves. They run the systems that handle incident detection, access, backups, patching and physical protection of critical infrastructure, and they decide how those controls operate in production. Their work produces most of the evidence an authority will examine, so they must be able to explain what each control does, when it was last tested and where its records live.
- Control operation: Run and monitor the technical and organizational measures in production, not only on paper.
- Incident handling: Own the detection, triage and reporting steps that feed the 24-hour early warning and the later reporting stages.
- Physical and resilience measures: Operate the protections for premises and infrastructure that the CER Directive requires where the entity is critical.
- Evidence generation: Keep logs, configuration baselines, test results and change records in a form that can be produced on request.
- Testing and drills: Schedule and run exercises, then record findings and fixes.
Confirm that each control has a named operator and that the operator can show a recent run of the control, not only its policy.
An implementation partner such as DeployOpen helps prepare the cybersecurity side of the program. Under a written, fixed scope, it can plan, configure, harden and document self-hosted open-source platforms inside the client's own infrastructure, and it can prepare systems, configuration and evidence for review. It does not own the controls, does not set the entity's risk appetite and does not decide whether the entity complies. It also does not issue audit reports, attestations or certificates, and no certificate under NIS2 exists.
- Systems and configuration: Build and harden the platforms that support the cybersecurity measures, within the agreed scope.
- Evidence preparation: Produce configuration exports, logs, test outputs and documentation that the organization can review and adopt.
- Testing support: Run security testing or exercises where the written scope includes them, and report results to the client.
- Knowledge transfer: Document runbooks so the internal team can operate the systems after handover.
- Retained support: Where the client buys a retainer, provide upgrades and continuing support under the agreed terms.
Before signing, ask the partner to state in writing which deliverables it provides and which decisions remain with the client.
Compliance is judged by parties outside the organization and outside its implementation partner. For NIS2, national competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Essential entities face ex ante supervision and important entities face ex post supervision. For CER, the competent authorities of each Member State identify critical entities and oversee their resilience. Where an entity also seeks a voluntary third-party review, such as an independent audit against a recognized framework, that auditor issues its own report, which is separate from any regulatory finding.
- Competent authorities: Expect information requests, inspections and scans, with fines for infringements.
- Independent audits: Commission these separately if the board wants external assurance, and confirm the auditor's accreditation.
- No NIS2 certificate: Do not accept any document described as a NIS2 certificate as proof of compliance.
- Assessor independence: Keep the assessor independent of the team that built the controls.
- Scope agreement: Agree the assessment scope in writing before fieldwork starts.
Confirm with your national competent authority which assurance evidence it accepts and how it expects to receive it.
What to have in place before the first supervisory review
A critical entity under the CER Directive that is also an essential entity under NIS2 needs its identification, risk assessment, incident process and control evidence to agree with each other. The cards below are the items a supervisor is most likely to ask for first, and each one names how to check it.
Confirmed identification status
Confirm in writing whether your national authority has identified your organization as a critical entity under the CER Directive. Identification triggers the NIS2 treatment described in Recital 30, so the answer determines your NIS2 category. Ask the authority for the notification date, since the CER resilience clock runs from it. Keep the notice on file with the board minutes that acknowledge it.
Joint cyber and physical risk assessment
The CER Directive requires a risk assessment that covers physical threats, while NIS2 Article 21 covers network and information systems. Run one assessment that covers both, so a flooded data center, a cut cable and a ransomware event appear in the same register. Check that the assessment names an owner, dates, and the date of its next review, since the CER cycle is at least every four years.
Incident process for both clocks
A single incident can start a 24-hour CER initial notification and a 24-hour NIS2 early warning. Test a tabletop exercise with a scenario that disrupts an essential service and a cyber trigger at once. Check that the runbook names who calls the CER authority, who files the NIS2 report, and how the 72-hour and one-month NIS2 steps are tracked. Record the time each clock started.
Evidence for Article 21 measures
Supervisors test the ten Article 21(2) measures through evidence, not statements. For each measure, collect a current policy, a configuration record, an access review and a test result. Use the ENISA technical guidance on examples of evidence to check that your records match what a supervisor expects. Gaps found in this review should appear in a dated remediation plan approved by management.
Mapping of CER sectors to NIS2 annexes
The CER Directive lists 11 sectors, and NIS2 lists 18 across Annexes I and II. Map each of your services to a sector in both lists and record the classification. Banking, financial market infrastructure and digital infrastructure are handled under DORA and NIS2 rather than the CER resilience chapters, so confirm which regime applies to each service. Ask counsel to confirm the mapping before you rely on it.
A named owner for each item
Each item above needs one accountable person who is not an outside adviser. Management must approve the measures and oversee them under Article 20, so record the board or executive sponsor for the program. Name a contact for the CER authority, a NIS2 reporting lead and a risk owner. Check that each name appears in a current org chart and that deputies are listed for reporting hours.
Frequently asked questions about NIS2 and the CER Directive
Does being identified as a critical entity under the CER Directive make an organization essential under NIS2?
Yes. Recital 30 of NIS2 says entities identified as critical entities under the CER Directive should be considered essential entities under NIS2. The consequence is that the cybersecurity obligations of NIS2 apply on top of the physical resilience duties of the CER Directive, and this applies regardless of company size. Each Member State must identify its critical entities by 17 July 2026, and the identified entity must be notified within one month of identification. The two sets of competent authorities are expected to cooperate and exchange information without undue delay. Ask your national authority which regime applies to your specific entity and which supervisor you will deal with for each regime.
Which sectors does the CER banking and digital infrastructure carve-out cover?
The carve-out in Article 8 of the CER Directive covers critical entities in banking, financial market infrastructure and digital infrastructure. For these entities, the CER resilience measures, incident notification and supervision chapters do not apply, because their resilience is addressed through DORA and NIS2. The carve-out does not remove the entity from the CER identification process, and it does not remove the NIS2 cybersecurity duties. Organizations in these sectors should confirm with their competent authority which obligations apply to them, since the boundary between the regimes depends on the entity's classification and national transposition.
What does the 24-hour incident notification under the CER Directive require?
A critical entity must send an initial notification within 24 hours of becoming aware of an incident that significantly disrupts, or could significantly disrupt, the delivery of essential services. The initial notice is allowed to be late only when the entity is operationally unable to meet the deadline. Where relevant, a detailed report follows within one month. In practice, the detection, triage and escalation steps must be defined before an incident happens, with named decision-makers who can confirm the disruption and submit the notice. Reporting for the same event may also trigger NIS2 reporting duties and, where personal data is involved, GDPR notification, so the process should map all three deadlines in one procedure.
Is there a NIS2 or CER certificate that proves compliance?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Under the CER Directive, the outcome of the supervisory process is likewise not a certificate issued by the EU. Organizations that want independent assurance can commission an assessment against a recognized framework, such as ISO/IEC 27001, but that is a separate choice and does not replace supervision. Only an independent auditor or certification body can issue an audit report or certificate. Confirm with your authority which evidence it expects and how it will test it.
How much work does a CER and NIS2 program need from internal staff?
Internal staff carry the decisions and the knowledge of how the business actually runs. Management must approve the risk-management measures and take responsibility for them. The CER risk assessment must be completed within nine months of notification and repeated at least every four years, and it needs input from operations, facilities, IT and business continuity owners. Staff must also run the incident response procedure, keep records current and take part in exercises. The effort depends on the number of sites, the number of systems in scope and how much documentation already exists. Ask any provider to state which of these tasks it will perform and which will stay with your team.
Can an implementation partner take over the NIS2 evidence work for a critical entity?
An implementation partner can prepare systems, configurations, logs, documentation and evidence for the controls that supervisors will test, and it can help integrate these into the entity's own records. DeployOpen, for example, plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares evidence for compliance assessments. It does not own the controls, sign off on the risk assessment or issue reports or certificates. Those remain with the entity's management and with independent assessors where an assessment is commissioned. Scope and deliverables are normally agreed in writing before work starts, so ask for a written list of the evidence items included.
How DeployOpen prepares NIS2 cyber evidence alongside CER work
DeployOpen plans, implements and documents the cybersecurity side of a NIS2 program inside the client's own infrastructure, under a written scope agreed before work starts. In a CER context, that means the cyber measures the Article 21 risk-management duties require, delivered in the client's own cloud accounts, data centers or air-gapped networks. The client keeps ownership of its controls, its risk decisions and its regulatory relationship with the competent authority. DeployOpen does not own physical resilience. Premises protection, response and recovery planning for physical events, and background checks under the CER framework remain with the entity and its specialists.
In practice, the cyber work usually covers the configuration and hardening of self-hosted platforms, logging and monitoring that can support the 24-hour early warning under Article 23, backup and recovery testing, access control records, and the policy and risk documentation a supervisor will ask to see. Where a CER entity also falls under NIS2, the physical and cyber records should use the same asset inventory and incident timeline, so a single event can be reported consistently to both authorities. Confirm early which sector-specific regime applies, because banking and digital infrastructure entities may be covered by DORA and NIS2 rather than by the CER resilience chapters.
DeployOpen does not issue audit reports, attestations or certificates, and it does not guarantee that a regulator will accept the evidence or that any incident will be avoided. NIS2 creates no certificate of compliance. Independent assessors, auditors or the competent authority make those judgments. What DeployOpen hands over is a set of configured systems, evidence packs, runbooks and documentation organized for independent review, along with a list of open items the client must resolve. Ask any implementation partner for the written scope, the named deliverables, who reviews the evidence, and which items remain with the organization after handover.
