Die NIS2-Richtlinie für SaaS-Unternehmen: Was mittelständische Softwareteams jetzt tun müssen

Ein Berliner SaaS-Anbieter mit 140 Mitarbeitenden und DACH-Kundenstamm verbrachte den größten Teil von 2024 in der Annahme, NIS2 sei "etwas für Banken und Versorger". Anfang 2026 schickte ein Enterprise-Kunde aus dem Fertigungssektor einen Lieferantenfragebogen mit vierzehn Fragen, die direkt auf Anhang I der Richtlinie abgebildet waren. Der CTO des Anbieters konnte drei beantworten. Innerhalb von sechs Wochen hatten sie sich beim BSI registriert, ihr Incident-Response-Runbook um eine 24-Stunden-Uhr herum neu geschrieben und Lieferketten-Sicherheitsklauseln in ihre Lieferantenverträge nachgerüstet. Der Kunde unterschrieb, aber erst nachdem die Sanierungsarbeit erledigt war.

So sieht NIS2-Richtlinien-Compliance 2026 in der Praxis aus. Die Richtlinie über Netz- und Informationssicherheit 2 hat den Anwendungsbereich der EU-Cybersicherheitsregulierung dramatisch ausgeweitet und Tausende mittelständischer Softwareunternehmen hineingezogen, die ihr Vorgänger nicht berührte. Wenn dein SaaS europäische Kunden in einem der erfassten Sektoren bedient, sind deine Beschaffungsgespräche jetzt Teil der Compliance-Geschichte eines anderen, und deine eigenen Pflichten sind konkreter, als die meisten Teams glauben. Dieser Beitrag ist eine praktische Aufschlüsselung für CTOs, Security-Verantwortliche und Gründer: was NIS2 tatsächlich verlangt, wo die Compliance-Linie verläuft und wie ein verteidigungsfähiges Sicherheitsprogramm unter dem neuen Regime aussieht.

Wen NIS2 tatsächlich erfasst und warum "wir sind nur ein SaaS-Tool" nicht mehr funktioniert

NIS2 klassifiziert regulierte Organisationen in zwei Stufen: wesentliche Einrichtungen und wichtige Einrichtungen. Die beiden Stufen unterliegen weitgehend ähnlichen Pflichten, unterscheiden sich aber in der Aufsichtsintensität und der Höhe der Bußgelder bei Verstößen. Die wichtige Frage für die meisten SaaS-Teams ist nicht die Stufe, sondern ob du überhaupt in den Anwendungsbereich fällst.

Die Richtlinie benennt achtzehn Sektoren über zwei Anhänge hinweg. Anhang I deckt Sektoren "hoher Kritikalität" ab, darunter Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, Verwaltung von IKT-Diensten (B2B), öffentliche Verwaltung und Weltraum. Anhang II deckt "sonstige kritische Sektoren" ab, darunter Post- und Kurierdienste, Abfallwirtschaft, Herstellung und Vertrieb von Chemikalien, Lebensmittelproduktion, Herstellung von Medizinprodukten, Computern und Elektronik, Kraftfahrzeugen, digitale Anbieter (Online-Marktplätze, Suchmaschinen, soziale Netzwerke) und Forschung.

Digitale Infrastruktur und Verwaltung von IKT-Diensten sind die Töpfe, die die meisten SaaS einfangen. DNS-Anbieter, Cloud-Computing-Dienstleister, Rechenzentrumsdienste, Content Delivery Networks, Vertrauensdiensteanbieter, Managed Service Provider und Managed Security Service Provider sind alle ausdrücklich genannt. Wenn dein Produkt B2B-Cloud-Dienste, MSP-artige Plattformen, Identitäts- und Zugriffsinfrastruktur oder operatives Tooling bereitstellt, auf das sich andere regulierte Einrichtungen verlassen, fällst du fast sicher in den Anwendungsbereich, unabhängig davon, ob das Wort "Cloud" in deinem Marketing auftaucht.

Größenschwellen bestimmen dann die Stufe. Eine Organisation gilt als wesentlich, wenn sie die EU-Definition eines Großunternehmens erfüllt (mindestens 250 Mitarbeitende oder Jahresumsatz über 50 Millionen Euro und Bilanzsumme über 43 Millionen Euro) in einem Sektor hoher Kritikalität. Sie gilt als wichtig, wenn sie die Schwellen für mittlere Unternehmen erfüllt (mindestens 50 Mitarbeitende oder 10 Millionen Euro Umsatz). Unterhalb dieser Schwellen fallen die meisten Unternehmen aus dem direkten Anwendungsbereich heraus, wobei es Ausnahmen für DNS-Anbieter, TLDs, qualifizierte Vertrauensdiensteanbieter und eine Handvoll anderer Kategorien gibt, bei denen die Größe irrelevant ist.

Die Implikation für ein typisches mittelständisches SaaS ist deutlich: Wenn du eine Managed-Cloud- oder SaaS-Plattform über fünfzig Mitarbeitenden mit europäischen Kunden bist, geh davon aus, dass du eine wichtige Einrichtung bist, und plane entsprechend. "Wir sind nur ein Tool" hört in dieser Größe auf, eine Verteidigung zu sein.

Die Pflichten, die jedes in den Anwendungsbereich fallende SaaS umsetzen muss

NIS2 Artikel 21 legt das Mindestmaß an Cybersicherheits-Risikomanagementmaßnahmen fest, das jede in den Anwendungsbereich fallende Organisation umsetzen muss. Die Liste ist bewusst technologieneutral, aber die Erwartung ist, dass jede Maßnahme operationalisiert wird, nicht auf einer Folie abgehakt.

Die zehn Maßnahmenbereiche, die die Richtlinie benennt, sind: Risikoanalyse und Sicherheitskonzepte für Informationssysteme; Bewältigung von Sicherheitsvorfällen; Aufrechterhaltung des Betriebs einschließlich Backup-Management und Krisenmanagement; Sicherheit der Lieferkette; Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen; Konzepte zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen; grundlegende Cyberhygiene und Cybersicherheitsschulungen; Konzepte für den Einsatz von Kryptografie und Verschlüsselung; Personalsicherheit, Zugriffskontrollkonzepte und Anlagenmanagement; und der Einsatz von Multi-Faktor-Authentifizierung, gesicherter Sprach-, Video- und Textkommunikation sowie Notfallkommunikationssystemen.

Für ein Softwareunternehmen übersetzt sich das meiste davon in vertraute Engineering-Arbeit: SSO und MFA für jedes interne System und jeden privilegierten Kundenzugang erzwingen; ein aktuelles Anlagenverzeichnis führen, das Code-Repositories, Cloud-Konten, SaaS-Anbieter und Produktionsdatenspeicher abdeckt; deinen SDLC mit Sicherheits-Checkpoints dokumentieren; Daten at rest und in transit mit modernen Algorithmen verschlüsseln; ein Schwachstellenmanagement-Programm mit nachverfolgten SLAs für die Behebung betreiben; Runbooks für Incident Response, Backup-Wiederherstellung und Krisenkommunikation pflegen; und Personal schulen, einschließlich, ausdrücklich, der Geschäftsleitung, in Cyberhygiene.

Die schwierigere Arbeit ist, diese Maßnahmen verteidigungsfähig zu machen. Ein NIS2-Audit sucht nicht nach einem Dokument mit der Aufschrift "Sicherheitskonzept". Es sucht nach Belegen, dass das Konzept gelebt wird: dass Entwickler nicht ohne die SDLC-Prüfungen in Produktion mergen können, dass Backups tatsächlich nach Plan wiederhergestellt werden, dass Zugriffsüberprüfungen stattfinden und Änderungen erzeugen, dass Incident-Tickets zu Post-mortems führen. Ein gründliches Code-Quality-Audit deckt oft die Lücke zwischen geschriebenem Konzept und ausgelieferter Realität auf, besonders rund um Dependency-Management, den Umgang mit Secrets und Eingabevalidierung in älteren Diensten.

Die 24-Stunden-Uhr: Vorfallmeldung unter NIS2

Die NIS2-Vorfallmeldung führt einen dreistufigen Zeitplan ein, der deutlich enger ist als das 72-Stunden-Fenster der DSGVO. Für erhebliche Vorfälle (solche, die eine schwere Betriebsstörung oder finanzielle Verluste verursachen oder verursachen können oder andere durch materiellen Schaden beeinträchtigen) müssen in den Anwendungsbereich fallende Organisationen innerhalb von 24 Stunden nach Kenntnisnahme eine Frühwarnung an das nationale CSIRT senden (in Deutschland das BSI).

Die Frühwarnung muss angeben, ob der Vorfall vermutlich durch rechtswidrige oder böswillige Handlungen verursacht wurde und ob er grenzüberschreitende Auswirkungen hat. Eine vollständige Vorfallmeldung mit einer ersten Bewertung von Schweregrad, Auswirkung und, soweit verfügbar, Kompromittierungsindikatoren folgt innerhalb von 72 Stunden. Ein Abschlussbericht ist innerhalb eines Monats fällig, einschließlich einer detaillierten Beschreibung, der Bedrohung oder Grundursache, der angewandten Gegenmaßnahmen und der grenzüberschreitenden Auswirkungen.

In Deutschland läuft die Meldung über das Meldeportal des BSI. Zuständige Behörden in anderen Mitgliedstaaten haben analoge Portale. Die empfangenden CSIRTs können während des Vorfalls jederzeit Zwischenstandsmeldungen anfordern.

Daraus folgen mehrere Engineering-Implikationen. Deine Erkennung muss tatsächlich funktionieren, du kannst eine 24-Stunden-Uhr nicht einhalten, wenn dein erstes Signal drei Tage später ein Support-Ticket ist. Deine On-Call-Eskalation muss einen Pfad zum Sicherheitsbeauftragten enthalten, den eine diensthabende Entwicklerin aufrufen kann, ohne um Erlaubnis zu fragen. Deine Meldevorlagen sollten für das BSI-Format vorbefüllt sein, damit ein erschöpfter Incident Commander um 3 Uhr nachts keinen juristischen Text entwirft. Und deine Vorfall-Taxonomie muss "erheblich" konsistent von "routinemäßig" unterscheiden können, denn Übermelden verbrennt politisches Kapital bei der Behörde, und Untermelden ist das, was Bußgelder erzeugt.

Ein praktischer Schritt ist, den NIS2-Zeitplan in das bestehende Incident-Runbook zu falten, statt einen separaten Prozess aufzusetzen. Ein integrierter Ablauf sieht so aus: Erkennung -> Schweregrad-Triage -> wenn erheblich, NIS2-Uhr zum Zeitpunkt der Kenntnisnahme starten -> 24-Stunden-Frühwarnung -> 72-Stunden-Meldung -> fortlaufende Eindämmung und Kundenkommunikation -> Abschlussbericht nach einem Monat. Teams, die regulatorische Meldung als separaten Arbeitsstrang behandeln, verfehlen durchgängig die erste Frist.

Lieferkettensicherheit: Was deine Kunden von dir verlangen werden

Artikel 21 benennt auch Lieferkettensicherheit als erforderliche Maßnahme, und diese Klausel treibt den größten Teil des Beschaffungsfragebogen-Drucks, den mittelständische SaaS-Anbieter 2026 spüren. In den Anwendungsbereich fallende Organisationen müssen die spezifischen Schwachstellen jedes direkten Lieferanten und die allgemeine Qualität und Cybersicherheitspraxis dieser Lieferanten berücksichtigen, einschließlich ihrer eigenen sicheren Entwicklungsverfahren.

Auf die Anbieterseite übersetzt: Deine regulierten Kunden brauchen Belege von dir. Die konkreten Artefakte, nach denen sie 2026 fragen, sind eine aktuelle SBOM für dein Produkt, ein Pentest-Bericht, der nicht älter als zwölf Monate ist, ein SOC-2-Type-II- oder ISO-27001-Bericht, eine dokumentierte Vorfallhistorie, eine Beschreibung des sicheren SDLC und Belege für Patch- und Dependency-Management. Größere Kunden fragen auch nach deiner eigenen NIS2-Selbstbewertung. Viele fragen, wie deine Legacy-Code-Optimierung und dein Refactoring-Fahrplan das Risiko in älteren Teilen des Stacks mindern, eine berechtigte Frage, denn bekannte ungepatchte Pfade in Legacy-Modulen sind einer der häufigsten Audit-Befunde.

Das eigennützige Argument ist es wert, ausbuchstabiert zu werden. Ein Anbieter, der dieses Paket auf Anfrage übergeben kann, schließt Enterprise-Deals schneller und mit höherer Abschlussquote als ein Anbieter, der jeden Fragebogen als maßgeschneidertes Projekt behandelt. Lieferkettensicherheit ist ein Vertriebs-Enabler, bevor sie eine Compliance-Steuer ist.

Deutschland-Spezifika: NIS2UmsuCG, das BSI und wie Registrierung aussieht

Deutschlands Umsetzung von NIS2, gemeinhin als NIS2UmsuCG bezeichnet, richtet sich an der Richtlinie aus und integriert sich in die bestehenden Strukturen des BSI-Gesetzes. Das Gesetz verlangt von betroffenen Einrichtungen, sich beim BSI zu registrieren und erhebliche Vorfälle über die Kanäle des BSI zu melden. Die Registrierung erfordert grundlegende organisatorische Angaben, die Sektorklassifizierung, Kontaktstellen für Sicherheitskommunikation und die in den Anwendungsbereich fallenden Dienste.

Das BSI hat weitreichende Aufsichtsbefugnisse, darunter Vor-Ort-Inspektionen, gezielte Sicherheitsaudits, anlassbezogene Audits ausgelöst durch einen Vorfall und Anforderungen von Belegen. Wesentliche Einrichtungen unterliegen einer Ex-ante-Aufsicht, wichtige Einrichtungen einer Ex-post-Aufsicht, die durch Hinweise auf Nichteinhaltung ausgelöst wird. Bußgelder erreichen bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes für wesentliche Einrichtungen und 7 Millionen Euro oder 1,4 Prozent für wichtige Einrichtungen. Die Geschäftsleitungshaftung ist ausdrücklich: leitende Manager können persönlich für die Billigung oder Überwachung der Risikomanagementmaßnahmen verantwortlich gemacht werden und können bei wiederholten schweren Verstößen von Leitungspositionen ausgeschlossen werden.

Für deutsche SaaS-Gründer sind die praktischen Implikationen dreifach. Registriere dich beim BSI, wenn du in den Anwendungsbereich fällst, eine verspätete Registrierung ist selbst ein Befund. Stelle sicher, dass deine Geschäftsleitung eine dokumentierte NIS2-Schulung erhalten hat, denn die Pflicht liegt ausdrücklich bei ihr. Und halte eine Vorab-Bewertung deiner Haltung gegenüber den Artikel-21-Maßnahmen bereit, denn wenn das BSI fragt, ist "wir arbeiten daran" schwächer als "hier ist unsere Gap-Analyse aus Q1 und der Sanierungsplan für jeden Befund".

Schluss

NIS2-Richtlinien-Compliance ist kein regulatorischer Nebenquest für mittelständisches SaaS; sie ist die EU-Cybersicherheits-Grundlinie, an der deine Enterprise-Kunden ihre Lieferantenverträge bereits ausrichten. Teams, die jetzt in die Artikel-21-Maßnahmen, den 24-Stunden-Meldeablauf, das Lieferketten-Beleg-Paket und eine saubere BSI-Registrierung investieren, kommen schneller auf der anderen Seite heraus, verkaufen leichter in regulierte Sektoren und müssen ihre leitenden Manager nicht der persönlichen Haftung ins Auge sehen lassen. Die Teams, die weiter zögern, sind die, die der nächste Vorfall oder der nächste Beschaffungszyklus erwischt.

Wolf-Tech hilft Softwareteams in Berlin und der EU, ihre Codebasen, Incident-Prozesse und SDLC gegen die NIS2-Anforderungen abzubilden und die Lücken zu schließen, die zählen, bevor ein Audit oder ein Kundenfragebogen sie aufdeckt. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung.