Einleitung: Warum NIS2 SaaS für Gründer:innen plötzlich relevant wirkt
Viele Gründer:innen fragen sich gerade dasselbe: Betrifft uns NIS2 SaaS wirklich direkt, oder ist das einfach ein Buzzword, das Kund:innen gerade im Einkauf abfragen? Die Unsicherheit ist verständlich, weil die Antwort weder ein klares Ja noch ein klares Nein ist.
Das Wichtigste zuerst: Nicht jede SaaS-Firma ist automatisch NIS2 betroffen. Für viele frühe Teams zeigt sich NIS-2 zuerst über Kundendruck, Ausschreibungen, Due Diligence und Security Questionnaire B2B-Prozesse. Dieser Beitrag hilft euch dabei, direkte Betroffenheit von indirekter Relevanz zu unterscheiden, die wichtigsten offiziellen BSI-Hilfen einzuordnen und ein realistisches Minimal-Setup für Cybersecurity SaaS in 30 Tagen aufzusetzen.
Es geht nicht um abstrakte Gesetzeslektüre, sondern um eine Entscheidungshilfe für Produkt, Security und Sales. Kleiner, aber wichtiger Hinweis vorab: Dieser Beitrag ist keine Rechtsberatung. Er liefert praxisnahe Orientierung. Für die konkrete Einordnung eurer Situation ist eine Einzelfallprüfung sinnvoll.
Was NIS-2 für SaaS-Teams tatsächlich bedeutet
NIS-2 ist der EU-Rahmen für ein höheres gemeinsames Cybersicherheitsniveau bei wesentlichen und wichtigen Einrichtungen. Keine Angst vor Paragraphen: Im Kern geht es um drei Bereiche, Risikomanagement, organisatorische und technische Sicherheitsmaßnahmen sowie Vorfallsmeldung. Das klingt abstrakt, ist aber für viele B2B-Teams gar nicht so weit weg vom gesunden Menschenverstand.
Aus dem offiziellen EU-Gesetzestext geht hervor, dass bestimmte digitale Dienste ausdrücklich genannt sind: Cloud-Computing-Dienste, Rechenzentrumsdienste, Managed Service Provider (MSP) und Managed Security Service Provider (MSSP). Dabei definiert die Richtlinie Cloud-Modelle ausdrücklich inklusive SaaS. Das bedeutet aber nicht, dass jede SaaS pauschal direkt reguliert ist. Es kommt auf Geschäftsmodell, Rolle und Kundenkreis an.
Die EU-Kommission erläutert in ihren offiziellen FAQs die betroffenen Sektoren und Einrichtungstypen in Klartext. Digitale Infrastruktur sowie ICT Service Management, also MSP und MSSP, liegen deutlich näher an direkter Relevanz als eine typische Fachanwendungs-SaaS ohne betriebsnahe Rolle. Für viele NIS-2 Startups ist daher nicht die erste Frage “Bußgeld oder nicht”, sondern ob Produkt und Betriebsmodell in Ausschreibungen, Vendor Reviews oder Kundenaudits plausibel bestehen.
Zwei Begriffe, die ihr im Kopf behalten solltet: “Direkt betroffen” heißt, dass das eigene Unternehmen nach Tätigkeit, Sektor und Rolle selbst in den NIS-2-Kontext fallen kann. “Indirekt betroffen” heißt, dass Kund:innen, Partner oder Beschaffungsteams entsprechende Anforderungen an Sicherheitsprozesse und Nachweise stellen, auch wenn ihr selbst nicht reguliert seid.
Sind wir direkt NIS2 betroffen oder eher indirekt unter Kundendruck?
“NIS2 betroffen” ist keine Bauchentscheidung. Entscheidend sind Geschäftstätigkeit, Kundensegmente, technische Rolle und Betriebsnähe. Wer diese Fragen für sich nicht klar beantworten kann, sollte nicht auf Basis von LinkedIn-Meinungen oder vereinfachten Schlagzeilen handeln.
Direkte Betroffenheit ist eine Möglichkeit, keine pauschale Behauptung. Besonders sorgfältig prüfen sollten Teams, die in Richtung Cloud-, Rechenzentrums-, Plattform-, MSP- oder MSSP-Leistungen gehen oder operative Kontrolle über kritische Systeme von Kund:innen ausüben. Wer tiefen Fernzugriff auf Kundensysteme hat, wer Monitoring oder Administration übernimmt, wer für den sicheren Betrieb zentraler Infrastruktur mitverantwortlich ist, dem empfiehlt sich eine klare Prüfung.
Indirekte Relevanz ist der häufigere Fall für Startups. Ihr verkauft an regulierte oder KRITIS-nahe Unternehmen, verarbeitet sensible oder betriebsrelevante Daten oder seid Teil ihrer Lieferkette. Dann werden Fragen zu Zugriffen, Backups, Incident Handling und Lieferanten schnell Teil des Vertriebs, lange bevor eine rechtliche Pflicht eures eigenen Unternehmens entsteht.
Das BSI hat in seinen sektorspezifischen FAQs einige hilfreiche Grenzfälle beschrieben: Reine IT-Sicherheitsberatung fällt in der Regel nicht automatisch unter MSSP. Webhosting ist nicht automatisch Cloud-Anbieter oder MSP. Zentraler IT-Betrieb in einer Tochtergesellschaft kann dagegen durchaus MSP/MSSP-Charakter haben. Diese Beispiele zeigen, dass es weder Entwarnung noch Alarm pauschal geben kann.
Die Richtlinie adressiert grundsätzlich mittlere und große Einrichtungen in bestimmten Sektoren, aber es gibt Sonderfälle, die unabhängig von der Unternehmensgröße relevant werden können. Das bedeutet: Weder frühe Phase noch der Begriff SaaS allein sind eine verlässliche Grundlage für eine Einschätzung.
So helfen BSI-Betroffenheitsprüfung und BSI Portal NIS2 bei der Einordnung
Der sinnvollste Erstcheck für Gründer:innen ist die BSI-Betroffenheitsprüfung. Sie führt systematisch durch Sektor, Unternehmensrolle und Tätigkeit und ist damit deutlich belastbarer als Bauchgefühl oder Internetrecherche. Wer noch nie damit gearbeitet hat: Der Entscheidungsbaum des BSI ist klar strukturiert und hilft, die richtigen Fragen zu stellen.
Wichtig dabei: Die Betroffenheitsprüfung ist eine Orientierung, keine verbindliche Rechtsprüfung. Das BSI selbst weist in seinen offiziellen FAQs darauf hin, dass Grenzfälle einer Einzelfallprüfung bedürfen. Dieser Beitrag tut das ebenfalls: Nutzt die BSI-Hilfen als erste strukturierte Einschätzung, nicht als Rechtsgutachten.
Das BSI Portal NIS2 ist der zentrale Ort für Registrierung und Kommunikation mit dem BSI, sobald Unternehmen unter entsprechende Pflichten fallen. Mit dem Inkrafttreten des NIS-2-Umsetzungsgesetzes am 06.12.2025 gelten Registrierungs- und Meldepflichten für betroffene Einrichtungen. Für viele Startups ist das noch nicht sofort operativ relevant, aber es ist sinnvoll, das Portal zu kennen, wenn direkte Betroffenheit näher rückt.
Was den Meldekontext angeht: Die Richtlinie sieht für erhebliche Vorfälle eine Frühwarnung innerhalb von 24 Stunden, eine vollständige Meldung innerhalb von 72 Stunden und einen Abschlussbericht binnen eines Monats vor. Das ist kein bürokratisches Detail, sondern ein klares Signal: Vorfälle brauchen klare interne Abläufe, bevor man überhaupt über Formulare oder Meldewege spricht.
Typische Gründerfälle: Wo NIS2 SaaS in der Praxis auftaucht
Abstrakte Einordnungen helfen nur begrenzt. Deshalb hier fünf typische Situationen, in denen das Thema für SaaS-Teams konkret wird.
Fall 1: B2B-SaaS für KRITIS-nahe oder regulierte Kund:innen. Ihr verkauft an Unternehmen in Energie, Gesundheit, Logistik, Wasser, öffentliche Versorgung oder industrielle Infrastruktur. In diesem Fall ist eher indirekter Druck zu erwarten: Vendor Security Reviews, Vertragsanhänge mit Sicherheitsanforderungen und Fragen in Einkaufsprozessen, noch bevor ihr selbst reguliert seid. Euer Produkt muss bestehen, nicht primär ihr als Einrichtung.
Fall 2: Managed Services oder MSP-nahe Angebote. Wenn euer Team Kundensysteme betreibt, überwacht, administriert oder tiefen Fernzugriff hat, steigt die Relevanz für eine genaue Prüfung deutlich. Hier solltet ihr die direkte Betroffenheit sorgfältig einordnen lassen, nicht vertagen.
Fall 3: Cloud-, Hosting- oder Infrastruktur-nahe Leistungen. Die EU-Durchführungsverordnung zu NIS-2 konkretisiert für bestimmte digitale Dienste wie DNS-, Cloud-, Rechenzentrums-, CDN-, MSP- und MSSP-Anbieter technische Anforderungen und Kriterien für erhebliche Vorfälle. Die Nähe zu diesen ausdrücklich genannten Diensten ist hier höher als bei klassischer Fachanwendungssoftware. Prüfen ist Pflicht.
Fall 4: Agentur, Studio oder projektbasierte Individualentwicklung. Meist kein Automatismus Richtung NIS-2, aber je nach Kundenkreis entstehen trotzdem hohe Sicherheits- und Dokumentationsanforderungen, vor allem wenn sensible Systeme entwickelt oder betrieben werden.
Fall 5: Internes Tooling oder Non-Core-Produkt. Wenn die Lösung nicht betriebs- oder sicherheitskritisch ist, ist direkte Betroffenheit oft weniger wahrscheinlich. Trotzdem kann solides Cybersecurity-SaaS-Niveau vertrieblich entscheidend sein, sobald ihr in Enterprise-Deals kommt.
Warum NIS-2 schon heute im Vertrieb auftaucht
Regulierte oder reifere B2B-Kund:innen wollen ihre Lieferkette absichern. Deshalb erscheinen Fragen zu Zugriffskontrolle, Backup, Incident Response, Lieferanten und Business Continuity schon vor einer rechtlichen Pflicht des SaaS-Anbieters, oft mitten in einem Erstgespräch oder kurz vor Vertragsabschluss.
Der Begriff Security Questionnaire B2B bezeichnet standardisierte Sicherheitsfragebögen in Vendor-Review-, RFP-, Procurement- oder Due-Diligence-Prozessen. Ein verbreitetes Beispiel ist der SIG Questionnaire (Standardized Information Gathering), der im Third-Party-Risk-Management eingesetzt wird und genau dazu dient, strukturierte Sicherheitsinformationen von Anbietern einzusammeln. Wenn ihr diese Fragen nicht beantworten könnt, verliert ihr Deals, auch ohne dass NIS-2 formal auf euch zutrifft.
Die Brücke zu Investoren und M&A ist ebenfalls real: Dokumentierte Sicherheitsprozesse schaffen nicht nur Vertrauen bei Kund:innen, sondern auch in Due-Diligence-Situationen. Wer als Käufer oder Investor ein Unternehmen übernimmt, übernimmt auch versteckte operative und Haftungsrisiken. Ein leeres Security-Konzept ist in diesen Momenten ein deutliches Warnsignal.
Der konkrete Business-Nutzen ist greifbar: schnellere Beantwortung von Kundenfragen, weniger Rückfragen im Beschaffungsprozess, weniger Einzelwissen in Köpfen, ein professionellerer Eindruck gegenüber Mittelstand und Enterprise. Ein kleines, sauber dokumentiertes Sicherheitsfundament ist im B2B Vertrieb oft wertvoller als viele Einzeltools ohne klare Verantwortlichkeiten.
Das Minimal-Setup für kleine Teams ohne Compliance-Abteilung
Das Ziel ist kein vollständiges ISMS. Es geht um eine glaubwürdige, dokumentierte Sicherheitsbasis, die euer Team in Vendor Reviews und Kundengesprächen belastbar macht. Sechs Bausteine reichen für den Anfang.
1. Verantwortlichkeiten festlegen. Wer trägt Security-Verantwortung, wer entscheidet im Vorfall, wer informiert Geschäftsführung, Kund:innen und externe Partner? Das BSI empfiehlt in seiner Checkliste für IT-Sicherheitsvorfälle explizit: Geschäftsleitung informieren, Zuständigkeiten definieren, Informationen strukturiert bündeln, externe Hilfe einbeziehen und Lessons Learned sichern. Genau das solltet ihr vor dem nächsten Enterprise-Deal schriftlich geregelt haben.
2. MFA priorisieren. Multi-Faktor-Authentifizierung gehört auf alle Admin-Konten, E-Mail, Cloud-Zugänge, Code-Repositories, Produktivsysteme und Support-Zugänge. Das ist kein Nice-to-have, sondern ausdrücklich Teil des Risikomanagements unter NIS-2 und der erste Punkt, den jeder Security Questionnaire abfragen wird.
3. Backup- und Restore-Prozess dokumentieren. Nicht nur festhalten, dass Backups existieren. Dokumentiert, was gesichert wird, wie oft, wo gespeichert wird, wer einen Restore auslösen darf und wann zuletzt getestet wurde. Das BSI betont im Kontext des IT-Grundschutzes: Datensicherung und möglicher Restore sollten regelmäßig getestet werden. Ungeprüfte Backups schaffen falsche Sicherheit.
4. Asset- und Tool-Liste aufbauen. Produktivsysteme, Datenbestände, kritische Konten, Endgeräte, Cloud-Dienste, Repositories und Admin-Zugänge in einer übersichtlichen Tabelle erfassen. Das hilft bei Incident Handling, Zugriffsreviews und macht Security Questionnaires deutlich schneller beantwortbar.
5. Incident-Workflow auf ein bis zwei Seiten definieren. Was ist ein Incident, wie wird eskaliert, wer sammelt Fakten, wann werden Zugänge gesperrt, wann wird externe Hilfe geholt, wie wird intern kommuniziert? Haltet das bewusst simpel. Für kleine Teams ist ein verständlicher Einseiter besser als ein perfektes, aber unlesbares Dokument.
6. Lieferantenübersicht pflegen. Welche Drittanbieter sind kritisch, wo liegen Daten, wer hat privilegierten Zugriff, welche Abhängigkeiten können den Betrieb stören? Lieferkettensicherheit ist in NIS-2 ausdrücklich adressiert und wird in Vendor Reviews regelmäßig abgefragt.
Als niedrigschwelliger Einstieg für sehr kleine Teams bietet das BSI den BSI CyberRisikoCheck nach DIN SPEC 27076 an. Er ist ausdrücklich als pragmatische Hilfestellung für kleine und Kleinstunternehmen konzipiert und eine gute Alternative zu schwergewichtigen ISMS-Ansätzen. Fangt damit an, statt auf “perfekte Compliance” zu warten.
30-Tage-Checkliste: Was Gründer:innen jetzt konkret dokumentieren sollten
Vier Wochen, vier Schwerpunkte. Die Checkliste soll nicht wie Bürokratie wirken, sondern wie Vorbereitung auf Enterprise-Sales, Vendor Reviews und Due Diligence.
- Woche 1 – Lage klären: Kundensegmente prüfen, Leistungsbild schärfen, BSI-Betroffenheitsprüfung als Erstcheck durchführen, offene Grenzfälle notieren. Leitfrage: “Wir verkaufen an wen, wir betreiben was, wir greifen worauf zu?”
- Woche 2 – Zugriffe ordnen: Admin-Konten erfassen, MFA aktivieren, privilegierte Zugänge reduzieren, Asset- und Tool-Liste anlegen.
- Woche 3 – Resilienz dokumentieren: Backup- und Restore-Ablauf niederschreiben, Incident-Workflow finalisieren, Notfallkontakte intern und extern bündeln.
- Woche 4 – Sales-ready werden: Lieferantenübersicht zusammenstellen, Standardantworten für Security Questionnaire B2B vorbereiten, einen knappen Security-One-Pager erstellen mit Zuständigkeiten, MFA-Status, Backup/Restore, Incident-Prozess und wichtigsten Dienstleistern.
NIS-2, CRA und AI Act: Bitte nicht vermischen
In vielen Gesprächen werden NIS-2, der Cyber Resilience Act (CRA) und der AI Act in einen Topf geworfen. Das macht die Einordnung schwieriger, nicht leichter. Hier die schnelle Abgrenzung.
NIS-2 ist ein Organisations- und Betriebsrahmen. Fokus: Risikomanagement, Sicherheitsmaßnahmen, Resilienz, Vorfallsmeldung und Pflichten betroffener Einrichtungen. Es geht um euren Betrieb als Organisation, nicht primär um euer Produkt als Artefakt.
CRA, der Cyber Resilience Act, ist ein horizontaler EU-Rahmen für Produkte mit digitalen Elementen. Er legt Sicherheitsanforderungen über den Produktlebenszyklus fest, von Secure-by-Design bis Vulnerability Handling. Merkhilfe: Produktseite, nicht Betriebsseite.
AI Act ist ein risikobasierter Rechtsrahmen für KI-Systeme, kein allgemeines Cybersicherheitsgesetz für Organisationen. Merkhilfe: KI-spezifische Risikoregulierung, nicht Security-Organisation.
Kompakt: NIS-2 = Betrieb und Organisation, CRA = Produkt und Sicherheitslebenszyklus, AI Act = KI-Regulierung. Wer diese drei auseinanderhält, kann Kundenfragen und interne Prioritäten deutlich besser einordnen.
Fazit: Erst sauber einordnen, dann die Security-Basics dokumentieren
Nochmal klar: Nicht jede SaaS ist automatisch NIS2 betroffen. Aber viele SaaS-Teams verkaufen in Umfelder, in denen NIS-2-Fragen heute schon auf Einkauf, Security und Due Diligence abstrahlen. Die Frage ist nicht mehr ob, sondern wann ihr damit konfrontiert werdet.
Die Entscheidungshilfe auf einen Satz verdichtet: Wer eher cloud-, hosting- oder managed-service-nah arbeitet, sollte die direkte Relevanz sorgfältig prüfen. Wer an regulierte Kund:innen verkauft, sollte spätestens jetzt die Minimaldokumentation für Cybersecurity SaaS aufsetzen.
Die fünf wichtigsten To-dos zum Abschluss:
- BSI-Betroffenheitsprüfung als Erstcheck durchführen
- Verantwortlichkeiten klar intern regeln
- MFA auf allen kritischen Zugängen aktivieren
- Backup/Restore dokumentieren und testen
- Incident-Workflow plus Lieferantenübersicht auf Papier bringen
Gute Dokumentation ersetzt keine Rechtsprüfung, aber sie macht euer Team glaubwürdiger, schneller und belastbarer in größeren B2B-Deals. Das zahlt sich aus, ob NIS-2 euch direkt betrifft oder nicht.
Hinweis: Dieser Beitrag ist keine Rechtsberatung. Für die konkrete Einordnung eurer Betroffenheit und Pflichtenlage ist eine Einzelfallprüfung sinnvoll, etwa mit einer auf IT-Recht oder Cybersecurity-Compliance spezialisierten Kanzlei oder Beratung.
FAQ zu NIS2 und SaaS
Ist meine SaaS-Firma automatisch von NIS-2 betroffen?
Nein, nicht automatisch. Ob euer Unternehmen direkt unter NIS-2 fällt, hängt von Geschäftstätigkeit, Sektor, Unternehmensgröße und technischer Rolle ab. Cloud-, MSP- und MSSP-nahe Dienste liegen näher an direkter Betroffenheit als klassische Fachanwendungs-SaaS. Der BSI-Entscheidungsbaum ist der sinnvollste Erstcheck.
Was ist der Unterschied zwischen direkt und indirekt NIS2 betroffen?
Direkt betroffen bedeutet, dass euer Unternehmen selbst unter die Regulierung fällt und eigene Pflichten hat. Indirekt betroffen bedeutet, dass eure Kund:innen reguliert sind und entsprechende Sicherheitsanforderungen an euch als Lieferanten stellen, auch ohne dass ihr selbst verpflichtet seid.
Was ist das BSI Portal NIS2 und brauchen wir das?
Das BSI Portal NIS2 ist der offizielle Kanal für Registrierung und Meldung, wenn Unternehmen unter NIS-2-Pflichten fallen. Mit dem NIS-2-Umsetzungsgesetz gilt das ab dem 06.12.2025. Für viele frühe Startups noch nicht sofort operativ relevant, aber gut zu kennen, wenn direkte Betroffenheit näher rückt.
Was fragt ein Security Questionnaire B2B konkret ab?
Typische Fragen drehen sich um Zugriffskontrolle und MFA, Backup- und Wiederherstellungsprozesse, Incident Response, Lieferantenmanagement, Business Continuity und Datensicherheit. Wer diese Fragen nicht strukturiert beantworten kann, verliert Enterprise-Deals, unabhängig davon, ob NIS-2 formal gilt.
Welcher Unterschied besteht zwischen NIS-2 und dem Cyber Resilience Act?
NIS-2 regelt Sicherheitsorganisation und Betrieb von Einrichtungen in bestimmten Sektoren. Der Cyber Resilience Act (CRA) legt Sicherheitsanforderungen für Produkte mit digitalen Elementen über den Produktlebenszyklus fest. Merkhilfe: NIS-2 ist Betriebsseite, CRA ist Produktseite.
