How to Use a Risk Management Tool to Demonstrate NIS2 Compliance

What is NIS2, and who does it apply to?

NIS2 — the Network and Information Security Directive 2 — is European Union legislation that sets cybersecurity and governance requirements for organisations operating in critical sectors. It replaces the original NIS Directive and significantly expands its scope.

If your organisation operates in sectors such as energy, transport, healthcare, financial services, digital infrastructure, water, or public administration, you are likely in scope. NIS2 distinguishes between "essential entities" (larger organisations in high-criticality sectors) and "important entities" (a broader second tier). Both categories must comply, though supervisory intensity differs.

Penalties for essential entities reach €10 million or 2% of global annual turnover, whichever is higher. For important entities, the ceiling is €7 million or 1.4% of global turnover. NIS2 was supposed to be transposed into national law across all EU member states by October 2024. Several countries missed that deadline — Germany had not completed transposition as of early 2026 — but national supervisors in the Netherlands, Belgium, and Denmark are already active. If you are in scope, the compliance obligation is real and approaching fast.

The gap between having controls and being able to prove it

Your firewall logs are clean. Your access controls are solid. You patched the critical vulnerability last quarter before any public exploit appeared. By any technical measure, your organisation's cybersecurity posture is reasonable.

Then an NIS2 supervisor walks in and asks you to demonstrate it.

That is where a lot of in-scope organisations discover a problem they did not expect. The controls exist. The evidence does not.

NIS2 compliance is fundamentally a documentation and governance challenge. The Directive uses the word "demonstrate" repeatedly and deliberately. Under Article 21, organisations must implement appropriate risk management measures. Under Article 20, management must approve those measures and be trained on them. Under Article 23, incidents must be reported to national authorities within specific time windows — 24 hours for an early warning, 72 hours for an initial notification. None of these obligations are satisfied by having something in place. You have to be able to show it, with a verifiable evidence trail, on demand.

That is exactly what a structured risk management tool is built to produce. Risk Companion is not a GRC platform — it is a practical risk management tool — but it addresses precisely the evidence-trail problem that NIS2 creates for in-scope organisations.

What NIS2 actually requires: the four obligation areas

Before exploring how a risk management tool helps, it is worth being precise about what NIS2 demands. Most organisations focus on Article 21 because it contains the ten minimum cybersecurity measures. But NIS2 compliance is built across four interconnected areas.

Article 21: Risk management measures

Article 21(2) sets out ten categories of measure that all essential and important entities must implement. They include risk analysis and security policies, incident handling, business continuity and crisis management, supply chain security, network and system security, cybersecurity training, cryptography policies, access control, multi-factor authentication, and the use of secured communications.

The critical word is "appropriate." Article 21(1) requires measures to be appropriate to the risks faced, taking into account the state of the art, applicable standards, the cost of implementation, and the size of the organisation. That proportionality requirement creates an immediate documentation obligation: you need to show how you assessed your risks, what you concluded, and why the measures you chose are a proportionate response.

A risk register that simply lists threats with no analysis, no control mapping, and no review dates does not satisfy this. NIS2 expects documented risk assessments, with named owners, linked measures, and evidence of ongoing review.

Article 20: Governance and management accountability

This is the article that catches boards and senior leadership teams off guard. Article 20 requires management bodies to approve cybersecurity risk management measures, to oversee their implementation, and to undergo training to adequately assess and manage risks.

In practice, this means organisations need records showing that management has reviewed and signed off on the risk management approach. Not a single approval email from 2022. Ongoing, documented oversight. Board minutes that reference specific risks. Training completion records for executives.

Most organisations have no structured way to produce this evidence when asked for it.

Article 23: Incident reporting obligations

NIS2 tightens incident reporting significantly compared to the original NIS Directive. A significant incident must trigger:

• An early warning to the relevant national authority within 24 hours
• An initial notification within 72 hours, including a preliminary assessment of severity and impact
• A final report within one month

The 24-hour early warning alone requires that your incident detection and escalation process is documented, tested, and capable of producing a structured notification under pressure. If your incident response process lives in someone's head or in an undated Word document, you will not meet that window reliably.

An incident log with timestamped entries, documented escalation steps, and records of every notification sent is not a nice-to-have. It is the evidence that demonstrates NIS2 compliance with Article 23.

Business continuity

Article 21(2)(c) specifically requires measures for business continuity and crisis management, including backup management, disaster recovery, and crisis management procedures. This overlaps with standard business continuity planning, but NIS2 requires that these measures are documented, tested, and reviewed.

Testing without records of testing is not enough. A business continuity plan that nobody has reviewed since it was written is not evidence of a functioning measure.

Why demonstrating compliance is harder than achieving it

Here is the counterintuitive reality: most in-scope organisations already do a reasonable amount of what NIS2 requires. They patch systems. They run backups. They have password policies. They respond to incidents.

The problem is that none of it is connected, attributed, or auditable.

Controls live in different systems. Ownership is informal. Risk assessments happen during ISO audits and then sit in a folder. Incidents are handled, but not logged in a way that produces a 24-hour-window notification record. Board oversight of cybersecurity consists of a quarterly slide in a risk committee pack.

When a supervisor asks for evidence that Article 21(1)'s proportionality requirement was met, there is no single place to go. When they ask who owns the supply chain security measure and when it was last reviewed, the answer involves searching through email.

This is the evidence gap. It is not a technical problem. It is a governance and process problem that a structured risk management tool is specifically designed to close.

What good evidence looks like in practice

For each NIS2 obligation area, there is a corresponding evidence artefact that regulators and auditors expect to see.

For Article 21 risk management: A documented risk assessment, conducted at a defined frequency, with each identified risk carrying a probability score, impact score, named owner, and linked measures. The assessment must be traceable: who conducted it, when, what method was used, and what changed as a result. Risk Companion's risk register structures exactly this. Every risk gets an owner, a risk score, and a set of linked measures. The dashboard shows what is open, what is overdue, and what has been completed. That is an audit trail, not just a list.

For Article 20 governance: Records showing that management has reviewed, approved, and been trained on the cybersecurity risk management approach. This means documented sign-off on policies and risk assessments, attendance or completion records for training, and board-level engagement with the risk picture. Risk Companion's team and collaboration features support this: risk owners receive reminders, comments create a record of review activity, and the dashboard gives management an up-to-date view of the organisation's risk posture as it updates automatically as the team works.

For Article 23 incident reporting: A timestamped incident log that records detection time, assessment, escalation steps, and each notification sent to national authorities. If you cannot show the timestamp of when you became aware of the incident alongside the timestamp of your 24-hour early warning submission, you cannot demonstrate NIS2 compliance with the reporting timeline. An incident record in Risk Companion, with measures documented as they are completed and owners assigned at each step, gives you that timeline automatically.

For business continuity: Documented plans with named owners, test completion records with dates and outcomes, and evidence of periodic review. A plan that has not been opened since it was written fails this test regardless of its quality.

The ISO 27001 question

Organisations already certified to ISO 27001 will have a meaningful head start on NIS2 compliance. The standard's requirements around risk assessment, asset management, access control, incident management, and business continuity align significantly with Article 21's ten measures.

But the gaps are real, and they catch ISO 27001 holders by surprise.

ISO 27001 does not require the same supply chain security depth that NIS2 Article 21(2)(d) demands. The standard addresses supplier relationships, but NIS2 expects documented assessments of each significant supplier's security practices, with evidence that vulnerabilities in the supply chain are identified and managed.

ISO 27001's incident management requirements do not map cleanly to Article 23's specific notification timelines. Certified organisations often have incident response procedures but no mechanism for producing a structured 24-hour early warning under operational pressure.

Most significantly, ISO 27001 certification does not address Article 20's management accountability requirements in the way NIS2 intends. Certification demonstrates that a management system is in place. NIS2 requires evidence that specific management individuals have reviewed, approved, and been trained on specific risk management decisions.

If you are ISO 27001 certified, use that as your foundation. Then map the gaps, particularly around supply chain risk assessments, incident notification timelines, and documented board engagement. Those are where the NIS2 compliance work concentrates.

What a risk management tool actually produces

A risk management tool is not a compliance shortcut. It does not write your policies or conduct your risk assessments for you. What it does is structure the process so that the output is usable as evidence.

Consider what happens without one. A risk assessment is conducted in a spreadsheet. The results are emailed to a manager. Some measures are implemented; others are noted as pending. Six months later, nobody can locate the original assessment, the manager has changed roles, and there is no record of which measures were implemented or whether they were reviewed.

Now consider what happens with Risk Companion in place. The risk assessment populates the risk register. Each risk is assigned an owner. Each control becomes a measure with a due date and a status. Overdue measures surface automatically. The dashboard shows the current risk posture. When a risk is reviewed, there is a record of who reviewed it and when. When the board wants a picture of the organisation's NIS2 risk management approach, the dashboard provides it without anyone building a fresh slide deck.

The difference is not the analysis itself, but the evidence that the analysis happened, was acted on, and is continuously maintained.

See how Risk Companion structures risk assessments and compliance reporting

Supply chain security: the area most organisations underestimate

Article 21(2)(d) requires measures addressing security in the supply chain, including the security-related aspects of relationships between each entity and its direct suppliers or service providers.

This is one of the most demanding NIS2 requirements in practice. It means assessing your critical suppliers, documenting those assessments, identifying the risks they introduce, and maintaining ongoing oversight of their security practices.

A logistics company operating 15 critical software vendors, a healthcare provider dependent on three specialist clinical systems suppliers, a financial services firm relying on cloud infrastructure from multiple providers — each needs to document what they know about each supplier's security posture, what measures manage that risk, and when the assessment was last reviewed.

That is not a one-time exercise. It is a continuous risk management obligation. A risk management tool that lets you create a risk entry per supplier, link specific measures to each, assign owners, and set review dates is the only practical way to manage it at scale. For more on how third-party risk fits into a broader risk management process, see our article on third-party risk management and geopolitical supply chain exposure.

The enforcement timeline is not your friend

Some organisations have used delayed national transposition as a reason to wait.

That is a mistake for two reasons. First, most member states have either transposed the Directive or are in the final stages. Enforcement follows transposition quickly. Second, building an evidence trail takes time. You cannot retrofit six months of continuous risk management documentation the week before a supervisor visit. The evidence of ongoing review has to be genuine, and genuine means it accumulates over time.

National supervisors in the Netherlands, Belgium, and Denmark are already active. Start now, even if your country's national law is not yet in force. The obligation to demonstrate NIS2 compliance will arrive — and the organisations that begin structuring their evidence trail today will be ready when it does.

Connecting NIS2 to operational risk management

One thing that often gets lost in the compliance conversation is that NIS2's requirements are not just about satisfying a supervisor. A well-maintained risk register, with named owners and linked measures, actively improves how an organisation manages its operational risks. Incident records with timestamped entries improve post-incident learning. Supply chain risk assessments surface vulnerabilities before suppliers become the source of a breach.

The organisations that will handle NIS2 compliance most effectively are those that treat it as an opportunity to build a risk management process that actually works day to day, not just at audit time. If you are thinking about how risk management integrates across the organisation more broadly, our piece on integrated risk management is worth reading alongside this one.

Risk Companion is built for exactly this: making real risk management visible, attributed, and continuous — and producing the evidence trail that NIS2 regulators will want to see.

Book a 30-minute demo to see how Risk Companion builds the NIS2 evidence trail