One Incident, Two Regulators, Two Regimes: Are You Ready for Both NIS2 and CER?

Preliminary remark: While this post draws on Belgian law as a concrete example, the underlying framework applies across the EU. Belgium is a useful lens: the Belgian CER Act of 19 December 2025 is one of the earliest national transpositions of the CER Directive, and Belgium's dual role as both an early NIS2 implementer and a host of major critical infrastructure, including energy interconnectors, LNG terminals, and cross-border pipeline networks, makes it a practical reference point for critical infrastructure operators across Europe. 

On 19 January 2026, Belgium published the Act of 19 December 2025 on the resilience of critical entities (“CER Act”), the Belgian transposition of the EU CER Directive. For operators of critical infrastructure in the energy, transport, water, health, digital and financial sectors, this adds a new layer of obligations to an already complex regulatory landscape. 

Most compliance teams are treating it as a separate project from NIS2 compliance. That is understandable. But it is also a mistake. 

This post explains why CER and NIS2 must be managed as a single integrated programme, what the key obligations under the CER Act are, and, most importantly, how the interaction between the two frameworks creates board governance consequences that the CER Act itself does not explicitly impose but that follow inevitably from the way the two regimes are connected. 

Two frameworks, one operator 

The CER Directive and the NIS2 Directive were adopted on the same day, 14 December 2022. They are deliberately designed as complementary instruments. 

CER addresses physical resilience: the ability of a critical entity to prevent, withstand, absorb and recover from incidents that disrupt essential services, whether caused by natural hazards, accidents, terrorism, sabotage or other threats. 

NIS2 addresses cyber resilience: the security of the network and information systems on which those essential services depend. 

The major difference in scope is that NIS2 applies automatically if an entity meets the requirements. CER instead only applies if an entity is designated as a critical entity by a competent sectoral authority. 

For a regulated entity such as an energy transmission operator, a water treatment facility, or a port authority, both frameworks apply simultaneously. The same organisation must implement physical resilience measures under CER and cybersecurity measures under NIS2. The same incident, a coordinated attack combining physical intrusion with a cyberattack on operational control systems, will trigger obligations under both frameworks at the same time. 

The bridge provision between CER and NIS2 

Article 3 § 4 of the Belgian NIS2 Act provides that an entity identified as a critical entity under the CER framework qualifies as an essential entity under NIS2. By operation of law, CER designation triggers NIS2 essential entity status, automatically, without any separate assessment. 

The practical consequence is significant. Many organisations in the energy, transport and water sectors have been tentatively hoping that their NIS2 obligations might be limited or qualified in some way by their specific operational profile. CER designation removes that ambiguity entirely. Once designated, you are an essential entity under NIS2, subject to its full compliance obligations, its ex-ante supervision by the CCB, and its penalty ceiling of €10 million or 2% of global annual turnover. 

For most operators of critical infrastructure, this is not surprising, they would likely have been essential entities under NIS2 in any event. But the bridge provision also matters for smaller entities that sit within critical infrastructure sectors but might otherwise have argued they fall below the NIS2 threshold. CER designation overrides the size threshold. Designation is the trigger, not size. 

The key CER Act obligations in brief 

The CER Act obligations crystallise upon designation as a critical entity by the competent sectoral authority, following the national and sectoral risk assessments. Two deadlines run from the moment of designation. 

Within nine months, the entity must complete a risk assessment covering all relevant risks, natural, technological, terrorist, insider, that could disrupt the provision of essential services, taking account of cross-sector dependencies. 

Within ten months, the entity must have implemented the measures set out in its resilience plan: technical, security and organisational measures covering prevention, physical protection, response and mitigation, recovery, personnel security and awareness. The legislation specifies physical protection measures expressly, fencing, barriers, perimeter monitoring, detection equipment, access controls, making clear that this is not a cybersecurity programme but a comprehensive physical security and resilience framework. 

Alongside these primary obligations, the entity must maintain a 24/7 reachable contact point, notify the competent authority of incidents within 24 hours, and cooperate with inspection services coordinated by the National Crisis Centre (NCCN). 

A critical planning point: designation is not a reason to wait 

Unlike NIS2, which operates on a self-assessment model where entities are in scope by operation of law from the moment they meet the sector and size criteria, the CER framework requires a formal act of designation by the competent sectoral authority before any compliance obligation arises. Until that designation notice arrives, there is technically no CER resilience plan to produce, no deadline running, and no notification obligation under the CER Act. 

It would be a serious mistake to treat this as breathing room. 

The nine-month deadline for completing the entity-level risk assessment and the ten-month deadline for implementing the resilience plan both start running from the date of designation. For an energy infrastructure operator, a port authority, or a water utility, building a credible resilience framework from scratch within ten months is an ambitious undertaking under the best of circumstances. Starting that work only after the designation notice lands makes it significantly harder. It also makes it far more likely that the first interaction with the competent authority will be one of documented delay rather than demonstrated preparedness. 

The practical approach is to treat CER designation as a planning horizon rather than a starting signal. The risk assessment methodology, the governance structure, the cross-functional working group, and the alignment with the NIS2 cybersecurity programme that the single-programme model requires: all of this can and should be built before the formal designation trigger. Organisations that have done this groundwork will be in a position to accelerate into compliance the moment designation arrives. Those that have not will be starting from zero under a statutory deadline. 

The notification cascade: three clocks running simultaneously 

For a critical infrastructure operator that is also an NIS2 essential entity , a significant incident triggers parallel notification obligations with different recipients, different content requirements and different deadlines. 

The CER Act requires an initial notification to the competent sectoral authority and the NCCN within 24 hours of becoming aware of an incident that significantly disrupts or is capable of significantly disrupting the provision of an essential service. 

The NIS2 Act requires an early warning to the CCB within 24 hours of becoming aware of a significant incident affecting network and information systems, followed by a fuller notification within 72 hours and a final report within one month.

Managing this cascade without pre-designed decision trees, pre-approved notification templates, and pre-designated contact points for each authority is operationally impossible under time pressure. Yet most organisations have not built this infrastructure. Building it after an incident has begun is too late. 

The board governance asymmetry and why it matters 

Here is the analytical point that most commentary on CER has missed. 

NIS2 creates explicit personal liability for management body members, through Articles 31 and 61 of the Belgian NIS2 Act, as analysed in our first post in this series. The management body must approve the cybersecurity measures, oversee their implementation, complete mandatory training, and can face individual suspension or public naming by the CCB if the entity repeatedly fails to comply. 

The CER Act contains no equivalent provision. The criminal sanctions in Article 41 §1 CER Act target the critical entity as a legal person, and where imprisonment is technically provided for, it is converted into a pecuniary fine for legal persons under Article 41bis of the Criminal Code. The only route to direct personal criminal exposure for an individual director under the CER Act is the obstruction offence in Article 41 §2, refusing to cooperate with an inspection, or knowingly providing false information. Under the Belgian Code of Companies and Associations (Wetboek van Vennootschappen en Verenigingen/Code des Sociétés et des Associations), the ordinary duty of diligent administration applies, as it does across all significant governance decisions. 

But here we see the consequence of the bridge provision. Because CER designation automatically triggers NIS2 essential entity status, the board of a CER-designated entity is subject to the NIS2 management body obligations as a direct result. The CER Act does not impose personal board liability for the resilience plan. NIS2 does impose personal board liability for the cybersecurity programme. And the two programmes must be coherent, because they govern the same organisation responding to the same incidents.

 A board that says "we will engage with the NIS2 governance obligations but treat the CER resilience plan as a management matter" has misunderstood the architecture. The resilience plan under CER and the cybersecurity programme under NIS2 should be aligned: same governance owner, coordinated risk assessments, unified incident reporting playbook. If the board is already engaged with NIS2 governance as it should be, the CER resilience plan belongs in the same governance framework, approved by the same body, reviewed on the same cycle. 

Should the board approve the resilience plan? 

The CER Act does not specify which corporate body must adopt or approve the resilience plan. This is a deliberate legislative choice, the CER framework focuses on outcomes, not on internal governance allocation. 

We nonetheless recommend that the board approve it, for three reasons. 

First, the resilience plan is a strategic document of the highest order. It defines how the organisation will protect, withstand, respond to and recover from incidents that could disrupt essential services. For an energy producer, a blackout due to lacking physical security can have catastrophic consequences. It has direct implications for capital expenditure, operational priorities, contractor relationships, and regulatory standing. This is precisely the type of decision that belongs at board level, not because the law requires it, but because that is what strategic governance means. 

Second, consistency with the NIS2 governance standard. The board is already required under Article 31 of the NIS2 Law to approve the cybersecurity risk management measures. Having the board approve the CER resilience plan alongside the NIS2 cybersecurity programme produces a coherent governance posture across both frameworks, demonstrating to both the sectoral authority and the CCB that the board exercises genuine oversight of the organisation's full resilience posture, physical and cyber. 

Third, evidentiary value. Board minutes recording formal approval of the resilience plan, and periodic review of its implementation, are the most powerful evidence available that the organisation has treated physical resilience as a genuine governance priority. If the organisation faces an enforcement action or a civil claim following an incident, those minutes matter. 

The single programme imperative 

The practical recommendation is simple to state and genuinely difficult to implement: treat CER and NIS2 as one coordinated compliance programme, not two parallel projects. 

This means one governance owner, typically the CISO or a Chief Resilience Officer with both physical and cyber scope, reporting to the board through a single consolidated dashboard. It means coordinated risk assessments that cover both physical and cyber threat scenarios and map the dependencies between them. It means a unified incident response playbook that handles notification cascades simultaneously, with pre-approved template notifications and pre-designated authority contacts for the NCCN, the CCB, and the competent sectoral authority. And it means a board that reviews both programmes together, on the same cycle, through the same reporting structure. 

The organisations that build this integrated architecture now, before designation, before the first inspection and before the first incident, will be in a fundamentally stronger position than those that treat each regulatory development as a separate workstream to be addressed when it becomes urgent.

One question to ask yourself today 

If you would like to discuss how to build an integrated CER and NIS2 compliance programme for your organisation, including the governance structure, the unified incident response playbook, or the board approval process for the resilience plan, Timelex would be glad to help. You can reach Geert Somers at geert.somers@timelex.eu or Wout Platteau at wout.platteau@timelex.eu. 

Geert Somers is a founding partner at Timelex and co-leads the firm's digital regulation and cybersecurity practice. Wout Platteau is associate at Timelex specialising in cybersecurity law and CER compliance. 

This post reflects EU and Belgian law as it stood in June 2026 and is intended as general legal information. It does not constitute legal advice for any specific situation. The Belgian CER Act of 19 December 2025 is recent legislation and awaits implementing royal decrees. It is intended as general legal information and does not constitute legal advice.*