Geschäftskontinuität beginnt mit Portabilität

In die meisten Geschäftskontinuitätspläne ist eine stillschweigende Annahme eingebaut: dass die Infrastruktur, auf der der Plan läuft, mitspielt. Dass Backups zugänglich sind. Dass Wiederherstellungsverfahren wie dokumentiert funktionieren. Dass der Anbieter, dessen Dienste den kritischen Pfad stützen, verfügbar ist – oder zumindest innerhalb des im Plan festgelegten Zeitfensters wiederhergestellt werden kann.

Diese Annahme wird jedes Mal auf die Probe gestellt, wenn ein großer Anbieter einen Ausfall, eine regionale Störung oder eine Dienstunterbrechung hat, die sich auf abhängige Workloads auswirkt. Und wenn es schiefgeht, dann meist auf ganz bestimmte Weise. Nicht, weil der Plan falsch war, sondern weil die Architektur ihn nicht umsetzen konnte.

Die Kluft zwischen einem Plan und einem Plan, der funktioniert

Das Wichtigste auf einen Blick: Die meisten Unternehmen haben Kontinuitätsstrategien dokumentiert und vertrauen darauf. Die Daten zu den tatsächlichen Wiederherstellungsergebnissen erzählen jedoch eine andere Geschichte.

Laut dem „Veeam Data Trust and Resilience Report 2026“, der auf Erkenntnissen von mehr als 900 leitenden IT-, Sicherheits- und Risikomanagern weltweit basiert, geben 90 % der Unternehmen an, zuversichtlich zu sein, dass sie sich innerhalb ihrer Wiederherstellungszeitziele (RTOs) von einem Cybervorfall erholen können. Nur 69 % sagen, dass diese RTOs vollständig auf die Geschäftskontinuitätsziele abgestimmt sind. 

Genau in dieser Lücke – zwischen dem Vertrauen in den Plan und der Übereinstimmung zwischen dem Plan und den tatsächlichen Anforderungen des Unternehmens – liegen die meisten Fehler bei der Geschäftskontinuität.

Die finanziellen Folgen dieser Lücke sind nicht abstrakt. Eine Cisco-Studie schätzt die durchschnittlichen Kosten von IT-Ausfällen für Großunternehmen auf 15.000 US-Dollar pro Minute. Ein einstündiger Ausfall kostet über eine halbe Million Dollar, noch bevor Reputationsschäden, SLA-Strafen gegenüber Kunden oder regulatorische Konsequenzen mit eingerechnet werden. 

Laut der jährlichen Ausfallanalyse 2026 des Uptime Institute geben 57 % der Befragten an, dass ihr letzter größerer Ausfall mehr als 100.000 Dollar gekostet hat, wobei jeder fünfte Ausfall die 1-Millionen-Dollar-Marke überschritt. Für die meisten Unternehmen sind Ausfallkosten kein theoretisches Risiko. Sie sind ein wiederkehrender Posten in der Bilanz.

Warum die Architektur die Kontinuitätsvariable ist, die in den meisten Plänen unterschätzt wird

Das Wichtigste auf einen Blick: Wiederherstellungszeitziele scheitern nicht wegen schlechter Planung, sondern weil die zugrunde liegende Architektur den Plan nicht umsetzen kann. Portabilität ist die architektonische Eigenschaft, die Kontinuitätsversprechen glaubwürdig macht.

Wenn ein Ausfall einen einzelnen cloud-Anbieter trifft, haben die Unternehmen, die sich am schnellsten erholen, eines gemeinsam: Ihre Workloads waren für ihren Betrieb nicht vollständig von diesem Anbieter abhängig. Sie verfügten über die architektonische Flexibilität, den Ausfall zu umgehen, in einer alternativen Umgebung neu zu starten oder ein Failover durchzuführen, das nicht davon abhängig war, dass das ausgefallene System wieder online ging.

Die Unternehmen, die damit zu kämpfen haben, weisen ein anderes Merkmal auf: Ihr Wiederherstellungsplan setzte voraus, dass der Anbieter an der eigenen Wiederherstellung mitwirkt. Die Wiederherstellung erfolgte aus backups, die in der Infrastruktur desselben Anbieters gespeichert waren. Umgebungen wurden mithilfe der Provisioning-Tools dieses Anbieters neu aufgebaut. Man musste warten, bis der Vorfall beim Anbieter behoben war, bevor der Wiederherstellungsprozess überhaupt beginnen konnte.

Das ist die Portabilitätslücke in der Praxis, und sie ist weit verbreitet. Laut dem „Flexera 2026 State of the Cloud Report“ nennen 78 % der Unternehmen die Portabilität von Workloads als eine der drei wichtigsten cloud-Prioritäten. Nur 22 % haben eine wirklich anbieterunabhängige Architektur erreicht. Die Kluft zwischen Anspruch und Realität ist der Grund für die meisten RTO-Verstöße. Unternehmen wissen, dass Portabilität wichtig ist. Die meisten haben sie aber nicht umgesetzt.

Lies den Leitfaden zur Standardisierung der Anwendungsbereitstellung über AWS, Azure und GCP hinweg.

Wenn Kontinuität zur Compliance-Verpflichtung wird

Das Wichtigste auf einen Blick: Für Finanzinstitute und Betreiber kritischer Infrastrukturen in der EU ist Anbieterportabilität nicht mehr nur eine bewährte Vorgehensweise. Der „Digital Operational Resilience Act“ macht das Management und den Nachweis von Konzentrationsrisiken zu einer gesetzlichen Verpflichtung.

Die wirtschaftlichen Argumente für Portabilität waren schon immer klar. Nun werden auch die regulatorischen Anforderungen deutlich.

Der „Digital Operational Resilience Act“ (DORA) der EU schreibt vor, dass Finanzunternehmen das Konzentrationsrisiko im Zusammenhang mit kritischen Drittanbietern, einschließlich cloud-Hyperscalern, aktiv steuern müssen. Unternehmen, die dem DORA unterliegen, können sich nicht einfach auf die SLAs eines einzelnen Anbieters als Grundlage für ihre Kontinuitätsvorsorge verlassen. Sie müssen nachweisen, dass sie das Risiko einer Anbieterkonzentration bewertet haben, die Auswirkungen eines Anbieterausfalls auf ihren Betrieb verstehen und Maßnahmen ergriffen haben, um diese Abhängigkeit zu steuern.

DORA gilt derzeit für Finanzunternehmen, die in der EU tätig sind, stellt aber eine regulatorische Richtung dar, die sich ausbreitet. Die britische Financial Conduct Authority hat ähnliche Anforderungen an die operative Resilienz veröffentlicht. Die NIS2-Richtlinie erweitert die Resilienzverpflichtungen auf eine breitere Gruppe von Betreibern kritischer Infrastrukturen in der gesamten EU. Das Muster ist einheitlich: Die Regulierungsbehörden behandeln die Konzentration auf cloud-Anbieter als systemisches Risiko, und die Organisationen, die diesen Rahmenbedingungen unterliegen, können Portabilität nicht länger als optionale architektonische Präferenz betrachten.

Für ITMMs in regulierten Branchen verändert dies die Diskussion um Portabilität grundlegend. Es geht nicht mehr darum, ob eine portablere Architektur betriebliche Vorteile bringen würde. Es geht darum, ob die aktuelle Architektur eine Compliance-Anforderung erfüllt – und welches Risiko besteht, wenn dies nicht der Fall ist.

Wie Portabilität in der Praxis tatsächlich aussieht

Das Wichtigste auf einen Blick: Bei Portabilität geht es nicht darum, identische Workloads gleichzeitig bei jedem Anbieter auszuführen. Es geht darum, sicherzustellen, dass die Bereitstellungsschicht von der Infrastruktur eines einzelnen Anbieters entkoppelt ist, sodass die Kontinuität nicht von der Verfügbarkeit oder der Kooperationsbereitschaft eines einzigen Anbieters abhängt.

Ein häufiges Missverständnis bezüglich Portabilität ist, dass man dafür alles ständig überall laufen lassen muss. Das ist teuer, komplex und für die meisten Workloads unnötig. Was Kontinuität tatsächlich erfordert, ist viel gezielter: die Fähigkeit, kritische Workloads zu verlagern, sobald die Entscheidung dafür fällt – ohne dass die Migration durch architektonische Abhängigkeiten von den proprietären Diensten eines einzelnen Anbieters blockiert wird.

Diese Unterscheidung ist wichtig, weil sie beeinflusst, wohin die Investitionen fließen. Portabilität auf der Bereitstellungsebene (wie Umgebungen definiert werden, wie Anwendungen sich mit Abhängigkeiten verbinden, wie Pipelines strukturiert sind) ist erreichbar, ohne Anwendungen neu zu schreiben oder anbieterspezifische Dienste aufzugeben, wenn diese echte Vorteile bieten. Es bedeutet, bewusste Entscheidungen darüber zu treffen, welche Dienste wiederherstellbare Abhängigkeiten schaffen und welche Ausstiegsmöglichkeiten schaffen, die mehr kosten, als der Dienst wert ist.

In der Praxis haben Unternehmen, die ihre Kontinuitätspläne erfolgreich umsetzen, in der Regel frühzeitig drei Entscheidungen getroffen: eine per Programmierung definierte Infrastruktur statt einer manuell in Anbieter-Konsolen zusammengestellten; eine von anbieterspezifischen Tools entkoppelte Umgebungsbereitstellung; und Deployment-Pipelines, die auf offenen Standards statt auf proprietären Abstraktionen basieren. Keine dieser Maßnahmen verhindert die Nutzung anbieterspezifischer Dienste, wenn diese einen Mehrwert bieten. Alle bewahren die Möglichkeit, umzuziehen, wenn ein Verbleib unhaltbar wird.

Ein funktionierender Geschäftskontinuitätsplan ist einer, bei dem das ausgefallene System sich nicht selbst wiederherstellen muss. Diese Fähigkeit aufzubauen ist eine architektonische Entscheidung, die auf der Bereitstellungsebene getroffen wird – lange bevor der Vorfall eintritt, der sie auf die Probe stellt.

Lies das Migrations-Playbook, um dich ohne Unterbrechungen aus der Anbieterabhängigkeit zu befreien.

Häufig gestellte Fragen (FAQ)

Wie unterscheidet sich Portabilität von einer Multicloud-Strategie? 

Eine Multicloud-Strategie bedeutet, Workloads bei mehr als einem Anbieter auszuführen. Portabilität bedeutet, dass diese Workloads bei Bedarf tatsächlich zwischen Anbietern verschoben werden können. Viele Unternehmen haben Multicloud-Bereitstellungen, bei denen einzelne Workloads immer noch tief in den proprietären Diensten eines einzigen Anbieters eingebettet sind. Das ist Multicloud-Abrechnung ohne Multicloud-Ausfallsicherheit. Portabilität erfordert architektonische Entscheidungen auf Workload-Ebene, nicht nur eine Diversifizierung der Anbieter auf Portfolio-Ebene.

Gilt DORA auch für Unternehmen außerhalb des EU-Finanzsektors? 

Direkt gesehen, nein. DORA gilt speziell für in der EU tätige Finanzunternehmen, darunter Banken, Versicherer, Wertpapierfirmen und deren kritische Drittanbieter. Allerdings wird ihr Rahmenkonzept zur Betrachtung von Konzentrationsrisiken (Identifizierung kritischer Abhängigkeiten, Bewertung der Auswirkungen eines Anbieterausfalls, Nachweis kontrollierter Ausfallsicherheit) zunehmend von Aufsichtsbehörden in anderen Branchen und Rechtsräumen übernommen. ITMMs außerhalb des EU-Finanzsektors sollten DORA eher als Frühindikator dafür betrachten, in welche Richtung sich die regulatorischen Erwartungen entwickeln, und nicht als aktuelle Verpflichtung.

Was ist der Unterschied zwischen RTO und der tatsächlichen Wiederherstellungsfähigkeit? 

Das Recovery Time Objective (RTO) ist die maximal akzeptable Zeit für die Wiederherstellung eines Systems nach einem Ausfall – ein Ziel, das im Rahmen der Kontinuitätsplanung festgelegt wird. Die tatsächliche Wiederherstellungsfähigkeit beschreibt, was bei einem echten Vorfall unter realen architektonischen Einschränkungen tatsächlich passiert. Die Lücke zwischen Vertrauen und Übereinstimmung im Veeam-Bericht 2026 spiegelt genau das wider: Unternehmen glauben, dass sie innerhalb ihrer RTOs wiederherstellen können, aber ein erheblicher Anteil räumt ein, dass diese RTOs nicht vollständig widerspiegeln, was das Unternehmen tatsächlich benötigt. Die häufigsten Ursachen sind Abhängigkeiten von der Infrastruktur des ausgefallenen Anbieters für die Wiederherstellung, undokumentierte Konfigurationsänderungen, die dokumentierte Wiederherstellungsverfahren ungenau machen, sowie manuelle Schritte, die unter dem Druck eines Vorfalls länger dauern als im Test.

Wie testen wir die Kontinuität, ohne den Betrieb zu stören? 

Der Standardansatz sind Tabletop-Übungen – strukturierte Durchspiele von Vorfallszenarien, bei denen geprüft wird, ob die Annahmen des Plans zutreffen, ohne die eigentliche Wiederherstellung durchzuführen. Über Tabletop-Übungen hinaus ist der wertvollste Test eine kontrollierte Failover-Übung in einer Nicht-Produktionsumgebung, die die Produktionsarchitektur so genau widerspiegelt, dass echte Einschränkungen zutage treten. Unternehmen mit einer in Code definierten Infrastruktur und temporärer Umgebungsprovisionierung können diese Übungen deutlich einfacher durchführen als solche mit manuell konfigurierten Umgebungen, da die Testumgebung per Definition reproduzierbar ist.

Ab wann sollte Portabilität zum Thema auf Vorstandsebene werden? 

Wenn Infrastrukturabhängigkeiten ein erhebliches finanzielles oder regulatorisches Risiko darstellen, das der Vorstand derzeit nicht berücksichtigt. Für die meisten Unternehmen bedeutet das, zwei Zahlen zu quantifizieren: die Kosten eines Ausfalls, der so lange dauert wie die erwartete Wiederherstellungszeit des Anbieters bei einem größeren Vorfall, und die geschätzten Kosten für die Abwanderung vom aktuellen Hauptanbieter, falls die Beziehung unhaltbar werden sollte. Wenn eine dieser Zahlen im Verhältnis zur Risikotoleranz des Unternehmens erheblich ist, ist diese Diskussion längst überfällig.