NIS2 (Directive (EU) 2022/2555) obliges in-scope companies — including many software and managed service providers — to implement ten specific cybersecurity risk-management measures, report significant incidents on a 24-hour/72-hour/one-month cadence, and hold management personally accountable, with fines up to €10 million or 2 percent of global turnover for essential entities. The transposition deadline was 17 October 2024; the Commission opened infringement proceedings against most member states for missing it, and as of mid-2025 a substantial minority still haven't finished. Don't mistake that chaos for a reprieve. If you sell into regulated sectors, your customers' NIS2 obligations are already flowing down to you through procurement questionnaires — the directive's supply chain provisions guarantee it.
Are you in scope? Probably closer than you think
NIS2 expanded from the original NIS directive's narrow scope to 18 sectors, split into essential and important entities. For software companies, the relevant hooks are: managed service providers and managed security service providers (essential or important depending on size), cloud computing providers, data center services, online marketplaces and search engines, and "digital providers." The size-cap rule generally pulls in companies with 50+ employees or €10M+ annual turnover in a covered sector, with carve-outs where smaller entities qualify anyway (DNS, trust services, and cases designated by member states).
Two things catch vendors off guard. First, jurisdiction: if you provide covered services in the EU, establishment outside it doesn't exempt you — you need an EU representative. Second, indirect scope: a pure product software vendor might sit outside NIS2 itself, but Article 21(2)(d) obliges every in-scope customer to manage their supply chain security, which contractually lands on you. The security questionnaires got noticeably longer in 2025 for exactly this reason.
The Article 21 measures, translated to engineering
Article 21(2) lists ten mandatory measure families. Several are standard fare (policies, business continuity, crypto, MFA). The ones with real engineering weight for a software vendor:
| Article 21(2) item | What it means for engineering |
|---|---|
| (d) supply chain security | Assess and manage risk from your own suppliers and components — including open source dependencies |
| (e) security in acquisition, development, maintenance | Secure SDLC, vulnerability handling, and disclosure processes |
| (b) incident handling | Detection, classification, and response capability that can feed the reporting clock |
| (f) effectiveness assessment | Testing and auditing that your measures actually work |
| (j) MFA and secured communications | MFA on production access; encrypted comms for crisis response |
For (d) and (e), the concrete deliverables look like: a maintained component inventory per product (an SBOM pipeline — see the beginner's guide if you're starting cold), continuous dependency scanning with documented remediation SLAs, a coordinated vulnerability disclosure policy with a security.txt, and supplier assessment records. The implementing regulation for digital infrastructure entities (2024/2690, adopted October 2024) spells out technical expectations in more detail, and it reads like a checklist an auditor would enjoy.
The reporting clock: 24 hours is shorter than it sounds
Article 23 sets the incident reporting cadence for significant incidents: an early warning to your CSIRT or competent authority within 24 hours of awareness, an incident notification with initial assessment within 72 hours, and a final report within one month (plus intermediate updates on request). "Significant" means capable of causing severe operational disruption or considerable damage, including to other parties.
The engineering implication is unglamorous: you need incident classification criteria written before the incident, an on-call path that can produce a defensible severity call inside a day, and templates ready so the 24-hour warning is a fill-in exercise. Run the drill once and you'll find the gaps — usually "who decides it's significant at 03:00 on a Saturday" and "which authority do we even notify in each member state we operate in." Both have boring answers that take an afternoon to document and a very expensive weekend to improvise.
Management liability and the enforcement math
NIS2 puts management bodies on the hook personally: they must approve the risk measures, oversee implementation, and undergo training — and member states must provide for their liability, including temporary bans from management roles for essential entities in egregious cases. Fines reach €10M or 2 percent of worldwide turnover for essential entities, €7M or 1.4 percent for important ones.
This changes the internal conversation. Security roadmap items that stalled for three quarters get funded when the board realizes Article 20 names them. Use it: a one-page mapping of your current controls to Article 21(2) items, with gaps highlighted, is the most effective budget document most security leads will write this year. If you also sell products with digital elements into the EU, note that the Cyber Resilience Act layers product-level obligations on top of NIS2's organizational ones — our CRA guide for software vendors covers the boundary between the two.
What to do this quarter
Sequence matters less than starting, but a sane order: (1) make the scope determination in writing, per entity and per member state, with legal counsel; (2) map existing controls (ISO 27001 gets you far — most of Article 21 overlaps its Annex A) and gap-list the rest; (3) stand up the incident classification and reporting runbook; (4) get the supply chain evidence pipeline running, because it's the slowest to mature and the first thing customers ask for. Vendors using Safeguard typically satisfy the component-level half of Article 21(2)(d) with the SBOM and scan exports they already generate; the supplier-assessment half is process work no tool does for you.
Frequently asked questions
Does NIS2 apply to software vendors directly?
It depends on the service. Managed service providers, cloud providers, marketplaces, and similar digital services are directly in scope above the size thresholds. Pure product vendors are often out of direct scope but inherit obligations contractually from in-scope customers under Article 21(2)(d).
What if our member state hasn't transposed NIS2 yet?
Directives bind through national law, so enforcement waits for transposition — but several states enacted laws with immediate registration duties, and cross-border customers won't wait. Building to the directive now avoids scrambling when your state's law lands with a short compliance window.
How does NIS2 relate to the Cyber Resilience Act?
NIS2 regulates organizations and their operations; the CRA regulates products with digital elements. A software vendor can face both: NIS2 for its managed service operations, CRA for the products it ships. The supply chain and vulnerability-handling work overlaps heavily, so build one program, not two.
What counts as a significant incident under NIS2?
An incident that has caused or can cause severe operational disruption or financial loss, or considerable material or non-material damage to others. Member state guidance and the 2024/2690 implementing regulation give sector-specific thresholds — encode them in your classification runbook rather than deciding case by case.
