NIS2 checklist: what you need to have in place to be compliant

In this article, we walk through the components you need to have in order step by step. Not as a legal summary, but as a practical overview you can use to structure your preparation and verify you're not overlooking anything.

NIS2 checklist in brief

What NIS2 compliance means

NIS2 has three core obligations: the duty of care, the reporting obligation and the registration obligation. The duty of care requires you to take appropriate and proportionate technical, operational and organisational measures to manage the risks to your network and information systems. The reporting obligation requires you to report significant incidents to the competent authority or CSIRT. The registration obligation requires you to register with the competent authority (in the Netherlands, the NCSC).

Being compliant means you can demonstrate that you fulfil these obligations. The emphasis is on "demonstrate": it's not just about implementing measures, but also about recording evidence that those measures exist, work and are maintained. Compliance is therefore not a one-off status but an ongoing cycle of assessing risks, taking measures, checking effectiveness and adjusting where needed. The supervisory authority assesses whether your measures are proportionate to the risks your organisation faces and the potential societal impact of an incident.

When a checklist helps

A checklist doesn't replace a risk assessment or complete security programme. But it is an effective tool for keeping track of all the components you need to cover. Article 21 of the directive lists ten measure categories that organisations must comply with at minimum. Added to these are the reporting obligation, the registration obligation and the governance requirements from Article 20. Together, these form a broad package of obligations that affects multiple departments.

Many organisations don't struggle with the question of what NIS2 requires, but with how to get all the components started in a structured way. A good checklist translates the directive into concrete action points, helps assign responsibilities and makes progress visible. It prevents you from fixating on one aspect (such as technical security) while other components (such as governance or supply chain security) fall behind. In this article, we use a six-step structure that fully covers the main pillars of NIS2.

Who this NIS2 checklist is for

Essential entities

Essential entities are large organisations in the highly critical sectors of Annex I of the directive: energy, transport, banking, financial market infrastructure, healthcare, drinking water, wastewater, digital infrastructure, ICT service management (B2B), government and space. Large means at least 250 employees or an annual turnover of more than fifty million euros and a balance sheet total of more than forty-three million euros. Certain organisations are always essential, regardless of their size: DNS service providers, top-level domain name registries, trust service providers and central government authorities.

Proactive supervision applies to essential entities. This means the supervisory authority can check whether you meet the obligations, even without an incident having occurred. Fines can reach up to ten million euros or two percent of global annual turnover. Board members are personally liable and can, in extreme cases, even be temporarily suspended. For this category, it is particularly important that governance is established at board level and that evidence is available at any time.

Important entities

Important entities are medium-sized organisations in the sectors of Annex I and Annex II, and large organisations from the sectors of Annex II. Annex II covers postal and courier services, waste management, the chemical sector, the food sector, the manufacturing sector (specific branches), digital providers and research institutions. Medium-sized means at least fifty employees or an annual turnover and balance sheet total of more than ten million euros.

The substantive obligations are identical to those of essential entities: the ten measure categories from Article 21 apply in full. The difference lies in supervision: important entities fall under reactive supervision. The supervisory authority only intervenes after an incident or upon signals of non-compliance. The maximum fines are lower: up to seven million euros or 1.4 percent of global annual turnover.

Organisations in preparation

Organisations that are not yet certain whether they fall under NIS2 also benefit from this checklist. The Dutch Digital Infrastructure Inspectorate (RDI) has developed a self-assessment tool that allows Dutch organisations to check whether the Cybersecurity Act applies to them. Additionally, the checklist is relevant for organisations in the supply chain of NIS2 entities. The directive obliges NIS2 entities to safeguard the cybersecurity of their chain. In practice, this translates into contractual requirements: a NIS2 entity can require its suppliers to implement certain measures and provide evidence of compliance. A thorough preparation takes six to twelve months, depending on your current security level.

Step 1: Governance and responsibility

Board responsibility

Article 20 of the NIS2 directive places responsibility for cybersecurity explicitly with the board. Management bodies must approve risk management measures, supervise their implementation and can be held personally liable for non-compliance. Additionally, the directive requires that members of management bodies undergo training in cybersecurity, so they are able to assess security risks and make informed decisions.

In practice, this means the board not only approves a security policy, but is actively involved in monitoring progress. The board must understand what risks the organisation faces, what measures have been taken and where residual risks lie. This involvement must be demonstrable. Think of minutes from board meetings where cybersecurity risks are discussed, formal approval decisions for the security policy and periodic reports on the status of measures.

Roles and ownership

In addition to board responsibility, operational roles must be clearly assigned. Who performs the risk assessment? Who monitors the implementation of controls? Who coordinates incident response? Who reports to the board? Cybersecurity affects multiple departments: IT, legal, HR, operations and management. Without clear ownership, tasks fall through the cracks.

It helps to assign an owner per control who is responsible for implementation, maintenance and evidence. Ensure that assignment is documented and that every owner understands what the measure entails, why it was chosen and what is expected of them. Also arrange an escalation path: if an owner determines that a measure is not feasible or no longer appropriate, that finding must reach someone who can act on it.

Policy frameworks

The first measure category from Article 21(2) is policy on risk analysis and information system security. That policy describes the principles, frameworks and responsibilities within which your organisation arranges its cybersecurity. It's not about thick policy documents, but about clear, workable frameworks that provide direction.

At minimum, you need policies for information security, access management, incident response, business continuity, vendor management and the use of cryptography. That policy must be approved by the board, communicated to relevant employees and periodically evaluated. A security policy that disappears into a drawer has no value. It must be a living document that employees know and follow.

Step 2: Risk management

Risk analysis

The core of NIS2 is risk-based. Measures are not chosen randomly but based on an analysis of the risks your organisation faces. The risk analysis maps out which threats are relevant, which vulnerabilities exist in your systems and processes, and what the potential impact of an incident is on your service delivery and on society.

Start by inventorying your most important assets: networks, servers, applications, databases, cloud environments and the data processed within them. Identify the relevant threats per asset and assess the likelihood and impact of each scenario. The NCSC recommends starting by mapping your "crown jewels": the interests and assets that absolutely must be protected. The result is a prioritised list of risks that serves as the basis for selecting controls.

Controls

Based on the risk analysis, you select controls that reduce the identified risks to an acceptable level. The directive prescribes ten measure categories in Article 21(2): (a) risk analysis and information system security, (b) incident handling, (c) business continuity including backup management and crisis management, (d) supply chain security, (e) security in the acquisition, development and maintenance of systems, (f) assessment of the effectiveness of measures, (g) basic cyber hygiene practices and training, (h) policies on cryptography and where appropriate encryption, (i) human resources security, access policies and asset management, and (j) multi-factor authentication and secured communications.

"Appropriate and proportionate" is the guiding principle. The measures must be proportionate to the risks, the size of your organisation and the potential societal impact of an incident. It helps to use an existing framework as a guide. The CyberFundamentals framework offers concrete measures per level (Basic, Important, Essential). The NIS2 Supply Chain framework focuses specifically on chain security. Both provide structure and prevent you from reinventing the wheel.

Prioritisation

Not all risks need to be addressed simultaneously. Prioritise based on the combination of likelihood and impact. Risks that are likely and have high societal or operational impact are addressed first. Risks with lower impact or likelihood are planned for a later phase.

You must document and be able to justify that prioritisation. A supervisory authority doesn't expect you to have covered everything on day one, but does expect you to have made conscious choices and have a plan for the rest. Also document risks you consciously accept, including the rationale. A consciously accepted risk with clear justification makes a stronger impression than a risk that was simply not noticed.

Step 3: Cybersecurity measures

Basic technical measures

Article 21 names several concrete technical measures as a minimum. Multi-factor authentication (category j) is explicitly required. Policy on cryptography and where appropriate the use of encryption (category h) is also a basic requirement. Access management based on the principle of least privilege falls under category i: employees only receive access to the systems and data they need for their role.

This further includes patch management (timely remediation of known vulnerabilities in software and systems), network security (segmentation, firewalls, secured connections) and endpoint security (laptops, mobile devices, servers). The NCSC provides concrete guidance for this, including advisory products on backup strategies, secure system configuration and testing of security measures. These technical measures form the foundation on which the rest of your security programme rests.

Protection of systems and data

Category e of Article 21 requires attention to security in the acquisition, development and maintenance of network and information systems. If your organisation develops or commissions software, security requirements must be included from the start. Think of secure coding, code reviews, vulnerability management and testing security measures before systems go into production.

Category c requires business continuity, including backup management and crisis management. This means not only making backups, but also regularly testing whether you can restore them. A backup that has never been tested may be worthless in a crisis situation. The NCSC recommends establishing a backup strategy that describes how often you make backups, where you store them (preferably at a location not accessible via your network) and how frequently you perform recovery tests.

Continuous monitoring

Implementing measures is not enough. Category f of Article 21 requires policies and procedures for assessing the effectiveness of your risk management measures. You must structurally verify whether your measures still work and whether there are deviations that indicate a security incident.

Continuous monitoring includes monitoring login attempts, detecting unusual network activity, checking whether configurations still comply with established policy and identifying vulnerabilities. The frequency and depth depend on your risk profile. It can range from automated tests running daily to periodic penetration tests. The principle is clear: you must not only be able to demonstrate that measures have been implemented, but also that they actually function.

Step 4: Incident response and reporting obligation

Incident detection

Before you can handle or report an incident, you must detect it. Category b of Article 21 requires procedures for incident handling. Incident detection starts with defining what constitutes an incident within your organisation, setting up monitoring on your critical systems and training employees to recognise and report suspicious situations.

Technical detection includes log analysis, monitoring network traffic and using detection tools that alert on anomalous behaviour. But human detection is just as important. An employee who reports a suspicious email or flags an unexplainable system change is often the first to notice an incident. Ensure there's a low-threshold channel for reporting incidents and that employees know reporting is encouraged, not penalised. Category g (cyber hygiene and training) plays a direct role here: trained employees detect incidents faster.

Internal follow-up

Once an incident is detected, there must be a clear process for handling it. Who is informed first? Who assesses the severity? Who decides to isolate systems, bring in external help or inform customers? An incident response plan describes these steps and prevents valuable time being lost in a crisis situation.

The incident response plan must be prepared in advance, approved by management and tested. The NCSC recommends practising with fictional incidents so employees build experience. A tabletop exercise where you walk through a scenario with the team can already provide significant insight into gaps. After every real or practised incident, you conduct an evaluation and incorporate the lessons learned into improvements to your procedures.

Reporting procedures

Article 23 of the NIS2 directive sets strict requirements for reporting significant incidents. An incident is significant if it can lead to serious operational disruptions, financial loss or considerable damage to other persons or organisations. The reporting deadlines are tight: within 24 hours an initial warning to the competent CSIRT or competent authority, within 72 hours a more detailed incident notification with an initial assessment of severity and impact, and within one month a final report describing the cause, the measures taken and any cross-border consequences.

In the Netherlands, the report goes to the NCSC or the sectoral CSIRT, depending on your sector. Ensure you know in advance who to report to, through which channel and what information you need to provide. Include the reporting procedure in your incident response plan and ensure the responsible persons know how to make the report. That 24-hour deadline is tight. If you only start figuring out how the reporting process works during an incident, you will almost certainly miss the deadline.

Step 5: Vendors and supply chain management

Third-party risks

Category d of Article 21 requires the security of the supply chain, including security-related aspects in the relationship with direct suppliers or service providers. This is one of the most underestimated components of NIS2. The directive requires you to map and manage the security risks of your direct suppliers. You must take into account each supplier's vulnerabilities, the overall quality of their products and their cybersecurity practices.

Start with an inventory. Which suppliers have access to your systems or data? Which services are critical for your business continuity? Not every supplier carries the same risk. A cloud provider hosting your production data represents a different risk than an office supplies vendor. Prioritise your assessments based on the type of service, the access to your systems and the sensitivity of the data.

Agreements and oversight

Based on your supplier assessment, you make contractual agreements about security requirements. The European Implementing Regulation (EU 2024/2690) for NIS2 provides concrete guidance in Chapter 5 on what should be contractually arranged. Think of requirements for incident reporting, the right to audit, minimum security standards, agreements on the use of subcontractors and staff skills and awareness.

The requirements must be proportionate. A supplier with administrative access to your network deserves stricter agreements than a supplier delivering a single SaaS application without access to sensitive data. Periodic reassessment is needed to verify that suppliers still meet the agreed-upon requirements. The Centre for Cybersecurity Belgium recommends that suppliers in the chain comply at minimum with the CyberFundamentals level Basic.

Documentation

All supplier assessments, contractual agreements and reassessments must be documented. A supervisory authority can request evidence that you actively manage the security of your chain. That evidence must show that you have assessed suppliers, on what criteria, what agreements you have made and how you monitor compliance.

A register of suppliers with their risk classification, the date of the last assessment and the status of contractual agreements is a practical tool. Keep it current and accessible to the responsible persons. During a supervisory authority inspection, you don't want to spend hours searching for the right information.

Step 6: Continuous oversight and improvement

Evaluation and audits

NIS2 is not a one-off project. The directive requires organisations to regularly evaluate the effectiveness of their measures. This can be done through internal audits, technical tests (penetration tests, vulnerability scans), management reviews or a combination thereof. The NCSC provides guidance for this in four steps: determine the goal, choose the method, manage the execution and follow up on improvements.

The frequency depends on your risk profile. What applies in all cases: results must be documented and shortcomings must lead to concrete improvement actions with an owner and a deadline. An evaluation without follow-up is a missed opportunity.

Reporting

The board must be periodically informed about the status of cybersecurity. That reporting must be understandable to non-technical board members and provide insight into the key risks, the status of controls, outstanding deviations and the progress of improvement actions. This is not only a NIS2 requirement (Article 20 places responsibility with the board), but also a prerequisite for giving substance to board accountability.

Avoid reports that only show green checkmarks without context. A board member must be able to assess, based on the report, whether the organisation is sufficiently protected and where additional attention is needed. Concise, focused on deviations and action points, and supported by data.

Continuous improvement

The directive expects a systematic approach to improvement. Findings from incidents, audits, evaluations and external developments (new threats, changed regulations) must be structurally translated into adjustments to your measures and procedures. This is the plan-do-check-act cycle that also underlies management systems such as ISO 27001.

Document improvement actions, assign an owner and track progress. An organisation that can show it learns from incidents and evaluations, and that this leads to demonstrable improvements, makes a stronger impression on a supervisory authority than an organisation with lots of documentation but no visible improvement cycle.

Common mistakes in NIS2 compliance

Starting too late

The most common mistake is procrastination. Organisations wait until the Cybersecurity Act formally comes into force and only then begin. The problem: a thorough implementation takes six to twelve months. If you only start when the law is in effect, you're behind from day one. Supervisory authorities are authorised to check immediately after entry into force, and proactive supervision applies to essential entities.

Start now with the components that take the most time: establishing governance, performing a risk assessment, implementing basic technical measures and getting the incident response process in order. That investment is valuable for your organisation regardless, irrespective of the precise date of entry into force.

Over-documentation

A second common mistake is producing extensive policy documents that nobody reads or follows. NIS2 asks for demonstrable measures, not thick reports. A concise, workable security policy that is actually followed is worth more than an extensive document that disappears into a folder.

Direct your documentation at two audiences: the employees who must work with it and the supervisory authority who wants to see that you're in control. Keep policies concise and concrete. Describe what you do, why and who is responsible. Preserve evidence that measures are implemented and work (automated test reports, log files, configuration exports). More documentation is not automatically better documentation.

Lack of coherence

The third mistake is treating NIS2 as a collection of separate action points. Governance without risk assessment leads to arbitrary measures. Technical measures without an incident response plan mean you don't know what to do when something goes wrong. Supply chain management without documentation makes you vulnerable during an inspection. The ten measure categories of Article 21 are not intended to be separate. They form a coherent whole in which each category builds on the others.

The role of tooling in a NIS2 checklist

Overview and structure

As the number of controls, vendors and policy documents grows, manual tracking becomes unreliable. A GRC platform centralises all components in one place: measures are linked to risks, owners are assigned, evidence is linked to the measure it applies to and deviations are tracked until resolved.

The advantage is that you can see at any moment how you're doing. Which measures are implemented? Which have an owner? Where is evidence missing? That transparency is useful not only for your own organisation, but also for the supervisory authority that wants to verify you're in control.

Continuous compliance

NIS2 requires ongoing monitoring and evaluation. Tooling makes it possible to continuously monitor controls through automated tests. Instead of manually checking whether multi-factor authentication is still active on all your systems, a platform can do that automatically and alert you as soon as something no longer complies.

This continuous monitoring transforms compliance from a periodic project into part of your daily operations. That is precisely what NIS2 aims for: structural attention to cybersecurity, not an annual sprint towards an audit.

Less manual work

NIS2 compliance involves a lot of repetitive work: collecting evidence, updating statuses, producing reports, scheduling supplier assessments. Automation through integrations with your cloud environments and development tools saves hours per week. Automatic reminders for periodic reassessments prevent things from falling through the cracks. That time saving also reduces the risk of human errors. A measure that is automatically monitored is less likely to be overlooked than one that must be checked manually.

How Tidal Control supports NIS2 compliance

Structure and workflows

Tidal Control provides support for NIS2 compliance through the CyberFundamentals framework and the NIS2 Supply Chain framework. The platform contains pre-built controls and policy templates aligned with the requirements of these frameworks. You start with a foundation that you adapt to your own situation, significantly shortening your implementation timeline.

Each control can be assigned an owner, tasks and deadlines. This creates workable workflows: everyone knows what needs to happen, who is responsible and when it must be completed. Deviations are recorded and tracked through deviation management, ensuring improvement actions don't get lost in emails or shared folders.

Overview and assurance

Through more than 150 automated tests across Microsoft Azure, AWS, GitHub, GitLab, Jira and other tools, the platform continuously checks whether your controls are working. You see in a single overview which measures comply, where attention is needed and how your compliance status is developing. The platform serves as one central source of truth for your compliance information.

That overview is useful at multiple levels. The operational team sees which tasks are outstanding. Management sees progress at framework level. During a supervisory authority inspection, you can demonstrate with a current, substantiated overview that your organisation is in control.

Scalability

Organisations that follow ISO 27001, SOC 2 or other frameworks alongside NIS2 manage all processes in one platform. Controls relevant to multiple standards are implemented once and automatically mapped to the relevant frameworks. This prevents duplicate work and makes it possible to scale efficiently as your compliance ambition grows or your organisation expands into new sectors or markets.

Frequently asked questions about the NIS2 checklist

Which organisations is this NIS2 checklist intended for?

The checklist is intended for medium-sized and large organisations in one of the eighteen sectors covered by NIS2. This concerns both essential and important entities. Additionally, the checklist is useful for organisations preparing for potential NIS2 obligations or those that indirectly face requirements as a supplier to a NIS2 entity. The RDI self-assessment tool helps determine whether you fall under the Cybersecurity Act.

When are you actually NIS2 compliant with this checklist?

The checklist helps address all required components, but compliance depends on the quality of your implementation. Ticking off action points is not sufficient. You must be able to demonstrate that your measures are appropriate and proportionate to your risks, that they work and that you continuously evaluate and improve them. The ten measure categories from Article 21 form the minimum. The specific implementation depends on your sector, size and risk profile.

Which parts of NIS2 are most commonly forgotten during preparation?

Three components are consistently underestimated. First, governance: board responsibility and training of board members (Article 20). Second, supply chain security: assessing and managing supplier risks (Article 21(2)(d)). Third, the reporting obligation: setting up a process that can meet the tight deadlines of 24 hours (initial warning) and 72 hours (incident notification) (Article 23). Many organisations start with technical measures and forget that NIS2 explicitly also sets organisational and process-related requirements.

How do you prevent a NIS2 checklist from leading to over-documentation?

By focusing on workable rather than exhaustive documentation. Write policies that employees actually read. Preserve evidence that measures work (automated test reports, configuration exports) rather than extensive descriptions of intentions. Limit yourself to what is needed for two purposes: the employees who work with the measures and the supervisory authority who wants to see that you're in control. A concise policy with working evidence is more powerful than an extensive document without demonstrable execution.

When does tooling become necessary to maintain a NIS2 checklist structurally?

Tooling becomes necessary as soon as manual tracking is no longer reliable. In practice, that tipping point occurs at organisations with more than fifty employees, multiple cloud environments or the ambition to follow multiple frameworks simultaneously. A GRC platform prevents information from becoming scattered across spreadsheets, emails and shared folders. It makes continuous compliance achievable and ensures you have a current picture of your compliance status at any moment, rather than only during audits.