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.
Does NIS2 apply to you?
The fastest way to settle it is to test three conditions together. You are likely in direct scope when all three hold:
- Sector: you operate in one of the 18 sectors named across the directive's two annexes, from energy, transport, water, and healthcare to digital infrastructure, ICT service management, public administration, and digital providers.
- Size: you are a medium or large entity, broadly 50 or more staff or 10 million euro or more in annual turnover, unless your member state has pulled smaller entities in your sector into scope.
- Establishment: you provide services in, or are established in, the EU. A UK-only operation is outside NIS2, but the same company's EU operations can be in scope.
Size and sector together usually decide it, but national transpositions vary, so the binding answer is always your own member state's act. The harder case is the company that fails the size or sector test yet still gets pulled in commercially, which is the next question.
What if NIS2 does not apply to you, but your customers ask anyway?
Many companies that are not directly in scope still have to answer for NIS2, because their customers are. Article 21(2)(d) makes supply-chain security one of the ten measures, so an in-scope entity has to manage the security of its suppliers. In practice that obligation travels downhill as a security questionnaire: the regulated customer asks you to show the same controls and evidence they are required to hold.
For a supplier, the trigger is rarely the regulator. It is a stalled deal, a procurement review, or a prospect that asks for current scan results and proof of remediation before the next meeting. The work to answer it is the same vulnerability-handling evidence the directly-regulated entity produces, which is covered next.
Knowing you are in scope, directly or by proxy, 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 wording that trips most teams up is the calibration test. Article 21(1) says the measures must take into account the "state-of-the-art" and, where relevant, European and international standards, weighed against the cost of implementation. It is not a fixed bar. It means your controls are judged against what is currently considered competent practice for an organisation of your size and risk, so a defensible, documented choice matters more than chasing the most advanced tool on the market. Standards such as ISO/IEC 27001 and the CIS Controls are the usual reference points for what "state-of-the-art" looks like in practice.
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.
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; where it appears, it traces to insurer questionnaires and market practice rather than the regulation. 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. If the scan itself is the open question, start with what a vulnerability scan is and what it tests, which also covers the cadence baselines insurers and auditors expect in practice.
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.
Two terms in that sentence carry the whole obligation. A "significant incident" is defined in Article 23(3): one that has caused or is capable of causing severe operational disruption or financial loss to your organisation, or that has affected other people through considerable material or non-material damage. Routine, contained events do not clear that bar; the test is severity and reach, not whether an attacker was involved. "Becoming aware" is when the clock starts, and it is earlier than most teams assume. It means the point at which you have reasonable grounds to believe a significant incident has occurred, not the point at which forensics confirm it. That is why the early warning at 24 hours is a flag, not a full report, and why the detail follows at 72 hours and one month as your understanding firms up.
| 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.
That same shift settles the budget conversation. A CFO who will not sign off on "trust me, we are handling it" will sign off against a record they can see, because liability now sits with the people approving the spend. The evidence trail an assessor asks for is the same artifact that justifies the investment internally: it replaces assurance with a documented, current account of what was found, fixed, and confirmed.
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 an ISO 27001 vulnerability management programme, you are most of the way to the vulnerability-handling measure NIS2 expects. ENISA's official mapping aligns the clause with ISO/IEC 27001:2022 control A.8.8, so one evidence record can serve both frameworks when findings are mapped at ingestion rather than tagged by hand per audit.
The caveat is scope: ISO certifies only what your Statement of Applicability covers, while NIS2 binds the whole legal entity and adds duties no certificate tests, incident reporting and management liability among them. What your certificate does and does not carry over is the subject of NIS2 vs ISO 27001. The same one-record logic extends to 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.
Does NIS2 apply to me?
NIS2 applies if you operate in one of its 18 critical sectors, are a medium or large entity (broadly 50 or more staff or 10 million euro or more in turnover), and provide services in the EU. Member states can pull smaller entities in, so confirm against your national transposition. Suppliers below the threshold are often reached through their customers' contracts instead.
When is NIS2 enforced from?
The directive set a transposition deadline of 17 October 2024, after which each member state's national act, not the directive itself, is what binds you. Several states transposed late, so national enforcement has come online in stages through 2025 and 2026. Once your member state's law is in force, its competent authority can supervise, request evidence, and impose fines. In practice the obligations are live wherever transposition is complete, and customer security questionnaires arrive regardless of the regulator's timetable.
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.
What counts as a significant incident under NIS2?
Under Article 23(3), an incident is significant if it has caused or could cause severe operational disruption or financial loss to your organisation, or considerable material or non-material damage to others. The 24-hour clock starts when you have reasonable grounds to believe such an incident has occurred, not when forensic analysis confirms it.
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.
Does ISO 27001 cover NIS2?
Not on its own. There is a crosswalk and significant overlap: ISO control A.8.8 maps directly to NIS2's vulnerability-handling measure, so an existing ISO 27001 programme covers much of the technical work. The gaps are scope and legal duties: ISO certifies only what your Statement of Applicability covers, while NIS2 binds the whole legal entity and adds obligations an ISO audit never tests, including incident reporting deadlines and management liability. For the control-by-control crosswalk, see NIS2 vs ISO 27001.
My customers are asking for NIS2 compliance. What do I show them?
Even if NIS2 does not apply to you directly, customers bound by it must secure their supply chain under Article 21(2)(d), so they pass the requirement down as a security questionnaire. What clears it is evidence: documented scan results, proof that critical findings were fixed, and a record of who did what and when.
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 · Tamper-evident audit evidence · EU data residency
