NIS2 (Directive (EU) 2022/2555) is the EU's updated network and information security directive. It replaces the original NIS Directive, widens the in-scope sectors, raises the baseline of mandatory controls, and adds real teeth: management-board accountability, mandatory supply-chain due diligence, and fines up to EUR 10 million or 2% of global turnover.
If you build software for EU regulated sectors - or for anyone who does - NIS2 already touches your roadmap. This guide translates the directive into developer-facing controls and shows how the work overlaps with the Cyber Essentials controls UK teams already know.
Who is in scope
NIS2 applies to essential and important entities operating in the EU above the medium-enterprise threshold (>= 50 staff or EUR 10m turnover). Sectors include:
- Essential: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (DNS, TLD, cloud, data centres, CDNs), ICT service management (B2B), public administration, space.
- Important: postal/courier, waste management, chemicals, food, manufacturing of medical devices and electronics, digital providers (online marketplaces, search engines, social platforms), research.
Even if you sit outside the listed sectors, your customers in those sectors will push the requirements down to you contractually. Treat that as the practical scope.
The ten Article 21 measures, translated
Article 21 lists the risk-management measures every in-scope entity must implement. Most map cleanly to engineering work.
| Article 21 measure | What it means in your codebase and pipeline |
|---|---|
| Risk analysis and information system security policies | Documented threat models per service; written AppSec policy; reviewed annually |
| Incident handling | Detection rules, on-call, runbooks, post-incident review process |
| Business continuity and crisis management | Backups, restore drills, RTO/RPO documented per service |
| Supply chain security | SBOMs, dependency scanning, vendor security questionnaires, action pinning |
| Security in acquisition, development and maintenance | Secure SDLC, code review with security focus, vulnerability handling SLA |
| Policies to assess effectiveness | KPIs for AppSec, periodic control testing, audit trail |
| Basic cyber hygiene practices and training | Annual security training for engineers, secure-coding refreshers |
| Cryptography and encryption | TLS everywhere, modern algorithms, documented key-management |
| Human resources, access control, asset management | RBAC in apps, least-privilege service accounts, joiner/leaver process |
| Multi-factor authentication and secure communications | MFA on all admin access, signed/encrypted internal comms where relevant |
Most of these will already exist in mature engineering organisations under different names. NIS2 makes them mandatory and makes the board accountable for them.
Incident reporting timeline
NIS2 sets a tight clock for significant incidents:
| Stage | Deadline | What you submit |
|---|---|---|
| Early warning | 24 hours from awareness | Whether the incident appears caused by malicious acts and could have cross-border impact |
| Incident notification | 72 hours from awareness | Update to the early warning, initial assessment of severity, indicators of compromise |
| Intermediate report | On request | Status update from the competent authority |
| Final report | 1 month after notification | Detailed description, threat type, mitigations, cross-border impact |
For software teams that means:
- Detection has to be reliable. If you only learn about incidents from customer tickets, you will miss the 24-hour clock.
- Logging has to be queryable in minutes, not days. Pre-build the queries that answer "what data was accessed?" and "from which IPs?".
- On-call has to know the regulatory clock. Add a NIS2 reporting step to incident runbooks for in-scope services.
Supply chain due diligence
This is the part that affects every software vendor in Europe, in scope or not.
In-scope entities must assess the security of their suppliers. In practice you will be asked for:
- A current SBOM for each release of your product.
- Evidence of dependency scanning in your CI pipeline (and SLAs for fixing High/Critical findings).
- Action and image digest pinning (no
@latest, no floating tags). - Documented patch SLAs - typically 14 days for critical vulnerabilities, mirroring Cyber Essentials.
- A vulnerability disclosure process with a published security contact.
- A track record of timely incident communications to customers.
Most of this is the same evidence Cyber Essentials Plus already asks for. The difference is that NIS2 makes it continuous and contractual, not annual and self-assessed.
How NIS2, Cyber Essentials, and DORA fit together
| Framework | Geography | Style | Best for |
|---|---|---|---|
| Cyber Essentials | UK | Five baseline controls, annual self-assessment (or audited Plus) | Floor for UK government supply chain |
| NIS2 | EU | Ten risk-management measures + incident reporting + supply chain | EU essential/important entities and their suppliers |
| DORA | EU finance | Operational resilience, ICT risk, third-party register | Banks, insurers, payment firms and their critical ICT providers |
If you already meet Cyber Essentials, you have a strong head start on NIS2 - but you still need to add incident-reporting workflows, supply-chain due diligence on your own dependencies, and board-level accountability. If you sell to EU finance, see also our companion guide on DORA secure SDLC for development teams.
A 90-day NIS2 readiness plan
Days 1-30:
- Inventory the services you sell into EU essential or important entities.
- Map each service to the Article 21 measures and identify gaps.
- Assign a board-level owner.
Days 31-60:
- Stand up an SBOM pipeline for every customer-facing release.
- Add a NIS2 reporting step to every relevant incident runbook.
- Run a tabletop incident exercise against the 24h / 72h clock.
Days 61-90:
- Issue an updated supplier security questionnaire to your own critical vendors.
- Publish an external vulnerability disclosure policy.
- Capture a single-page evidence pack you can share with procurement.
Where to go next
- Cyber Essentials for development teams - the UK baseline that covers the technical floor.
- DORA secure SDLC for development teams - the financial-services counterpart.
- Threat Model Tool - produce the per-service threat models Article 21 implicitly requires.
- AppSec Scorecard - a 10-minute self-assessment that maps to NIS2 measures.
NIS2 is not a one-off project. It is a continuous obligation, with an audit trail, that the board now answers for. Build the controls into the way your team ships software - not into a binder that lives on a shared drive.