NIS2: Who Actually Has to Comply, What It Costs to Ignore and Why Nmap/AI Can't Prove It for You

Half the questions I get about NIS2 are some version of "do we actually have to do this, or is it another directive that sits in a drawer?"

Short answer: you have to do it, the drawer option expired, and the tools being sold to make it painless mostly can't.

Let's take that apart, with sources, and end somewhere useful.

NIS2 is Directive (EU) 2022/2555. A directive is not a regulation, so it does not bite you directly. It binds you through your own country's law, the way GDPR does. That single fact is behind most of the confusion, and it is where we should start, because "for whom is this mandatory" has a precise answer and "what happens if you ignore it" has numbers.

I've spent the last stretch reading the actual legal text, the Commission's implementing regulation, and the national transpositions, and then mapping all of it against what security tools can and can't do. This post is that work, in four parts, and then an honest pitch for where Pentesterra fits. Every claim links to a source. I would rather you check them.

Part 1: Who has to comply, and what it costs to ignore

The two-part test

You are in scope if both are true:

• you operate in one of NIS2's 18 sectors, and
• you are at least a medium-sized company.

The sectors come from two annexes:

• Annex I (high criticality): energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management (managed service and managed security providers), public administration, space.
• Annex II (other critical): postal and courier, waste management, chemicals, food, manufacturing (medical devices, electronics, machinery, vehicles), digital providers (marketplaces, search engines, social networks) and research.

"Medium-sized" follows the EU SME definition: from 50 staff, or annual turnover and balance sheet both over 10 million euro. Below that you are usually out, with exceptions that ignore size entirely:

• DNS providers, TLD registries, trust service providers and public electronic communications;
• anyone a member state names as sole or critical provider (NIS2 Art.2 and Art.3);
• if you sell across the EU but sit outside it, you still need an EU representative (Art.26).

Essential vs important is not a compliment, it's your supervision regime

NIS2 splits in-scope entities into essential and important. It is not a ranking of how good your security is. It decides how the regulator watches you and how hard they can hit you.

Essential entities get proactive supervision: on-site inspections, random checks, regular and targeted audits, and, in the text itself, "security scans" (Art.32(2)). Important entities get reactive supervision, triggered when there is an indication something is wrong (Art.33). Either way, management bodies must approve the security measures, oversee them, and can be held personally liable (Art.20). That last part is why boards started paying attention.

So has anyone actually been fined?

Here is the honest version, because you'll see scarier claims. There is not yet a long public list of NIS2 fines. The reason is timing: the transposition deadline was 17 October 2024, and most countries missed it. In July 2026 the Commission took Ireland, Spain, France and the Netherlands to the EU Court of Justice for still not having transposed, asking for lump-sum and daily penalties. So the enforcement machine is only now switching on.

What is real and dated is the exposure. Germany's law (NIS2UmsuCG) came into force in December 2025, and the number of supervised entities jumped from about 4,500 to roughly 29,500, with a registration deadline in March 2026. Belgium requires its essential entities to have a conformity assessment under way by 18 April 2026. Italy's ACN set significant-incident reporting from 1 January 2026 and baseline measures for most listed entities by around 31 October 2026. The fines are not hypothetical, they are scheduled.

The takeaway for Part 1: if you are a medium or larger company in one of the 18 sectors, this is mandatory now, the penalties reach into eight figures and into your executives personally, and the countries that were slow are being pushed by the Court. The drawer is closed.

Part 2: Do you need a certified auditor to "get NIS2 certified"?

Short version: there is no EU "NIS2 certificate." NIS2 works like GDPR: you have to be compliant and be able to show it when the authority asks, and nobody hands you a certificate that ends the conversation. This is in the text, not my reading of it. The directive makes cybersecurity certification explicitly voluntary - a member state may require you to use certified products or services under a European scheme, but there is no "certified NIS2" status for the entity (Directive Art.24). What actually binds you is the duty to produce "evidence of implementation ... and the respective underlying evidence" when the authority asks (Art.32(2)(g), 33(2)(f)) - the same be-compliant-and-demonstrate-it model as GDPR's accountability principle.

A few things follow from that, and they are worth getting right because vendors blur them.

• The Commission implementing regulation (CIR 2024/2690) spells out the technical and methodological measures in a 13-section annex of roughly 160 numbered requirements. It is directly binding on digital-infrastructure providers (DNS, cloud, data centres, MSPs, and so on). For everyone else the detailed measures come from national law, but the CIR annex, mirrored by ENISA's June 2025 implementation guidance, is the practical reference. That is the structure this whole analysis is built on.
• Who checks you is your national authority: ACN in Italy, BSI in Germany, CCB in Belgium. Essential entities are checked proactively, important ones after a signal (Art.32 and 33). Targeted audits by an independent body are paid by the audited company (Art.32(2), 33(2)). Read that twice: the audit is on your bill.
• "Certified auditor" is not the same as "certified you." Expect vendors to wave credentials around, so separate two things they blur. A person or firm can hold audit qualifications (CISA, ISO 27001 Lead Auditor) or be an accredited conformity-assessment body, and for a targeted audit NIS2 does require a qualified independent body (Art.32(2)(e)) - whose bill you pay. None of that changes what the tool in the engagement produces: no credential turns a banner-grabbing scan into reproducible evidence, and no private auditor issues a state "NIS2 certificate" - the national authority supervises, and the auditor's report is one input to it. So when a service is sold as "assessment by certified auditors," the question that matters is what evidence the assessment actually leaves behind, not whose signature is on the cover.
• ISO 27001 is not automatically NIS2. It covers most of the Art.21 areas and is a strong evidence base, but it does not cover the Art.23 reporting timelines, national registration, or the specific management-liability duties. Belgium formally accepts ISO 27001 (with the right scope and Statement of Applicability) or its own CyberFundamentals framework as a route. Germany only forces recurring proof (every three years, via audit or certification) on critical-infrastructure operators, not on every entity.
• Something is coming, but it is not here. The direction of travel is simplification and certification. The Commission's Digital Omnibus (19 November 2025) already unified incident reporting and clarified how NIS2 sits next to the CER Directive and DORA. Then on 20 January 2026 it proposed a full cybersecurity package: targeted NIS2 amendments plus a revised Cybersecurity Act. The headline for compliance is a cyber-posture certificate - the Commission wants entities to "certify their cyber posture ... [and] get presumption of conformity with NIS2 and other Union legislations." An essential entity holding one could be spared targeted audits for the covered requirements, but only where the certificate comes from a third-party conformity assessment body (Art.78(2) of the revised Act), and "on-site inspections, security scans, or targeted information requests ... remain available." The same package narrows scope for about 28,700 companies (6,200 of them micro and small) and adds a small mid-cap category covering another 22,500. Separately, NIS2's own review clause (Art.40) has the Commission reporting by 17 October 2027, with a legislative proposal attached "where necessary." None of it is law: the certification scheme does not exist yet, ENISA has to build a candidate "within one year as a rule," and adoption is not expected before late 2026 or 2027. If anything it sharpens the point - even the exemption being drafted is a certificate from an accredited body, not a clean scan. Do not plan around it yet.

So the practical question is not "who certifies me" but "who assembles the evidence." An accredited auditor issues the final opinion where one is required. Before that, someone has to produce the evidence base: the technical findings, the tested controls, the documented answers for everything a scan can't see. That "someone" is where a tool, a service, or a platform earns its keep. Which brings us to the tools.

Part 3: The market is full of "NIS2 checkers." Most of them can't check NIS2

Every few weeks a new product appears that promises a NIS2 assessment from a button. Strip the interface and it is almost always the same open-source stack: nmap and NSE scripts for the network, a few Kali tools, and lately an LLM agent driving all of it. There are real, shipping examples of the pattern, like mcp-kali-server ("run nmap, nxc or any other tool" from a chat client) and hexstrike-ai ("autonomously run 150+ cybersecurity tools", installable with apt install).

I like these tools. I've used all of them for years, and Pentesterra uses the same primitives under the hood. The problem is not the tools. The problem is the claim that their output is NIS2 evidence. It isn't, and here is the sourced reason, in three layers. (For the deeper teardown of why these scanners miss vulnerabilities in the first place, I wrote a separate sourced piece.)

Layer 1: coverage. Most of NIS2 isn't scannable at all

First, the distinction the rest of this section rests on. A technical control is one you can prove by running something: a script, a scan, a check that returns a fact about the system - is TLS 1.2+ enforced, is this port closed, is that CVE patched. An organizational control is a matter of process, policy and people: that a SIEM exists and log sources are correctly classified, that management reviewed the risk treatment, that staff are trained, that suppliers signed incident clauses. You cannot run a check for those - the evidence is a document and an attestation, not a scan result. A mixed control is one where a scan gives a partial signal but a document still has to carry the rest. This is not a Pentesterra opinion; it is the shape of the standard.

I mapped all 226 requirement lines (the CIR annex plus directive-level duties) by nature. 153 are organizational - policies, reviews, contracts, training, physical security, governance, and everything that lives in a SIEM or a logbook rather than on a port. 50 are mixed. Only 23 are purely technical. No scanner, however clever, produces evidence that your backups were test-restored, that supplier contracts carry incident clauses, or that the board approved the security policy. The best it can do is write a sentence claiming so, which is exactly the thing an auditor exists to disprove. That caps a pure scanner at roughly 73 lines before you even ask how well it does them.

Layer 2: Nmap is a fine port scanner and a poor compliance tool

Checked against a live install: Nmap 7.98 ships 613 NSE scripts, and 211 of them are tagged intrusive. It does a genuinely good job on a handful of NIS2-relevant facts: TLS and SSH cipher strength, SMB signing, clear-text admin protocols, exposed services. That is about 8 of the 226 lines verified cleanly.

Then it runs out. There is no NSE script for SPF, DKIM, DMARC, MTA-STS, DANE, RPKI, MFA, SSO, OAuth, SAML, JWT, WebAuthn or a security.txt disclosure channel - the exact controls a compliance check needs most. Its CVE output (vulners) is banner-based: it matches the version string against a remote database. Red Hat says the consequence plainly - tools that decide "based solely on the version number ... can result in false positives as they do not account for backported security fixes." Hand that raw list to an auditor as your patch-management evidence and you have handed them a list they cannot trust. And Nmap keeps no evidence store: each run is a standalone XML file, no history, no re-test, no criticality or remediation record. CIR 6.5.2 asks for tests documented "including assessment of criticality and mitigating actions for each finding." Raw XML is not that.

Layer 3: the AI agent adds reach, and takes away evidence

An LLM driving Kali reaches further than bare Nmap. But three properties make its output unusable as evidence, no matter how good the model is.

It is not reproducible. Reproducibility is the base property of evidence. LLM inference doesn't have it, even at temperature 0. Thinking Machines Lab showed in 2025 that the same prompt sent a thousand times "returns dozens of different responses," because server-side batching changes the numerical path. An assessment you can't reproduce is a sample, not an audit.

Its results are low and inconsistent, measured. On the AutoPenBench benchmark a fully autonomous agent solved 21% of tasks (9% on real-world targets); with a human helping, 64%. A separate 400-run study pointed the same model at the same fixed target 100 times and got wildly different outcomes - one model succeeded 85 times, another 25 - with failure modes like output truncation and running out of budget. A control that "passes" on Monday and "fails" on Tuesday against an unchanged system is measuring the agent, not you.

It still runs the same tools. The agent inherits Nmap's coverage gaps and adds orchestration and prose. On the 153 organizational lines it can only generate text, and an LLM asked "is this NIS2-compliant?" will answer confidently with no basis - a hallucinated verdict wearing an assessment's clothes. Under NIS2, a false "compliant" is worse than no answer, because Art.20 makes it your management's problem.

The legal test all of this fails

This is the part that isn't my opinion. NIS2 and the CIR say what evidence has to look like:

• tests run "according to a documented test methodology" (CIR 6.5.2(b));
• results documented "including assessment of criticality and mitigating actions for each finding" (CIR 6.5.2(c));
• vulnerability scans "at planned intervals" with "recorded evidence" (CIR 6.10.2(b));
• "evidence of implementation ... and the respective underlying evidence" available to the authority (Art.32(2)(g), 33(2)(f));
• written proportionality reasoning for any "where appropriate" measure you don't apply (CIR Art.2(2)).

Methodology, reproducibility, criticality, chain of custody, documented reasoning. Those are properties of a process and a record, not of a single clever scan. A port scanner has none of them; an autonomous agent actively breaks the first two. Judge any "NIS2 tool" by that list, not by how many Kali tools it can launch.

Part 4: The full control map, all 226 lines

Below is the complete thing, nothing hidden. Every requirement of the CIR 2024/2690 annex (with lettered sub-items split where the technical answer differs) plus six directive-level duties, grouped by the 13 annex sections. For each line: its type, whether Pentesterra evidences it today, which Pentesterra capability covers it, what Nmap+NSE and an AI-Kali wrapper can do, and a short note.

This is also where the questionnaire earns its place. Every organizational and mixed line that a tool cannot reach is not left blank - it becomes a structured question, answered by the right person on your side, with the supporting document attached. That is how the assessment stays complete against the standard instead of covering only the 10% a scanner can see. The technical findings and the documented answers, with their evidence files, are what we hand to the auditor.

How to read the columns

• Type: technical (a tool can verify it), mixed (a document plus a technical signal), org (governance: a policy, approval, review, contract or record) and manual (a recurring human task: training, testing, drills, restores, background checks). Org and manual are the two kinds of organizational control - together they are the 153 organizational lines in the chart above. A on an org or manual line is not a platform "gap": those are done off the tool and evidenced by a documented answer, so the tally below counts only unmet technical and mixed controls as gaps.
• Pentesterra: evidenced automatically today · partial or external only · covered by the questionnaire · questionnaire, partially · not covered yet.
• Covered by: which Pentesterra capability. Bold = wired today, a trailing ° = on the Q4 2026 roadmap. "Identity & Access" is deliberately store-agnostic: web SSO, OAuth/SAML/OIDC, JWT, WebAuthn, session and brute/lockout checks; an on-prem directory (AD/LDAP/Kerberos) where one exists; or a cloud identity provider. It never assumes you run Active Directory.
• Nmap + NSE / AI-Kali: can verify deterministically · partial signal · can only produce an unverified claim · cannot address it.

Section D - Directive-level obligations (not in the CIR Annex)

Section 1 - Policy on the security of network and information systems (Art.21(2)(a))

Section 2 - Risk management policy (Art.21(2)(a))

Section 3 - Incident handling (Art.21(2)(b))

Section 4 - Business continuity and crisis management (Art.21(2)(c))

Section 5 - Supply chain security (Art.21(2)(d))

Section 6 - Security in acquisition, development and maintenance (Art.21(2)(e))

Section 7 - Effectiveness assessment (Art.21(2)(f))

Section 8 - Cyber hygiene and security training (Art.21(2)(g))

Section 9 - Cryptography (Art.21(2)(h))

Section 10 - Human resources security (Art.21(2)(i))

Section 11 - Access control (Art.21(2)(i),(j))

Section 12 - Asset management (Art.21(2)(i))

Section 13 - Environmental and physical security (Art.21(2)(c),(e),(i))

Reach is not evidence

Here is the trap in every "free NIS2 scanner" pitch: it counts what a tool touches, not what it can prove. Run against all 226 lines and the gap is not subtle. Nmap reaches 46 controls, an AI-Kali agent 66, and neither reaches more than a handful of the 153 organizational controls that actually decide NIS2. But reaching a control is not evidencing it. Nmap's output is deterministic, so it verifies 8; the AI agent's runs are not reproducible, so however many tools it fires, it proves none. Pentesterra evidences 216 - the 46 technical with first-party proof and the 170 organizational and manual through the questionnaire, each with the underlying evidence attached to the assessment. That is what you are paying for: not a bigger scan than Nmap, but an audit-ready evidence base across the whole standard, including the 68% no scanner can reach.

In closing: what Pentesterra actually does here

I'll be straight about our own numbers, because Part 3 was about honesty. Today we evidence 46 of those 226 lines with first-party technical proof and cover the organizational and manual controls - 170 lines - through the structured questionnaire, so the assessment is complete against the whole standard. Only 10 lines, all purely technical, are not yet automated; those are on the Q4 2026 roadmap and marked as such in the table above. We do not issue a compliance verdict and we are not your auditor. What we do is produce the evidence base an auditor needs, and an indicative readiness view for your own management.

Concretely, Pentesterra brings to a NIS2 assessment:

• First-party technical evidence on the technical and mixed controls - from external exposure, network and web/API testing, DevGuard code and supply-chain scanning, identity and access testing, and phishing simulation. Real findings with proof, not a version guess. And we attach that evidence - the findings, the proof-of-concept, the scan records - to the assessment, so what reaches the auditor is the underlying evidence the law asks for, not a summary.
• A structured questionnaire for the organizational controls, routed to the right people, with document attachments, so the assessment is complete against the whole standard and not just the scannable slice. This is the part that keeps you from quietly failing on the 68% no scanner can see.
• One matrix that shows, per control, what the evidence says, what the answer says, and where the gaps are - plus an indicative readiness score and a white-label gap report you can hand onward. Every gap becomes a concrete next step rather than a vague "improve security."

And you can use it two ways. As a service, where we run the assessment and deliver the evidence base and gap report. Or as a platform, where your own team, or your partner's, runs the self-assessment, launches the technical modules, and manages the evidence in one place. Same engine either way.

NIS2 is not going back in the drawer, and the tools promising to make it disappear mostly can't produce what a regulator will ask for. If you want to see the assessment on your own scope, the compliance module is here, and I'm happy to walk a real environment through it.

---

Sources

• Directive (EU) 2022/2555 (NIS2), full text: eur-lex.europa.eu - scope (Art.2, 3), governance and liability (Art.20), measures (Art.21), incident reporting (Art.23), certification (Art.24), registration (Art.27), supervision and fines (Art.32-34)
• Commission Implementing Regulation (EU) 2024/2690, full annex: eur-lex.europa.eu
• Commission refers IE, ES, FR, NL to the Court of Justice (Jul 2026): ec.europa.eu, IP/26/1499
• Commission cybersecurity package / NIS2 amendment Q&A (Jan 2026) - cyber-posture certificate, "presumption of conformity", ~28,700 entities eased, 22,500 small mid-caps: digital-strategy.ec.europa.eu
• Analysis of the Jan 2026 NIS2 amendments - targeted-audit exemption for certificate holders, "on-site inspections, security scans ... remain available": Covington, Inside Privacy
• Certification only where done by a third-party conformity assessment body (Art.78(2) revised Cybersecurity Act): Reed Smith
• NIS2 Art.40 review clause - Commission report by 17 October 2027, legislative proposal "where necessary": nis2resources.eu
• Belgium CCB, 18 April 2026 conformity deadline: ccb.belgium.be
• Germany BSIG proof duty (§39): gesetze-im-internet.de
• Italy ACN, NIS second phase: acn.gov.it
• Red Hat, security backporting and version-based false positives: access.redhat.com
• Thinking Machines Lab, Defeating Nondeterminism in LLM Inference (2025): thinkingmachines.ai
• Gioacchini et al., AutoPenBench (arXiv 2410.03225): arxiv.org
• Erdem, A 400-Run Empirical Study of LLM Penetration Testing Consistency (arXiv 2605.30096, 2026): arxiv.org
• The "AI + Kali" product category: mcp-kali-server, hexstrike-ai
• Deeper teardown of scanner accuracy: Why Nmap and Open-Source Scanners Don't Detect Vulnerabilities Reliably