Donnerstagnachmittag. Der Geschäftsführer eines zehnköpfigen Softwareunternehmens in Bratislava öffnet eine E-Mail seines größten Kunden. Einer Bank. Im Anhang liegt ein langer Fragebogen zur Cybersicherheit, der Datenverschlüsselung, Incident Response, Penetrationstests, Zugriffsverwaltung, Backups und Notfallwiederherstellung abdeckt.
Das Unternehmen hat ein solides Payroll-SaaS-Produkt, das von Hunderten Kunden genutzt wird. Sein Incident-Response-Prozess ist nicht formalisiert, und der letzte Penetrationstest deckt die aktuelle Version nicht mehr ab. Es kann der Bank keine überprüfbaren Antworten geben.
Das passiert immer häufiger. Der Grund hat einen Namen: NIS2.
NIS2 (Network and Information Security Directive 2) ist eine EU-Richtlinie. Die Slowakei hat sie durch eine Novelle des Gesetzes Nr. 69/2018 über Cybersicherheit umgesetzt, die seit dem 1. Januar 2025 in Kraft ist. Sie erfasst Einrichtungen in Sektoren wie Energie, Verkehr, Gesundheitswesen, digitale Infrastruktur und ausgewählte digitale Dienste. Der genaue Anwendungsbereich sollte anhand des slowakischen Gesetzes geprüft und nicht allein aus der Unternehmensgröße abgeleitet werden.
Ihr Softwareunternehmen steht möglicherweise nicht auf dieser Liste. Einige Ihrer Kunden schon.
NIS2 verpflichtet regulierte Einrichtungen, Sicherheitsrisiken über ihre gesamte Lieferkette hinweg zu steuern. Artikel 21 verweist ausdrücklich auf „die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern". In der Praxis bedeutet das, dass eine Bank, die Ihr Payroll-System nutzt, dafür verantwortlich ist, dass Sie als Lieferant einen bestimmten Sicherheitsstandard erfüllen.
NIS2 reguliert Ihr Unternehmen also nicht direkt und landet trotzdem auf Ihrem Schreibtisch. Ihre Kunden werden Fragen stellen, die Sie beantworten können müssen. Wenn Sie das nicht können, suchen sie nach Alternativen.
Was erwartet ein Unternehmenskunde von einem SaaS-Lieferanten? Aus den Fragebögen, die wir bei unseren Kunden sehen, tauchen mehrere Bereiche immer wieder auf.
Wer hat Zugriff auf Produktionsdaten? Wie werden Berechtigungen vergeben und entzogen? Haben Sie MFA für Administratoren? Befolgen Sie das Prinzip der geringsten Rechte? Wenn ein Entwickler das Unternehmen verlässt, wie lange dauert es, bis sein Zugriff auf die Infrastruktur entzogen wird?
Die meisten kleinen Softwareunternehmen handhaben Zugriffe ad hoc. Das halbe Team kennt das Admin-Passwort der Datenbank. SSH-Schlüssel werden nicht rotiert. Ein ausscheidender Mitarbeiter hat eine Woche später noch Produktionszugriff, weil „wir nicht dazu gekommen sind, ihn zu entziehen". Für einen Unternehmenskunden ist das inakzeptabel.
Verwenden Sie bei der Übertragung eine aktuell unterstützte TLS-Version und bei ruhenden Daten eine starke Verschlüsselung mit verwalteten Schlüsseln. Das betrifft Datenbanken, Backups und Logs. Ein unverschlüsseltes Backup oder Logs ohne ordentliche Zugriffskontrollen sind ernsthafte Risiken.
Scannen Sie Abhängigkeiten? Wie oft? Was passiert, wenn eine kritische CVE in einer von Ihnen genutzten Bibliothek auftaucht? Legen Sie risikobasierte Fristen für die Behebung fest und halten Sie Nachweise bereit, dass Probleme bewertet und behoben wurden. Eine Software Bill of Materials kann dem Kunden helfen, die Auswirkung einer neuen Schwachstelle schneller einzuschätzen.
Code-Review, statische Analyse, Sicherheitstests vor dem Release. Wenn Sie Code-Reviews nur gelegentlich durchführen und keine automatisierten Sicherheitsscans haben, ist dies der erste Bereich, den es zu verbessern gilt. Kunden werden nach Ihrem SDLC-Prozess fragen. Wenn Sie ihn nicht dokumentiert haben, ist „wir machen Code-Review" keine ausreichende Antwort.
NIS2 verpflichtet regulierte Einrichtungen, Sicherheitsvorfälle zu melden. Innerhalb von 24 Stunden nach Entdeckung ist eine Frühwarnung fällig, innerhalb von 72 Stunden eine detaillierte Meldung und innerhalb eines Monats ein Abschlussbericht.
Als Lieferant betrifft Sie das indirekt. Kommt es in Ihrem SaaS-System zu einer Datenpanne, muss Ihr Kunde (die Bank, der Versicherer) den Vorfall der Aufsichtsbehörde melden. Und er wird Informationen von Ihnen benötigen. Was passiert ist, wann, wie groß der Umfang war, welche Daten betroffen waren und welche Maßnahmen Sie ergriffen haben.
Ohne einen Incident-Response-Plan können Sie diese Informationen nicht rechtzeitig liefern. „Wir melden uns, sobald wir es untersucht haben" ist keine Antwort, die eine Bank akzeptiert, wenn sie 24 Stunden Zeit hat, um es der Aufsichtsbehörde zu melden.
Ein Incident-Response-Plan für ein kleines Unternehmen muss kein 50-seitiges Dokument sein. Sie müssen wissen, wer die Kontaktperson ist, welcher Kommunikationskanal genutzt wird, wer das System abschalten darf, wo die Logs liegen und wer sie analysieren kann. Der Prozess sollte schriftlich festgehalten, regelmäßig getestet und nach wesentlichen Systemänderungen aktualisiert werden.
Ereignisaufzeichnungen helfen bei Sicherheitsuntersuchungen und weiteren Pflichten. Zum Beispiel benötigen auch KI-Systeme mit hohem Risiko nach dem AI Act eine angemessene Protokollierung. Sie brauchen keine separate Protokollierungsplattform für jedes Regelwerk. Sie brauchen einen durchdachten Audit-Trail, der Sicherheitsereignisse, KI-Entscheidungen und wichtige Datenänderungen abdeckt.
In der Praxis bedeutet das strukturierte Logs mit Zeitstempeln, Identität des Akteurs, Art der Aktion und Ergebnis. Die Aufbewahrung sollte sich nach Zweck, Risiko, Vertrag und geltenden Regeln richten. Es gibt keine einzige universelle Frist für jedes System. Logs müssen manipulationssicher und für Audits zugänglich sein, ohne zwei Tage lang unlesbare Textdateien durchsuchen zu müssen.
Lieferkettensicherheit nach NIS2 bedeutet, dass Ihr regulierter Kunde Nachweise verlangt. Keine Versprechen. Nachweise.
Standardisierte Formulare (oft auf Basis des CAIQ der Cloud Security Alliance oder der eigenen Vorlage des Kunden), in denen Sie Fragen zu Verschlüsselung, Zugriffen, Tests und Backup-Richtlinien beantworten. Wenn Sie keine Antworten vorbereitet haben, kostet Sie jeder Fragebogen Tage an Arbeit.
Ein Kunde kann ISO 27001 oder einen anderen unabhängigen Nachweis verlangen. Eine Zertifizierung ersetzt keine funktionierenden technischen Kontrollen. Ohne sie brauchen Sie einen anderen vereinbarten Weg, um nachzuweisen, dass die Prozesse existieren und funktionieren.
Legen Sie Umfang und Häufigkeit nach Risiko und Vertrag fest, bei wichtigen Systemen mit einem unabhängigen Tester. Der Kunde will den Bericht sehen und den Nachweis, dass gefundene Schwachstellen behoben wurden. Ein Bericht zu einer veralteten Version des Systems hilft nicht.
Vereinbaren Sie Reaktions- und Behebungszeiten auf Basis der Schwere und des realistischen Ausnutzungsrisikos. Wenn Sie monatlich releasen und eine aktiv ausgenutzte kritische Schwachstelle entdecken, brauchen Sie einen Weg, eine Korrektur außerhalb des normalen Zyklus auszuliefern.
Wenn Sie ein Multi-Tenant-SaaS auf gemeinsam genutzter Infrastruktur betreiben, erwarten von NIS2 betroffene Kunden eine überprüfbare Datenisolierung.
Kunde A darf niemals die Daten von Kunde B sehen. Nicht durch einen Anwendungsfehler, nicht durch eine falsch konfigurierte Abfrage, nicht durch ein Leck in den Logs. Eine gemeinsame Datenbank mit einer tenant_id-Spalte gibt Ihnen eine logische Isolierung, und manche Unternehmenskunden verlangen stattdessen eine separate Datenbank oder ein separates Schema. Was auch immer Sie wählen, die Architektur muss klar zeigen, wie sie diese Isolierung durchsetzt und wie sie sie testet.
Bei Backups geht das gern unter. Wenn Sie die gesamte Datenbank auf einmal sichern, kann die Wiederherstellung eines einzelnen Mandanten die Daten aller Kunden betreffen. Klären Sie vorab, wie sich ein einzelner Kunde sicher wiederherstellen lässt, ohne die anderen zu berühren und ohne sie offenzulegen.
GDPR und NIS2 überschneiden sich hier. Bei einer Löschanfrage brauchen Sie einen dokumentierten Ansatz, um den Zugriff in aktiven Systemen zu entfernen und die Daten in Backups gemäß der geltenden Aufbewahrungsfrist zu behandeln. Bei gemeinsam genutzten Backups ist das nicht trivial.
Wenn Sie ein Softwareunternehmen sind, das an regulierte Kunden verkauft, beginnen Sie hier.
Erfassen Sie, welche Ihrer Kunden reguliert sind (Banken, Versicherer, Gesundheitseinrichtungen, Energieunternehmen) und welche Sicherheitsanforderungen sie haben werden. Wenn Sie es nicht wissen, fragen Sie sie direkt. Besser sechs Monate im Voraus vorbereitet sein, als sich unter Druck durch einen Fragebogen zu kämpfen.
Formalisieren Sie Ihren Incident-Response-Plan. Er muss nicht lang sein, aber er muss existieren, aktuell und getestet sein.
Führen Sie automatisiertes Scannen von Abhängigkeiten ein und legen Sie risikobasierte Behebungsfristen fest. Es ist einer der schnellsten Wege, Ihr Sicherheitsniveau ohne große Investition zu verbessern.
Ziehen Sie eine ISO-27001-Zertifizierung in Betracht, wenn Ihre Kunden oder Ihr Zielsegment sie verlangen. Beginnen Sie mit funktionierenden Kontrollen, denn ein Zertifikat ersetzt sie nicht.
Wenn Sie nicht sicher sind, wo Sie anfangen sollen, melden Sie sich bei uns. Wir führen Sicherheitsbewertungen und Architekturdesign für Unternehmen durch, die die Anforderungen regulierter Kunden erfüllen müssen. Über die nationale Cybersicherheitsstrategie der Slowakei und ihre Auswirkungen auf IT-Lieferanten haben wir in einem separaten Artikel geschrieben.
Gründer und technischer Leiter von Rise.sk. Er konzipiert und liefert Webanwendungen, Datensysteme und Automatisierungen und schreibt über Softwareentscheidungen, KI und digitale Dienste.
Die EU-Verordnung über die digitale operationale Resilienz (DORA) verändert, wie Finanzinstitute IT-Zulieferer auswählen und steuern. Wenn Sie Software für Banken oder Versicherer entwickeln, sollten Sie das wissen.
Chinesische Modelle liegen nur noch Monate hinter der US-Spitze, nicht Jahre, und das zu einem Bruchteil der Kosten. Für ein europäisches Unternehmen ist die eigentliche Frage nicht, wer das Rennen gewinnt, sondern ob und wie man sie einsetzt.
Der AI Act ist nicht nur ein rechtliches Thema. Unternehmen benötigen ein Inventar der KI-Tools, Eigentümer, Daten, Risiken, Protokolle, menschlichen Prüfung und Anbieterverantwortlichkeiten.
Ihr Kontext entscheidet
