NIS2 Directive for SaaS Companies: What Mid-Size Software Teams Must Do Now

A Berlin SaaS vendor with 140 employees and a DACH customer base spent most of 2024 assuming NIS2 was "something for banks and utilities." In early 2026 an enterprise customer in the manufacturing sector sent a supplier questionnaire containing fourteen questions mapped directly to Annex I of the directive. The vendor's CTO could answer three. Within six weeks they had registered with the BSI, rewritten their incident response runbook around a 24-hour clock, and retrofitted supply-chain security clauses into their vendor contracts. The customer signed — but only after the remediation work was done.

This is what NIS2 directive compliance looks like in practice in 2026. The Network and Information Security 2 Directive dramatically expanded the scope of EU cybersecurity regulation, pulling in thousands of mid-size software companies that were previously untouched by its predecessor. If your SaaS serves European customers in any of the covered sectors, your procurement conversations are now part of someone else's compliance story — and your own obligations are more concrete than most teams realise. This post is a practical breakdown for CTOs, security leads, and founders of what NIS2 actually requires, where the compliance line sits, and what a defensible security programme looks like under the new regime.

Who NIS2 Actually Covers — and Why "We're Just a SaaS Tool" No Longer Works

NIS2 classifies regulated organisations into two tiers: essential entities and important entities. The two tiers face broadly similar obligations but differ on supervision intensity and the size of the fines attached to violations. The important question for most SaaS teams is not the tier — it is whether you are in scope at all.

The directive names eighteen sectors across two annexes. Annex I covers sectors of "high criticality" including energy, transport, banking, financial market infrastructures, health, drinking water, wastewater, digital infrastructure, ICT service management (B2B), public administration, and space. Annex II covers "other critical sectors" including postal and courier services, waste management, manufacture and distribution of chemicals, food production, manufacturing of medical devices, computers and electronics, motor vehicles, digital providers (online marketplaces, search engines, social networking platforms), and research.

Digital infrastructure and ICT service management are the buckets that catch most SaaS. DNS providers, cloud computing service providers, data centre services, content delivery networks, trust service providers, managed service providers, and managed security service providers are all explicitly named. If your product provides B2B cloud services, MSP-style platforms, identity and access infrastructure, or operational tooling that other regulated entities rely on, you are almost certainly in scope regardless of whether the word "cloud" appears in your marketing.

Size thresholds then determine tier. An organisation qualifies as essential when it meets the EU definition of a large enterprise — at least 250 employees or annual turnover above €50 million and balance sheet total above €43 million — in a high-criticality sector. It qualifies as important when it meets the medium-enterprise thresholds — at least 50 employees or €10 million turnover. Below those thresholds, most companies drop out of direct scope, though there are exceptions for DNS providers, TLDs, qualified trust service providers, and a handful of other categories where size is irrelevant.

The implication for a typical mid-size SaaS is blunt: if you are a managed cloud or SaaS platform above fifty employees with European customers, assume you are an important entity and plan accordingly. "We're just a tool" stops being a defense at that size.

The Obligations Every In-Scope SaaS Must Implement

NIS2 Article 21 sets out the minimum set of cybersecurity risk-management measures every in-scope organisation must implement. The list is deliberately technology-neutral, but the expectation is that each measure is operationalised — not checked off on a slide.

The ten measure areas the directive names are: risk analysis and information system security policies; incident handling; business continuity including backup management and crisis management; supply chain security; security in acquisition, development and maintenance of network and information systems; policies to assess the effectiveness of cybersecurity risk-management measures; basic cyber hygiene practices and cybersecurity training; policies regarding the use of cryptography and encryption; human resources security, access control policies and asset management; and the use of multi-factor authentication, secured voice/video/text communications and emergency communications systems.

For a software company, most of these translate into familiar engineering work: enforce SSO and MFA for every internal system and every privileged customer account; keep a current asset inventory covering code repositories, cloud accounts, SaaS vendors, and production data stores; document your SDLC with security checkpoints; encrypt data at rest and in transit with modern algorithms; run a vulnerability management programme with tracked SLAs for remediation; maintain runbooks for incident response, backup restoration, and crisis communications; and train staff — including, explicitly, management — in cyber hygiene.

The harder work is making these measures defensible. A NIS2 audit is not looking for a document labelled "Security Policy." It is looking for evidence the policy is lived: that engineers cannot merge to production without the SDLC checks, that backups are actually restored on a schedule, that access reviews happen and generate changes, that incident tickets trace to post-mortems. A thorough code quality audit often surfaces the gap between written policy and shipped reality — particularly around dependency management, secret handling, and input validation in older services.

The 24-Hour Clock: Incident Reporting Under NIS2

NIS2 incident reporting introduces a three-stage timeline that is markedly tighter than GDPR's 72-hour breach window. For significant incidents — those causing or capable of causing severe operational disruption or financial loss, or affecting others by material damage — in-scope organisations must send an early warning to the national CSIRT (the BSI in Germany) within 24 hours of awareness.

The early warning must indicate whether the incident is suspected to be caused by unlawful or malicious acts and whether it has cross-border impact. A full incident notification with an initial assessment of severity, impact, and where available indicators of compromise, follows within 72 hours. A final report is due within one month, including a detailed description, threat or root cause, applied mitigation measures, and cross-border implications.

In Germany the reporting flows through the BSI's Meldeportal. Competent authorities in other member states have analogous portals. The receiving CSIRTs can request intermediate status updates at any point during the incident.

Several engineering implications follow. Your detection needs to actually work — you cannot meet a 24-hour clock if your first signal is a customer support ticket three days later. Your on-call escalation must include a security-officer path that a duty engineer can invoke without asking permission. Your reporting templates should be pre-filled for the BSI format so that a tired incident commander at 03:00 is not drafting legal text. And your incident taxonomy must be able to distinguish "significant" from "routine" consistently — because over-reporting burns political capital with the regulator, and under-reporting is what generates fines.

A practical step is to fold the NIS2 timeline into the existing incident runbook rather than bolting a separate process on. An integrated flow looks like: detection → severity triage → if significant, start the NIS2 clock at the time of awareness → 24-hour early warning → 72-hour notification → continuous mitigation and customer communication → one-month final report. Teams that treat regulatory reporting as a separate workstream consistently miss the first deadline.

Supply Chain Security: What Your Customers Will Ask You

Article 21 also names supply chain security as a required measure, and this is the clause that is driving most of the procurement-questionnaire pressure mid-size SaaS vendors are feeling in 2026. In-scope organisations must take into account vulnerabilities specific to each direct supplier and the overall quality and cybersecurity practices of those suppliers — including their own secure development procedures.

Translated to the vendor side: your regulated customers need evidence from you. The concrete artefacts they are asking for in 2026 are a current SBOM for your product, a penetration test report no more than twelve months old, a SOC 2 Type II or ISO 27001 report, documented incident history, a secure SDLC description, and evidence of patch and dependency management. Larger customers also ask for your own NIS2 self-assessment. Many ask how your legacy code optimization and refactoring roadmap mitigates risk in older parts of the stack — a reasonable question, because known unpatched paths in legacy modules are one of the most common audit findings.

The self-interested argument is worth spelling out. A vendor that can hand over this pack on request closes enterprise deals faster and at a higher win rate than a vendor that treats each questionnaire as a bespoke project. Supply chain security is a sales enabler before it is a compliance tax.

Germany Specifics: NIS2UmsuCG, the BSI, and What Registration Looks Like

Germany's transposition of NIS2 — commonly referred to as the NIS2UmsuCG — aligns with the directive while integrating with existing BSI-Gesetz structures. The law requires affected entities to register with the BSI and to report significant incidents through the BSI's channels. Registration requires basic organisational details, sector classification, contact points for security communications, and the services in scope.

The BSI has broad supervisory powers including on-site inspections, targeted security audits, ad-hoc audits triggered by an incident, and requests for evidence. Essential entities face ex-ante supervision; important entities face ex-post supervision triggered by indications of non-compliance. Fines reach up to €10 million or 2 percent of global annual turnover for essential entities and €7 million or 1.4 percent for important entities. Management liability is explicit: senior managers can be held personally responsible for approving or overseeing the risk management measures, and can be barred from management positions in cases of repeated serious violations.

For German SaaS founders the practical implications are threefold. Register with the BSI if you are in scope — delayed registration is itself a finding. Ensure your management board has had a documented NIS2 training, because the obligation is explicitly on them. And have a pre-assessment of your posture against the Article 21 measures ready, because when the BSI comes asking, "we're working on it" is weaker than "here is our gap analysis from Q1 and the remediation plan for each finding."

Closing

NIS2 directive compliance is not a regulatory side-quest for mid-size SaaS; it is the EU cybersecurity baseline your enterprise customers are already mapping their supplier contracts against. Teams that invest now in the Article 21 measures, the 24-hour incident reporting flow, the supply-chain evidence pack, and a clean BSI registration come out the other side faster, sell more easily into regulated sectors, and do not have their senior managers staring down personal liability. The teams that keep stalling are the ones caught by the next incident or the next procurement cycle.

Wolf-Tech helps Berlin and EU-based software teams map their codebases, incident processes, and SDLC against NIS2 requirements and close the gaps that matter before an audit or a customer questionnaire surfaces them. Contact us at hello@wolf-tech.io or visit wolf-tech.io for a free consultation.