Bildquelle: Foto von RDNE Stock project auf Pexels / https://www.pexels.com/photo/a-person-writing-on-white-printer-paper-9034261/
Zwischen ISO 22301 und ITSCM zeigt erst die Übung, ob kritische Serviceabhängigkeiten wirklich bekannt sind
ISO 22301 ist die internationale Norm für Business Continuity Management Systeme. Sie beschreibt, wie Organisationen kritische Abläufe auf Störungen vorbereiten, Ausfälle bewerten, Wiederanlauf planen und die Wirksamkeit ihrer Vorkehrungen regelmäßig überprüfen. Für IT-Teams ist das Thema relevant, weil geschäftliche Kontinuität heute fast immer an digitalen Services, Lieferanten, Identitäten, Datenflüssen und Betriebsabläufen hängt.
Genau daran hapert es in vielen Organisationen. Die Norm ist gekauft, ein Notfallhandbuch liegt in SharePoint, die Fachbereiche haben eine Business-Impact-Analyse und die Infrastruktur betreibt Backups sowie sekundäre Standorte. Trotzdem zeigt schon eine einfache Übung oft, dass wichtige Voraussetzungen fehlen. Kontaktketten sind veraltet, ein kritischer SaaS-Dienst hängt an einem einzigen Identitätsprovider, der alternative Kommunikationsweg ist nicht geprobt und die Recovery-Reihenfolge passt nicht zur echten Serviceabhängigkeit. Auf dem Papier wirkt die Lage kontrolliert, im Ablauf ist sie es nicht.
Der Grund ist selten mangelnder Fleiß. Häufiger liegt das Problem darin, dass Business Continuity und ITSCM in getrennten Sprachen arbeiten. Das BCM-Team denkt in kritischen Prozessen, Maximalschäden und Führungsreaktion. Die IT denkt in Plattformen, Datenbanken, Cloud-Abhängigkeiten, Runbooks und Change-Fenstern. Solange diese beiden Sichten nicht an denselben Services zusammenlaufen, bleibt Kontinuität eine sauber dokumentierte, aber nur begrenzt belastbare Disziplin.
Kontinuität scheitert selten am Backup, sondern an der Übersetzung in Services
Viele technische Teams setzen Business Continuity noch immer fast automatisch mit Disaster Recovery gleich. Das ist verständlich, aber zu kurz. Backups, Replikation, Ausweichstandorte und Failover-Prozesse sind wichtige Bausteine, doch sie beantworten noch nicht die geschäftlich entscheidende Frage: Welcher Service muss wann in welcher Mindestqualität wieder laufen?
Genau hier beginnt die Arbeit von ITSCM. Ein kritischer Geschäftsprozess wird nicht durch irgendeinen Server erbracht, sondern durch eine Kombination aus Fachanwendung, Identitätsdiensten, Netzwerk, Datenbank, Schnittstellen, Lieferanten, Supportwegen und oft auch manuellen Ersatzverfahren. Wenn nur die technische Plattform betrachtet wird, entstehen typische Fehleinschätzungen. Dann gibt es vielleicht ein gutes Datenbank-Failover, aber keinen getesteten Weg, wie Fachbereiche während des Ausfalls priorisiert arbeiten. Oder ein SaaS-Anbieter verspricht hohe Verfügbarkeit, während niemand intern festgelegt hat, welche Services bei längerer Störung zuerst umgestellt, kommuniziert oder vorübergehend vereinfacht werden müssen.
Die Praxis zeigt deshalb immer wieder: Je stärker IT-Services aus Cloud, SaaS und externen Plattformbausteinen zusammengesetzt sind, desto wichtiger wird eine saubere Übersetzung von BCM-Zielen in echte Servicebilder. Ohne diese Übersetzung wirken RTO und RPO oft präziser, als sie im Alltag tatsächlich sind.
Die wichtigste Lücke liegt meist in Abhängigkeiten und Reihenfolgen
Wenn Kontinuitätsprogramme scheitern, liegt es oft nicht am Fehlen einzelner Dokumente, sondern an falschen oder unvollständigen Abhängigkeiten. Ein Service gilt als kritisch, weil er unmittelbar Umsatz, Versorgung oder öffentliche Leistung stützt. In der Recovery-Planung taucht er dann trotzdem nur als Anwendungseintrag auf. Seine Abhängigkeit von Identitätsdiensten, MDM, DNS, Zertifikaten, Messaging, externen APIs oder Freigabeketten bleibt unscharf. Genau dadurch entstehen in Übungen böse Überraschungen.
Ein klassisches Beispiel ist die Reihenfolge des Wiederanlaufs. Teams testen eine Anwendung erfolgreich im isolierten Failover und merken erst später, dass der Zugriff auf Stamm- oder Referenzdaten, die Authentisierung privilegierter Konten oder ein externer Zahlungs- beziehungsweise Registerdienst im Szenario gefehlt hat. Der eigentliche Service wäre also trotz funktionierender Kernanwendung noch nicht arbeitsfähig gewesen. Für das Management ist das ein wichtiger Unterschied: verfügbar ist nicht dasselbe wie betriebsfähig.
Deshalb sollte ITSCM nicht nur Systeme inventarisieren, sondern Serviceketten sichtbar machen. Welche gemeinsamen Plattformdienste tragen mehrere kritische Services zugleich? Welche Lieferanten oder Subdienstleister bilden verdeckte Konzentrationsrisiken? Welche manuellen Übergänge sind für den Notbetrieb unverzichtbar? Und welche Änderungen im Tagesgeschäft verschieben unbemerkt die Wiederanlaufreihenfolge?
Übungen sind der Lackmustest für ISO 22301 in der IT
Die ISO-22301-Logik lebt nicht von schönen Ordnerstrukturen, sondern von Review, Test und kontinuierlicher Verbesserung. Genau deshalb sind Übungen so wertvoll. Sie zwingen Organisationen dazu, Annahmen in Verhalten zu übersetzen. Eine Liste von Ansprechpartnern ist nur dann belastbar, wenn sie in einer Störung erreichbar ist. Ein Runbook ist nur dann nützlich, wenn Rollen, Berechtigungen und Vorbedingungen im Szenario wirklich funktionieren. Ein Ausweichprozess ist nur dann ein echter Ausweichprozess, wenn Fachbereich, Kommunikation, Dienstleister und Technik denselben Takt halten.
Viele Häuser üben allerdings zu klein. Sie testen das Recovery eines einzelnen Systems, aber nicht die Führungs- und Entscheidungslogik rundherum. Oder sie simulieren nur einen Infrastrukturausfall, obwohl wahrscheinlicher ein Mischszenario aus Cyberangriff, Lieferantenausfall, Identitätsproblem oder beschädigten Daten wäre. Das Ergebnis ist ein trügerisches Sicherheitsgefühl. Die Technik hat einen Teil des Szenarios bestanden, der Service als Ganzes aber noch nicht.
Gute Übungen arbeiten deshalb entlang realer Servicefragen. Wer priorisiert Wiederanlauf bei konkurrierenden Engpässen? Welche Kommunikationswege greifen, wenn Standardwerkzeuge betroffen sind? Welche Lieferanten müssen in welchem Zeitfenster reagieren? Welche Ersatzverfahren dürfen Fachbereiche tatsächlich anwenden? Und welche Entscheidung braucht Managementfreigabe, bevor der Notbetrieb in den Regelbetrieb zurückgeführt wird? Erst solche Fragen machen Kontinuität belastbar.
Lieferanten und SaaS gehören in den Kern des Kontinuitätsmodells
Mit Hybrid-IT und SaaS verschiebt sich die Kontinuitätsarbeit deutlich. Früher ließ sich ein großer Teil der Diskussion innerhalb der eigenen Infrastruktur führen. Heute hängen kritische Services oft an Plattformanbietern, Identitätsdiensten, Kollaborationswerkzeugen, Netzprovidern, Zahlungs- oder Registerdiensten und spezialisierten Managed Services. Damit wird Supplier Management zu einem festen Bestandteil von ITSCM.
Operativ heißt das: Verträge, Eskalationswege, Supportfenster, Datenexporte, Wiederanlaufannahmen und Exit- beziehungsweise Ersatzszenarien müssen zur Kritikalität des jeweiligen Service passen. Ein Lieferant mit hoher Verfügbarkeit ist noch kein belastbarer Kontinuitätsbaustein, wenn bei längerer Störung unklar bleibt, wie Daten exportiert, Nutzer informiert oder manuelle Prozesse aktiviert werden. Ebenso problematisch ist ein formal vorhandener Exit-Plan, der zwar den Vertragsordner füllt, aber nicht in Runbooks, Servicekatalog und Krisenkommunikation anschließt.
Gerade hier lohnt sich die enge Verbindung zwischen BCM, Supplier Management und Service-Ownern. Kontinuität ist kein Infrastrukturthema mehr, das man isoliert im Rechenzentrum lösen könnte. Sie hängt daran, ob interne und externe Leistungsteile gemeinsam geführt werden.
Was IT-Leitungen jetzt konkret verbessern sollten
- Mit Services statt mit Einzelkomponenten beginnen: Kritische Geschäftsleistungen zuerst als echte Serviceketten beschreiben, nicht nur als Anwendungs- oder Serverlisten.
- RTO und RPO begründen: Wiederanlauf- und Datenziele nicht historisch übernehmen, sondern an reale Geschäftsfolgen und Abhängigkeiten koppeln.
- Übungen größer denken: Nicht nur Technik-Failover testen, sondern Führungswege, Lieferantenreaktion, Kommunikationsmittel und manuelle Ersatzverfahren einbeziehen.
- Änderungen rückkoppeln: Größere Architektur-, IAM-, Netzwerk-, SaaS- oder Provider-Änderungen müssen Kontinuitätsannahmen sichtbar aktualisieren.
- Gemeinsame Datenbasis schaffen: Business-Impact-Analyse, Servicekatalog, Lieferanteninventar und Recovery-Runbooks dürfen nicht voneinander abweichen.
- Nach jeder Übung echte Korrekturen erzwingen: Kontinuität reift erst, wenn Findings zu Rollen, Abhängigkeiten und Wiederanlaufreihenfolge verbindlich nachgezogen werden.
Fazit
ISO 22301 schafft für Business Continuity einen sinnvollen Rahmen, aber der operative Wert entsteht in der IT erst dort, wo kritische Prozesse auf konkrete Services, Abhängigkeiten und Übungen treffen. Genau an dieser Stelle trennt sich gut dokumentierte Vorsorge von echter Resilienz. Wenn Teams nur Backups und Notfallordner pflegen, ohne Wiederanlaufreihenfolge, Lieferantenbezug, Identitätsabhängigkeiten und manuelle Ersatzwege gemeinsam zu prüfen, bleibt das Programm lückenhaft.
Für CIOs, Service-Owner, BCM-Verantwortliche und Betriebsleitungen lautet die entscheidende Frage deshalb nicht, ob ein Kontinuitätsdokument vorhanden ist. Die bessere Frage ist, ob eine realistische Übung zeigen würde, dass die kritischen Serviceabhängigkeiten tatsächlich bekannt, priorisiert und handhabbar sind. Genau dort beginnt belastbare IT-Kontinuität.
