In short
NIS2 obliges affected entities to manage security on a risk basis: every measure rests on a documented, repeatable risk analysis. A seven-step approach has proven itself — define the scope, inventory assets, identify threats, assess risks, decide on treatment, implement measures, and keep the analysis current. NIS2 does not prescribe a specific method; ISO/IEC 27005 and Germany's BSI Standard 200-3 are the established choices. Management must approve the risk management measures and oversee their implementation — and can be held personally accountable.
What does NIS2 require for risk analysis?
The core of NIS2 is a risk-based approach: affected entities must take appropriate and proportionate technical, operational, and organizational measures to manage the risks to their IT and services (Article 21 of the directive, Section 30 BSIG in Germany). Proportionate means the measures follow from the entity's risk exposure, its size, and the potential impact of an incident — none of which can be justified without a risk analysis.
NIS2 follows an all-hazards approach: it covers not only cyberattacks but also physical causes such as power failures, natural events, or human error. The risk analysis must be documented, traceable, and repeatable — a one-off snapshot is not enough. The law does not prescribe a specific methodology.
Steps 1 and 2: how do you define the scope and inventory assets?
Start from what must be protected. In practice, the reliable route is to begin with the critical services and business processes — the ones whose failure would hit customers, supply, or legal obligations — and work backwards to the supporting systems, data, and service providers.
The second step is a solid asset inventory: systems, applications, data sets, networks, and external services, each with an owner, criticality, and a classification for confidentiality, integrity, and availability. This inventory is the foundation — the risks you analyze always attach to assets you know about. Outdated or incomplete inventories are the most common cause of blind spots in practice.
Steps 3 and 4: how do you identify and assess risks?
Established catalogs keep the identification complete: the elementary threats of the BSI IT-Grundschutz methodology, or the threat and vulnerability lists in ISO/IEC 27005. From these, formulate concrete risk scenarios per asset group — for example, “ransomware encrypts the production database” or “failure of the only data center location.”
Each scenario is assessed by likelihood and impact — on defined scales used consistently across the company (four levels is common). Risk acceptance criteria, set in advance, determine from which level a risk must be treated. The result is a prioritized risk register: the ordered list of all assessed risks with owners.
Steps 5 and 6: how do you treat risks and implement measures?
For every risk above the acceptance threshold there are four treatment options:
- Mitigate: technical or organizational measures reduce likelihood or impact — the standard case
- Avoid: the risky activity or technology is discontinued or replaced
- Transfer: the risk is shifted, for example through insurance or contractual arrangements with providers
- Accept: the residual risk is knowingly carried — documented and approved at the appropriate level
Annex A of ISO/IEC 27001 (93 controls) has proven itself as the measure catalog — it covers the areas Section 30 BSIG requires, such as access control, cryptography, business continuity, and supply chain security. Every measure needs an owner, a deadline, and a traceable implementation status; the remaining residual risk is documented and formally accepted.
Step 7: how do you keep the risk analysis current?
A risk analysis ages quickly: new systems, new suppliers, new threat landscapes. What works in practice is a fixed review cycle — at least annually — plus event-driven updates after material changes, security incidents, and the onboarding of new critical service providers.
NIS2 explicitly puts management on the hook: executives must approve the risk management measures, oversee their implementation, and undergo regular training (Section 38 BSIG) — and can be held personally accountable for violations. Regular management reporting covering the risk posture, measure progress, and open residual risks is therefore not optional polish but part of compliance.
Which method should you choose — ISO 27005, BSI 200-3, or your own matrix?
NIS2 does not mandate a method — what matters is that the approach is documented, consistent, and repeatable. ISO/IEC 27005 is the right choice if you are building or certifying an ISO 27001 ISMS anyway; BSI Standard 200-3 fits organizations close to IT-Grundschutz or the German public sector. To get started, a lean, self-defined risk matrix is fine — as long as scales, acceptance criteria, and responsibilities are cleanly defined.
Set up the risk analysis properly once and it serves several regimes at the same time: NIS2, ISO 27001 (clauses 6 and 8), and GDPR risk assessments all draw on the same base. Flux Platform covers the full cycle — assets from the CMDB with CIA classification, a risk register with assessment and treatment workflows, measures mapped to ISO 27001 and NIS2, and reports that let management demonstrably meet its approval duty.
Frequently asked questions
How often must the NIS2 risk analysis be repeated?
NIS2 sets no fixed interval but requires effective, current risk management. The established practice is a full review at least once a year, plus event-driven updates — for new systems, material changes, security incidents, or new critical service providers.
Which method does NIS2 require for the risk analysis?
None specifically. NIS2 requires a risk-based, all-hazards approach with a documented, repeatable procedure. ISO/IEC 27005 and BSI Standard 200-3 are established in practice; a self-defined risk matrix is also acceptable if scales and acceptance criteria are cleanly defined.
Is a spreadsheet enough for the NIS2 risk analysis?
For the very first pass, a spreadsheet can do. In ongoing operation it becomes a risk itself: no versioning, no workflows, no links to assets and measures, no reliable evidence for supervisors or auditors. A tool-based risk register keeps assessments, owners, and history consistent.
Does management have to approve the risk analysis?
Yes. Under Section 38 BSIG, management must approve the risk management measures and oversee their implementation — and can be held personally accountable for violations. A documented approval of the risk analysis and treatment plan is the usual evidence.
How does this differ from an ISO 27001 risk assessment?
At the core it doesn't: both require documented, repeatable risk management with assessment and treatment. Organizations already running an ISO 27001 ISMS with a maintained risk register largely satisfy the NIS2 requirement and mainly need to sharpen the all-hazards view and management reporting.