Was passiert, wenn der IT-Dienstleister ausfällt?

In Lieferketten-Analysen steht fast immer dieselbe Frage im Mittelpunkt: Kann über einen Dienstleister ein Angriff in unser Unternehmen laufen? Das ist die richtige Frage. Sie ist nur nicht die einzige.

Die zweite lautet: Was passiert, wenn dieser Dienstleister ausfällt — ohne dass wir angegriffen wurden?

Was passiert, wenn der IT-Dienstleister ausfällt?

Zugänge, Know-how und Wiederanlauf hängen dann an einer Organisation, die gerade nicht liefert. Wer administriert die Firewall, wenn niemand mehr abhebt? Wer kennt das Passwort zum Hypervisor? Wo liegt das Backup, und hat es schon einmal jemand aus dem eigenen Haus zurückgespielt? § 32 Abs. 4 lit. c NISG 2026 verlangt die Aufrechterhaltung des Betriebs samt Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement; lit. d verlangt die Sicherheit der Lieferkette. Der Ausfall eines zentralen Dienstleisters liegt genau im Schnittpunkt beider Pflichten — und damit auf dem Tisch der Geschäftsführung.

Drei Ausfallarten, ein Effekt

Für die Wirkung auf dein Unternehmen ist die Ursache zweitrangig. Drei Wege führen zum selben Zustand:

• Der Dienstleister wird selbst angegriffen. Er ist mit der eigenen Wiederherstellung beschäftigt. Deine Tickets bleiben liegen, obwohl bei dir technisch nichts passiert ist.
• Der Dienstleister fällt wirtschaftlich aus. Insolvenz, Übernahme, Rückzug aus dem Geschäftsfeld. Verträge laufen formal weiter, die Menschen, die dein System kennen, sind weg.
• Die Zusammenarbeit endet im Streit. Preiserhöhung, Qualitätsmängel, Vertrauensbruch. Du willst wechseln und merkst, dass der Wechsel an Zugängen und Dokumentation hängt, die du nicht hast.

Der dritte Fall ist der häufigste und der am schlechtesten vorbereitete. Er fühlt sich wie ein kaufmännisches Thema an und wirkt doch als Verfügbarkeitsrisiko.

Was NIS2, NISG 2026 und ISO 27001 dazu verlangen

Die Pflicht liegt auf drei Ebenen, die zusammenwirken.

Die europäische Ebene. Die NIS2-Richtlinie (EU) 2022/2555 nennt in Artikel 21 Abs. 2 die Mindestbereiche des Risikomanagements. Litera c deckt die Aufrechterhaltung des Betriebs ab, Litera d die Sicherheit der Lieferkette einschließlich der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern.

Die österreichische Ebene. § 32 Abs. 4 NISG 2026 (BGBl. I Nr. 94/2025, in Kraft ab 1. Oktober 2026) übernimmt diese Systematik im selben Buchstabenschema. Lit. c: Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement. Lit. d: Sicherheit der Lieferkette, ausdrücklich unter Berücksichtigung der spezifischen Schwachstellen der einzelnen unmittelbaren Anbieter. Wie weit die Maßnahmen zu gehen haben, bemisst sich nach § 32 Abs. 3 an Risikoexposition, Unternehmensgröße und der Schwere möglicher Vorfälle.

Die operative Ebene. ISO 27001:2022 liefert die Controls, mit denen sich das im ISMS abbilden lässt: A.5.19 bis A.5.22 für die Lieferantenbeziehung von der Auswahl über den Vertrag bis zur laufenden Überwachung, A.5.29 für Informationssicherheit während einer Störung und A.5.30 für die IKT-Bereitschaft zur Betriebskontinuität.

Der Nachweis wird später konkret: Nach § 33 Abs. 1 NISG 2026 erstreckt sich die Selbstdeklaration an die Cybersicherheitsbehörde ausdrücklich auch auf die Sicherheit der Lieferketten. Wer die Abhängigkeit von einem einzelnen Dienstleister nie erhoben hat, hat an dieser Stelle nichts zu berichten.

Konzentrationsrisiko sichtbar machen

Das Risiko entsteht nicht dadurch, dass du einen Dienstleister hast. Es entsteht dadurch, dass mehrere kritische Fähigkeiten bei genau einem liegen und niemand das je zusammengezählt hat. Vier Fragen reichen für den ersten Befund:

1. Welche Systeme administriert ausschließlich der Dienstleister? Nicht welche er betreut. Welche sonst niemand bedienen kann.
2. Welche Zugänge und Berechtigungen liegen nur bei ihm? Domain-Admin, Hypervisor, Firewall, Backup-Konsole, Cloud-Tenant, Domain-Registrar.
3. Welche Dokumentation existiert nur in seinen Systemen? Netzpläne, Passwort-Tresor, Lizenzübersicht, Wiederanlauf-Reihenfolge.
4. Wie lange wärt ihr ohne ihn handlungsfähig? In Stunden, nicht in Adjektiven.

Dazu gehört die Frage, wie viele deiner Lieferanten ihrerseits denselben Subdienstleister oder dieselbe Cloud-Plattform nutzen. Diese verdeckte Bündelung ist der Punkt, an dem aus mehreren scheinbar unabhängigen Partnern eine gemeinsame Schwachstelle wird. Die Systematik dahinter beschreibt der Beitrag zur Risikoklassifizierung zwischen Einkauf und Security; warum die Steuerung dieser Risiken auf der Leitungsebene liegt, steht in Lieferantenrisiken sind Chefsache.

Exit-Fähigkeit gehört in den Vertrag

Ein Vertrag, der nur den Normalbetrieb regelt, hilft im Ausfall wenig. Vier Punkte machen den Unterschied:

• Herausgabe von Daten und Konfigurationen in einem verwendbaren Format, mit Frist und ohne Zusatzverhandlung.
• Zweitzugang auf deiner Seite — mindestens ein administrativer Zugang je kritischem System, der dir gehört und regelmäßig getestet wird.
• Übergabepflicht bei Vertragsende, inklusive Dokumentation und einer definierten Mitwirkungszeit nach dem letzten Tag.
• Informationspflicht bei Vorfällen und bei Subunternehmer-Wechsel, damit du deine eigene Meldepflicht nach § 34 NISG 2026 überhaupt erfüllen kannst.

Welche Mindestbereiche ein Dienstleistervertrag nach NIS2 abdecken muss und wie sie auf ISO-27001-Controls abbilden, schlüsselt der Beitrag Drittparteienmanagement nach NIS2 — vom Vertrag bis zum Audit-Recht auf.

Der Test: Wiederanlauf ohne den Dienstleister

Alle bisherigen Punkte lassen sich auf dem Papier beantworten. Ob sie tragen, zeigt eine Übung. Das Szenario braucht keine Ransomware: Der Dienstleister hebt seit 48 Stunden nicht ab, und ein zentrales System muss wieder laufen.

Was dabei regelmäßig sichtbar wird: Der Passwort-Tresor liegt beim Dienstleister. Die Backup-Rücksicherung hat noch nie jemand aus dem eigenen Haus durchgeführt. Und die Frage, wer die Ersatzbeschaffung freigeben darf, ist bis in die Geschäftsführung ungeklärt. Wie so eine Übung in 45 Minuten aufgesetzt wird, zeigt Eine Tabletop Exercise zeigt, was kein Audit zeigt.

Fazit

Der Ausfall des IT-Dienstleisters ist ein Verfügbarkeitsrisiko mit oft kaufmännischer Ursache. § 32 Abs. 4 lit. c und lit. d NISG 2026 machen ihn zum Bestandteil des Risikomanagements, § 33 Abs. 1 zum Gegenstand der Selbstdeklaration. Die Arbeit daran ist überschaubar: Abhängigkeiten erheben, Zweitzugänge sichern, Exit-Klauseln nachziehen, einmal üben.

Wer den Ausgangsbefund strukturiert erheben will, findet ihn im Cyber Reality Check; wer den Nachweis gegenüber einem Großkunden führen muss, im IT-Sicherheitsnachweis. Die laufende Steuerung dieser Abhängigkeiten ist eine der Kernaufgaben, die ein externer CISO übernimmt — entschieden wird sie in der Geschäftsführung.

---

Quellen-Stack dieses Beitrags

1. ✅ NIS2-Richtlinie (EU) 2022/2555, Art. 21 Abs. 2 lit. c und lit. d — wortlaut-verifiziert gegen quellen/NISG2026_CELEX_32022L2555_EN_TXT.pdf (31.08.2026). Lit. c: „business continuity, such as backup management and disaster recovery, and crisis management“; lit. d: „supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers“.
2. NISG 2026 (BGBl. I Nr. 94/2025), § 32 Abs. 1/3/4 lit. c und lit. d, § 33 Abs. 1, § 34 — verifiziert gegen quellen/nisg-2026-paragraph-32-risikomanagement.md
3. ✅ ISO/IEC 27001:2022 Annex A — Control-Nummern und Titel verifiziert gegen quellen/CIS ISO_IEC_27001_2022(en).pdf (31.08.2026): A.5.19 Information security in supplier relationships, A.5.20 Addressing information security within supplier agreements, A.5.21 Managing information security in the ICT supply chain, A.5.22 Monitoring, review and change management of supplier services, A.5.29 Information security during disruption, A.5.30 ICT readiness for business continuity.