Directive (EU) 2022/2555, better known as NIS2, replaced the original 2016 NIS Directive and had a national transposition deadline of 17 October 2024. It significantly widens the number of organisations subject to EU cybersecurity law and raises the bar on risk management, governance and incident reporting. If you own or operate web applications, APIs or online services in the EU, this article explains — in practical, non-legal terms — where you may stand and how security testing supports your obligations.
Who is in scope
NIS2 applies to medium and large entities (generally 50+ employees or €10M+ turnover) that operate in listed sectors. It splits them into two tiers:
- Essential entities (Annex I): energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure (DNS, TLD registries, cloud, data centres, CDNs), ICT service management, public administration and space.
- Important entities (Annex II): postal services, waste management, chemicals, food, manufacturing, digital providers (online marketplaces, search engines, social platforms) and research.
Size thresholds are not the only trigger — some entities are in scope regardless of size (for example DNS and TLD registries, or qualified trust service providers). Crucially, NIS2 reaches your supply chain: even if you are out of direct scope, an in-scope customer will push these requirements to you contractually.
The risk-management obligations (Article 21)
Article 21 requires appropriate and proportionate technical, operational and organisational measures using an all-hazards approach. The directive names a minimum set that maps cleanly onto established security frameworks such as ISO/IEC 27001 and the NIST Cybersecurity Framework:
- Risk analysis and information system security policies
- Incident handling (detection, response, recovery)
- Business continuity, backup management and crisis management
- Supply-chain security, including relationships with direct suppliers
- Security in acquisition, development and maintenance — including vulnerability handling and disclosure
- Policies to assess the effectiveness of measures (i.e. testing and audit)
- Basic cyber hygiene and training
- Cryptography and encryption policies
- Access control, asset management and multi-factor authentication
Two points deserve emphasis. First, management bodies must approve and oversee these measures and can be held liable (Article 20) — cybersecurity is now a board-level duty, not just an IT concern. Second, the requirement to assess effectiveness is where testing becomes non-negotiable.
Incident reporting: the 24/72-hour clock (Article 23)
NIS2 imposes a strict, multi-stage timeline for significant incidents (those causing severe operational disruption, financial loss, or material harm to others):
- Within 24 hours — an early warning to the CSIRT or competent authority, flagging whether the incident is suspected to be unlawful or malicious and whether it could have cross-border impact.
- Within 72 hours — an incident notification with an initial assessment, severity, impact and indicators of compromise.
- On request — an intermediate status update.
- Within one month — a final report covering root cause, mitigation and cross-border impact.
These deadlines are tight. Meeting them requires logging, detection and an incident-response runbook that are tested in advance — not improvised during a breach.
How penetration testing and security audits support compliance
NIS2 does not mandate a specific test methodology, but a penetration test is the most direct evidence that you have assessed the effectiveness of your measures and that your vulnerability-handling process works. Concretely, testing supports several Article 21 clauses at once:
- Vulnerability handling — a test grounded in the OWASP Top 10 and OWASP Web Security Testing Guide (WSTG) surfaces issues like broken access control (A01), injection (A03) and SSRF (A10) before attackers do.
- Prioritisation with CVSS — findings scored with CVSS v3.1/v4.0 let you triage and demonstrate a risk-based approach, and mapping to CWE and MITRE ATT&CK shows analytical rigour.
- Effectiveness assessment — retesting after remediation produces documented proof that fixes actually closed the gap.
- Supply-chain assurance — a report you can share gives your in-scope customers the evidence their own NIS2 obligations demand.
- Incident-response readiness — red-team or purple-team exercises validate that your 24/72-hour detection and reporting chain actually fires.
A defensible cadence is at least annual testing plus a re-test after any significant change to internet-facing systems, complemented by continuous vulnerability scanning between engagements.
Practical next steps
- Determine your scope: sector (Annex I/II), size thresholds and any size-independent triggers.
- Map current controls to the Article 21 minimum set; treat ISO/IEC 27001 or the NIST CSF as your backbone.
- Build and rehearse an incident-response plan aligned to the 24/72-hour/one-month timeline.
- Commission an OWASP/WSTG-grounded penetration test with CVSS-scored findings and a remediation re-test.
- Push equivalent expectations onto your own suppliers.
This article is practical guidance, not legal advice. Exact obligations depend on your Member State's transposition law and your entity classification — confirm the specifics with qualified counsel and your national CSIRT.