Core Cybersecurity Risk-Management Measures Under NIS2 - Mastering the EU NIS2 Directive: From Legal Framework to Practical Compliance

1. From NIS1 to NIS2: Why Risk-Management Is Now Central

NIS2 (Directive (EU) 2022/2555) significantly raises the bar for cybersecurity in the EU. Since it had to be transposed by 18 October 2024 (about 1 year ago relative to today), most Member States now have national laws in force or in late-stage drafting.

Under NIS1, security obligations were often high-level and unevenly enforced. NIS2 changes this by:

Defining a core set of risk-management measures in Article 21(2).
Making these measures mandatory for both essential and important entities (see your earlier module on scope).
Linking them tightly to supervision and sanctions (Articles 31–34).

NIS2 is technology-neutral and risk-based:

It does not prescribe specific products or tools.
It requires entities to implement appropriate and proportionate technical, operational and organisational measures (TOMs) to manage cybersecurity risks.
These measures must cover network and information systems, the physical environment, and people/processes.

For this module, we treat Article 21(2) as the core checklist, and we map it to ISO/IEC 27001:2022 and related standards (e.g., ISO/IEC 27002:2022, ISO 22301, ISO 27035, ISO 27036, ISO 27005). Your task is to understand each NIS2 requirement and translate it into concrete controls and risk-based choices.

> Key framing: Think of NIS2 Article 21(2) as “what must be covered”, and ISO 27001 + other frameworks as “how to implement it in a structured way.”

2. Article 21(2) Overview: The NIS2 Risk-Management Menu

Article 21(2) lists the minimum areas your measures must cover. Paraphrased and grouped, they are:

Risk analysis and information system security policies
Incident handling (detection, response, reporting)
Business continuity & crisis management (including backup, disaster recovery)
Security in supply chains and supplier relationships
Security in network and information systems acquisition, development and maintenance (including vulnerability handling and disclosure)
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
Basic cyber hygiene and cybersecurity training
Policies and procedures regarding the use of cryptography and, where appropriate, encryption
Human resources security, access control policies and asset management
Use of multi-factor authentication (MFA), continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems

Each of these is mandatory in scope, but implementation is risk-based and proportionate:

A small regional water utility and a pan-European cloud provider must both address incident handling, but the depth and tooling will differ.
Supervisory authorities will assess whether measures are appropriate given the entity’s risk profile, not whether it copied a specific standard.

In the next steps, we unpack these clusters, map them to ISO 27001 controls, and explore how far you need to go under the proportionality principle.

3. Risk Analysis & Security Policies: Building the NIS2 Control Spine

3.1 What NIS2 Requires

Article 21(2)(a) requires:

> “policies on risk analysis and information system security”

This is the foundation: if your risk analysis and policies are weak, all other measures become arbitrary.

3.2 Mapping to ISO/IEC 27001:2022

Key mappings:

Clause 4–6: Context of the organization, needs and expectations, risk assessment and treatment.
Annex A controls (selected):
A.5.1 Policies for information security
A.5.3 Segregation of duties
A.5.7 Threat intelligence
A.5.9 Inventory of information and other associated assets
A.5.10 Acceptable use of information and associated assets
A.5.12 Classification of information
ISO/IEC 27005: risk management methodology.

3.3 What “Good Enough” Looks Like (for NIS2)

A NIS2-compliant setup typically includes:

Formal risk management methodology

Documented in a policy (e.g., based on ISO 27005 or ENISA guidance).
Defines impact criteria (e.g., safety, service continuity, data protection, financial loss, reputational impact).
Defines likelihood scales, risk matrix, and treatment options.

Up-to-date asset inventory and criticality classification

Systems, applications, data sets, networks, facilities.
Criticality mapped to essential/important services under NIS2.

Information security policy suite

Top-level Information Security Policy approved by top management.
Supporting policies: access control, acceptable use, mobile/BYOD, remote access, backup, logging & monitoring, etc.

Risk register and treatment plans

Documented high-risk scenarios, owners, deadlines, and chosen controls.

3.4 Edge Case to Consider

Entity already ISO 27001 certified:
Usually close to NIS2-compliant, but not automatically compliant.
You must check that the scope of the ISMS covers all NIS2-relevant services and systems, and that NIS2-specific topics (e.g., secured emergency communications) are explicitly addressed.

> Take-away: For NIS2, you need traceability from risk → policy → controls → evidence. ISO 27001 provides the structure, but you must align the scope and risk criteria with NIS2’s focus on essential/important services.

4. Thought Exercise: Designing a Minimal NIS2 Risk Methodology

Imagine you are the security lead of a mid-sized electricity distribution operator (an essential entity under NIS2) in an EU Member State where the national NIS2 law entered into force in mid-2025.

Your board asks for a 2-page summary of your cybersecurity risk-management approach to show the regulator during an upcoming inspection.

Task: Sketch the outline of that 2-page document. In bullet points, write down:

Risk criteria:

Which impact dimensions will you use (e.g., safety, supply continuity, environment, financial, legal)?
How will you grade them (e.g., 1–5)?

Risk sources & scenarios:

List at least 5 threat scenarios specific to electricity distribution (e.g., compromise of SCADA, ransomware on billing systems, OT–IT gateway abuse).

Method steps:

How often do you reassess risks?
Who is involved (roles, not names)?
How do you decide when a risk is unacceptable and must be treated?

Link to controls:

For one high-risk scenario, write how you would link it to at least three concrete controls (e.g., network segmentation, MFA, incident playbook).

> Reflection: After you draft your outline, ask yourself: Would a regulator be able to see that my controls are clearly driven by risk, not just best-practice checklists?

5. Incident Handling & Reporting: From Detection to Lessons Learned

5.1 NIS2 Requirements

Article 21(2)(b)–(c) covers:

Incident handling
Business continuity and crisis management (we focus on continuity later; here we emphasize incident handling itself)

These link to Articles 23–24 on incident notification (early warning, incident notification, final report) with strict timeframes.

5.2 Mapping to ISO & Related Standards

ISO/IEC 27001 Annex A:
A.5.26 Response to information security incidents
A.8.7 Event logging
A.8.15 Logging and A.8.16 Monitoring activities
A.8.23 Web filtering, A.8.24 Use of privileged utility programs (supporting controls)
ISO/IEC 27035-1/2: Incident management principles and procedures.
ENISA guidance on incident reporting under NIS2 (drafts and final documents published around 2023–2025).

5.3 Practical Control Set

A risk-based NIS2 implementation usually includes:

Incident Management Policy & Playbooks

Defined severity levels (e.g., SEV1–SEV4) with mapped actions.
Playbooks for top scenarios: ransomware, DDoS, data exfiltration, OT system compromise.

Detection & Monitoring

Centralized logging (SIEM or log management) for critical systems.
Alerting thresholds aligned with NIS2’s notion of a “significant incident” (impact on service, duration, geographical spread).

Structured Response Process

Triage → Containment → Eradication → Recovery → Post-incident review.
Clear roles: incident manager, communications lead, legal/compliance, business owner.

Regulatory Reporting Workflow

Internal trigger conditions for NIS2 reporting (e.g., service unavailability > X hours, serious impact on safety).
Templates for early warning and incident notification including required fields (time, cause, impact, mitigation, cross-border effect).
Coordination with data protection officer if GDPR personal data breach reporting is also required.

Lessons Learned & Control Improvement

Root cause analysis (technical + organizational).
Systematic update of risk register and controls.

5.4 Edge Case

Cloud-reliant SMEs as “important entities”:
They may have limited in-house SOC capabilities.
Proportionate implementation can rely on managed detection and response (MDR), but the entity remains accountable under NIS2 and must ensure the provider’s SLAs and reporting support NIS2 incident timeframes.

> Take-away: Under NIS2, incident handling is not just a technical function. It is a regulated process with legal deadlines and documentation requirements.

6. Quick Check: Incident Handling Under NIS2

Test your understanding of how incident handling links to NIS2 obligations.

An important entity suffers a ransomware attack that briefly encrypts some internal HR files but does not affect the delivery of the NIS2-regulated service. Which statement best reflects its NIS2 obligations?

It clearly has no NIS2 obligations because the regulated service was not impacted at all.
It must still perform incident handling and assess whether this is a ‘significant incident’ under NIS2, even if it might ultimately not report it.
It only has to report the incident to the data protection authority under GDPR; NIS2 never applies to confidentiality-only breaches.

Show Answer

Answer: B) It must still perform incident handling and assess whether this is a ‘significant incident’ under NIS2, even if it might ultimately not report it.

NIS2 focuses on the continuity and security of essential/important services, but entities must still **handle all incidents systematically** and assess whether they qualify as ‘significant’ under national NIS2 rules. A confidentiality-only breach may still be relevant (e.g., if it indicates deeper compromise). So the entity must perform incident handling and a NIS2 significance assessment, even if it ultimately decides that no NIS2 notification is required.

7. Business Continuity, Crisis Management & Backup: Keeping Services Alive

7.1 NIS2 Requirements

Article 21(2)(c) explicitly includes:

Business continuity
Crisis management
Backup management

The focus is on service continuity, not just data availability.

7.2 ISO & Related Standards

ISO 22301:2019 – Business continuity management systems.
ISO/IEC 27001 Annex A:
A.5.29 Information security during disruption
A.8.13 Information backup
A.5.30 ICT readiness for business continuity

7.3 Practical Implementation

Business Impact Analysis (BIA)

Identify critical processes linked to NIS2 services.
Define Maximum Tolerable Downtime (MTD) and Recovery Time Objective (RTO) for key systems.

Continuity & Disaster Recovery Plans

Documented procedures for switching to alternate sites, manual workarounds, or degraded modes.
Clear escalation trees and decision thresholds for crisis declaration.

Backup Strategy

Risk-based selection of RPO (Recovery Point Objective) per system.
3-2-1 principle: 3 copies, 2 media types, 1 off-site/immutable.
Regular restore tests and documentation.

Crisis Management Structures

Crisis team with defined roles (CEO/COO, CISO, legal, communications, operations).
Crisis communication plan (internal, regulators, media, customers).
Coordination with national CSIRTs and sectoral authorities.

7.4 Proportionality Examples

Large telecom operator (essential):
Geo-redundant data centers, hot standby for critical systems, complex crisis simulation exercises.

Mid-sized waste management company (important):
Nightly backups to cloud, tested quarterly; documented manual fallback processes; tabletop exercises once per year.

> Take-away: Under NIS2, backups and DR are not optional good practices. They are explicitly mandated and must be demonstrably aligned with service continuity requirements.

8. Supply Chain, Secure Development & Vulnerability Management

8.1 NIS2 Requirements

Article 21(2)(d)–(e) covers:

Security in supply chains and supplier relationships
Security in the acquisition, development and maintenance of network and information systems, including:
Vulnerability handling.
Coordinated vulnerability disclosure (CVD) where appropriate.

Given recent high-profile supply-chain attacks (e.g., SolarWinds, Kaseya), NIS2 places strong emphasis on third-party risk.

8.2 ISO Mapping

ISO/IEC 27001 Annex A:
A.5.19 Information security in supplier relationships
A.5.20 Addressing information security within supplier agreements
A.5.21 Managing information security in the ICT supply chain
A.8.25 Secure development life cycle
A.8.26 Application security requirements
A.8.27 Secure system architecture and engineering principles
A.8.28 Secure coding
A.8.33 Vulnerability management
ISO/IEC 27036: Information security for supplier relationships.
ISO/IEC 29147 & 30111: Vulnerability disclosure and handling.

8.3 Concrete Controls

Supplier Risk Management Framework

Supplier classification (critical vs non-critical).
Security clauses in contracts (MFA, logging, patching SLAs, breach notification aligned with NIS2, audit rights).
Onboarding and periodic reassessment (e.g., questionnaires, attestations, audits).

Secure SDLC (for in-house or heavily customized systems)

Security requirements in design (threat modeling).
Code reviews and static/dynamic analysis.
Pre-production security testing (penetration testing, fuzzing for critical components).

Vulnerability Management

Centralized vulnerability register.
Patch management policy with risk-based timelines (e.g., critical internet-facing vulnerabilities patched within X days).
External vulnerability disclosure channel (security.txt, public PGP key, or bug bounty program for large entities).

8.4 Edge Case: Heavy Cloud Outsourcing

A small digital infrastructure provider classified as an important entity may rely almost entirely on hyperscale cloud providers.
Proportional NIS2 implementation still requires:
Due diligence on provider certifications (e.g., ISO 27001, SOC 2) and their incident/continuity capabilities.
Contractual mapping of NIS2 reporting timelines and access to logs/forensics.
Internal processes to aggregate and act on cloud provider alerts.

> Take-away: You cannot outsource NIS2 responsibility. You can outsource implementation, but you must retain governance and assurance over third parties.

9. Quick Check: Supply Chain Security

Evaluate how NIS2 impacts supplier relationships.

Which of the following best aligns with NIS2’s expectations for managing ICT supply-chain risk?

Relying solely on the supplier’s ISO 27001 certificate as proof of full NIS2 compliance.
Including security requirements and NIS2-aligned incident notification clauses in supplier contracts, plus performing periodic risk-based assessments.
Treating suppliers as fully responsible for any incident involving their systems, so no internal controls are needed.

Show Answer

Answer: B) Including security requirements and NIS2-aligned incident notification clauses in supplier contracts, plus performing periodic risk-based assessments.

NIS2 requires entities to actively manage security in supply chains. That includes **contractual security clauses** and **ongoing, risk-based assessments**. ISO 27001 certification is useful evidence but not sufficient on its own, and legal responsibility under NIS2 remains with the regulated entity.

10. Human Factor, Training, Cryptography & Access Control

10.1 NIS2 Requirements

Article 21(2)(f)–(j) emphasizes:

Policies to assess effectiveness of cybersecurity measures
Basic cyber hygiene and cybersecurity training
Cryptography and encryption policies
Human resources security, access control, and asset management
MFA, continuous authentication, and secured communications (including emergency communications)

10.2 ISO Mapping

ISO/IEC 27001 Annex A (selected):
A.5.14 Information security in project management (for effectiveness assessment)
A.6.3 Information security awareness, education and training
A.8.2 Privileged access rights
A.8.3 User access provisioning
A.8.4 Management of secret authentication information
A.8.5 Review of user access rights
A.8.9 Use of cryptography
A.8.10 Key management
A.7.4 Physical and environmental security

10.3 Practical Controls

Training & Awareness

Mandatory annual training for all staff, with role-based modules for admins, developers, and executives.
Phishing simulations, secure remote work guidelines.

Access Management & MFA

Centralized identity and access management (IAM).
MFA for all remote access and privileged accounts; risk-based MFA for general users.
Periodic access reviews (at least annually for high-risk systems).

Cryptography Policy

Approved algorithms and key lengths (aligned with current ENISA/EU recommendations).
Rules for TLS configuration, data-at-rest encryption, and key management (HSMs, rotation, separation of duties).

Effectiveness Assessment

KPIs and KRIs (e.g., patching timelines, phishing click rates, incident MTTR).
Internal audits and management reviews.
Penetration testing and red teaming for high-risk entities.

Secured Communications & Emergency Channels

Encrypted email and messaging for sensitive discussions.
Out-of-band, secure emergency channels (e.g., pre-registered phone trees, secure messaging apps with verified identities) for crisis situations.

> Take-away: NIS2 explicitly pulls people, identity, and cryptography into the core risk-management discussion. Weak MFA or training can undermine even the best technical defenses.

11. Applying Proportionality: Two Contrasting Mini-Case Studies

You will compare two entities and decide how proportionality affects implementation of the same NIS2 requirement.

Case A: Regional Hospital (Essential Entity)

Runs its own data center with electronic health records (EHR), imaging systems, and on-site labs.
Limited but dedicated IT and security team.
High safety and life-critical impact if systems fail.

Case B: Small Managed Service Provider (Important Entity)

Provides remote monitoring and maintenance for HVAC systems in critical infrastructure facilities.
Mostly cloud-based; staff are remote.
Failure impacts comfort and potentially some safety, but usually with longer time scales.

Task: For each of the three NIS2 topics below, write down how implementation differs between A and B, while both remain compliant.

Incident Detection & Monitoring

What tooling and coverage is minimally acceptable for each?
How often should logs be reviewed or alerts tuned?

Backup & Disaster Recovery

What RTO/RPO might be justified for core systems?
How often should they test restores?

MFA & Access Control

Which accounts must use MFA in each case?
Are there any justifiable exceptions, and how would you document them risk-wise?

> Reflection: Proportionality is not an excuse to do the minimum everywhere. It is a way to allocate more security to higher-impact risks while still covering all Article 21(2) topics in a defensible way.

12. Flashcard Review: Core NIS2 Risk-Management Concepts

Flip these cards (mentally or with your own notes) to reinforce key concepts from the module.

Article 21(2) NIS2: The central list of mandatory cybersecurity risk-management measures that essential and important entities must implement, covering areas such as risk analysis, incident handling, business continuity, supply-chain security, secure development, training, cryptography, access control, and MFA.
Proportionality (under NIS2): The principle that cybersecurity measures must be appropriate to the entity’s risk exposure, size, and the criticality of services. All Article 21(2) areas must be addressed, but depth and sophistication can vary based on risk.
Link between NIS2 and ISO/IEC 27001: NIS2 defines *what* must be covered in risk management; ISO/IEC 27001 provides a structured way to implement and document the *how*. ISO 27001 certification helps but does not guarantee NIS2 compliance unless scope and controls match NIS2 obligations.
Incident Handling vs. Incident Reporting: Incident handling is the internal technical and organizational process for managing security events; incident reporting under NIS2 is the legal obligation to notify competent authorities and CSIRTs about significant incidents within defined timeframes.
Supply-chain security under NIS2: A requirement to manage cybersecurity risks stemming from suppliers and service providers, including contractual security clauses, due diligence, and continuous monitoring of third-party risk. Responsibility remains with the regulated entity.
Business Continuity & Backup in NIS2: NIS2 explicitly mandates business continuity, crisis management, and backup management. Entities must be able to maintain or restore essential/important services within risk-based RTO/RPO targets, supported by tested backup and recovery processes.
MFA and secure communications: NIS2 explicitly calls for multi-factor authentication, continuous authentication solutions, and secured voice/video/text communications, including secured emergency communication systems, especially for access to critical systems and during crises.

Key Terms

NIS2: Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union, which replaced the original NIS Directive. It strengthens security and incident reporting obligations for essential and important entities.
Article 21(2): The part of NIS2 that lists the minimum cybersecurity risk-management measures entities must implement, including risk analysis, incident handling, business continuity, supply-chain security, secure development, training, cryptography, and access control.
Proportionality: The regulatory principle that security measures must be commensurate with the entity’s risk profile, size, and the criticality of the services provided, without being excessive or insufficient.
Essential entity: Under NIS2, an organization in a critical sector (e.g., energy, transport, health) that meets certain size/importance criteria and is subject to more stringent supervision and enforcement compared to important entities.
Important entity: An organization in sectors covered by NIS2 that is less critical than essential entities but still subject to the same substantive cybersecurity and incident reporting obligations, with generally lighter ex post supervision.
Incident handling: The end-to-end process of detecting, analyzing, containing, eradicating, and recovering from security incidents, including post-incident review and lessons learned.
Supply-chain risk: Cybersecurity risk arising from suppliers, service providers, and other third parties who design, deliver, maintain, or operate systems and services used by the entity.
ISO/IEC 27001:2022: The international standard specifying requirements for an information security management system (ISMS). Often used as a reference framework for implementing NIS2-compliant controls.
RTO (Recovery Time Objective): The maximum acceptable time that a system or process can be unavailable after a disruption before causing unacceptable impact.
Business Impact Analysis (BIA): A process to identify and evaluate the effects of disruptions on business functions, used to determine recovery priorities and objectives (RTO/RPO) for business continuity planning.
RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time (e.g., last 4 hours of transactions) that an organization is willing to tolerate after an incident.
Multi-factor authentication (MFA): An authentication method that requires at least two independent credentials (factors), such as something you know (password), something you have (token), and something you are (biometrics).
Coordinated Vulnerability Disclosure (CVD): A structured process in which security researchers and organizations work together to identify, report, and remediate vulnerabilities before they are widely disclosed.
ISMS (Information Security Management System): A systematic approach to managing sensitive information and related risks, including policies, procedures, and technical/organizational controls, as defined in ISO/IEC 27001.
SIEM (Security Information and Event Management): A class of tools that collect, normalize, and analyze log and event data from multiple sources to detect and respond to security incidents.