A risk analysis under NIS2 is not a paper exercise to be filed away. It is the connecting element between business risks, the technical reality in operations and demonstrable decisions. In practice many programmes do not fail due to missing security measures, but because priorities, responsibilities and acceptance boundaries (what is ‚justifiable‘, what is not?) are not clearly defined. NIS2 increases the pressure: management responsibility, the ability to report incidents and the evidence of ‚appropriate and proportionate‘ measures must coherently align.
This article provides a methodology that can be implemented in heterogeneous IT landscapes without freezing into model perfection. The focus is on metrics, decision thresholds and auditable documentation that support operations, security and management equally: What exactly is assessed? Which figures does management need? When is a risk ‚red‘ and who is authorised to accept it? And how do you prevent risk analyses from stalling in endless workshops?
Risk analysis under NIS2: What NIS2 practically requires
NIS2 requires risk-based organisational and technical measures. Less decisive is a particular framework than the ability to systematically identify, assess, treat and continuously monitor risks. For companies this means: the risk analysis must map scope, methodology, results and decisions in a way that is explainable in audits and to supervisors/authorities.
Typical audit and evidentiary questions you should be able to answer with your risk analysis:
- Scope: Which systems, processes, locations and service providers are covered – and why?
- Risk criteria: What does ‚high‘ mean concretely (downtime, data exfiltration, security incident, legal consequences)?
- Treatment: Which measures reduce which risk, by when, and with which owner?
- Acceptance: Which risks have been consciously accepted – and at what decision level?
- Monitoring: Which KRIs (Key Risk Indicators) indicate whether the risk is worsening or measures are not effective?
Important: NIS2 is not a pure IT security exercise. If the risk analysis maintains IT lists but does not establish a connection to process criticality, supply chain dependencies and recovery objectives (BCM/DR), it remains weak for decision-making.
Define scope precisely: No reliable decisions without clear boundaries
The most common mistake is a scope that consists of a „system inventory list“ without clear prioritisation. For NIS2 you need a Minimum Viable Scope that covers business-critical services, and a growth concept to expand iteratively.
A practical scope in three levels
- Level 1: Critical services/processes (e.g. production, logistics, billing, customer portal). This is the management view.
- Level 2: Supporting IT services (e.g. IAM, e-mail, network, virtualization, backup, monitoring). This is the operations view.
- Level 3: Assets (applications, databases, interfaces, cloud workloads, endpoints, suppliers). This is the technical detail view.
The risk analysis must link the layers: a failure of „IAM“ is not just an IT issue, but can mean „no access to core systems.“ The assessment must make this chain visible, otherwise false priorities will arise.
Methodology: a lean process that remains auditable
Consistency matters for management decisions. A methodology is good when different teams reach comparable results in similar situations. You achieve this with fixed evaluation dimensions and clear rules, not with maximal detail depth.
Step 1: Scenarios instead of „asset risks“
Assess risks as scenarios: „Ransomware encrypts file servers and central application data“, „Cloud identity is compromised and admin roles are abused“, „Supplier fails, patch and support chain breaks.“ Scenarios are more understandable for stakeholders and can be translated directly into controls (measures).
Step 2: Assessment along CIA plus operational consequences
Traditionally, risks are assessed by CIA: Confidentiality, Integrity and Availability. For NIS2 you should extend this by an operational/governance dimension, for example:
- Operational impact (service interruption, RTO/RPO, manual workarounds)
- Data impact (personal data, trade secrets, manipulation)
- Regulatory/Contract (notification obligations, SLA breaches, liability risks)
- Supply chain (single points of failure in service providers/software)
This prevents availability from being underestimated because „no sensitive data“ are affected, while operational downtime would be severe.
Step 3: Define the risk formula and scales
Commonly: Risk = likelihood × impact. Crucial is that you define scales in writing: What does „likelihood 3“ mean? How is „impact 4“ justified? Without definitions arbitrary values will appear.
A pragmatic approach is a 5×5 matrix with concrete thresholds for impact (in hours, euro ranges, data classes, number of customers) and likelihood (based on exposure, attack pressure, history, control maturity). Important: scales must fit your organization and remain stable over time.
Metrics that management actually needs (and IT can deliver)
A risk analysis becomes controllable when reduced to a small number of understandable metrics. At the same time, the metrics must be technically integrable, otherwise they remain „PowerPoint numbers.“
RTO and RPO: operationalizing recovery objectives
RTO (Recovery Time Objective) is the maximum tolerable recovery time for a service. RPO (Recovery Point Objective) is the maximum tolerable data loss measured as a time window. Both metrics connect Business Impact Analysis (BIA) with backup, RESTore and architecture decisions.
Practical rule: RTO/RPO are not wishes but requirements for operations, architecture and budget. If a service has RTO=4h but RESTore tests regularly take 12h, that is a documented, measurable risk.
SLE and ALE: monetization without false precision
For budgeting decisions, a rough monetization is helpful. SLE (Single Loss Expectancy) describes the loss from a single event; ALE (Annual Loss Expectancy) the expected annual loss (SLE × annual occurrence frequency). This also works with ranges and conservative assumptions.
Transparency is key: document assumptions (e.g. production downtime per hour, contractual penalties, external forensics, recovery costs). Management can then make a conscious decision whether a control is economical.
KRIs instead of just KPIs: early warning signals for rising risk
KRI (Key Risk Indicator) is an early indicator of risk development, as opposed to a KPI (Key Performance Indicator) for performance. Examples that are particularly useful in NIS2 contexts:
- Patch backlog in days by criticality (e.g. proportion of critical patches > 14 days open)
- MFA coverage for admin and remote access
- Share of systems without reliable asset ownership (owner unknown)
- Backup-RESTore success rate and RESTore time from exercises
- Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) for security incidents
- Suppliers: share of critical vendors without a current risk/security assessment
KRIs are management-ready when they have clear thresholds and lead directly to actions (e.g. change freeze, additional resources, exception approval).
Decision boundaries: who may accept which risk?
The core of NIS2-compliant governance is not the matrix but the decision boundary. Without defined boundaries two typical failure modes arise: IT implicitly accepts risks ‚by doing nothing‘, or everything is escalated and decision-making capability is blocked.
A practical risk rule set (Risk Appetite & Delegation)
Define Risk Appetite (risk tolerance) as a framework: Which types of risks are fundamentally not accepted (e.g. lack of recoverability of critical data, admin access without MFA)? Which risks may be temporarily tolerated (with a deadline and plan)?
Then define Delegation of Authority: who may accept risks of which level. An example that has proven effective in many organizations:
- Green: Team/Service owner may accept if documented and monitoring is active.
- Yellow: IT management or the CISO with security responsibility must approve, including a schedule.
- Red: Executive management must decide; acceptance only time-limited and with compensating measures/contingency plan.
These rules must be compatible with audit and liability realities. Decisive is traceability: date, decision, rationale, duration of acceptance, compensating measures.
From risk to action: Risk treatment plan (Risk Treatment Plan) that works in operations
A risk analysis only becomes „living“ when it transitions into a Risikobehandlungsplan (Risk Treatment Plan). This plan should include per risk/scenario: target state, action packages, owner, rough budget estimate, dependencies and evidence.
Four treatment options – with typical pitfalls
- Mitigation (reduce): introduce/improve controls. Pitfall: measures without measurable risk reduction (e.g., „awareness“ without KRI).
- Transfer: e.g., insurance or outsourcing. Pitfall: transfer does not replace control obligations; the supplier must be integrated into governance.
- Avoid: change or shut down the service. Pitfall: shadow IT arises if no alternative exists.
- Accept: deliberate, time-limited, with monitoring. Pitfall: „acceptance“ used as an excuse for lacking resources.
Control families that are typically highly effective in NIS2 risk analyses
Without framework dogma, measures can be grouped into a few control families that you can reference in the risk analysis:
- Identity & Access: MFA, privileged accounts, role models, Joiner/Mover/Leaver process.
- Vulnerability & Patch: scanning, prioritization, maintenance windows, exceptions, EOL strategy.
- Backup & Recovery: offline/immutable backups, RESTore exercises, RTO/RPO evidence.
- Monitoring & Detection: central logs, alerting, use cases, time-to-detect.
- Network & Segmentation: zoning, remote access, East-West controls.
- Supplier Controls: minimum requirements, evidence, exit plan, subcontractors.
Operational benefit increases when each measure has a clear evidence path: ticket, change record, configuration evidence, test log, report.
Audit perspective: which evidence auditors really want to see
Audit readiness does not mean answering every technical detail question in advance. It means that your decisions are systematic and repeatable. Auditors often look for coherence: do the risk analysis, action plan, incident response and operational documentation align?
Evidence packages that work in practice
- Methodology document: Scales, criteria, roles, review cycle, tooling.
- Risk register: Scenarios, assessment, owner, status, treatment, acceptances.
- Evidence of measure implementation: Change records, system configurations, policy approvals.
- Tests and exercises: RESTore tests, incident tabletops, lessons learned, follow-up tasks.
- Supplier documentation: Risk classification, due diligence, contractual clauses, escalation paths.
A recurring problem is „Evidence Drift“: measures are implemented, but evidence is not versioned or is not discoverable. This is less a security issue than an operational and documentation issue. Clear filing concepts and linkage via ticket IDs help here.
Technical data foundation: where do assessments and KRIs reliably originate?
Risk assessments become more credible when they are coupled to measured data. You do not have to introduce a SIEM or a fully developed ISMS tool immediately for this. What matters is a reliable minimal data foundation.
Minimal set of data sources (realistic in many environments)
- CMDB/asset list: at minimum system, owner, criticality, location/hosting, EOL status.
- Vulnerability and patch data: Scanner reports or patch compliance reports.
- Backup reports: Job status, RESTore tests, run times.
- IAM reports: MFA status, privileged groups, recertifications.
- Incident and ticket data: MTTD/MTTR, repeat incidents, change failure rate.
Mapping is important: which data source feeds which KRI? Who is the data owner? How often is it updated? This „data governance“ is an undeRESTimated success factor because it reduces discussions about data quality.
Templates, checklists and decision templates (particularly helpful for NIS2)
To ensure that the risk analysis under NIS2 works not only conceptually but practically, a set of standardized templates helps. You can store and version these in your ISMS (information security management system) or in quality management.
1) Risk scenario template (compact but complete)
Title:
Affected service/process:
Scenario description (What happens?):
Trigger/Threat (e.g. phishing, misconfiguration, supplier outage):
Vulnerability (Why is this possible?):
Affected assets (systems, data, interfaces):
Impact (CIA + operational consequences):
RTO/RPO requirement:
Existing controls (current state):
Likelihood (scale value + justification):
Impact (scale value + justification):
Risk level (matrix):
Owner:
Treatment option (mitigate/transfer/avoid/accept):
Action package + target date:
Compensating measures (if accept):
Evidence/proof:
Review date:2) Decision logic for ‚red‘ (escalation and stop/go rules)
High risks require clear triggers. A practical logic is to define ‚red‘ not only by the matrix but by non-negotiable minimum requirements (guardrails). Examples:
- Critical service without proven recoverability (no successful RESTore test) → automatically red
- Privileged accounts without MFA or without recertification → automatically red
- Internet-exposed systems without a patching process or with EOL software → automatically red
Such guardrails reduce discussions because they define „red lines“ that management must consciously set and be accountable for.
3) Management decision template (one page, decision-ready)
Subject/Risk:
Brief description of the scenario:
Affected business-critical services:
Current risk level and trend (KRI):
Worst-case impact (time, data, legal/contractual):
Recommended option (Mitigate/Transfer/Avoid/Accept):
Cost/resource range (bandwidth):
Target date and milestones:
Residual risk after implementation:
Decision (date, decision-maker, duration if accepted):
Conditions/compensating measures:
Next review date:Supply chains and third parties: risk analysis does not stop at the firewall
Many NIS2-relevant risks are tied to service providers: Managed Services, Cloud, external software maintenance, data center, communication providers. A pure „supplier assessment“ in the form of a questionnaire is rarely sufficient operationally. You need a link between supplier risk and your critical services.
Pragmatic classification of critical suppliers
- Criticality: Which services depend directly on it? Is there an exit plan?
- Access model: Does the supplier have privileged access? How is it controlled (MFA, jump host, logging)?
- Dependencies: Subcontractors, single points of failure, proprietary interfaces.
- Evidence: Reports, penetration tests, availability statistics, incident processes (without necessarily requiring certificates).
Operationally important is the question: How quickly do you learn about disruptions or security incidents at the supplier, and how does that feed into your reporting and escalation logic?
This topic can be integrated well into a dedicated supply chain program; in many organizations it makes sense to bring Procurement, Legal, IT and Security together into a recurring assessment loop.
Review cycle and operations: risk analysis as a continuous process
NIS2 does not expect a document to be produced once a year. Reality is dynamic: new attack surfaces, system migrations, cloud changes, new service providers, personnel changes. For the risk analysis to „live“, it needs a cadence and clear triggers for reassessment.
Proven triggers for re-assessments
- Major changes: new locations, cloud migration, new core application, data center relocation
- Security Incidents: especially in cases of repeat patterns or new attack methods
- Audit and findings: when evidence is missing or controls are not effective
- Supplier change: new MSPs, new SaaS providers, changed contract conditions
RACI and interfaces to ITIL/change processes
To prevent risk decisions from happening ad hoc, they must be integrated into existing processes. A Change Advisory Board (CAB) can, for example, serve as a control point where risk-relevant changes are only approved with a documented assessment. The decisive factor is not the body, but the rule: „No critical change without a risk check and a rollback plan.“
Cost and implementation logic: How to build a robust program from risk priorities
Management rightly asks about effort, side effects and sequencing. A good risk analysis delivers not just „red/yellow/green“, but an actionable portfolio: Quick Wins, structural measures and long-term modernization.
A pragmatic portfolio model
- Immediate measures (0–6 weeks): Close guardrails (MFA for admin, backup hardening, logging baseline, EOL stop).
- Stabilization (6 weeks–6 months): Patch and vulnerability process, RESTore exercises, incident playbooks, role recertification.
- Structural (6–18 months): Segmentation, identity modernization, centralization of logs, vendor program, automation.
Side-effect analysis is essential: some controls increase short-term complexity (e.g. segmentation) or require operational maturity (e.g. alerting that does not end in „Alert Fatigue“). These risks must also go into the register: „Control Risk“ is real.
Conclusion: A NIS2 risk analysis is effective when it forces decisions
A NIS2 risk analysis is not successful because it is elegantly modeled, but because it has consequences: clear red lines, traceable acceptance decisions, measurable KRIs and a risk treatment plan anchored in operations. If you define scope, methodology and decision authority cleanly, you get a system that improves audit readiness while easing IT’s daily work: fewer surprises, better priorities, more transparency about technical debt and dependencies.
If you want to explore the adjacent components in more depth, governance, implementation roadmap, budget logic and supply chain management are particularly suitable to be structured as a coherent article series and cross-linked internally.
For this topic, NIS2 risk management and assessing IT security risks are also important. The article places these aspects in a comprehensible way and shows what matters in everyday practice.