NIS2 enforcement is here: what regulators are checking and what happens if you're not ready

Where enforcement stands now

NIS2 entered into force across EU member states in October 2024. The transposition period gave national legislators time to write NIS2 into domestic law, and most have now done so. In the Netherlands, the Cyberbeveiligingswet (Cybersecurity Act) is the primary vehicle. The Rijksdienst voor Digitale Infrastructuur (RDI) serves as the main supervisory authority for most sectors, with the NCSC coordinating incident response and intelligence sharing. Sector-specific regulators, including De Nederlandsche Bank for financial market infrastructure, retain their own supervisory role under the NIS2 framework.

Several national authorities across the EU began with self-assessment questionnaires. These asked in-scope organisations to rate their own compliance against the 18 security measures in Article 21. That phase provided regulators with a picture of the landscape. The formal inspection cycle that follows operates differently: regulators request documentation, conduct on-site assessments, interview responsible managers, and verify that documented controls actually function.

Energy, water, transport, health, and digital infrastructure operators face the first inspection waves. Financial market infrastructure organisations sit under sector-specific supervision that already runs on a comparable cadence. If your organisation operates in one of these sectors and has not received a questionnaire or pre-inspection notice, that does not mean you are out of scope. Your number has not come up yet.

What regulators actually check

NIS2 Article 21 lists 18 specific security measures. Regulators do not treat these as a checklist to mark off. They look for evidence that each measure functions as intended in the operating environment, not simply that a policy document exists. The areas that generate the most findings in early enforcement cycles are:

• Governance documentation: Regulators ask for board-level sign-off on the cybersecurity policy, documented roles and responsibilities, and evidence that senior management has taken ownership. NIS2 holds management personally accountable. Regulators look for board minutes that show active engagement with security risk, not a signed policy that IT produced and management never discussed.
• Risk management records: A dated, scope-defined risk register with named asset owners, documented threats, assessed impact, and recorded mitigations. Regulators want to see the register is a live document with version history, not a one-off exercise produced for this audit.
• Supply chain security policies: NIS2 extends obligations to the supply chain. Regulators ask how your organisation assesses the security posture of critical suppliers, what contractual terms you impose, and how you monitor ongoing compliance. Supply chain security produces more audit findings than any other area.
• Access control evidence: Logs demonstrating least-privilege enforcement, records of access reviews, MFA deployment coverage, and evidence of privileged access management for administrative accounts. Regulators check that controls function, not just that a policy mandates them.
• Business continuity plans: Tested, dated continuity and disaster recovery plans with defined recovery time and recovery point objectives. A plan that has never been tested is likely to generate a finding.
• Staff awareness training records: Completion rates, content evidence, and frequency of awareness training. This extends to phishing simulation programmes and records of role-specific security training for high-risk job functions.

Regulators also examine your incident detection capability. They want to know how your organisation would identify a significant incident and who is responsible for that determination. Organisations that cannot demonstrate a functional detection mechanism face a difficult conversation regardless of how their other controls look on paper.

The fine structure (and when it applies)

NIS2 creates two tiers of financial penalty, tied to your entity classification:

• Essential entities: Maximum fine of €10 million or 2% of total global annual turnover, whichever is higher.
• Important entities: Maximum fine of €7 million or 1.4% of total global annual turnover, whichever is higher.

These are ceiling figures. Regulators set the actual fine based on breach severity, how long the non-compliance ran, how much your organisation cooperated during the investigation, and whether you self-reported. A first-time finding with documented remediation effort draws a different response than a pattern of non-compliance or an attempt to conceal an incident.

Beyond financial penalties, NIS2 gives national authorities two tools that carry direct operational weight. First, they can issue binding instructions requiring specific remediation steps within a defined timeframe. Second, for essential entities, they can temporarily ban a named person in a management role from performing their duties. That possibility tends to sharpen board attention on cybersecurity governance faster than a fine.

Member states may also require your organisation to publicly disclose a cybersecurity breach. A mandated public disclosure, a fine, and a remediation order arriving together represent the realistic worst-case scenario. Plan for all three, not just the financial penalty.

Incident reporting: the timeline that catches organisations out

The incident reporting obligations in NIS2 are precise. Most organisations underestimate how hard it is to meet them under real conditions. The clock starts the moment your organisation becomes aware of a significant incident, not when you have confirmed its scope or cause.

• Within 24 hours: Submit an early warning to the national competent authority. This does not need to be a full report, but it must reach the regulator. Content required: basic notification that a significant incident has occurred or is suspected, initial assessment of whether it appears to be criminal or cross-border, and any immediate impacts identified.
• Within 72 hours: Submit a full incident notification. This must include an updated assessment of the incident, its severity, the indicators of compromise if known, and the measures your organisation has taken or initiated.
• Within one month: Submit a final report. This covers the detailed description of the incident, root cause analysis, remediation actions taken, any cross-border impact, and lessons learned.

The failure point for most organisations is not the 72-hour or one-month report. It is the 24-hour early warning. Organisations that lack a defined escalation path from detection to notification decision consistently miss this window. Your incident response plan must name the person responsible for making the notification decision, define what "significant incident" means in your context, and include the contact details for your national authority. That information cannot live in a document no one can find at 2am on a Sunday.

A separate compliance finding can result from each stage of the reporting timeline missed. Three missed stages in a single incident generate three separate compliance failures. Regulators treat the reporting obligation as independent of whether the underlying incident reflects a security gap: even if your controls were adequate, failing to report a significant incident correctly is itself a violation.

What to prioritise if you haven't started

If your organisation sits within NIS2 scope and has not started a compliance programme, trying to address all 18 measures at once will produce slow progress across every front. Start with the three areas that give you the most coverage and the strongest position if a regulator asks what you have done:

1. Risk register

Build a dated, structured risk register that names your critical assets, documents the threats to them, assesses likelihood and impact, identifies control gaps, and assigns owners. Regulators request this first. Involve IT, operations, and a senior management sponsor in building it. A risk register that your operations team has never seen is not a risk register: it is a document.

2. Incident response plan

Write and test an incident response plan covering detection, escalation, notification (including the NIS2 reporting timelines and contact details for RDI and NCSC), containment, recovery, and post-incident review. Assign named people, not job titles. Run a tabletop exercise. Finding gaps in a drill costs far less than missing the 24-hour notification window during a real incident.

3. Supply chain security review

Identify your critical suppliers: those whose failure or compromise would disrupt your operations or trigger a reportable incident. Assess their security posture through questionnaires, contractual terms, or third-party assurance reports. Regulators accept that supply chain security takes time to build. They want to see a documented programme with evidence of progress, not a completed solution.

These three areas do not replace the full Article 21 security programme. They give you the fastest path to a defensible position if a regulator contacts you in the next few months.

What this means for your organisation

National authorities are running inspections now. Your organisation may be late to the compliance programme, but the early audit findings from other organisations show exactly what regulators focus on and what generates findings. That is useful intelligence. Use it.

• Confirm your entity classification (essential or important) and identify which national supervisory authority has jurisdiction over your sector. This determines your supervision model and your applicable fine ceiling.
• Produce or update your risk register with board-level sign-off and a clear review schedule. Date it. Version it.
• Write your incident response plan around the NIS2 notification timelines. Test it. Store it somewhere everyone with a role in it can access during an incident.
• Conduct a basic supplier security assessment covering your top-tier critical suppliers. Document your methodology and your findings.
• Get formal management sign-off on the cybersecurity policy. Make sure your board understands that NIS2 creates personal accountability for directors, not only organisational accountability for the company.
• Schedule a gap assessment against all 18 Article 21 measures. The output gives you a prioritised remediation roadmap and serves as evidence of a functioning governance programme if an auditor asks what your organisation has been doing.

Cyvra works with organisations at every stage of the NIS2 compliance process, from initial scoping and gap assessments to policy development, supply chain reviews, and incident response planning. If you need a structured starting point or a second opinion on your current posture, speak to our compliance team.

How Cyvra helps with NIS2

Cyvra works with essential and important entities across the Netherlands and UK to build the evidence base regulators expect. Our engagements cover the full audit trail: risk registers, governance documentation, incident response plans, and supply chain security reviews scoped to what your supervisory authority will actually look for.

If your organisation has not yet started, we prioritise the areas that produce the most audit findings first. If you have already completed an initial self-assessment, we identify the remaining gaps and close them before a formal inspection arrives.

• NIS2 gap assessment: identify which of the 18 required measures you have in place and which need documentation or implementation
• Risk register creation: build a documented risk management process that meets the standard supervisory authorities check first
• Incident response planning: write and test a plan that meets the 24-hour early warning window and the 72-hour follow-up requirement
• Supply chain security review: assess your third-party risk and produce the documented controls auditors ask about most
• Governance documentation: produce board-level records showing active management engagement, not just a signed policy from IT

Talk to our audits and compliance team or our cybersecurity practice about where your organisation stands.