Praxisorientierte Einordnung zu BCM, ITSCM und Disaster Recovery: Zuständigkeiten sauber trennen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Business Continuity Management aufbauen.
Business Continuity Management, IT Service Continuity Management und Disaster Recovery verfolgen ein gemeinsames Ziel: kritische Leistungen trotz Störung aufrechterhalten oder rechtzeitig wiederherstellen. Trotzdem sind sie nicht identisch. BCM steuert die Kontinuität aus Geschäftssicht. ITSCM übersetzt Anforderungen in die Kontinuität von IT-Services. Disaster Recovery organisiert den technischen Wiederanlauf nach schwerwiegenden Ausfällen.
Unklare Zuständigkeiten erzeugen Doppelarbeit und Lücken. Der Fachbereich erwartet eine Wiederherstellung, die nie technisch bestätigt wurde. Die IT testet Systeme, ohne fachliche Mindestleistungen zu kennen. Der DR-Plan endet beim Serverstart, während BCM von vollständiger Kundenfähigkeit ausgeht. Dieser Vergleich entwickelt eine klare Aufgabenteilung und zeigt die verbindenden Übergaben.
BCM: Geschäftsfähigkeit und Priorität
BCM betrachtet Produkte, Dienstleistungen, Geschäftsaktivitäten und Ressourcen. Es analysiert zeitabhängige Auswirkungen, legt Mindestbetriebsniveau fest, entwickelt Kontinuitätsstrategien und organisiert Krisen- sowie Ersatzverfahren. Die Verantwortung liegt bei Leitung und Geschäftsbereichen, unterstützt durch eine BCM-Funktion.
BCM beantwortet: Welche Leistungen müssen wann wieder verfügbar sein? Welche Folgen sind nicht akzeptabel? Welche manuellen, personellen, räumlichen oder lieferantenseitigen Alternativen existieren? Welche Priorität gilt bei knappen Ressourcen?
ITSCM: Kontinuität der unterstützenden IT-Services
IT Service Continuity Management übersetzt geschäftliche Anforderungen in Service-Architektur, Wiederherstellungsoptionen, technische Zielwerte und Pläne. Es betrachtet einen IT-Service Ende-zu-Ende, einschließlich Anwendungen, Infrastruktur, Identität, Daten, Netzwerk und Anbieter.
ITSCM beantwortet: Welche IT-Services unterstützen die priorisierte Leistung? Welche Verfügbarkeit und Wiederaufnahme sind erforderlich? Welche Strategie erfüllt RTO, RPO, Kapazität und Sicherheit? Wie werden Servicekontinuität und Changes dauerhaft gesteuert?
Disaster Recovery: technischer Wiederanlauf
Disaster Recovery führt konkrete Wiederherstellungsaktivitäten aus. Dazu gehören Aktivierung einer Ersatzumgebung, Aufbau von Infrastruktur, Restore von Daten, Wiederherstellung von Identitäten, Verbindung von Schnittstellen, technische Validierung und Rückkehr.
DR beantwortet: Wie wird eine definierte Umgebung nach einem schweren Ausfall praktisch wiederhergestellt? In welcher Reihenfolge werden Komponenten aufgebaut? Wer führt Schritte aus, welche Sicherheitsgrenzen gelten und wie wird Erfolg nachgewiesen?
Incident Response und Krisenmanagement ergänzen das Modell
Bei Cyberereignissen analysiert und begrenzt Incident Response den Angriff. Krisenmanagement trifft übergreifende Entscheidungen und steuert Kommunikation. Diese Funktionen überschneiden sich nicht vollständig mit BCM, ITSCM oder DR, müssen aber verbunden sein.
Ein Recovery darf beispielsweise erst beginnen, wenn ein geeigneter Wiederherstellungspunkt und eine saubere Umgebung bestimmt sind. Der Krisenstab kann priorisieren, welcher Service zuerst kommt. BCM aktiviert Ersatzverfahren, während Technik untersucht und wiederherstellt.
Direkter Vergleich der Verantwortungsbereiche
| Frage | BCM | ITSCM | Disaster Recovery |
|---|---|---|---|
| Primärer Gegenstand | Geschäftsleistung und Aktivität | IT-Service | Technische Umgebung und Komponenten |
| Hauptverantwortung | Leitung und Fachbereiche | IT-Service- und Continuity-Verantwortung | Recovery Lead und technische Teams |
| Zentrale Analyse | Business Impact Analyse | Service- und Risikoanalyse | Abhängigkeit und technische Wiederherstellung |
| Typisches Ziel | Mindestleistung innerhalb fachlicher Grenze | IT-Service innerhalb vereinbarter Ziele | Systeme und Daten kontrolliert wiederherstellen |
| Abnahme | fachlicher Service Owner | IT-Service Owner | technische und sicherheitliche Prüfer |
Die Grenzen sind in der Praxis durchlässig, müssen aber an Übergaben eindeutig werden. BCM priorisiert den geschäftlichen Bedarf, ITSCM übersetzt ihn in Serviceziele und Disaster Recovery stellt technische Fähigkeiten bereit. Gemeinsame Übungen zeigen, ob Entscheidungen, Informationen und Abnahmen zwischen diesen Ebenen funktionieren.
Der gemeinsame Bezugsrahmen ist der Geschäftsservice
Alle drei Ebenen sollten dieselbe Service-Landkarte verwenden. BCM beschreibt die Kunden- oder Unternehmensleistung. ITSCM ordnet IT-Services zu. DR zerlegt diese in wiederherzustellende Komponenten. Eindeutige Identifikatoren und Eigentümer erleichtern die Verknüpfung.
Ohne gemeinsamen Bezug entstehen widersprüchliche Inventare. Ein Fachprozess heißt anders als der IT-Service, der wiederum mehrere Systemnamen umfasst. Im Ereignis kostet diese Übersetzung Zeit. Pflegen Sie Beziehungen zentral und prüfen Sie sie nach Änderungen.
Übergabe 1: Von der BIA zu IT-Anforderungen
Die BIA liefert Mindestleistung, zeitliche Grenze, Wiederaufnahmeziel, Datenanforderung, Nutzer und Abhängigkeiten. ITSCM übersetzt dies in Service-RTO, Service-RPO, Kapazität, Verfügbarkeit und technische Anforderungen.
Die Übersetzung ist kein blindes Weiterreichen. Fachliches Ziel und technische Machbarkeit werden abgeglichen. Wenn ein Ziel nicht erreichbar oder wirtschaftlich unverhältnismäßig ist, erhält die Leitung Optionen: Architektur verbessern, Ersatzverfahren stärken oder Risiko akzeptieren.
Übergabe 2: Vom IT-Service zur Recovery-Architektur
ITSCM wählt oder steuert Strategien wie Redundanz, Zweitumgebung, Wiederaufbau oder Anbieterleistung. Disaster Recovery konkretisiert Reihenfolge, Runbooks, Zugänge, Daten, Werkzeuge und technische Freigaben.
Die DR-Architektur muss den gesamten Service abdecken. Ein einzelner Datenbank-Restore genügt nicht, wenn Identität, Netzwerk und Schnittstellen fehlen. Service Owner und Recovery Lead bestätigen Abhängigkeiten und Testumfang.
Übergabe 3: Von technischer Recovery zur fachlichen Wiederaufnahme
DR meldet technische Bereitschaft und Sicherheitsstatus. ITSCM prüft den IT-Service Ende-zu-Ende. Der Fachbereich führt repräsentative Geschäftstests aus und bestätigt das Mindestniveau. Erst danach gilt die Leistung als wiederaufgenommen.
Definieren Sie Kriterien und Protokoll. Ein eingeschränkter Betrieb kann akzeptiert werden, wenn Rest-Risiken, fehlende Funktionen und Dauer transparent sind. Die Entscheidung liegt beim zuständigen Owner beziehungsweise Krisengremium.
Wer legt RTO und RPO fest?
Der Fachbereich begründet Geschäftstoleranz und Datenfolgen. BCM moderiert und kalibriert. ITSCM bewertet Servicekonsequenzen und technische Optionen. DR liefert gemessene Wiederherstellungszeiten und praktische Grenzen.
Keiner der Beteiligten sollte den Wert allein bestimmen. Ein Fachbereich kann keinen technisch unbegründeten Null-Ausfall anordnen; die IT darf ein Ziel nicht nur aus vorhandener Backup-Frequenz ableiten. Die Leitung entscheidet über Abweichung und Investition.
Wer verantwortet Notfallpläne?
BCM verantwortet Rahmen, Methodik und fachliche Kontinuitätspläne. Fachbereiche besitzen ihre Ersatzverfahren. ITSCM verantwortet IT-Service-Continuity-Pläne und Strategien. DR-Runbooks gehören den technischen Ausführungsverantwortlichen.
Ein zentrales Dokumentenmanagement sorgt für Version, Zugriff und Notfallverfügbarkeit. Vermeiden Sie Kopien derselben Kontaktdaten und Ziele in mehreren Dateien. Verlinken Sie auf eine kontrollierte Quelle.
Wer aktiviert welche Struktur?
Definieren Sie Auslöser für BCM-/Krisenorganisation, IT-Service-Continuity und DR. Ein technischer Ausfall kann DR aktivieren, ohne eine Unternehmenskrise zu sein. Ein personeller oder Lieferantenausfall kann BCM aktivieren, ohne technische Recovery. Ein Cyberangriff kann alle Ebenen betreffen.
Eine Aktivierungsmatrix enthält Schwellen, Entscheider, Alarmierungsweg und Eskalation. Die Strukturen teilen ein Lagebild, behalten aber klare Führung. Testen Sie Übergänge in Tabletop Exercises.
Wer steuert externe Anbieter?
Einkauf und Lieferantenmanagement gestalten Vertrag und Governance. BCM bewertet geschäftliche Konzentration und Alternativen. ITSCM definiert Serviceanforderungen. DR kennt technische Aktivierung und Wiederherstellung. Incident Response regelt gegebenenfalls Untersuchungszugriff.
Benennen Sie im Ereignis einen internen Owner je Anbieter. Mehrere parallele Anfragen erzeugen Widersprüche. Verträge und Supportwege müssen außerhalb des ausgefallenen Systems verfügbar sein.
Wer kommuniziert im Ereignis?
Technische Teams liefern Fakten und Prognosen. Service Owner übersetzen Auswirkungen. BCM oder Krisenstab konsolidiert das Lagebild. Unternehmenskommunikation steuert interne und externe Aussagen mit Recht und Datenschutz.
DR sollte keine eigenständige Kundenkommunikation betreiben. Ebenso darf Kommunikation keine technische Wiederherstellungszeit versprechen, die nicht bestätigt wurde. Definierte Lagezyklen halten Aussagen synchron.
RACI-Beispiel für zentrale Aufgaben
Bei der BIA ist der Geschäfts-Owner verantwortlich, BCM methodisch zuständig, ITSCM konsultiert. Bei der Service-Strategie ist ITSCM verantwortlich, Fachbereich und BCM werden konsultiert, die Leitung genehmigt wesentliche Risiken. Beim technischen Restore ist DR verantwortlich; Sicherheit, Service Owner und Fachbereich prüfen.
RACI darf nicht mehrere „Accountable“-Rollen pro Entscheidung erzeugen. Benennen Sie genau eine endgültig verantwortliche Rolle. Ergänzen Sie Vertretung und Eskalation, weil eine Matrix allein keine Erreichbarkeit schafft.
Testarten den Ebenen zuordnen
BCM testet Alarmierung, Krisenführung, Ersatzverfahren und fachliche Kontinuität. ITSCM testet Service-Failover, Abhängigkeiten und End-to-End-Zielwerte. DR testet technische Runbooks, Backup-Restore, Infrastrukturaufbau und sichere Wiederherstellung.
Integrierte Übungen verbinden die Ebenen. Ein technisches Team stellt isoliert wieder her, der Krisenstab priorisiert, BCM betreibt eine Alternative und der Fachbereich nimmt ab. Der Bericht trennt Ergebnisse je Fähigkeit.
Gemeinsame und getrennte Kennzahlen
Gemeinsam sind Zeit bis zur fachlichen Wiederaufnahme, erreichter Datenstand und Maßnahmenwirksamkeit. BCM misst zusätzlich Abdeckung kritischer Leistungen, Aktivierbarkeit von Workarounds und Erreichbarkeit. ITSCM misst Serviceziele und Abhängigkeiten. DR misst technische Schritte, Restore-Zeiten und Fehler.
Vermeiden Sie, technische Kennzahlen als Geschäftsergebnis zu berichten. Eine schnelle Datenbank ist nur ein Teil des RTO. Umgekehrt sollte BCM technische Engpässe nicht hinter einer allgemeinen Ampel verbergen.
Typische Organisationsmodelle
In kleineren Unternehmen können BCM und ITSCM von wenigen Rollen koordiniert werden, solange Verantwortlichkeiten klar bleiben. In größeren Organisationen existieren eigene Funktionen, Service Owner und Recovery Teams. Ein übergreifendes Resilienz-Gremium verbindet sie.
Das Modell ist weniger wichtig als die Übergabe. Zentralisierung kann Konsistenz schaffen, aber Fachverantwortung nicht ersetzen. Dezentralisierung kann Nähe erzeugen, braucht jedoch gemeinsame Methode und Steuerung.
Typische Konflikte und ihre Auflösung
Konflikt: Fachbereich verlangt kurze Zeit, IT meldet längere Recovery. Auflösung: gemessene Ist-Leistung, Architekturvarianten, Ersatzverfahren und Risikoentscheidung transparent machen.
Konflikt: DR erklärt Erfolg, Fachbereich kann nicht arbeiten. Auflösung: Endpunkt und Fachabnahme im RTO definieren.
Konflikt: BCM erwartet Lieferantenalternative, Einkauf kennt keine. Auflösung: Strategie in Sourcing, Vertrag und Test überführen.
Konflikt: Security verzögert Recovery. Auflösung: vorab abgestufte Sicherheitsfreigaben und eingeschränkten Betrieb definieren.
Ein Minimalmodell für mittelständische Unternehmen
Benennen Sie einen BCM-Koordinator, Service Owner für kritische Leistungen, ITSCM-Verantwortung und Recovery Leads für zentrale Plattformen. Nutzen Sie eine gemeinsame BIA-/Service-Landkarte, ein Zielwerte-Register und ein Maßnahmenregister.
Führen Sie quartalsweise ein Resilienz-Review durch. Mindestens jährlich verbindet eine Übung fachliche Kontinuität und technischen Wiederanlauf. Wesentliche Änderungen lösen gezielte Aktualisierung und Tests aus.
Ein 60-Tage-Klärungsprojekt
In Woche eins bis zwei werden bestehende Rollen, Pläne und Inventare aufgenommen. Wochen drei und vier gleichen kritische Leistungen mit IT-Services ab. Wochen fünf und sechs klären Zielwerte, Strategien und Lücken. Wochen sieben und acht prüfen Übergaben in einem Tabletop.
Das Ergebnis sind Rollenmodell, Service-Mapping, Aktivierungsmatrix, abgestimmte Ziele und priorisierte Maßnahmen. Es ersetzt nicht alle technischen Tests, schafft aber eine eindeutige Arbeitsgrundlage.
Fazit: Trennung schafft Klarheit, Verbindung schafft Resilienz
BCM verantwortet Geschäftspriorität und Kontinuität, ITSCM die Kontinuität unterstützender IT-Services und Disaster Recovery die technische Wiederherstellung. Die Disziplinen brauchen klare Grenzen, aber gemeinsame Services, Zielwerte, Lage und Tests.
BlackMount unterstützt Unternehmen beim Aufbau eines integrierten Business Continuity Managements mit sauberer ITSCM- und DR-Verknüpfung. Damit werden Zuständigkeiten ausführbar und Wiederanlaufziele Ende-zu-Ende nachweisbar.
