NIS2 regelt den Betrieb, der Cyber Resilience Act das Produkt. Die Checkliste führt Startups in sechs Schritten von der Betroffenheit bis zur Meldefähigkeit.

Bei einem Startup führt NIS2 zu zwei Fragen, die gern vermischt werden. Die eine betrifft den eigenen Betrieb, die andere das eigene Produkt, und dafür gelten verschiedene Regelwerke. Wer sie trennt, spart sich ein Projekt, das es nicht braucht.
Zuerst den Betrieb. Das BSIG regelt, wie ein Unternehmen seine eigene IT und seine Dienste absichert, meldet und nachweist. Für ein Startup mit einem Cloud-Angebot ist das der einschlägige Rahmen, denn Anbieter von Cloud-Computing-Diensten stehen im Sektor Digitale Infrastruktur.
Das Produkt regelt ein anderes Gesetz, der Cyber Resilience Act, und der zielt auf Produkte mit digitalen Elementen, also auf Hardware und Software, die eine Verbindung zu Geräten oder Netzwerken herstellen können. Reine Software-as-a-Service-Angebote sind grundsätzlich nicht sein Ziel, sie fallen in den Bereich von NIS2 und BSIG. Die Ausnahme lohnt sich zu kennen: Dient die eigene Cloud als Fernverarbeitungslösung für ein Produkt mit digitalen Elementen, kann sie doch in den Anwendungsbereich rutschen. Für die Praxis heißt das: Solange das Angebot rein als Dienst läuft, ist NIS2 der Maßstab. Sobald ein Gerät, ein Agent oder eine Komponente beim Kunden dazukommt, gehört die Frage neu geprüft, und dann zählt der 11. September 2026, ab dem die Meldepflichten des Cyber Resilience Act für Hersteller vernetzter Produkte gelten.
Deutlich früher als gedacht, und hier stehen echte Zahlen. Für Anbieter von Cloud-Computing-Diensten konkretisiert die Durchführungsverordnung (EU) 2024/2690 in Artikel 7, wann ein Vorfall erheblich ist. Erheblich ist er unter anderem, wenn der Dienst länger als 30 Minuten vollständig nicht verfügbar ist. Ebenso, wenn die Verfügbarkeit für mehr als fünf Prozent der Nutzer in der Union oder für mehr als eine Million Nutzer, je nachdem welcher Wert niedriger ist, länger als eine Stunde beeinträchtigt ist. Und ebenso, wenn Integrität, Vertraulichkeit oder Authentizität von Daten durch eine vermutete böswillige Handlung beeinträchtigt sind.
Diese 30 Minuten sind die wichtigste Zahl für ein junges Cloud-Unternehmen. Sie bedeuten, dass ein kurzer Vollausfall die gestufte Meldekette des § 32 BSIG auslöst, mit Frühwarnung binnen 24 Stunden, Meldung mit erster Bewertung binnen 72 Stunden und Abschlussbericht binnen eines Monats. Die Daten dafür liegen meist schon vor: Wer eine Statusseite betreibt und Verfügbarkeit gegenüber Kunden ausweist, hat die Messgrundlage. Sie muss nur mit der Meldeentscheidung verbunden werden, und zwar vorher.
Mehr als sichere Server. § 30 Absatz 2 Nummer 5 BSIG verlangt Sicherheit in Beschaffung, Entwicklung und Wartung von IT-Systemen einschließlich des Managements und der Offenlegung von Schwachstellen. Bei einem Produktunternehmen reicht diese Pflicht damit direkt in die Entwicklung und nicht nur in den Betrieb.
Praktisch heißt das drei Dinge. Die Build- und Deployment-Kette gehört in den Geltungsbereich, samt der Zugänge zu Repositories, Pipelines und Secrets. Die eigenen Abhängigkeiten gehören inventarisiert, weil eine Schwachstelle in einer Bibliothek eine Schwachstelle im eigenen Dienst ist. Und es braucht einen Weg, über den Dritte eine gefundene Schwachstelle melden können, sowie eine Festlegung, wie damit umgegangen wird. Der letzte Punkt fehlt in fast jedem Startup, obwohl er im Gesetz ausdrücklich genannt ist und in Vendor-Assessments abgefragt wird.
Weil der Kunde die Pflicht weitergeben muss. Jede regulierte Einrichtung hat die Sicherheit ihrer Lieferkette zu regeln, einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu ihren unmittelbaren Anbietern. Ein Startup, das an eine Bank, eine Klinik oder einen Industriekonzern liefert, ist genau dieser unmittelbare Anbieter, und deshalb kommt der Sicherheitsfragebogen unabhängig von der eigenen Betroffenheit.
Das ist der Punkt, an dem sich Aufwand in Umsatz übersetzt. Gefragt wird nach Zugriffskontrolle und Mehrfaktor-Authentifizierung, nach Backup und Wiederherstellungszeiten, nach der Meldekette bei einem Vorfall, nach Subunternehmern und Verarbeitungsorten. Wer diese Antworten einmal belastbar aufschreibt und pflegt, verkürzt jede Vorqualifizierung. Wer sie nicht hat, verhandelt unter Zeitdruck, weil dann der Kunde die Frist setzt.
Drei. Erstens der eigene Cloud-Stack als Lieferkette. Hyperscaler, Monitoring, Auth-Provider und Support-Werkzeuge sind Anbieter im Sinne der Pflicht, und die eigene Liste dieser Dienste ist die Voraussetzung dafür, Kundenfragen überhaupt beantworten zu können.
Zweitens die geteilte Verantwortung. Ein Vorfall beim Cloud-Anbieter ist nicht automatisch der eigene erhebliche Vorfall, aber der eigene Dienst kann dabei trotzdem ausfallen. Die Meldepflicht hängt am eigenen Dienst, nicht an der Ursache, und diese Unterscheidung gehört vor den ersten Ausfall geklärt. Drittens das Offboarding. In schnell wachsenden Teams bleiben Zugänge zu Repositories, Cloud-Konsolen und Secrets länger aktiv als die Person im Unternehmen, und genau darauf schaut jede Prüfung zuerst.
Die Checkliste richtet sich an Gründerinnen und Gründer, Geschäftsführungen, CTOs sowie Sicherheits- und Compliance-Verantwortliche in Startups mit digitalem Geschäftsmodell. Laden Sie sie kostenfrei herunter.
Sprechen Sie mit unseren Expert:innen und erfahren Sie, wie das Digital Compliance Office Ihre Compliance automatisiert.
Gespräch vereinbaren