A customer's security questionnaire lands in your inbox, or a notice arrives from your national authority, and it asks for something your scanner cannot hand over: proof that you manage vulnerabilities as a programme, not a tool you run when there is time. You have scan reports. What you may not have is the trail that shows findings were triaged, fixed, and confirmed fixed.
That gap is what NIS2 compliance comes down to. The directive does not reward owning a scanner. It asks in-scope organisations to operate defined security measures and to demonstrate, on request, that those measures are real and current. For an IT manager carrying security and compliance on the same desk, the work is less about buying detection and more about producing evidence.
By the end of this guide you will know what NIS2 requires, who it applies to, what non-compliance costs, and the specific evidence an assessor expects for the vulnerability-handling measure at the centre of it.
What is NIS2 compliance?
NIS2 compliance is the state of meeting the obligations set by Directive (EU) 2022/2555, the European Union's second Network and Information Security directive. It means an in-scope organisation has implemented the Article 21 risk-management measures, reports significant incidents within the legal deadlines, and can produce evidence that the measures operate. It is a continuous state, not a one-time certificate.
The directive replaced the original 2016 NIS rules and widened both the sectors covered and the obligations imposed. It takes an all-hazards approach, meaning the measures must address risks from any source: technical failure, human error, supply-chain weakness, or deliberate attack.
NIS2 is a directive, so it does not apply to you directly. Each member state transposes it into national law, and your obligations come from that national act. The directive set a transposition deadline of 17 October 2024 under Article 41, and the substance is harmonised across the EU even where the national wording differs.
One practical consequence: the United Kingdom is outside NIS2. If you operate only in the UK, this directive does not bind you, though UK organisations offering services into the EU can still fall in scope through their EU operations.
Who does NIS2 apply to? Essential and important entities
NIS2 applies to medium and large organisations operating in the 18 sectors the directive designates as critical across its two annexes, from energy, transport, water, and healthcare to digital infrastructure, public administration, and managed service providers. In-scope organisations are sorted into two categories that determine how they are supervised and how hard they can be fined: essential entities and important entities.
The category does not change the security obligations. Both essential and important entities must meet the same Article 21 measures. What differs is the supervisory regime and the penalty ceiling.
| Essential entities | Important entities | |
|---|---|---|
| Typical profile | Larger operators in the highest-criticality sectors | In-scope entities not classed as essential |
| Supervision | Proactive (audits, inspections without prior incident) | Reactive (triggered by evidence of non-compliance) |
| Maximum fine | At least 10 million euro or 2% of global turnover | At least 7 million euro or 1.4% of global turnover |
| Article 21 measures | Apply in full | Apply in full |
The directive targets medium-sized and larger entities, broadly those with at least 50 staff or 10 million euro in annual turnover, though member states can pull smaller entities into scope and the exact figures follow each national transposition, so confirm your status against your own member state's act. If you are unsure which category you fall into, that scoping decision is the first thing to settle, because it sets your supervisory exposure.
Knowing you are in scope is the easy part. The harder question is what the measures require.
What does NIS2 require? The Article 21 measures
Article 21 of the directive requires in-scope entities to take "appropriate and proportionate technical, operational and organisational measures" to manage the risks to their network and information systems. Paragraph 2 then lists ten minimum measures every entity must cover. They are the backbone of NIS2 compliance and the checklist any assessment works from.
The ten measures under Article 21(2):
| Ref | Measure |
|---|---|
| (a) | Risk analysis and information system security policies |
| (b) | Incident handling |
| (c) | Business continuity, backup, disaster recovery, and crisis management |
| (d) | Supply-chain security |
| (e) | Security in acquisition, development, and maintenance, including vulnerability handling and disclosure |
| (f) | Policies to assess the effectiveness of the measures |
| (g) | Basic cyber hygiene practices and security training |
| (h) | Cryptography and, where appropriate, encryption |
| (i) | Human resources security, access control, and asset management |
| (j) | Multi-factor authentication, secured communications, and continuous authentication |
The list is deliberately broad because the all-hazards principle demands it. Some measures are governance work, such as policies and training. Others are technical and continuous. Measure (e), vulnerability handling and disclosure, is the one most directly served by tooling, and it is where an IT team can show concrete, repeatable evidence fastest.
What NIS2 requires for vulnerability management
NIS2 makes vulnerability management a legal requirement through Article 21(2)(e), which covers "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." In practice that means finding vulnerabilities across the systems you run, fixing the ones that matter, disclosing where required, and keeping evidence that the cycle happens.
The directive states the obligation; the detail of what good looks like lives in Commission Implementing Regulation (EU) 2024/2690. Its Annex, section 6.10, translates the vulnerability-handling measure into concrete duties: monitor for vulnerability information through appropriate channels, perform scans and record evidence of the results at planned intervals, address critical vulnerabilities without undue delay, and run a coordinated vulnerability disclosure procedure.
Covered entities must "perform, where appropriate, vulnerability scans, and record evidence of the results of the scans, at planned intervals." The cadence is risk-based, not a fixed number.
There is an important scope boundary here. The implementing regulation binds a named sub-set of digital providers:
- DNS service providers and top-level-domain registries
- Cloud computing and data centre service providers
- Content delivery networks
- Managed service providers and managed security service providers
- Online marketplaces, search engines, and social-networking platforms
- Trust service providers
If you are a manufacturer, a healthcare provider, or an energy or water SMB, you are bound by the directive's Article 21(2)(e), and the implementing regulation shows the technical detail your competent authority will look toward, rather than a regulation that binds you line by line. If you are one of the named digital providers, the implementing regulation binds you directly.
Either way, the same artifact answers the requirement. The European Union Agency for Cybersecurity (ENISA) published technical implementation guidance that lists, for the vulnerability-handling clause, the "examples of evidence" an assessor looks for. The guidance is advisory rather than binding, but it is the clearest public statement of what proof means here.
ENISA's named evidence for vulnerability handling includes:
- Documented scan reports: the technical output of the scans you ran.
- Schedule and follow-up logs: records showing scan schedules, results, and the actions taken on them.
- Proof of remediation: evidence that findings assessed as critical have been addressed.
- Accountability records: timelines and the responsible people for each remediation, plus verification that fixes worked.
- Justified exceptions: records of any vulnerability not addressed, with the reasoning for not addressing it.
Read that list back and the pattern is clear: a scan report on its own satisfies none of these points. Every item is about the lifecycle around the scan, who acted, when, and whether the fix was confirmed. ENISA points to standard severity inputs such as the Common Vulnerability Scoring System (CVSS) and the Exploit Prediction Scoring System (EPSS) to decide what counts as critical, and expects critical and high findings to be handled without undue delay.
This is the gap most teams hit, and it is the work Vornin is built to remove. Findings from across your external attack surface, web apps, infrastructure, code, and cloud are auto-mapped at ingestion to the NIS2 measures they touch, one of nine compliance frameworks Vornin maps from a single finding, every status change is sealed in a tamper-evident evidence chain, and any finding exports as an auditor pack your assessor can verify. The evidence ENISA describes is produced as a by-product of running the programme, not assembled by hand the week before a review.
Does NIS2 require monthly scanning?
No. Neither the directive nor the implementing regulation names a scanning frequency. The implementing regulation says scans happen "at planned intervals," which means a cadence you set and justify from your own risk assessment, not a number handed to you.
The "monthly scanning" claim is a persistent myth. What the law expects is a regular, planned cadence backed by reasoning, not an ad-hoc scan when someone remembers. A quarterly cycle for low-risk assets and a tighter cycle for internet-facing systems can both be defensible if your risk assessment supports them. The only fixed interval ENISA names anywhere in this area is a biannual review of your vulnerability-monitoring channels, which is a different obligation from the scans themselves.
If you want the operational picture of what a defensible cadence looks like in practice, that is the subject of how to run a vulnerability management programme.
NIS2 incident reporting deadlines: 24 hours, 72 hours, one month
Beyond risk management, NIS2 sets strict incident-reporting deadlines under Article 23. For a significant incident, an entity must submit an early warning within 24 hours of becoming aware of it, a fuller incident notification within 72 hours, and a final report within one month of that notification.
| Stage | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Initial flag; whether the incident may be malicious or cross-border |
| Incident notification | Within 72 hours of becoming aware | Updated assessment, severity, indicators of compromise |
| Final report | Within one month of the notification | Root cause, mitigation, cross-border impact |
Incident reporting is a process obligation, handled through your national Computer Security Incident Response Team (CSIRT) or competent authority. It is separate from vulnerability scanning, and no scanner files these reports for you. It belongs in your incident-handling plan under Article 21(2)(b), and it is worth naming plainly so you do not assume a vulnerability tool covers it.
What non-compliance costs: fines and management liability
NIS2 backs its requirements with administrative fines and personal accountability for leadership. Under Article 34, essential entities face fines of a maximum of at least 10 million euro or 2% of total worldwide annual turnover, whichever is higher. Important entities face at least 7 million euro or 1.4%.
The phrasing matters. The directive sets "a maximum of at least" those figures, which is a floor on the ceiling that member states must allow, not a cap. National law can permit higher maximums, so the headline numbers are the minimum exposure, not the limit.
Fines for essential entities reach a maximum of at least 10 million euro or 2% of global annual turnover, whichever is higher. Member states must allow at least this ceiling.
The accountability goes further than the corporate balance sheet. Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures, oversee their implementation, and states they can be held liable for the entity's infringements. Directors must also follow training so they can identify risks. For the board, NIS2 turns vulnerability management from an IT line item into a governance duty with names attached, which is often what unlocks the budget to do it properly.
How to prepare for a NIS2 audit
Preparing for NIS2 comes down to three moves:
- Confirm your scope. Settle whether you are an essential or important entity, and whether the implementing regulation binds you directly or shows the technical detail your authority looks toward.
- Close the gaps across the Article 21 measures. Run a gap analysis against the ten measures and remediate where you are exposed.
- Build the evidence trail that proves the measures operate. Capture the lifecycle around each control, not just the latest scan output.
The first two are governance and engineering work. The third is where most teams are caught short, because evidence is easy to assume and hard to retrieve under time pressure.
A gap analysis maps your current controls against the ten measures and surfaces where you are exposed. From there the work is ordinary security operations: assign owners, remediate, and set the planned cadence your risk assessment supports. None of that is novel. The part that fails reviews is not the scanning, it is being unable to show the history when someone asks.
What a NIS2 audit checks
A NIS2 assessment is not a tick-box certificate exercise. A competent authority, or an enterprise customer running supplier diligence, checks whether your security measures exist and operate, and asks for the evidence. For vulnerability handling, that evidence is ENISA's named artifacts: documented scan reports, proof that critical findings were addressed, and records of who remediated what and when.
The honest difficulty is that a scan report proves you looked once. The assessor wants the lifecycle: the finding, its priority, the fix, and confirmation the fix held. This is the closure loop that breaks down in spreadsheets and chat threads, where "we think it's fixed" is the most you can say. Vornin keeps that loop intact, auto-resolving a finding only when a later scan no longer detects it, timestamping the confirmation, and sealing the whole history in a tamper-evident chain so the record cannot be quietly edited after the fact.
NIS2 also reaches well past anything a scanner can test. Measures like training, business continuity, and supply-chain governance need human sign-off, not a scan result. Honest compliance handling marks those controls as requiring manual attestation rather than scoring them as passed, so your evidence reflects reality. For an IT manager covering security without a dedicated team, having the technical evidence produced automatically frees the time the governance measures genuinely demand.
NIS2 and ISO 27001: one control, one evidence record
If you already run ISO 27001, you are most of the way to the vulnerability-handling measure NIS2 expects. ENISA's official mapping table aligns the implementing regulation's vulnerability-handling clause with ISO/IEC 27001:2022 control A.8.8, management of technical vulnerabilities. The underlying control is the same.
That overlap is worth banking. An organisation running an ISO 27001 vulnerability management programme under control A.8.8 is already doing the work NIS2's measure (e) names, so the question is not whether to do it twice but whether one evidence record can serve both frameworks. It can, when findings are mapped to every framework they touch at ingestion rather than tagged by hand per audit. The same logic extends to the other regimes an EU organisation juggles, including DORA's ICT risk requirements for financial entities and the wider set of frameworks a compliance team manages across the estate.
Frequently asked questions
What is NIS2 compliance in a nutshell?
NIS2 compliance means an in-scope organisation has implemented the Article 21 security measures of Directive (EU) 2022/2555, reports significant incidents on time, and can prove the measures operate. It is an ongoing state demonstrated through evidence, not a certificate you hold.
Is NIS2 certification mandatory?
There is no formal NIS2 certificate, and none is required. NIS2 is not a certification scheme. You demonstrate compliance through evidence to your national competent authority, which can supervise and fine you. This differs from ISO 27001, where an accredited certification body audits you and issues a certificate.
What are the penalties for NIS2 non-compliance?
Under Article 34, essential entities face fines of a maximum of at least 10 million euro or 2% of global annual turnover, whichever is higher. Important entities face at least 7 million euro or 1.4%. Under Article 20, management bodies can also be held personally liable for infringements.
What are the NIS2 incident reporting deadlines?
Article 23 sets three deadlines for a significant incident: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within one month of the notification. Reports go to your national CSIRT or competent authority.
How often does NIS2 require vulnerability scanning?
NIS2 does not set a fixed scanning frequency. The implementing regulation requires scans "at planned intervals," meaning a regular cadence you set and justify from your risk assessment. There is no monthly mandate. ENISA names only a biannual review of vulnerability-monitoring channels.
Key takeaways recap
NIS2 compliance is the ongoing state of meeting the Article 21 measures and being able to prove it, across essential and important entities in critical sectors. Vulnerability handling under Article 21(2)(e) is the most tool-served measure, and the proof an assessor wants is the lifecycle around the scan, not the scan alone. The penalties are real and now reach the boardroom, which is what tends to move budget. The teams that pass are the ones whose evidence is a by-product of running the programme, not a scramble before the review.
Read-only access · Repository data processed temporarily and deleted immediately · EU-hosted.
