NIS2 für Cloud-Provider + SaaS-Anbieter: Sektor 'Cloud Computing'

Hauptartikel: NIS2-Umsetzung Deutschland — der vollständige Pillar-Artikel zum Thema.

1. Sektor-Klassifikation

Cloud-Computing-Dienste gehören zum Sektor Digitale Infrastruktur (Anhang I NIS-2-Richtlinie / Anlage 1 BSIG). Anders als DNS-Diensteanbieter, TLD-Namenregister oder qualifizierte Vertrauensdiensteanbieter sind Cloud-Anbieter jedoch nicht größenunabhängig wesentliche Einrichtung — die Einstufung richtet sich nach der Unternehmensgröße (§ 28 Abs. 1 und 2 BSIG):

• Besonders wichtige (= wesentliche) Einrichtung: großes Unternehmen einer Anlage-1-Art (§ 28 Abs. 1 Nr. 4 BSIG).
• Wichtige Einrichtung: mittleres Unternehmen (§ 28 Abs. 2 Nr. 3 BSIG).

Unterhalb der Schwelle für mittlere Unternehmen (unter 50 Beschäftigte und je unter 10 Mio. EUR) fallen Cloud-Anbieter grundsätzlich nicht unter NIS2 — die für Betreiber kritischer Anlagen, DNS, TLD, Vertrauensdienste und bestimmte Telekommunikationsanbieter geltende Größenunabhängigkeit greift für die Einrichtungsart Cloud Computing gerade nicht. Wer daneben eine kritische Anlage betreibt, ist allerdings über diese Betreibereigenschaft größenunabhängig besonders wichtige Einrichtung (§ 28 Abs. 1 Nr. 1 BSIG).

Für die größenabhängige Einstufung müssen zwei Voraussetzungen zugleich erfüllt sein: die Zuordnung zu einer in Anlage 1 oder 2 BSIG bestimmten Einrichtungsart und das Erreichen der Größenschwelle. Für Cloud-Computing-Dienste ist die Einrichtungsart eine solche der Anlage 1; das ist der Grund, warum ein Cloud-Anbieter überhaupt in die Kategorie „besonders wichtig" aufsteigen kann — § 28 Abs. 1 Nr. 4 BSIG erfasst ausschließlich Anlage-1-Arten, während § 28 Abs. 2 Nr. 3 BSIG Anlage-1- und Anlage-2-Arten erfasst.

Zwei Fallstricke bei der Rechnung: Erstens genügt der Umsatz allein nie — § 28 Abs. 1 Nr. 4 Buchst. b BSIG verlangt Umsatz und Bilanzsumme kumulativ; nur die Mitarbeiterzahl wirkt als eigenständiges Kriterium. Zweitens gilt für die Berechnung von Mitarbeiterzahl, Jahresumsatz und Bilanzsumme die Empfehlung 2003/361/EG mit Ausnahme von Art. 3 Abs. 4 ihres Anhangs (§ 28 Abs. 4 BSIG) — Konzernzugehörigkeit kann verbundene Unternehmen einbeziehen und einen für sich genommen kleinen SaaS-Anbieter in die Betroffenheit ziehen. In Österreich wird die Größenbestimmung ab dem 01.10.2026 nach derselben Empfehlung mit derselben Ausnahme vorgenommen (§ 25 NISG 2026).

Deutschland und Österreich: Die in diesem Artikel genannten §§ 28, 30, 32, 33, 35, 38, 39 und 65 BSIG gelten nur in Deutschland. In Österreich greift statt des BSIG das NISG 2026 (BGBl. I Nr. 94/2025) — kundgemacht am 23.12.2025, anwendbar aber erst mit Ablauf von neun Monaten nach der Kundmachung zum nächstfolgenden Monatsersten, also ab dem 01.10.2026 (§ 51 Abs. 1 und 2 NISG 2026); zum Stand dieses Artikels bestehen daraus noch keine wirksamen Pflichten. Alle nachfolgenden Angaben zum NISG 2026 gelten ab diesem Datum. Cloud-Computing zählt dort ebenfalls zur Digitalen Infrastruktur (Anlage 1); die Größenschwellen (großes Unternehmen = wesentliche Einrichtung, mittleres Unternehmen = wichtige Einrichtung) entsprechen den deutschen Werten. Die österreichischen Pflichten im Einzelnen — Maßnahmenkatalog, Meldewege und Fristen, Registrierung und Selbstdeklaration — stehen in den Abschnitten 3, 5 und 7.

2. SaaS-Provider als Cloud-Provider?

SaaS gehört ausdrücklich zu den Dienstmodellen des Cloud-Computing im Sinne von NIS2. Maßgeblich ist die Legaldefinition: Ein „Cloud-Computing-Dienst" ist ein digitaler Dienst, der auf Abruf die Verwaltung eines skalierbaren und elastischen Pools gemeinsam nutzbarer Rechenressourcen sowie den umfassenden Fernzugang zu diesem Pool ermöglicht, auch wenn die Rechenressourcen auf mehrere Standorte verteilt sind (§ 2 Nr. 4 BSIG; sachgleich Art. 6 Nr. 30 NIS-2-Richtlinie). Erwägungsgrund 33 der NIS-2-Richtlinie zählt die Dienstmodelle ausdrücklich auf: IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) und NaaS (Network as a Service) gehören „unter anderem" dazu. Die Bereitstellungsmodelle umfassen private, gemeinschaftliche, öffentliche und hybride Cloud.

Über die Betroffenheit entscheidet daher nicht das Dienstmodell, sondern zwei andere Fragen: (1) Erfüllt der Dienst die Definition — skalierbarer und elastischer Ressourcen-Pool, Verwaltung auf Abruf, umfassender Fernzugang? (2) Werden die Größenschwellen aus Abschnitt 1 erreicht? Eine einzelne, nicht skalierbare Web-Anwendung ohne elastischen Ressourcen-Pool fällt nicht unter die Definition — „reines SaaS" ist als Kategorie aber kein Ausschlussgrund.

Die Zuordnung bleibt nicht intern, sondern wird gegenüber der Behörde aktenkundig: § 33 Abs. 1 BSIG verlangt bei der Registrierung die Angabe des relevanten Sektors nach Anlage 1 oder 2 (Fristen und vollständige Angabenliste: Abschnitt 7). Praxisempfehlung: Dokumentieren Sie die Prüfung in dieser Reihenfolge — Erfüllung der Legaldefinition, dann Größe nach § 28 Abs. 1 und 2 BSIG, dann Konzernverbund nach § 28 Abs. 4 BSIG — und halten Sie das Ergebnis mit Datum fest.

3. Maßnahmenpflichten nach § 30 BSIG — was für Cloud-Anbieter dazukommt

Für Cloud-Anbieter gilt der allgemeine Maßnahmenkatalog des § 30 BSIG; cloud-spezifisch wirken vor allem zwei Punkte: die Zuordnung zu Anlage 1 mit dem daran hängenden Aufstieg in die Kategorie „besonders wichtig" und die durch die Durchführungsverordnung (EU) 2024/2690 konkretisierte Meldeschwelle (Abschnitt 5).

Rechtlich verankert ist zunächst der Maßstab: § 30 Abs. 1 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen, um Störungen der Verfügbarkeit, Integrität und Vertraulichkeit der IT-Systeme zu vermeiden und die Auswirkungen von Sicherheitsvorfällen gering zu halten; die Einhaltung ist zu dokumentieren. Das österreichische Pendant, § 32 Abs. 1 NISG 2026, verlangt geeignete und verhältnismäßige Risikomanagementmaßnahmen in technischer, operativer und organisatorischer Hinsicht. Nach § 30 Abs. 2 Satz 1 BSIG sollen die Maßnahmen zudem dem Stand der Technik und den einschlägigen Normen folgen und müssen auf einem gefahrenübergreifenden Ansatz beruhen (Nachweiswert von Zertifikaten: Abschnitt 6).

Der Katalog des § 30 Abs. 2 BSIG nennt zehn Bereiche: (1) Konzepte für Risikoanalyse und Sicherheit von Informationssystemen, (2) Bewältigung von Sicherheitsvorfällen, (3) Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung und Krisenmanagement, (4) Sicherheit der Lieferkette, (5) Sicherheit bei Erwerb, Entwicklung und Wartung, (6) Bewertung der Wirksamkeit der Maßnahmen, (7) grundlegende Schulungen und Sensibilisierungsmaßnahmen, (8) Kryptografie und Verschlüsselung, (9) Personalsicherheit und Zugriffskontrolle, (10) Multi-Faktor-Authentifizierung, kontinuierliche Authentifizierung und sichere Kommunikation. In Österreich steht der gleichlaufende Katalog in § 32 Abs. 4 lit. a bis j NISG 2026, in derselben Reihenfolge (lit. d = Sicherheit der Lieferkette, lit. g = Cyberhygiene und Schulungen). Praxisempfehlung: Anbieter, die ihre Plattform selbst entwickeln, füllen Bereich 5 typischerweise OWASP-orientiert aus und ergänzen ein Schwachstellenmanagement über einen CVD-Prozess (Coordinated Vulnerability Disclosure).

Praxisempfehlung: Regeln Sie die vier cloud-typischen Erwartungen Ihrer Kunden — strengere Service-Level-Agreements, höhere Verfügbarkeits-Standards, Orientierung am ENISA-Cloud-Security-Benchmark und eine EU-Datenboundary — ausdrücklich im Kundenvertrag und im Maßnahmenpaket; die Umsetzungstiefe bleibt nach § 30 Abs. 1 BSIG risikobasiert.

4. Lieferkette und Sub-Provider: wer wofür verantwortlich ist

Verantwortlich für die Sicherheit Ihrer Lieferkette bleiben Sie: Sie ist ein eigener Pflichtbereich des Maßnahmenkatalogs (§ 30 Abs. 2 Nr. 4 BSIG; § 32 Abs. 4 lit. d NISG 2026) und damit Ihre eigene Pflicht als Einrichtung — unabhängig davon, welche Pflichten Ihre Lieferanten ihrerseits treffen. In der Praxis betrifft das die Rechenzentren, Managed-Service-Partner und Software-Zulieferer, aus denen Ihr Dienst zusammengesetzt ist — Vertragsklauseln zur Cybersicherheit gegenüber Sub-Providern sind der praktische Hebel dafür. Bereich 4 gilt zugleich als häufigste Audit-Beanstandung 2026, typischerweise weil Cybersecurity-Klauseln in den Verträgen fehlen. In der Umsetzung haben sich vier Bausteine etabliert (Praxisempfehlung, keine gesetzliche Aufzählung):

• Lieferanten-Bewertung mit Risikoklassifizierung — kritische von unkritischen Sub-Providern trennen.
• Cybersecurity-Klauseln im Standard-Vertragswerk statt in Einzelverhandlungen.
• Right-to-Audit für kritische Lieferanten.
• Vertragliche Vorfall-Benachrichtigung durch den Sub-Provider, üblicherweise binnen 24 Stunden — damit Ihre eigene 24-Stunden-Frist nach § 32 Abs. 1 Nr. 1 BSIG einhaltbar bleibt.

Datenschutzrechtlich läuft die Kette parallel, aber nach anderer Logik: Art. 28 Abs. 1 DSGVO verpflichtet den Verantwortlichen — also Ihren Kunden —, nur mit Auftragsverarbeitern zu arbeiten, die hinreichende Garantien für geeignete technische und organisatorische Maßnahmen bieten; Art. 28 Abs. 3 DSGVO gibt den Mindestinhalt des Auftragsverarbeitungsvertrags vor (Gegenstand und Dauer, Art und Zweck, Art der Daten, Kategorien betroffener Personen, Pflichten und Rechte des Verantwortlichen). Das ist der Grund, aus dem Ihre Kunden Fragebögen, Nachweise und Audit-Berichte anfordern — Grundlage der Anfrage ist ihre eigene Pflicht nach Art. 28 Abs. 1 DSGVO; welche Nachweise Sie als Auftragsverarbeiter dafür bereitstellen, regelt der Auftragsverarbeitungsvertrag nach Art. 28 Abs. 3 DSGVO.

5. Vorfall-Meldung: Behörde, Kunden, Fristen

Die 24-Stunden-Frist gilt nicht für die Kundeninformation. Sie betrifft ausschließlich die Frühwarnung an die Behörde: in Deutschland die frühe Erstmeldung an die gemeinsame Meldestelle von BSI und BBK (§ 32 Abs. 1 Nr. 1 BSIG), in Österreich die Frühwarnung an das zuständige CSIRT (§ 34 Abs. 2 Z 1 NISG 2026). Es folgen die Meldung mit Erstbewertung binnen 72 Stunden und die Abschlussmeldung binnen eines Monats.

Gegenüber den Empfängern der Dienste — also Ihren Kunden — gilt kein Stundenraster, sondern der Maßstab „unverzüglich":

• Deutschland: Das BSI kann anordnen, die Empfänger der Dienste unverzüglich über einen erheblichen Sicherheitsvorfall zu unterrichten, der die Erbringung des jeweiligen Dienstes beeinträchtigen könnte; die Unterrichtung kann auch über die eigene Internetseite erfolgen (§ 35 Abs. 1 BSIG). Ohne Anordnung — und damit von sich aus — müssen Einrichtungen der Sektoren digitale Infrastruktur, Verwaltung von IKT-Diensten und Digitale Dienste, also auch Cloud-Anbieter, den potenziell von einer erheblichen Cyberbedrohung betroffenen Empfängern und dem BSI unverzüglich mögliche Abhilfemaßnahmen sowie die Bedrohung selbst mitteilen (§ 35 Abs. 2 BSIG).
• Österreich: Beeinträchtigt ein erheblicher Cybersicherheitsvorfall die Erbringung des Dienstes, sind die Empfänger der Dienste unverzüglich zu unterrichten und, soweit möglich, mögliche Abhilfemaßnahmen mitzuteilen (§ 34 Abs. 3 NISG 2026); die Cybersicherheitsbehörde kann eine Unterrichtung der potenziell von einer erheblichen Cyberbedrohung betroffenen Personen zusätzlich mit Bescheid anordnen (§ 39 Abs. 3 Z 1 lit. a NISG 2026).
• Datenschutzrechtlich: Als Auftragsverarbeiter meldet der Cloud-Provider eine Verletzung des Schutzes personenbezogener Daten dem Verantwortlichen ebenfalls „unverzüglich" (Art. 33 Abs. 2 DSGVO). Die 72-Stunden-Frist des Art. 33 Abs. 1 DSGVO trifft den Verantwortlichen gegenüber der Aufsichtsbehörde — nicht den Provider gegenüber dem Kunden. Die Benachrichtigung der betroffenen Personen bei voraussichtlich hohem Risiko liegt nach Art. 34 Abs. 1 DSGVO ebenfalls beim Verantwortlichen.

Praktische Folge: Kürzere Informationsfristen gegenüber Kunden (z. B. „binnen 24 Stunden") sind eine vertragliche Zusage aus AVV oder SLA, keine gesetzliche NIS2-Pflicht.

Wann ist ein Vorfall erheblich?

Ob die Meldekette überhaupt anläuft, entscheidet die Erheblichkeitsschwelle. Meldepflichtig ist der erhebliche Sicherheitsvorfall nach § 2 Nr. 11 BSIG: ein Sicherheitsvorfall, der schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die Einrichtung verursacht hat oder verursachen kann, oder der andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann; beide Alternativen genügen jeweils für sich und erfassen auch das bloße Verursachen-Können. Für Cloud-Anbieter kommt eine Besonderheit hinzu: Die Durchführungsverordnung (EU) 2024/2690 konkretisiert diese Schwelle mit quantitativen Kriterien — unter anderem Anzahl betroffener Nutzer, finanzielle Auswirkungen und Dauer — und zwar für bestimmte digitale Einrichtungsarten, zu denen Cloud- und Rechenzentrumsdienste ausdrücklich zählen (neben DNS-Diensteanbietern, TLD-Name-Registries, CDN, Managed-(Security-)Service-Providern, Online-Marktplätzen, Suchmaschinen, sozialen Netzwerken und Vertrauensdiensteanbietern; vgl. § 30 Abs. 3 BSIG). Für Einrichtungen außerhalb dieser Liste gilt bis zu einer Rechtsverordnung nach § 56 Abs. 5 BSIG allein die Definition des § 2 Nr. 11 BSIG. In Österreich definiert § 35 Abs. 1 NISG 2026 den erheblichen Cybersicherheitsvorfall über dieselben zwei Alternativen, verlangt im Wortlaut aber ausdrücklich schwerwiegende Betriebsstörungen der erbrachten Dienste oder schwerwiegende finanzielle Verluste.

Praxisempfehlung: Weil die Erheblichkeitsbewertung im Ernstfall unter Zeitdruck stattfindet, gehört die Bewertungslogik vorab ins Incident-Response-Playbook — mit eigenen Auslösern, den quantitativen Kriterien der Durchführungsverordnung (EU) 2024/2690 und einer namentlich benannten Person, die die Meldeentscheidung trifft. Die 24-Stunden-Uhr läuft ab Kenntnis, nicht ab Vorfallsbeginn, und sie läuft auch nachts und am Wochenende; eine durchgehende Erreichbarkeit über interne Rufbereitschaft oder einen externen SOC-Dienstleister ist der übliche Weg, das organisatorisch zu halten.

6. Empfohlene Standards und ihr Nachweiswert

Für Cloud- und SaaS-Anbieter sind vier Standards einschlägig: ISO 27017 (Cloud-Security), ISO 27018 (Cloud-Privacy), der BSI-Cloud-Standard C5 und CSA STAR.

Welchen Nachweiswert solche Zertifikate haben, bestimmt § 30 Abs. 2 Satz 1 BSIG: Die Maßnahmen sollen den Stand der Technik einhalten und die einschlägigen europäischen und internationalen Normen berücksichtigen. Als Orientierung für den Stand der Technik dienen in der Aufsichtspraxis die BSI-IT-Grundschutz-Bausteine, ISO 27002, die ENISA Technical Implementation Guidance v1.0 (26.06.2025) und branchenspezifische Standards; ein statischer Standard ist das nicht — die laufende Aktualisierung gehört dazu.

Für die Lückenanalyse ist die Erfahrung mit ISO 27001 der nützlichste Anhaltspunkt: Eine Zertifizierung deckt 70 bis 80 % der Anforderungen des § 30 BSIG ab. Die typischen Lücken liegen bei den Meldepflichten 24 h / 72 h / 1 Monat (§ 32 BSIG), bei der Lieferketten-Sorgfalt nach § 30 Abs. 2 Nr. 4 BSIG und bei den Geschäftsleitungspflichten nach § 38 BSIG — genau die drei Punkte, die in den Abschnitten 4, 5 und 8 stehen. Praxisempfehlung zu Bereich 8 (Kryptografie): TLS 1.3 nach BSI TR-02102 für Daten in Transit und HTTPS durchgängig, AES-256 für Daten at Rest einschließlich Backups, S/MIME oder PGP für sensible E-Mail-Kommunikation, HSM oder gleichwertiges Key-Management-System für die Schlüsselverwaltung sowie die Vorbereitung auf Post-Quantum-Verfahren (NIST-Standards 2024).

7. Registrierung, Nachweis und Aufsicht

Die Registrierung ist eine eigenständige Pflicht und nicht Teil des Risikomanagements: Besonders wichtige und wichtige Einrichtungen sowie Domain-Name-Registry-Diensteanbieter registrieren sich spätestens drei Monate, nachdem sie erstmals oder erneut als solche gelten, über eine gemeinsam vom BSI und dem Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) eingerichtete Registrierungsmöglichkeit — praktisch über das Portal „Mein Unternehmenskonto" (§ 33 Abs. 1 BSIG). Das BSI weist darauf hin, dass die gesetzliche Registrierungsfrist bereits abgelaufen ist; wer sie versäumt hat, holt die Registrierung nach — die Pflicht besteht fort.

Zu übermitteln sind Name samt Rechtsform und ggf. Handelsregisternummer, Anschrift und aktuelle Kontaktdaten einschließlich E-Mail, öffentlicher IP-Adressbereiche und Telefonnummern, der relevante Sektor nach Anlage 1 oder 2, die Liste der EU-Mitgliedstaaten mit Diensterbringung sowie die zuständigen Aufsichtsbehörden des Bundes und der Länder. Praxisempfehlung: Führen Sie die Länderliste als eigenen, versionierten Datensatz — maßgeblich ist, in welchen Mitgliedstaaten der Dienst erbracht wird. Änderungen sind unverzüglich, spätestens zwei Wochen nach Kenntnis zu übermitteln (§ 33 Abs. 5 BSIG). Betreiber kritischer Anlagen registrieren sich abweichend nach § 8 KRITIS-Dachgesetz (§ 33 Abs. 2 BSIG); kommt eine Einrichtung ihrer Registrierungspflicht nicht nach, kann das BSI die Registrierung selbst vornehmen (§ 33 Abs. 3 BSIG).

Vom laufenden Nachweis ist die Registrierung strikt zu trennen — und hier weichen die Rechtsräume deutlich voneinander ab. In Deutschland trifft die turnusmäßige Nachweispflicht durch Sicherheitsaudits, Prüfungen oder Zertifizierungen nach § 39 Abs. 1 BSIG in erster Linie Betreiber kritischer Anlagen: zu einem vom BSI festgelegten Zeitpunkt, frühestens drei Jahre nachdem sie erstmals als Betreiber einer kritischen Anlage gelten, und anschließend alle drei Jahre; zu übermitteln sind die Ergebnisse einschließlich aufgedeckter Sicherheitsmängel. Für die übrigen besonders wichtigen und wichtigen Einrichtungen gilt jedenfalls die Dokumentationspflicht nach § 30 Abs. 1 BSIG. In Österreich gilt ein anderes Modell: Wesentliche und wichtige Einrichtungen übermitteln der Cybersicherheitsbehörde binnen zwölf Monaten nach Eintritt der Registrierungspflicht strukturierte Informationen zu den umgesetzten Risikomanagementmaßnahmen (Selbstdeklaration, § 33 Abs. 1 NISG 2026); auf Aufforderung ist die Umsetzung binnen zwei Jahren durch eine unabhängige Stelle nachzuweisen, wobei wesentliche Einrichtungen die operative und organisatorische Umsetzung bereits binnen zwei Monaten nach Aufforderung belegen müssen (§ 33 Abs. 2 NISG 2026). Die erstmalige Aufforderung kann frühestens zwei Jahre nach Inkrafttreten erfolgen, also ab dem 01.10.2028.

Unterschiedlich ist außerdem die Aufsichtsintensität: Nach der Systematik der NIS-2-Richtlinie unterliegen wesentliche Einrichtungen einer proaktiven Aufsicht, wichtige Einrichtungen einer Ex-post-Aufsicht. Zuständig ist in Deutschland das BSI als Bundesoberbehörde im Geschäftsbereich des Bundesministeriums des Innern und zentrale Stelle für Informationssicherheit auf nationaler Ebene (§ 1 BSIG). In Österreich ist es das Bundesamt für Cybersicherheit (Cybersicherheitsbehörde), eine dem Bundesminister für Inneres unmittelbar nachgeordnete Behörde mit bundesweiter Zuständigkeit und Sitz in Wien (§ 3a Abs. 1 und 2, § 3b Abs. 3 NISG 2026); Aufsicht und Durchsetzung folgen den §§ 38 und 39 NISG 2026. Die Registrierung erfolgt dort bei der Cybersicherheitsbehörde binnen drei Monaten ab Inkrafttreten, also bis Ende 2026 (§ 29 Abs. 2 und 3 NISG 2026); zu übermitteln sind unter anderem Sektor und Teilsektor nach Anlage 1 oder 2, die Mitgliedstaaten der Diensterbringung, die Hauptniederlassung und Angaben zu den Schwellenwerten. Änderungen der Kerndaten sind binnen zwei Wochen nachzumelden (§ 29 Abs. 4 NISG 2026). Konzernstrukturen mit deutscher und österreichischer Gesellschaft müssen sich in beiden Ländern separat registrieren.

8. Geschäftsleitung und Bußgeldrahmen

Die Verantwortung für die Risikomanagementmaßnahmen liegt bei der Geschäftsleitung selbst: § 38 Abs. 1 BSIG verpflichtet sie, die Maßnahmen nach § 30 umzusetzen und ihre Umsetzung zu überwachen — beides, nicht nur das eine. Verletzt sie diese Pflichten, haftet sie ihrer Einrichtung für einen schuldhaft verursachten Schaden nach den Regeln des für die Rechtsform geltenden Gesellschaftsrechts; nach dem BSIG selbst haftet die Geschäftsleitung nur subsidiär, nämlich wenn das maßgebliche Gesellschaftsrecht keine solche Haftungsregelung enthält (§ 38 Abs. 2 Satz 2 BSIG). Hinzu kommt die Pflicht zur regelmäßigen Teilnahme an Schulungen (§ 38 Abs. 3 BSIG); das Gesetz sagt „regelmäßig" — die konkrete Taktung ist eine Praxisentscheidung, keine gesetzliche Frist.

Der Unterschied zwischen den Rechtsräumen ist feiner, als er wirkt. Anders als die Richtlinie kennt das BSIG kein pauschales „höherer Wert gilt": Die Umsatzvariante greift nur ab einem Gesamtumsatz von mehr als 500 Mio. EUR und nur für die in § 65 Abs. 6 und 7 BSIG bezeichneten Verstöße. Gesamtumsatz ist dabei die Summe aller weltweiten Umsatzerlöse des Unternehmens, dem die Einrichtung angehört, im Geschäftsjahr vor der Behördenentscheidung (§ 65 Abs. 8 BSIG). Hat eine Datenschutzaufsichtsbehörde für dasselbe Verhalten bereits ein DSGVO-Bußgeld verhängt, ist eine zusätzliche Geldbuße nach dem BSIG ausgeschlossen (§ 65 Abs. 11 BSIG) — für Cloud-Anbieter ein praktisch bedeutsamer Berührungspunkt, weil derselbe Vorfall häufig zugleich personenbezogene Daten betrifft. Österreich übernimmt dagegen die EU-Maxima einschließlich der Regel „je nachdem, welcher Betrag höher ist"; verhängt werden die Verwaltungsstrafen dort von der Bezirksverwaltungsbehörde (§ 44 Abs. 1 NISG 2026), während die Aufsicht bei der Cybersicherheitsbehörde bleibt. Für die Leitungsorgane schreibt § 31 Abs. 1 und 2 NISG 2026 vor, die Einhaltung der Risikomanagementmaßnahmen sicherzustellen und zu beaufsichtigen sowie an Cybersicherheitsschulungen teilzunehmen; eine ausdrückliche Innenhaftungs-Regel analog § 38 Abs. 2 BSIG enthält das NISG 2026 nicht.

9. Praxis-Fahrplan für Cloud- und SaaS-Anbieter

Der Fahrplan hat neun Schritte — von der Prüfung der Legaldefinition über Registrierung, Geschäftsleitungsbeschluss und Maßnahmenpaket bis zur separaten österreichischen Gesellschaft; jeder Schritt liefert die Grundlage des nächsten. Er ist eine Praxisempfehlung, keine gesetzliche Fristenkette — gesetzlich fixiert sind allein die Fristen, die die Spalte „Charakter" ausdrücklich als solche ausweist.

Praxis-Rhythmen (Erfahrungswerte aus der Umsetzung, keine gesetzlichen Fristen): jährliche Schulung aller Mitarbeitenden mit Lernerfolgskontrolle, Onboarding-Schulung neuer Beschäftigter in den ersten vier Wochen, quartalsweise Phishing-Simulation mit Auswertung der Klickrate, jährlicher Penetrationstest, internes Audit sowie externes Audit alle zwei Jahre und quartalsweises Reporting der Wirksamkeitskennzahlen an die Geschäftsleitung. Gesetzlich vorgegeben ist an dieser Stelle, dass Schulungen und eine Wirksamkeitsbewertung stattfinden (§ 30 Abs. 2 Nr. 6 und 7 BSIG; § 32 Abs. 4 NISG 2026) — den Takt bestimmt die Einrichtung risikobasiert selbst.