The NIS2 Directive expanded the EU’s cybersecurity rulebook well beyond the critical infrastructure operators who were covered under the original 2016 NIS Directive, and a lot of website owners are only now realizing they fall inside its scope. If your organization operates in sectors like healthcare, energy, transport, digital infrastructure, public administration, food production, waste management, or even manufacturing of certain goods, and you have 50+ employees or €10 million+ in annual turnover, NIS2 likely applies to you – and that includes the security of your public-facing website and web applications.
What NIS2 actually requires from website operators
NIS2 entered into force at the EU level on 2023-01-16, with member states required to transpose it into national law by 2024-10-17. Enforcement timelines have varied wildly by country – Germany’s implementation stalled for over a year and only cleared cabinet approval in mid-2025, while Belgium and Croatia had national laws in place before the deadline. Check your specific jurisdiction’s implementing law rather than assuming a single EU-wide date applies.
The directive doesn’t hand you a checklist of technical controls the way PCI DSS does. Instead it requires “appropriate and proportionate technical, operational and organisational measures” under Article 21, covering risk analysis, incident handling, business continuity, supply chain security, and vulnerability disclosure. For a website, that translates into concrete obligations: you need to know what vulnerabilities exist on your public-facing assets, you need a process to fix them within a reasonable window, and you need to be able to detect and report a significant incident to your national CSIRT within 24 hours of becoming aware of it (an early warning), followed by a full notification within 72 hours.
That 24-hour clock is where most website owners get caught out. You can’t report what you don’t know about. A defaced page, a leaking API endpoint, or a webshell planted through an outdated plugin can sit undetected for weeks on a site that only gets checked manually every quarter.
Who is actually in scope
NIS2 splits covered entities into “essential” and “important” categories, with essential entities (energy, transport, banking, health, water, digital infrastructure like DNS providers and cloud services) facing stricter supervision and higher fines – up to €10 million or 2% of global annual turnover, whichever is higher. Important entities (postal services, waste management, chemicals, food, manufacturing, digital providers like online marketplaces and social networks) face fines up to €7 million or 1.4% of turnover.
The supply chain provision in Article 21(2)(d) is the part that catches agencies and SaaS vendors off guard. If your client is a NIS2-covered hospital network or a regional energy utility, and you build or host their website, you can be pulled into their compliance obligations as a supplier even if your own company wouldn’t independently meet the size thresholds. Expect contract addendums asking for evidence of vulnerability management, incident response times, and security testing cadence.
Building the technical baseline
A seasoned GRC lead doesn’t start NIS2 preparation with a policy document – they start with an asset and vulnerability inventory, because auditors and CSIRTs will ask “how do you know your exposure at any given moment” before they ask about your written procedures.
Practically, that means:
Continuous vulnerability scanning covering OWASP Top 10 categories – SQL injection, XSS, broken authentication, security misconfiguration – run on a recurring schedule rather than once a year before an audit.
SSL/TLS and header hardening checked against current standards, since expired certificates or missing HSTS headers are exactly the kind of “appropriate technical measure” an auditor flags first.
Documented incident detection and alerting so the 24-hour early-warning clock can actually be met – if malware or a defacement is discovered on day 9 because nobody looked, the clock problem is baked in before you’ve written a single word of the report.
Third-party and plugin inventory, particularly for WordPress sites, where a single outdated plugin remains one of the most common initial access vectors in breach investigations.
A written, tested incident response runbook naming who notifies the national CSIRT and within what timeframe.
None of this requires exotic tooling. A website security checklist covering these categories, run consistently rather than sporadically, gets most small-to-mid organizations most of the way to a defensible position.
A common misconception worth correcting
Plenty of teams assume NIS2 is only about large critical infrastructure operators and that a marketing site or a customer portal wouldn’t count. That’s not how the directive is written. Scope is determined by the organization’s sector and size, not by the sensitivity of the specific website – a hospital’s appointment booking site is in scope even though it “just” schedules visits, because the entity operating it is covered. The corollary myth – that having a firewall or a WAF in front of the site satisfies the risk-management requirement – is equally wrong. Article 21 explicitly lists vulnerability handling and disclosure as a separate measure from network security controls; a WAF blocking known attack patterns doesn’t tell you whether the CMS behind it is running a version with a published CVE.
Practical rollout sequence
Start with a gap assessment against your national implementing law’s specific requirements, since penalties, reporting portals, and grace periods differ between, say, Ireland’s NCSC and Poland’s implementation. Layer in continuous scanning next, because it feeds both the risk-analysis requirement and the incident-detection requirement at once. Regular security audits should follow a cadence tied to your risk profile – monthly for essential entities handling sensitive citizen or patient data, quarterly at minimum for important entities. Finally, wire up alerting so that findings reach the right person fast enough to matter; the mechanics of that notification chain are covered in more depth when looking at how alerting supports incident response. Organizations already handling GDPR obligations have a head start, since much of the data-protection groundwork overlaps with NIS2’s risk-management expectations.
Frequently asked questions
Does NIS2 apply to a small business under 50 employees?
Generally no, unless the entity is explicitly named regardless of size (certain DNS providers, trust service providers, or public administration bodies) or it falls under the supply-chain obligations of a larger covered client. Check national guidance, since a few member states extended scope to smaller entities in specific sectors.
What counts as a “significant incident” that must be reported?
An incident causing severe operational disruption, financial loss, or affecting other persons through considerable material or non-material damage. A brief, contained port scan doesn’t qualify; a data breach exposing customer records or a ransomware event that takes the site offline does.
Is a WAF or CDN enough to satisfy NIS2’s technical measures requirement?
No. Perimeter controls address one layer of risk but don’t cover vulnerability management, patching cadence, or incident detection, all of which are separately required under Article 21.
NIS2 compliance for a website isn’t a one-time certification – it’s an operating rhythm of scanning, patching, and documented response that has to keep running quietly in the background, because the regulation assumes you’ll know about a problem before a regulator or a customer tells you.