The NIS2 directive became enforceable in EU member states in October 2024. It applies to roughly 160,000 organizations across Europe — significantly broader scope than its predecessor NIS1. If you work at a company with 50+ employees or €10M+ turnover in one of the covered sectors (and the list is long: energy, transport, banking, health, digital infrastructure, ICT services, public administration, and more), NIS2 probably applies to you.
The directive is 66 pages of legal text. I've read it, and I've spent the past year helping organizations figure out what it actually requires from a technical standpoint. Here's the translation that I wish had existed when I started.
Who actually needs to worry
NIS2 splits covered entities into two tiers:
Essential entities — large organizations in critical sectors (energy, transport, banking, health, water, digital infrastructure, space). Stricter supervision, larger fines (up to €10M or 2% of global turnover).
Important entities — medium organizations in the same sectors plus additional ones (postal, waste, food, manufacturing, chemicals, research). Lighter supervision, still real fines (up to €7M or 1.4% of global turnover).
Size thresholds: 50+ employees OR €10M+ annual turnover. If you're smaller, NIS2 doesn't directly apply — but if you're in the supply chain of a covered entity (which you probably are if you sell software or services to larger companies), Article 22 supply chain risk requirements will flow downstream to you contractually.
What Article 21 actually requires
Article 21 is the technical heart of NIS2. It says covered entities must implement "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risk. The directive lists minimum measures:
| NIS2 Article 21 requirement | What it means technically |
|---|---|
| Risk analysis and information security policies | Written security policy, annual risk assessment, asset inventory |
| Incident handling | SIEM or log aggregation, incident response plan, defined escalation paths |
| Business continuity | Tested backups, RTO/RPO defined, BCP documentation |
| Supply chain security | Vendor risk questionnaires, contractual security clauses, software composition analysis |
| Network and information system security | Network segmentation, firewall ruleset review, patch management SLA |
| Policies for cryptography | TLS 1.2+ enforced, encryption at rest for sensitive data, key management documented |
| Human resources security and access control policies | MFA for all privileged accounts, role-based access, joiner/mover/leaver process |
| Multi-factor authentication | MFA for remote access, admin consoles, and email. Not optional. |
| Asset management | CMDB or equivalent, software inventory, end-of-life tracking |
| Monitoring and vulnerability handling | Vulnerability scanning cadence, patch SLA by severity, monitoring coverage |
The directive doesn't tell you HOW to implement any of this. It tells you WHAT outcomes are required. That's intentional — it's technology-neutral. But it means you have to make the technical decisions yourself.
The 24-hour incident reporting requirement (Article 23)
This is the one that most organizations are least prepared for. If you have a "significant incident" — one that causes or could cause severe operational disruption or financial damage — you have:
- 24 hours to submit an "early warning" to your national competent authority (NIS2 body in your country)
- 72 hours to submit a full incident notification
- 1 month to submit a final report
"Significant incident" is defined as: affecting more than 5% of users, causing financial loss over €500K, or affecting other entities. Ransomware that encrypts your systems qualifies. A data breach affecting customer records qualifies.
The practical implication: you need an incident response runbook that includes regulatory notification steps, and someone needs to own that notification process. If your IR process currently ends with "tell the CTO," you're not ready.
Here's a minimal incident notification checklist to build into your runbook:
□ T+0h Incident confirmed → open war room channel
□ T+2h Assess scope: how many systems/users affected?
□ T+4h Determine if "significant incident" threshold is met
□ T+8h If significant: draft early warning (who, what, when, initial scope)
□ T+24h Submit early warning to national authority
□ T+48h Update internal documentation with current containment status
□ T+72h Submit full notification (cause, affected systems, measures taken)
□ T+30d Submit final report with root cause, timeline, remediation
The national authority contact differs by country. In France it's ANSSI. In Germany it's BSI. In the Netherlands it's NCSC-NL. You need to know your contact before an incident happens.
Supply chain risk (Article 22)
Article 22 requires covered entities to assess and manage cybersecurity risks in their supply chains. This creates a cascade effect: if you sell software or services to a bank, a hospital, or an energy company, expect them to send you security questionnaires, contractual security requirements, and potentially audit rights.
From a developer perspective, this means:
- Software composition analysis (SCA) — you need to know what open source libraries are in your product and track CVEs against them. Tools: Dependency-Track, Snyk, Trivy.
- SBOM — Software Bill of Materials. Some contracts will require you to provide one.
- Vulnerability disclosure — you need a process for receiving and acting on vulnerability reports.
- Patch SLA — critical vulnerabilities: 72 hours for mitigation, 30 days for remediation, documented.
DORA overlap for financial sector
If you're in financial services or supply financial services companies, the Digital Operational Resilience Act (DORA) applies alongside NIS2. DORA is more prescriptive: it requires ICT risk management frameworks, mandatory penetration testing (TLPT — Threat-Led Penetration Testing for significant institutions), and direct regulatory supervision of critical third-party ICT providers.
The two frameworks overlap significantly — DORA's ICT risk requirements largely satisfy NIS2's Article 21. But DORA goes further on testing requirements and third-party oversight.
What to actually do first
If I were advising a developer-heavy company getting started with NIS2 compliance:
MFA everywhere — this is the highest-impact, lowest-effort control. Every privileged account, every remote access method, every admin console. Do this first.
Asset inventory — you can't protect what you don't know you have. Even a spreadsheet is better than nothing. Include software dependencies.
Patch management process — define your SLA by severity (critical: 72h, high: 7 days, medium: 30 days) and start tracking it.
Backup and recovery test — when did you last test your backup restore? Define your RTO/RPO. Test it.
Incident response plan — even a simple one. Who gets called, what do they do, who notifies the regulator.
NIS2 isn't going away, and enforcement is starting to ramp up across EU member states. The organizations that treat it as a checkbox exercise will spend money on documentation with no security improvement. The organizations that treat it as a forcing function to fix actual gaps will be both more secure and more compliant.
For more technical security content and free hardening resources, check the article library at AYI NEDJIMI Consultants — we cover NIS2 implementation, Active Directory security, firewall hardening, and more in depth.
I run AYI NEDJIMI Consultants, a cybersecurity consulting firm. We publish free security hardening checklists for FortiGate, Palo Alto, pfSense, Sophos, Active Directory and more — PDF and Excel.
