Sector-Specific and Cross-Border Case Studies

1. Setting the Scene: Why Sector & Cross‑Border Case Studies Matter

NIS2 (Directive (EU) 2022/2555) has applied since October 2024 and must be implemented in all EU Member States’ national laws by 17 October 2024. As of today (late 2025), most Member States have adopted (or are finalising) their national NIS2 acts, often with sector‑specific nuances.

This module assumes you already understand:

• Core NIS2 obligations (risk management, incident reporting, governance, supervision, sanctions)
• The essential vs important entity classification
• How NIS2 can be mapped to frameworks like ISO/IEC 27001 and SOC 2

Here we stress‑test that knowledge with complex sectoral and cross‑border scenarios. You will:

• Apply NIS2 requirements to energy, cloud, and healthcare cases
• Analyse multi‑country group compliance strategies
• Deal with staggered and conflicting national rules
• Extract lessons from early enforcement trends (2024–2025)

As you go through each step, treat the scenarios like mini consulting engagements: identify the legal classification, determine the applicable obligations, and design a realistic compliance response under time and budget constraints.

2. Recap: Essential vs Important & Cross‑Border Triggers

Before diving into cases, anchor the key classification rules:

2.1 Essential vs Important (high‑level)

NIS2 Annex I (essential) and Annex II (important) list sectors and subsectors. In practice, national transposition acts:

• Refine thresholds (e.g., MW capacity in energy, number of hospital beds, cloud turnover)
• Add or clarify sub‑sectors (e.g., specific digital infrastructure types)

Essential entities typically include:

• Energy operators (electricity, gas, oil) above national thresholds
• Certain digital infrastructure (IXPs, DNS, TLD registries, some data centres)
• Healthcare providers (hospitals, clinics above size thresholds, e‑prescription services)
• Public administration in many Member States (depending on national choices)

Important entities often include:

• Many digital service providers (e.g., some cloud providers, SaaS) not captured as essential
• Manufacturers of certain critical products
• Smaller but still significant providers in the same sectors as essential entities

2.2 Cross‑Border and Group Dimensions

Key NIS2 cross‑border features:

1. Main establishment / representative (Art. 26)

• For entities established in more than one Member State, the main establishment is usually where the core network and information systems are located or where decisions are taken.
• For entities not established in the EU but offering services in the EU, a representative in the EU is required.

1. Lead competent authority

• The authority of the Member State of main establishment usually acts as the lead, coordinating with others where services are provided.

1. Group‑level vs entity‑level compliance

• NIS2 obligations attach to entities, not to corporate groups as such, but group‑wide policies and SOCs (security operations centres) are often used to comply efficiently.

When analysing a case, always ask:

1. Is the entity in Annex I or II?
2. Does national law upgrade/downgrade its status?
3. Where is the main establishment?
4. Is there a non‑EU parent or key supplier that changes the risk picture?

3. Energy Sector Case Study: Cross‑Border TSO/DSO Group

Scenario

NordGrid Group operates electricity transmission and distribution across three EU Member States:

• NordGrid SE – Transmission System Operator (TSO) in State A (headquarters; largest network; regional control centre)
• NordGrid D – Distribution System Operator (DSO) in State B
• NordGrid C – DSO in State C, operating mainly medium‑voltage networks

All three countries have now transposed NIS2, but with slightly different thresholds and enforcement practices:

• State A: TSOs and DSOs above 100,000 customers are essential; strong, proactive supervision.
• State B: TSOs essential; DSOs with ≥50,000 customers are important; supervision mainly ex post.
• State C: TSOs and DSOs above 20,000 customers are essential; the national energy regulator is also the NIS2 authority.

NordGrid SE hosts:

• The central SCADA/EMS platform used by all three entities
• A central SOC (24/7) and a group CSIRT‑like team
• A shared OT patch management system

Questions to Analyse

1. Classification

• How are the three entities classified under NIS2 and national laws?
• Is the group itself classified, or only the legal entities?

1. Main establishment & lead authority

• Which Member State’s authority likely acts as the lead for cross‑border supervision?

1. Risk management & incident reporting

• How should NordGrid structure its risk management and incident reporting processes across the three countries?

Reasoned Analysis (Model Answer)

1. Classification

• NordGrid SE (State A): TSO with large customer base ⇒ essential entity under NIS2 and national law.
• NordGrid D (State B): DSO above 50,000 customers ⇒ important entity (per State B’s law).
• NordGrid C (State C): DSO above 20,000 customers ⇒ essential entity (State C’s stricter law).
• NIS2 applies to entities, not groups, so NordGrid Group as a holding company is not itself an entity unless it also operates covered services.

1. Main establishment & lead authority

• The core network and information systems (SCADA/EMS, SOC, OT patching) and strategic decision‑making sit in State A.
• Therefore, State A’s NIS2 authority is likely the lead competent authority, coordinating with State B and C.

1. Risk management & incident reporting

• NordGrid can adopt a group‑wide ISMS (e.g., ISO/IEC 27001 for OT and IT) with local add‑ons.
• The central SOC can serve all entities, but:
• Incident classification must respect each national law’s thresholds and timelines.
• For a major SCADA incident affecting all three countries, NordGrid should:
• Perform a single technical analysis, but
• File separate notifications to each national authority, coordinated by the lead authority in State A.
• Essential entities (SE, C) must expect proactive supervision (audits, requests for evidence), while the important entity (D) may face ex post supervision but still needs equivalent technical controls.

Visual Description

Imagine a hub‑and‑spoke diagram:

• The hub (State A) contains the Group SOC and SCADA/EMS.
• Three spokes go to State A, B, C entities.
• Arrows from each entity to its national NIS2 authority; a bold arrow from the Group SOC to State A authority as lead.

Use this mental image to remember: centralised operations, decentralised legal accountability.

4. Thought Exercise: Tuning Controls to Mixed Essential/Important Status

You are hired as an external consultant by NordGrid Group.

Task: You must propose a three‑layer control architecture that:

1. Ensures essential entities (SE and C) clearly meet the higher expectations of proactive supervision.
2. Keeps implementation overhead low for the important entity (D), while still meeting NIS2.
3. Respects that all three share the same SCADA and SOC.

Write down (or mentally structure) your answer in three layers:

1. Group‑core controls (mandatory for all)

Examples to consider:

• Unified risk management methodology (aligned to ISO/IEC 27005)
• Shared SOC with standardised incident playbooks
• Common OT hardening baselines and change management

1. Essential‑only enhancements

Examples to consider:

• More frequent OT security testing and red‑teaming
• More detailed business continuity and crisis exercises with regulators
• Additional board‑level reporting and documented risk acceptance

1. Local/national overlays

Examples to consider:

• Country‑specific incident reporting templates and thresholds
• Local training on national regulatory expectations
• Mapping of national energy‑sector rules (e.g., REMIT, network codes) to NIS2 duties

Reflection prompts:

• Where would you place vulnerability scanning and patch management for OT? Group‑core or essential‑only?
• How do you prevent the important entity (D) from becoming a weak link in incident response, given it uses the same SCADA?

Take 3–4 minutes to sketch your layers before moving on.

5. Cloud Service Provider Case Study: Multi‑Region EU Operations

Scenario

SkyCompute is a mid‑size cloud provider headquartered in State D (EU), with:

• Two large data centres in State D
• One smaller edge data centre in State E (EU)
• Significant customers in States F and G (EU), mostly SaaS startups and some hospitals using IaaS/PaaS

SkyCompute is ISO/IEC 27001 certified and has a SOC 2 Type II report for US clients.

National NIS2 transposition:

• State D treats large cloud providers as essential entities when they exceed certain turnover and customer thresholds; SkyCompute exceeds them.
• State E classifies data centres above a certain power usage as important entities; SkyCompute’s edge DC is below that threshold, so not a separate entity.
• States F and G have implemented NIS2 but have not added extra requirements for foreign cloud providers beyond NIS2.

Questions

1. Is SkyCompute an essential or important entity, and in which State?
2. Does the edge DC in State E create a separate NIS2 entity?
3. How should SkyCompute leverage ISO 27001 and SOC 2 to comply with NIS2, and where are the gaps?
4. How does cross‑border incident reporting work if a major outage hits customers in D, F, and G simultaneously?

Reasoned Analysis (Model Answer)

1. Classification & main establishment

• SkyCompute is established in State D, operating cloud computing services at scale ⇒ essential entity under State D’s NIS2 law.
• The main establishment is in State D (HQ, main DCs, decision‑making).

1. Edge DC in State E

• The edge DC is a facility, not a separate legal entity.
• It does not cross the threshold to be classified on its own in State E.
• SkyCompute, as an entity in State D, remains responsible for that DC as part of its network and information systems.

1. Leveraging ISO 27001 & SOC 2

• ISO/IEC 27001 and SOC 2 give a strong baseline for Annex I and II risk management measures (access control, logging, change management, etc.).
• Typical gaps for NIS2 include:
• Governance: Board‑level accountability, management liability, and explicit risk acceptance documentation.
• Incident reporting: NIS2‑specific timelines (e.g., early warning, intermediate, final report) and coordination with the national CSIRT.
• Supply chain: NIS2’s explicit focus on risk from suppliers, including non‑EU hyperscalers and hardware vendors.
• Business continuity: More detailed service continuity and crisis communication plans for essential services.

1. Cross‑border incident reporting

• A major outage affecting customers in D, F, and G is reported to State D’s NIS2 authority (lead), since SkyCompute is established there.
• State D’s authority coordinates with F and G if necessary.
• SkyCompute should maintain:
• A single internal incident record but
• Customer‑specific communication (e.g., hospitals in F and G) that may be required by local health or data protection laws.

Visual Description

Picture a map of the EU with:

• A large node in State D labelled SkyCompute (essential)
• A small satellite node in State E labelled Edge DC (facility only)
• Arrows from D to F and G representing service provision, not separate NIS2 establishments.

A thick arrow from SkyCompute to State D’s NIS2 authority shows the lead supervisory relationship.

6. Quick Check: Cloud Provider Classification & Reporting

Apply what you just learned about SkyCompute to test your understanding.

7. Healthcare Case Study: Hospital Group with Mixed Digitalization

Scenario

MedEuropa Group operates hospitals in State H and State I:

• MedEuropa H1: Large university hospital in State H, highly digitalised (EHR, e‑prescription, telemedicine).
• MedEuropa H2: Medium‑size regional hospital in State H, partial digitalisation.
• MedEuropa I1: Private specialist clinic in State I, heavy use of cloud‑hosted EHR (SkyCompute) and networked medical devices.

National NIS2 transposition:

• State H: All hospitals above 250 employees are essential entities; H1 and H2 qualify.
• State I: Only hospitals above 500 employees are essential; I1 is below the threshold but is still classified as an important entity due to critical services provided (cardiac surgery).

MedEuropa has a central IT and security team in State H, but I1 also has a local IT/security unit.

Key Issues

1. Classification asymmetry

• H1 and H2: essential (State H)
• I1: important (State I)

1. Use of external cloud (SkyCompute)

• EHR and imaging data for I1 are hosted on SkyCompute (an essential entity in State D).

1. Incident scenario

• A ransomware attack compromises MedEuropa’s central identity provider (IdP) in State H, used by all three hospitals.
• H1 and H2 experience full IT outage; I1 experiences degraded access to EHR but can use local emergency procedures.

Analysis

1. Who reports what, where?

• H1 and H2 (essential entities in State H) must:
• Report a significant incident to State H’s NIS2 authority within the prescribed timelines.
• Coordinate with the national health authority if required by sectoral rules.
• I1 (important entity in State I) must:
• Assess whether the incident significantly affects the provision of its services.
• If yes, report to State I’s NIS2 authority, potentially referencing that the root cause lies in a shared IdP in State H.

1. Group‑level vs local responsibilities

• The central IdP is a shared asset; the group security team in H has a duty of care to all hospitals.
• However, legal responsibility for NIS2 compliance (including reporting) lies with each entity:
• H1, H2, I1 each need their own incident classification and reporting workflow.

1. Supply chain and dependency management

• I1 depends on SkyCompute for EHR; if SkyCompute itself has an incident (e.g., outage, data breach), this may cascade into I1’s NIS2 reporting.
• MedEuropa should maintain a dependency matrix:
• Which services are critical for which hospitals?
• Which are on‑prem vs cloud vs shared group services?

1. Governance challenge

• The board of MedEuropa Group must ensure:
• Consistent minimum security controls across H1, H2, and I1.
• Recognition that essential entities may face higher fines and more intensive supervision.
• Documented decisions where risk differs (e.g., older devices at I1, slower patching cycles).

This case illustrates how mixed classification and shared identity infrastructure can create complex, multi‑jurisdictional incident handling requirements.

8. Handling Staggered National Rules: Conflict Resolution Exercise

Assume the following twist to the MedEuropa scenario:

• State H requires essential entities to notify within 12 hours of becoming aware of a significant incident (stricter than NIS2’s standard early‑warning timeline).
• State I follows the baseline NIS2 timing (e.g., early warning within 24 hours).
• The IdP ransomware attack is detected at 08:00 on Monday.

Your task: Design a group incident handling timeline for the first 48 hours that:

1. Complies with both States’ rules.
2. Avoids inconsistent or contradictory information being sent to two different authorities.
3. Leverages the central security team efficiently.

Consider the following milestones and draft them in your notes:

• T0 (08:00 Monday): Initial detection.
• T+X: Internal incident classification and triage.
• T+Y: Early warning/initial notification to State H.
• T+Z: Early warning/initial notification to State I (if required).
• T+24h and T+48h: Intermediate and final reports.

Reflection questions:

• Do you send a single, joint notification for H1 and H2, or separate ones? Why?
• How do you ensure that the description of the root cause (IdP compromise) is synchronised between the notifications to State H and State I?
• What internal communication mechanisms (e.g., war room, shared incident tracker) would you put in place to ensure consistency?

Spend 3–4 minutes outlining your timeline and justifications.

9. Early Enforcement Trends (2024–2025): Pitfalls & Best Practices

By late 2025, several trends have emerged from early NIS2 implementation and enforcement in Member States that transposed on time or early. While details vary, common patterns include:

9.1 Common Pitfalls

1. Formalism without substance

• Entities copy‑paste ISO 27001 policies but do not adapt them to NIS2‑specific obligations (e.g., incident timelines, governance).
• Regulators increasingly ask for evidence of implementation, not just documentation.

1. Underestimating governance duties

• Senior management is nominally responsible but not trained on NIS2.
• No clear process for board‑level risk acceptance or for assigning responsibility for NIS2 non‑compliance.

1. Fragmented incident response

• Large groups lack a single incident taxonomy across countries.
• Local teams decide independently whether to report, leading to inconsistent notifications.

1. Weak supply chain oversight

• Entities rely heavily on cloud, MSPs, and OT vendors, but contracts lack NIS2‑aligned clauses (e.g., incident support, notification timelines, audit rights).

1. Ignoring cross‑border coordination

• No clear internal rule on which entity leads in a multi‑country incident.
• Authorities receive overlapping or contradictory reports from related entities.

9.2 Emerging Best Practices

1. Group‑wide NIS2 playbooks

• Large groups develop cross‑border incident playbooks specifying:
• Lead entity for coordination
• Internal reporting deadlines (stricter than legal ones)
• Templates for multi‑jurisdiction notifications.

1. NIS2‑aware board training

• Annual (or more frequent) training for board and senior management on:
• NIS2 obligations and liability
• Recent enforcement cases and fines
• Sector‑specific expectations (e.g., healthcare vs energy).

1. Integrated ISMS with national overlays

• Use a single ISMS (often ISO 27001‑based) for the group, then attach country‑specific annexes for NIS2 and sectoral laws.

1. Contractual alignment with key suppliers

• New and renewed contracts with cloud/OT/MSP providers include:
• NIS2‑aligned incident support and notification SLAs
• Cooperation clauses for regulatory investigations
• Minimum security requirements and audit rights.

1. Central registers and dependency mapping

• Maintain a register of NIS2‑covered entities within the group (classification, main establishment, authorities, contacts).
• Maintain dependency maps linking critical services to IT/OT systems and suppliers.

When analysing any case, test it against these pitfalls and best practices to see where the entity would likely face regulatory criticism or praise.

10. Flashcard Review: Key Cross‑Border & Sector Concepts

Flip through these flashcards to reinforce core concepts from the case studies.