ITSCM und Hochverfügbarkeit richtig einordnen

Ein automatisches Failover kann einen Serverausfall in Sekunden abfangen. Es beantwortet jedoch nicht die Frage, wie ein kritischer Geschäftsprozess weiterarbeitet, wenn Daten logisch beschädigt sind, ein Rechenzentrum ausfällt oder wichtige Abhängigkeiten nicht verfügbar sind. Genau hier liegt der entscheidende Unterschied bei ITSCM versus Hochverfügbarkeit: Hochverfügbarkeit reduziert bestimmte technische Unterbrechungen. IT Service Continuity Management sichert die Wiederanlauf- und Wiederherstellungsfähigkeit geschäftskritischer IT-Services unter außergewöhnlichen Störungsbedingungen ab.

Für Verantwortliche aus IT, Informationssicherheit, Risikomanagement und Compliance ist diese Abgrenzung mehr als eine Begriffsfrage. Sie entscheidet darüber, ob Investitionen in Technik, Organisation und Notfallplanung tatsächlich die Geschäftsanforderungen erfüllen - und ob die Organisation im Ernstfall handlungsfähig bleibt.

ITSCM versus Hochverfügbarkeit: Zwei unterschiedliche Aufgaben

Hochverfügbarkeit bezeichnet eine technische Eigenschaft oder Architektur. Redundante Komponenten, Cluster, gespiegelte Systeme, mehrere Netzwerkpfade oder geografisch getrennte Betriebsstandorte sollen dafür sorgen, dass ein Service bei einem einzelnen Fehler weiterläuft oder nur kurz unterbrochen wird. Ziel ist eine möglichst hohe Verfügbarkeit im regulären Betrieb.

ITSCM ist dagegen ein Managementprozess innerhalb des Business Continuity Managements. Er verbindet kritische Geschäftsprozesse mit den dafür erforderlichen IT-Services, Ressourcen, Dienstleistern und Wiederanlaufverfahren. Ausgangspunkt ist nicht die Frage, welche Plattform technisch redundant betrieben werden kann. Ausgangspunkt ist die Frage, welche Auswirkungen ein IT-Ausfall auf das Unternehmen hätte und innerhalb welcher Zeit ein Service mit welcher Datenqualität wieder verfügbar sein muss.

Beide Disziplinen ergänzen sich. Hochverfügbarkeit kann eine wirksame Maßnahme sein, um enge Verfügbarkeitsziele zu erreichen. Sie ersetzt jedoch weder eine Business Impact Analyse noch Business Continuity Pläne, Wiederherstellungsverfahren, Krisenkommunikation oder regelmäßige Tests. Wer Hochverfügbarkeit als vollständige IT-Notfallvorsorge versteht, schafft leicht eine gefährliche Lücke zwischen technischem Anspruch und tatsächlicher Krisenfähigkeit.

Warum ein Failover kein IT-Notfallkonzept ist

Ein Failover funktioniert nur für Szenarien, die die zugrunde liegende Architektur berücksichtigt. Fällt ein einzelner Server aus, kann ein Cluster den Dienst übernehmen. Ist hingegen eine fehlerhafte Konfiguration auf alle Systeme repliziert worden, hilft die Redundanz möglicherweise nicht weiter. Das Gleiche gilt bei Ransomware, kompromittierten Administrationskonten, fehlerhaften Software-Releases oder einer Beschädigung konsistenter Datenbestände.

Auch räumliche Redundanz hat Grenzen. Zwei Standorte können durch dieselbe Lieferantenstörung, eine zentrale Identitätsplattform, eine gemeinsame Managementebene oder eine ungeplante Änderung betroffen sein. Häufig liegen kritische Abhängigkeiten außerhalb des eigentlichen Anwendungssystems: DNS, Zertifikate, Zeitdienste, Storage, Netzwerk, externe Schnittstellen, Betriebsdienstleister oder Schlüsselpersonen. ITSCM macht diese Abhängigkeiten sichtbar und bewertet sie im Zusammenhang mit der geschäftlichen Wirkung.

Hochverfügbarkeit ist zudem nicht zwangsläufig wirtschaftlich sinnvoll. Eine aktive aktive Architektur über mehrere Standorte kann für einen hochkritischen Echtzeitservice angemessen sein. Für ein System, das erst nach einigen Stunden wieder benötigt wird, sind gesicherte Backups, dokumentierte Wiederanlaufverfahren und ein getesteter Wiederherstellungsplatz unter Umständen die bessere Lösung. Die passende Vorsorge ergibt sich aus Risiko, Schadenspotenzial, regulatorischen Vorgaben und akzeptierter Unterbrechungszeit - nicht aus einem pauschalen Technikstandard.

Verfügbarkeit, Wiederanlauf und Wiederherstellung sauber trennen

Für eine belastbare Planung sollten drei Ziele getrennt betrachtet werden. Die Verfügbarkeit beschreibt, wie zuverlässig ein Service im Normalbetrieb erreichbar ist. Die Wiederanlaufzeit, häufig als RTO definiert, legt fest, wann ein ausgefallener Service nach einer schweren Störung wieder nutzbar sein muss. Der Recovery Point Objective, kurz RPO, bestimmt, welcher Datenverlust maximal akzeptabel ist.

Diese Werte entstehen nicht im Rechenzentrum, sondern aus den Anforderungen der Fachbereiche. Kann ein Auftragseingang vier Stunden ausfallen? Dürfen Buchungsdaten verloren gehen? Muss eine Kundenkommunikation weiterlaufen, auch wenn das führende System nicht verfügbar ist? Solche Fragen machen deutlich, dass technische Kennzahlen immer an geschäftliche Prioritäten gebunden sind.

Was ITSCM für kritische IT-Services leistet

ITSCM schafft einen nachvollziehbaren Rahmen, um IT-Notfallvorsorge dauerhaft zu steuern. Eine Business Impact Analyse identifiziert zunächst die zeitkritischen Geschäftsprozesse und deren Folgen bei Unterbrechung. Darauf aufbauend werden die unterstützenden IT-Services priorisiert und Wiederanlaufziele festgelegt.

Die eigentliche Arbeit beginnt danach. Für jeden relevanten Service müssen technische und organisatorische Abhängigkeiten erfasst werden: Anwendungen, Datenbanken, Infrastruktur, Berechtigungen, Schnittstellen, Betriebsprozesse, externe Provider und Verträge. Anschließend wird entschieden, welche Vorsorgestrategie die Ziele erfüllt. Das kann Hochverfügbarkeit sein, aber ebenso eine Backup- und Restore-Strategie, ein Warmstandby, ein manueller Ersatzprozess oder ein abgestimmtes Wiederanlaufverfahren.

Ein ITSCM-Konzept beschreibt außerdem Rollen, Eskalationswege und Entscheidungsbefugnisse. Im Ereignisfall müssen Teams nicht nur Systeme wiederherstellen, sondern Lagebilder bewerten, Prioritäten abstimmen, Fachbereiche informieren und gegebenenfalls den Krisenstab einbinden. Gerade bei komplexen Störungen entscheidet diese Zusammenarbeit oft stärker über die tatsächliche Ausfallzeit als die reine Leistungsfähigkeit einzelner Technologien.

Tests zeigen, ob Planung und Technik zusammenpassen

Ein dokumentierter Notfallplan ist noch kein Nachweis für Wiederherstellungsfähigkeit. Erst Tests und Übungen zeigen, ob Backups lesbar sind, Wiederanlaufreihenfolgen stimmen, Ansprechpartner erreichbar bleiben und Abhängigkeiten vollständig erfasst wurden. Besonders wertvoll sind Tests, die nicht nur den technischen Restore betrachten, sondern die Nutzbarkeit des Services aus Sicht des Fachbereichs prüfen.

Der Umfang muss zur Kritikalität passen. Ein hochkritischer Service benötigt häufig regelmäßige technische Wiederherstellungstests und abgestimmte Übungen mit Betrieb, Fachbereich und Krisenmanagement. Bei weniger kritischen Services können dokumentierte Reviews und gezielte Tests angemessen sein. Entscheidend ist, dass Ergebnisse in die Planung zurückfließen: Änderungen an Architektur, Lieferanten, Anwendungen oder Organisationsstrukturen müssen auch ITSCM-Unterlagen und Testkonzepte nachziehen.

Wann Hochverfügbarkeit die richtige Maßnahme ist

Hochverfügbarkeit ist besonders sinnvoll, wenn bereits kurze Unterbrechungen erhebliche Schäden verursachen oder sicherheitsrelevante Folgen haben. Beispiele sind zentrale Transaktionssysteme, Leit- und Steuerungsfunktionen, kritische Kommunikationsdienste oder Plattformen mit vertraglich zugesicherten sehr kurzen Reaktionszeiten. Voraussetzung ist jedoch, dass die Architektur konsequent auf die relevanten Fehlerbilder ausgelegt wird.

Dabei sind Kosten und Komplexität offen zu bewerten. Mehr Redundanz bedeutet meist mehr Komponenten, mehr Betriebsaufwand und mehr potenzielle Fehlkonfigurationen. Auch Wartungsfenster, Datenkonsistenz, Lizenzmodelle und die Fähigkeit des Betriebsteams gehören in die Entscheidung. Eine technisch beeindruckende Architektur ist kein Gewinn, wenn sie nicht nachvollziehbar betrieben, überwacht und im Störungsfall beherrscht werden kann.

ITSCM liefert den Maßstab für diese Entscheidung. Es definiert den erforderlichen Wiederanlauf und die zulässigen Datenverluste, während Architektur und Betrieb die geeigneten technischen Maßnahmen umsetzen. So wird Hochverfügbarkeit zu einem gezielten Baustein der Resilienz statt zu einem isolierten Infrastrukturprojekt.

Regulatorische Anforderungen verlangen belastbare Nachweise

NIS-2, DORA, KRITIS-Anforderungen und etablierte Standards wie BSI 200-4 erhöhen den Druck, Vorsorge nicht nur technisch, sondern organisatorisch nachweisbar zu gestalten. Gefordert sind risikoorientierte Prozesse, klare Verantwortlichkeiten, angemessene Maßnahmen, Tests und eine kontinuierliche Verbesserung. Eine Verfügbarkeitskennzahl oder ein einzelnes Clusterkonzept reicht dafür nicht aus.

Prüfbar wird vor allem die Kette von der geschäftlichen Anforderung bis zur umgesetzten Maßnahme: Wurden kritische Services identifiziert? Sind Wiederanlaufziele begründet? Gibt es belastbare Notfallverfahren? Wurden diese getestet und nach Änderungen aktualisiert? Können Verantwortliche im Ernstfall Entscheidungen treffen und diese dokumentieren? ITSCM schafft die Struktur, um diese Fragen nachvollziehbar zu beantworten.

Softwaregestützte Prozesse helfen, Abhängigkeiten, Maßnahmen, Tests und Verantwortlichkeiten konsistent zu pflegen. Mit einer Plattform wie [alive-IT] lassen sich Informationen aus BCM, ITSCM und Krisenmanagement konsolidieren, statt sie in voneinander getrennten Dokumentenständen zu verwalten. Die Software ersetzt keine fachliche Bewertung, unterstützt aber deren dauerhafte Operationalisierung.

Der richtige nächste Schritt ist eine gemeinsame Sicht auf Risiken

Statt zwischen ITSCM und Hochverfügbarkeit zu wählen, sollten Organisationen ihre kritischen Geschäftsprozesse, realistischen Ausfallszenarien und vorhandenen technischen Maßnahmen gemeinsam betrachten. Dort, wo Hochverfügbarkeit die Anforderungen erfüllt, ist sie ein wertvoller Schutz. Dort, wo sie an Grenzen stößt, braucht es belastbare Wiederherstellung, klare Führung und eingeübte Zusammenarbeit. Resilienz entsteht, wenn Technik und Notfallorganisation dieselbe geschäftliche Priorität verfolgen.