SaaS-Anbieter und B2B-Cloud: Der vollständige NIS2-Leitfaden

Cloud-Computing-Dienste stehen in einer besonderen Verantwortung unter NIS2: Sie sind nach Anhang I Nr. 8 der NIS2-Richtlinie (EU) 2022/2555 als Wesentliche Einrichtungen eingestuft und unterliegen damit den strengsten Anforderungen. Dieser Leitfaden richtet sich an Gründer, Geschäftsführer und CTOs von SaaS-Unternehmen und B2B-Cloud-Diensten, die verstehen wollen, welche Pflichten auf sie zukommen.

Wer ist betroffen?

NIS2 Anhang I Nr. 8 erfasst Cloud-Computing-Dienste nach der Definition in Verordnung (EU) 2018/1807. Drei Merkmale sind entscheidend: On-demand-Bereitstellung skalierbarer Ressourcen für mehrere Mandanten über ein Netz. Konkret bedeutet das: SaaS-Anbieter, die Geschäftskunden eigenständig provisionierbare Dienste anbieten, Multi-Tenancy betreiben und eigene Infrastruktur oder Managed-Hosting betreiben.

Die Größenschwelle folgt der KMU-Empfehlung 2003/361/EG Art. 2: mindestens 50 Mitarbeitende (Vollzeitäquivalente) oder mindestens 10 Mio. Euro Jahresumsatz. Beide Schwellen müssen zwei Geschäftsjahre in Folge überschritten sein, um Betroffenheit auszulösen. Das heißt: Ein SaaS-Unternehmen im schnellen Wachstum sollte die Betroffenheit prospektiv prüfen.

Wer lediglich White-Label-Software eines anderen Anbieters weiterverkauft oder keinen eigenen Service-Stack betreibt, fällt nicht unter Anhang I Nr. 8, kann aber unter Anhang II als sonstiger digitaler Dienst eingestuft werden.

Die Pflichten nach § 30 BSIG-neu

§ 30 BSIG-neu fordert ein umfassendes Risikomanagement-System mit technisch-organisatorischen Maßnahmen (TOMs). Für SaaS-Anbieter besonders relevant:

1. Risikoanalyse und -management: Regelmäßige Bewertung der eigenen Sicherheitsarchitektur - Cloud-Infrastruktur, Authentifizierungssysteme, Datenbankzugriffe, API-Sicherheit.
2. Incident Handling: Ein dokumentierter Incident-Response-Plan mit klaren Eskalationsstufen und Kommunikationswegen gegenüber dem BSI und betroffenen Kunden.
3. Business Continuity: Backup-Konzepte, Disaster-Recovery-Pläne und Wiederherstellungsziele (RTO/RPO) müssen dokumentiert und getestet sein.
4. Supply-Chain-Sicherheit: AWS, Azure, GCP, Stripe, Auth0 und andere kritische Zulieferer müssen in der Risikoanalyse dokumentiert sein (§ 30 Abs. 2 Nr. 4 BSIG-neu).
5. Zugangskontrolle und MFA: Multi-Faktor-Authentifizierung für alle privilegierten Zugriffe auf Produktionssysteme ist Pflicht.
6. Verschlüsselung: Kundendaten müssen sowohl at-rest als auch in-transit verschlüsselt sein.
7. Schulung: Technisches Personal muss regelmäßig zu Cybersicherheitsthemen geschult werden.

Fristen und Meldepflichten

BSI-Registrierung nach § 33 BSIG-neu innerhalb von drei Monaten nach Feststellung der Betroffenheit. Für Sicherheitsvorfälle nach § 32 BSIG-neu gilt eine dreistufige Meldekette: Erstmeldung innerhalb von 24 Stunden, vollständige Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb von 30 Tagen nach dem Vorfall.

Bei einem Sicherheitsvorfall, der Kundendaten betrifft, laufen parallel zwei Meldestränge: Die NIS2-Meldepflicht gegenüber dem BSI und die DSGVO-Meldepflicht gegenüber der Datenschutzbehörde nach Art. 33 DSGVO (ebenfalls 72 Stunden). Betroffene Kunden müssen zusätzlich nach Art. 34 DSGVO informiert werden, wenn ein hohes Risiko für deren Rechte und Freiheiten besteht. Ein interner Incident-Response-Plan muss beide Meldestränge koordinieren und sollte vor dem ersten Vorfall fertiggestellt sein.

Bußgelder und persönliche Haftung

Wichtige Einrichtungen nach Anhang I: bis 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes (§ 65 BSIG-neu). Hinzu kommt persönliche Geschäftsleiterhaftung nach § 38 BSIG-neu: Geschäftsführer und Vorstände müssen Cybersicherheitsmaßnahmen billigen, überwachen und regelmäßig schulen. Nachgewiesene Vernachlässigung kann zu persönlicher Haftung führen, unabhängig von der gesellschaftsrechtlichen Haftungsbeschränkung einer GmbH.

Für SaaS-Anbieter kommt vertragliche Haftung gegenüber Kunden hinzu: Verletzt ein Anbieter seine NIS2-Pflichten und verursacht dadurch einen Schaden beim Kunden, können DSGVO-Bußgelder und Schadensersatzansprüche gleichzeitig anfallen.

DORA: Was für Finanzkunden zusätzlich gilt

Die Verordnung (EU) 2022/2554 (Digital Operational Resilience Act, kurz DORA) ist seit 17. Januar 2025 in Kraft und gilt für alle IKT-Drittdienstleister, die Finanzunternehmen wie Banken, Versicherungen oder Kapitalverwaltungsgesellschaften bedienen.

Als IKT-Drittdienstleister mit Finanzkunden bist du nach Art. 28 DORA verpflichtet, bestimmte Vertragsbestandteile aufzunehmen: eine dokumentierte Exit-Strategie, die dem Finanzunternehmen einen geordneten Wechsel ermöglicht; Audit-Rechte des Finanzunternehmens und dessen Aufsichtsbehörde; sowie eine vollständige Offenlegung der Sub-Outsourcing-Kette, inklusive aller Sub-Processor, die sicherheitsrelevante Funktionen übernehmen.

Kritische IKT-Drittdienstleister (Critical Third-Party Providers, CTPP) werden direkt von den europäischen Aufsichtsbehörden (ESA) beaufsichtigt. In der Praxis betrifft das nur Hyperscaler wie AWS, Azure oder Google Cloud, nicht typische SaaS-Anbieter. Für SaaS-Anbieter mit Finanzkunden im Portfolio ist ein DORA-konformer Vertragsnachtrag (Addendum) zum bestehenden Hauptvertrag in den meisten Fällen ausreichend, um die Art. 28 Pflichten zu erfüllen.

Typische Fehler vermeiden

"Wir sind nur Software, kein IT-Betrieb": Dieser Irrtum ist weit verbreitet. NIS2 Anhang I Nr. 8 stellt nicht auf die interne Selbstwahrnehmung ab, sondern auf die Merkmale des Dienstes. Wer mandantenfähige Software auf eigener Infrastruktur betreibt und Kunden On-demand-Zugang bietet, ist Cloud-Computing-Dienst nach NIS2 - unabhängig davon, ob das Unternehmen sich als Softwarehaus oder Plattformanbieter bezeichnet.

Sub-Processor-Liste nicht gepflegt: Sowohl DORA Art. 28 als auch DSGVO Art. 28 verlangen eine aktuelle Liste aller Sub-Processor. Viele SaaS-Anbieter haben AWS oder Stripe in der AVV stehen, vergessen aber CDN-Anbieter, E-Mail-Dienstleister oder Authentifizierungsdienste. Eine unvollständige Sub-Processor-Liste ist ein Compliance-Risiko gegenüber Kunden und Aufsichtsbehörden.

Incident-Meldekette nur intern geregelt: NIS2 verlangt eine 24-Stunden-Erstmeldung an das BSI bei erheblichen Vorfällen (§ 32 BSIG-neu). Wer nur einen internen Eskalationsprozess hat, aber keinen dokumentierten Weg zum BSI-Meldeportal, wird im Ernstfall zu langsam sein. Zusätzlich sind betroffene Kunden zu informieren - ein Schritt, der im Incident-Response-Plan explizit vorgesehen sein muss.

Erste Schritte

1. Prüfe die NIS2-Betroffenheit anhand der vier Cloud-Service-Kriterien und der Größenschwellen.
2. Starte eine Gap-Analyse deiner aktuellen Sicherheitsarchitektur gegen die TOMs des § 30 BSIG-neu.
3. Dokumentiere deine Supply Chain: alle Cloud-Provider, Sub-Processor und kritischen Drittdienste.
4. Erstelle einen Incident-Response-Plan mit explizitem BSI-Meldepfad und Kunden-Notifizierungsschritt.
5. Prüfe alle Kunden-AVVs auf DSGVO-Konformität und aktualisiere die Sub-Processor-Liste.
6. Falls Finanzkunden im Portfolio: DORA-Addendum zu bestehenden Verträgen erstellen.
7. Plane die BSI-Registrierung binnen drei Monaten nach Feststellung der Betroffenheit.

Nutze den branchengenauen NIS2-Rechner für SaaS-Anbieter, um deine Betroffenheit zu klären.