NIS2 risk management: not all risks are equally important

Why is risk management becoming so important under NIS2?

For many organisations, cybersecurity is no longer a purely technical specialist topic. It has become part of corporate governance. The reason is simple: the threat landscape is intensifying, regulatory requirements are increasing and many organisations still only react once something has already happened.

This is precisely the mindset that becomes problematic under NIS2. The requirements are not aimed at companies merely being able to prove that individual security measures are in place. What is required is a transparent, risk-based and permanently functioning system. In other words, this is not a one-off project, but a management process that is regularly reviewed, adapted and documented.

For particularly important and important entities, this means that cyber risks must be systematically identified, assessed, managed and controlled. Organisations that do not know today which risks exist within their business will find it difficult tomorrow to provide a robust explanation of why certain measures were implemented, postponed or accepted.

In short: NIS2 shifts the focus from “Do we have security technology?” to “Can we manage our risks?”

What does NIS2 essentially require from risk management?

At the heart of NIS2 is the idea that information security must be manageable. Section 30 BSIG does not refer only to security in general, but explicitly to risk management measures for particularly important and important entities. The core requirement is a system consisting of risk analysis, security concepts and effectiveness control.

In practice, this means that organisations should not only define which protective measures they use. They must also be able to demonstrate why these measures are appropriate, how they work and how they are further developed.

The following aspects are particularly important:

• Concepts for risk analysis and IT security: Risks must be identified and assessed in a structured way and translated into security concepts.
• Procedures for assessing effectiveness: Measures should not only be introduced, but reviewed regularly.
• Risk-based approach and proportionality: Not every risk is equally critical. Priorities must be set in a transparent and comprehensible way.
• Documentation: Decisions, assessments, measures and risk acceptances should be demonstrable in a robust manner.
• State of the art and relevant standards: Security measures must be aligned with recognised benchmarks.
• Cross-hazard thinking: Cyber risks should not be viewed in isolation, but in connection with business processes, suppliers, data flows and outage scenarios.
• Regular updates: Risks change. Risk management must therefore evolve accordingly.

This makes one thing clear: a single document is not enough. Organisations need a robust control framework that works in everyday operations.

How does good NIS2 risk management begin?

The first step is transparency. Only what is identified can be managed. Good risk management therefore does not begin with a list of technical tools, but with the question: What do we actually need to protect?

This initially requires an overview of assets, critical services, IT flows and data flows. Organisations should know which systems, applications, processes, information and service providers are particularly important for their business operations. Only then can they determine which risks are relevant and where priorities need to be set.

A practical starting point primarily includes:

• Asset inventory: Which systems, applications, data assets and services exist?
• Critical services: Which processes are particularly important for operations?
• Risk register: Which risks exist, how are they assessed and how are they developing?
• Security objectives: What specifically needs to be protected – availability, integrity, confidentiality or resilience?
• Policies and standards: Which rules are binding for key protection areas?
• Management approvals: Which decisions have been made and who is responsible for them?
• Update cycles: When are risks, measures and evidence reviewed?

It is particularly helpful not to describe risks in the abstract, but to think in terms of concrete scenarios: What would happen in the event of an attack on the corporate network? What happens if critical systems fail? What would be the consequences of data loss or a data protection incident? Scenarios like these make risks tangible and make prioritisation easier.

How can cyber risks be assessed and prioritised effectively?

For risk management to become controllable, risks must be made comparable. This requires a method that is not overly complicated, but still sufficiently meaningful. A simple logic that is easy to understand in practice is to consider cause, risk scenario and impact.

For example: weak passwords, missing access controls or a phishing email may be causes or vulnerabilities. These may lead to the risk scenario of a hacker attack on the corporate network. Possible impacts include data loss, business interruptions, reputational damage or data protection incidents.

The risk is then assessed. Typical criteria include:

• Likelihood of occurrence: How likely is it that the scenario will materialise?
• Damage or impact: How severe would the consequences be?
• Overall risk: How high is the risk resulting from the combination of these two factors?

This assessment helps organisations deploy resources in a targeted way. A risk with a high likelihood and high impact must be treated differently from a risk with a low impact. What matters is not pretending to achieve perfect mathematical precision. The decisive point is that the assessment is carried out consistently, transparently and with proper documentation.

The initial assessment is followed by risk treatment. Measures are defined, responsibilities are assigned and the residual risk is assessed again. This is exactly where it becomes apparent whether risk management exists only on paper or whether it actually has a steering effect.

Which measures are part of robust risk management?

Technology is important, but it is not enough on its own. NIS2-compliant risk management depends on the combination of technical and organisational measures. Only when both are considered together does a system emerge that not only provides protection, but can also be managed and evidenced.

Technical measures may include, for example:

• firewalls to protect critical systems
• monitoring to detect suspicious activities
• multi-factor authentication procedures
• password policies
• regular penetration tests

Organisational measures are just as important. These include, for example:

• binding policies and standards
• training and awareness measures
• clear responsibilities
• documented approvals
• regular reviews
• procedures for assessing effectiveness

The central point is this: measures should not be selected in isolation. They must contribute to the treatment of specific risks. If the initial risk is a hacker attack on the corporate network, the selected measures should visibly help reduce either the likelihood of occurrence or the level of damage.

In most cases, a residual risk remains. This must be assessed and – if it is not reduced further – consciously accepted. This risk acceptance should also be documented. It is precisely here that it becomes clear whether responsibility has been clearly assigned within the organisation.

Who needs to take responsibility in risk management?

Risk management does not work as a purely IT-driven task. It depends on exchange between business departments, management, IT, legal, information security and other stakeholders. Risks often arise where processes actually take place: in HR, production, procurement, legal, IT or supplier management.

This is why two perspectives are needed:

• Risk owners: They know the processes, systems and vulnerabilities in their area. They understand where things could become painful in a real incident.
• Risk managers: They make risks tangible, structure the process, moderate assessments and ensure that decisions become transparent and comprehensible.

For this to work, roles and decision-making paths must be clearly defined. Organisations should determine who is responsible for the overall programme, who acts as asset owner, service owner or supplier owner, and who makes decisions in the context of incidents or business continuity management.

The following are particularly important:

• clear allocation of risks
• regular review of measure implementation
• monitoring and reassessment of risk developments
• binding escalation paths
• management reporting
• documented risk acceptances
• transparent and comprehensible prioritisation

Without this structure, measures often remain non-binding. In a real incident, it is then unclear who makes decisions, who needs to be informed and which risks were consciously accepted.

How can risk management be permanently embedded in the organisation?

A risk management system is only effective if it does not exist separately from day-to-day business. It must be integrated into existing processes. Otherwise, it becomes a parallel process that has to be laboriously reactivated during audits or incidents, but has little impact in everyday operations.

A good approach is to translate obligations into existing workflows. This may mean incorporating risk-related questions into change and project processes, linking them to supplier management, or anchoring controls and evidence in the ISMS.

In practical terms, the following are particularly important:

• Mandatory fields in existing processes: Risk-relevant information should be recorded where decisions are already being made.
• Controls and evidence in the ISMS: Measures and evidence should be centrally structured and reviewable.
• Integration with supplier management: Risks arising from service provider relationships should not be considered separately from cyber risk management.
• Use of change and project processes: New systems, processes or changes should be assessed on a risk-based basis.
• Tests, exercises and KPIs: Effectiveness must be measurable and verifiable.
• Fixed review cycles: Risks, measures and documentation should be updated regularly.

In this way, risk management develops from a compliance project into a component of governance. That is exactly what matters: governance needs to have a place in everyday business.

What role does emergency planning play in NIS2 risk management?

Risk management does not end with prevention. The question of how an organisation responds in an emergency is also part of it. Even good security measures cannot completely eliminate every risk.

That is why realistic emergency and recovery plans are needed. The decisive factor is that these plans do not merely exist on paper, but are tested regularly. In a crisis, there is no time to clarify responsibilities for the first time or improvise communication channels.

A robust emergency approach includes:

• emergency and recovery plans
• designated emergency teams from security, legal, IT and management
• clear escalation and decision-making paths
• regular exercises and tests
• follow-up and improvement after tests or incidents

Being prepared is better than hoping for the best. This is particularly important under NIS2, because organisations should be able to show that they have not only identified risks, but also built response capability.

Conclusion: What should organisations do now?

The main problem is not that organisations are unaware of cybersecurity measures. The main problem is that risks, responsibilities and evidence are often not linked systematically enough. This is exactly where NIS2 increases the pressure: risk management must be transparent, proportionate, documented and effective on an ongoing basis.

The key takeaway is this: NIS2-compliant risk management is not a one-off project and not a purely IT-related task. It is an ongoing management process that makes risks visible, enables better decisions and clearly assigns responsibility.