Der neue internationale Standard ISO/IEC 27031:2025 stellt diesen Status quo in Frage. Die Norm fordert unmissverständlich die Integration eines ganzheitlichen BCM-Ansatzes in die IT-Funktion selbst und behandelt diese als eine abzusichernde Geschäftseinheit.

Das grundlegende Missverständnis: Warum die IT ihr eigenes BCM braucht

In Organisationen herrscht eine konzeptionelle Unschärfe, die im Krisenfall katastrophale Folgen haben kann: die Verwechslung von BCM und ITSCM.

Business Continuity Management ist ein ganzheitlicher und strategischer Managementprozess, der darauf abzielt, die zeitkritischen Geschäftsprozesse der gesamten Organisation vor den Auswirkungen von Ereignissen mit Ausfallpotenzial zu schützen. BCM betrachtet alle Ressourcen, die zur Wertschöpfung beitragen: Menschen, Infrastruktur, Lieferketten und Technologie.

IT Service Continuity Management hingegen ist eine spezialisierte Disziplin und ein Teilbereich des BCM. Sein Fokus liegt ausschließlich auf den Wiederanlauf und der Wiederherstellung der technologischen Infrastruktur und der IT-Services, um die vom Business im BCM-Prozess definierten Ziele zu erfüllen. ITSCM ist der technische Beitrag der IT zur übergeordneten Resilienz des Unternehmens.

Das Problem entsteht, wenn die IT-Abteilung ihre Aufgabe als erfüllt ansieht, sobald sie einen IT Recovery Plan hat. Sie übersieht dabei, dass sie selbst eine zeitkritische Geschäftseinheit ist, die auf Weisen ausfallen kann, die weit über einen reinen Systemausfall hinausgehen. Ein IT Recovery Plan mag den Wiederanlauf und die Wiederherstellung eines Servers regeln, aber er beantwortet nicht die Frage, was passiert, wenn die dafür notwendigen Administratoren aufgrund einer Pandemie nicht verfügbar sind.

Die Wurzeln des Missverständnisses: Eine historisch-kulturelle Analyse

Diese gefährliche Vereinfachung ist kein Zufall, sondern das Ergebnis einer langen Entwicklung, die von organisatorischen Silos und dem Einfluss etablierter Frameworks geprägt ist.

• Seit den Anfängen der Unternehmens-IT wurden IT-Abteilungen oft als zentralisierte, technische Support-Einheiten betrachtet, die organisatorisch von den Kerngeschäftsbereichen getrennt waren, was zu historischen Silos zwischen Business und IT führte. Diese Trennung führte zu unterschiedlichen Prioritäten, Kommunikationsbarrieren und einem Mangel an geteilter Verantwortung für die gesamtunternehmerische Resilienz. Das Business "bestellt" Services, die IT "liefert" – eine Dynamik, die ein integriertes BCM-Verständnis erschwert.

• Das weit verbreitete Framework ITIL (IT Infrastructure Library) hat die IT zwar professionalisiert, aber gleichzeitig ihre Rolle als Dienstleister zementiert, was als der ITIL-Effekt bezeichnet werden kann. Da ITSCM ein Kernprozess innerhalb von ITIL ist, haben viele IT-Organisationen diesen als ihre primäre und oft einzige Kontinuitätsverpflichtung verinnerlicht. Sie erfüllen damit die Anforderungen ihres Frameworks, übersehen aber die Notwendigkeit, sich selbst als eine Geschäftseinheit zu betrachten, die ebenfalls ein BCM benötigt.

• IT-Experten denken naturgemäß in technologischen Lösungen, was zu einer technologiezentrierten Sichtweise führt. Ein "Notfall" wird primär als Systemausfall, Netzwerkproblem oder Cyberangriff verstanden. Der Wiederanlauf und die Wiederherstellung fokussiert sich auf Daten-Backups und redundante Hardware. Risiken wie der Ausfall von Schlüsselpersonal oder der Wegfall eines zeitkritischen Lieferanten fallen oft aus diesem technologiezentrierten Raster heraus.

Das Mandat der ISO 27031:2025: Die IT als abzusichernde Geschäftseinheit

Der neue Standard ISO 27031 bricht radikal mit dieser isolierten Sichtweise. Er behandelt die IT-Funktion nicht mehr nur als technischen Dienstleister, sondern als eine eigenständige, zeitkritische Geschäftseinheit, die ein eigenes, integriertes BCM benötigt.

Dieser Paradigmenwechsel wird durch mehrere Schlüsselaspekte der Norm untermauert:

• Die Norm fordert explizit die Integration statt Isolation (Kapitel 6) der "ICT Readiness for Business Continuity" (IRBC) in das gesamtunternehmerische BCM. Dies positioniert die IT nicht als externen Lieferanten, sondern als integralen Bestandteil der Resilienzstrategie, der sich denselben ganzheitlichen Prinzipien unterwerfen muss wie jede andere Abteilung.

• Ein ganzheitlicher Ressourcenfokus wird durch die ISO 27031 etabliert, indem sie explizit die abzusichernden Ressourcen der IT-Funktion auflistet. Dazu gehören nicht nur Technologie und Daten, sondern auch "staff competencies" (Mitarbeiterkompetenzen), "facilities" (Standorte), "processes" (interne Prozesse) und "suppliers" (Lieferanten). Damit wird unmissverständlich klargemacht, dass ein reiner ITSCM-Ansatz, der sich nur auf den Wiederanlauf und die Wiederherstellung von Technologie und Daten konzentriert, nicht ausreicht. Die IT muss Pläne für den Ausfall von Schlüsselpersonal, den Verlust ihrer Arbeitsstätten, den Ausfall ihrer IT-Infrastruktur und den Ausfall ihrer eigenen Lieferanten haben.

• Der Standard weist dem Top-Management eine klare Verantwortung (Kapitel 13) für die Bewertung und Genehmigung der IRBC-Strategien zu. Dies hebt die Kontinuität der IT-Funktion selbst auf eine strategische Ebene und signalisiert, dass sie mit der gleichen Ernsthaftigkeit behandelt werden muss wie die Kontinuität von z. B. einer Produktion.

Die ISO 27031 verlangt von der IT also, sich selbst einer Business Impact Analyse zu unterziehen und ein BCM zu implementieren, das ihre eigene Organisation absichert, damit sie überhaupt in der Lage ist, ihre ITSCM-Aufgaben für den Rest des Unternehmens zu erfüllen.

Die Risiken des ITSCM-Trugschlusses in der Praxis

Wenn eine IT-Abteilung nur ITSCM betreibt und glaubt, damit resilient zu sein, setzt sie das Unternehmen unkalkulierbaren Risiken aus. Ein reiner Fokus auf die technische Wiederherstellung lässt zeitkritische, nicht-technische Ausfallszenarien unberücksichtigt:

• Ein IT Recovery Plan, der nur die technischen Wiederherstellungsschritte beschreibt, ist wertlos, wenn niemand da ist, der ihn ausführen kann, was das Risiko des Ausfalls von Schlüsselpersonal Was passiert, wenn die wenigen Spezialisten, die ein komplexes Altsystem oder eine kritische Datenbank administrieren, aufgrund einer Pandemie, eines Unfalls oder eines Streiks gleichzeitig ausfallen? Ein BCM für die IT würde hier Maßnahmen wie z. B. Multi-Skill-Training, Separation of Core Skills und Automatisierung fordern.

• Der Verlust von IT-Standorten ist ein weiteres Risiko, denn ein Brand im Verwaltungsgebäude der IT, eine regionale Überschwemmung oder ein Stromausfall, der die Arbeitsplätze der IT-Mitarbeiter betrifft, kann die Fähigkeit zur Koordination des Wiederanlaufs und der Wiederherstellung lahmlegen. ITSCM plant den Wiederanlauf von Servern in einem Ausweichrechenzentrum, aber ein BCM für die IT plant, von wo aus die IT-Teams diesen Wiederanlauf überhaupt steuern und durchführen können.

• Die IT selbst ist auf eine Kette von Prozessen angewiesen, und der Zusammenbruch interner IT-Prozesse kann eine effektive Reaktion auf den eigentlichen Notfall unmöglich machen. Wenn die Systeme, die diese internen Prozesse unterstützen (z. B. Ticketsystem, Monitoring-Tools), oder das dafür zuständige Personal ausfallen, verliert die IT ihre Steuerungsfähigkeit.

• Die IT ist massiv von externen Partnern abhängig, weshalb der Ausfall von Lieferanten ein erhebliches Risiko darstellt. Ein ITSCM-Plan mag ein Backup der Cloud-Daten vorsehen, aber ein BCM für die IT analysiert die vertraglichen Verpflichtungen, plant alternative Lieferanten und definiert Prozesse für den Fall, dass ein strategischer Partner ausfällt.

Fazit

Die Annahme, dass ITSCM oder IRBC ein BCM für die IT ersetzt, ist eine der gefährlichsten Resilienz-Lücken in modernen Unternehmen. Sie entspringt einer veralteten, technologiezentrierten Sichtweise und wird durch organisatorische Silos zementiert. Die ISO/IEC 27031  macht unmissverständlich klar: Die IT ist nicht nur ein Dienstleister, sondern eine kritische Geschäftseinheit, die ein eigenes, integriertes Business Continuity Management benötigt.

Handlungsempfehlungen für Führungsebene und Verantwortliche:

• Die klare Zuweisung der Verantwortung ist entscheidend. Die Führungsebene muss anerkennen, dass die IT-Organisation selbst ein BCM benötigt. Die Verantwortung für dieses "interne" BCM der IT muss klar beim CIO/IT-Leiter verankert werden, in enger Abstimmung mit dem BCM-Verantwortlichen des Unternehmens.

• Die Durchführung einer BIA für die IT-Organisation ist unerlässlich. Führen Sie eine Business Impact Analyse durch, die nicht die IT-Services für andere, sondern die internen Prozesse, das Personal, die Standorte und die Lieferanten der IT-Abteilung selbst bewertet. Identifizieren Sie die wahren "Single Points of Failure" innerhalb Ihrer IT-Organisation.

• Die Entwicklung von BCP in der IT ist ein Muss. Erweitern Sie die Sichtweise um die bestehenden IT- und Desaster-Recovery-Pläne um nicht-technische Aspekte. Erstellen Sie konkrete Pläne für Szenarien wie den Ausfall von Schlüsselpersonal, den Verlust von IT-Arbeitsplätzen, Ausfall IT-Infrastruktur und den Ausfall kritischer IT-Lieferanten.

• Die Etablierung einer integrierten Testkultur ist fundamental. Führen Sie Übungen durch, die nicht nur den technischen Failover testen, sondern auch die Resilienz der IT-Organisation selbst. Simulieren Sie den Ausfall von IT-Personal und testen Sie, ob die dokumentierten Prozesse auch von alternativen Teams ausgeführt werden können.

Schließen Sie die Resilienz-Lücke: Ist Ihre IT wirklich resilient oder nur wiederherstellbar?

Die ISO 27031:2025 fordert eine neue Denkweise. Ein rein technischer Wiederanlaufplan reicht nicht mehr aus, um die IT selbst abzusichern. Wir unterstützen Sie dabei, die Lücke zwischen ITSCM und einem echten BCM für Ihre IT zu schließen – von der BIA für Ihre IT-Organisation bis zur Entwicklung integrierter Notfallpläne. Kontaktieren Sie uns, um die Resilienz Ihrer IT auf den Prüfstand zu stellen und sie zu einer krisenfesten Geschäftseinheit zu machen.

Das Kernstück dieser Neuausrichtung ist Klausel 6.6a. Sie schreibt unmissverständlich vor: Wenn die Informations- und Kommunikationstechnologie (IKT) die vom Geschäftsbetrieb geforderten Wiederanlaufzeiten (Recovery Time Objective – RTO) oder Wiederherstellungszeitpunkte (Recovery Point Objective – RPO) nicht erfüllen kann, muss die Organisation Workarounds im Business Continuity Plan (BCP) beschreiben, die den Betrieb für die Dauer dieser Lücke ohne IKT ermöglicht. 

Diese Anforderung wird durch Klausel 10.4 ergänzt, die „temporäre Workarounds“ als Lösung definiert. Dabei handelt es sich um manuelle oder teilmanuelle Prozesse, die es ermöglichen, zeitkritische Geschäftsprozesse mit potenziell geringerer Effizienz fortzusetzen, bis die IT-Services wieder verfügbar sind. Die Norm erzwingt damit eine ehrliche Auseinandersetzung mit der Lücke zwischen den Geschäftsanforderungen und den realen, oft budgetlimitierten IKT-Fähigkeiten. 

Ein entscheidender Aspekt, der in der Praxis oft zu Missverständnissen führt, ist die notwendige Unterscheidung zwischen den Wiederanlaufzielen des Business und denen der IT. Das vom Geschäftsbetrieb definierte RTO (Business-RTO) gibt an, wann ein Geschäftsprozess wieder laufen muss. Damit dies gelingt, muss die zugrunde liegende IKT-Infrastruktur zwangsläufig früher wiederhergestellt sein. Das RTO der IKT (IKT-RTO) muss also signifikant kürzer sein als das Business-RTO, um einen Puffer für den Neustart der Geschäftsprozesse, die Datenvalidierung und die Kommunikation zu schaffen. Noch wichtiger ist jedoch die tatsächliche Wiederanlaufzeit (Recovery Time Actual, RTA). Im Gegensatz zum RTO, der ein Zielwert ist, ist die RTA der gemessene Wert, der bei einem Test oder einer Simulation ermittelt wird, um die Leistungsfähigkeit für den Ernstfall zu bestimmen. Die RTA ist somit der ultimative Realitätscheck für jeden BCP.

Die Praxis-Lücke: Warum bekannte Prinzipien scheitern

Obwohl die Prinzipien der ISO-Norm in der Fachwelt bekannt sind, klafft eine gefährliche Lücke zwischen Theorie und Umsetzung. Die Gründe dafür sind systemisch und lassen sich oft auf grundlegende Fehleinschätzungen zurückführen:

• Eine organisatorische Kluft entsteht, da die Verantwortung für die Aufrechterhaltung des Geschäftsbetriebs fälschlicherweise oft als reine IT-Aufgabe missverstanden wird. Die Fachbereiche definieren ihre Anforderungen, die IT liefert, was das Budget hergibt. Der manuelle Workaround eines Geschäftsprozess fällt in das Zuständigkeitsvakuum zwischen diesen beiden Silos. Keine Seite fühlt sich für die Finanzierung, Entwicklung und das Testen verantwortlich.

• Das „Papierplan“-Syndrom beschreibt das Phänomen, bei dem viele BCPs nur existieren, um Audit-Anforderungen zu erfüllen. Sie sind oft veraltet, ungetestet und unrealistisch. Insbesondere manuelle Prozesse werden selten funktional getestet, da dies operativ aufwendig ist. Ein theoretischer Walkthrough Test reicht nicht aus, um die Belastbarkeit eines manuellen Prozesses unter Stress zu validieren.

• Eine fehlende Nachhaltigkeitsplanung führt dazu, dass manuelle Workarounds oft nur für sehr kurze Zeiträume ausgelegt sind. Jüngste Vorfälle wie der CrowdStrike-Ausfall 2024 zeigten jedoch, dass der Wiederanlauf und die Wiederherstellung Tage dauern kann und massive manuelle Eingriffe erfordert. Ein nicht nachhaltiger manueller Prozess kann durch massive Ineffizienz und hohe Fehleranfälligkeit schnell einen unkontrollierbaren Rückstand erzeugen und so zu einer eigenständigen, noch größeren Krise führen.

Diese systemischen Versäumnisse sind keine rein operativen Mängel. Sie manifestieren sich in direkten und oft verheerenden finanziellen Verlusten. Um das Ausmaß dieser Risiken zu verdeutlichen, belegt eine Studie von Information Technology Intelligence Consulting aus dem Jahr 2024 folgende Zahlen: Für 90% der Unternehmen verursacht eine einzige Stunde Ausfallzeit Kosten von über 300.000 US-Dollar, wobei 41% der Unternehmen sogar von Kosten zwischen 1 und 5 Millionen US-Dollar pro Stunde berichten. Dies unterstreicht die wirtschaftliche Notwendigkeit, die durch die ISO-Norm geforderte operative Resilienz zu schaffen und das Budget für entsprechende Maßnahmen zu rechtfertigen.

Die entscheidende Methodik: Die Gap-Analyse

Der Prozess, die Anforderungen des Business (Business-RTO) mit den nachgewiesenen Fähigkeiten der IT (gemessen als RTA) zu vergleichen, ist die Gap-Analyse. Diese Analyse ist keine oberflächliche Prüfung, sondern eine tiefgehende, mehrschichtige Untersuchung der gesamten technologischen Kette. Sie beginnt bei der Basisinfrastruktur wie Stromversorgung und Klimatisierung des Rechenzentrums, geht über die Netzwerkkomponenten, Server und Speichersysteme bis hin zu den Datenbanken und schließlich der Anwendung selbst, die den Geschäftsservice bereitstellt.

Jeder dieser Layer hat eigene Wiederherstellungscharakteristika und Abhängigkeiten. Nur durch eine solche granulare Analyse kann die IT eine realistische und ehrliche Aussage über ihre tatsächliche Wiederanlaufzeit (RTA – ermittelt durch das Testen der unterschiedlichen Komponenten) treffen. Das Ergebnis dieser Gap-Analyse ist die Grundlage für die strategische Entscheidung: Entweder wird in die Technologie investiert, um die Lücke zu schließen, oder es wird ein manueller Workaround entwickelt. 

Ein Handlungsrahmen für wirksame Workarounds

Um die Anforderungen der Norm zu erfüllen und die Praxis-Lücke zu schließen, ist ein strukturierter Ansatz erforderlich:

• Realitätsnahes Design erfordert, dass digitale Prozesse akribisch in analoge, schrittweise Anleitungen übersetzt werden. Diese müssen in einem krisentauglichen „Playbook“-Format, dem BCP, dokumentiert und offline in gedruckter Form verfügbar sein.

• Quantitative Ressourcenplanung bedeutet, dass der Plan präzise definieren muss, wie viele Mitarbeiter und welche Materialien (z. B. vorgedruckte Formulare, Rechner) benötigt werden, um ein definiertes Mindestmaß an Service aufrechtzuerhalten.
• Modellierung des Rückstands ist notwendig, da die geringere Effizienz manueller Arbeit quantifiziert werden muss. Ein Modell, das den stündlich anfallenden Rückstand (Backlog) berechnet, ermöglicht es dem Krisenmanagement, proaktiv zu steuern und die wahren Geschäftsauswirkungen an die Führungsebene zu kommunizieren.

• Validierung ist entscheidend, weshalb die Teststrategie über Tests hinausgehen muss. Funktionale Tests, bei denen ein Team den manuellen Prozess real durchführt, und integrierte Tests, die die Übergaben zwischen Abteilungen testen, sind unerlässlich, um die tatsächliche Funktionsfähigkeit nachzuweisen.

Fazit

Die ISO 27031:2025 zwingt Organisationen, eine unbequeme Wahrheit zu akzeptieren: Technologische Resilienz allein ist unzureichend. Die Fähigkeit, zeitkritische Geschäftsprozesse temporär ohne IT aufrechtzuerhalten, ist kein optionales Extra, sondern ein zentraler Bestandteil eines BCM nach Stand der Technik. Die weit verbreitete Praxis, die Lücke zwischen RTO-Anforderungen und IT-Fähigkeiten durch Risikoakzeptanz zu ignorieren, ist nach der Norm nicht länger konform.

Handlungsempfehlungen für Führungsebene und Verantwortliche:

• Die klare Zuweisung der Verantwortung ist entscheidend. Die Verantwortung für die Entwicklung und Pflege manueller Workarounds muss explizit den Prozessverantwortlichen der Geschäftsprozesse zugewiesen werden, nicht der IT.

• Die Bereitstellung von Budgets ist unerlässlich. Schaffen Sie dedizierte Budgetposten für die Ressourcen, die für manuelle Workarounds benötigt werden – dazu gehören unter anderem Schulungszeit für Mitarbeiter, IT-Hardware, Druckkosten für Notfall-Formulare und die Durchführung realistischer Tests mit ggf. externer Unterstützung.

• Die Quantifizierung und Berichterstattung von Risiken ist ein Muss. Erstellen Sie eine transparente Gap-Analyse und eine quantitative Modellierung des potenziellen Geschäftsrückstands bei einem Ausfall. Der Business Case für die Investition in Workarounds muss auf der Basis der Reduzierung des finanziellen Restrisikos argumentiert werden, nicht als reiner Kostenfaktor.

• Die Etablierung einer Testkultur ist fundamental. Etablieren Sie ein mandatorisches, progressives Testprogramm, das über einfache Tests hinausgeht und regelmäßige funktionale Drills für diese Workarounds vorschreibt. Fördern Sie eine Kultur, in der bei Tests aufgedeckte Schwachstellen als wertvolle Erkenntnisse und nicht als Versagen betrachtet werden.

Der nächste Schritt: Von der Planung zur gelebten Resilienz

Die Umsetzung dieser anspruchsvollen Aufgaben, von der Gap-Analyse bis zur Entwicklung robuster Workarounds, erfordert spezifisches Fachwissen. IRBC- und BCM-Verantwortliche müssen zu internen Treibern werden und die strategische Notwendigkeit gegenüber der Führungsebene verdeutlichen. Externe Expertise kann diesen Prozess entscheidend beschleunigen. Handeln Sie jetzt, denn dies ist keine Compliance-Übung, sondern eine strategische Investition in die Überlebensfähigkeit und Resilienz Ihres Unternehmens.

Zwei Welten, eine Kennzahl: Wann startet die Uhr wirklich?

Die Kontroverse lässt sich auf eine einfache Frage reduzieren: Wann beginnt die RTO? Die Antwort darauf spaltet Organisationen oft in zwei Lager, die sich an den Standards von ISO und der gängigen Praxis des BSI orientieren.

• Die Business-Perspektive (gemäß ISO 22301 & ISO 27031): Für das Business beginnt der Schaden exakt zum Zeitpunkt des Störfalls. Jede Sekunde Ausfall kostet Geld, Vertrauen und Marktanteile. Internationale Standards wie die ISO 22301:2019 und die neue ISO 27031:2025 sind hier unmissverständlich: Die RTO-Zeitmessung startet mit dem "incident occurs" – dem Moment des Schadensereignisses. Diese Perspektive ist die einzig logische Grundlage für eine valide Business Impact Analyse (BIA), da sie die gesamte Dauer der Nichtverfügbarkeit erfasst.

• Die IT-Perspektive (gängige Praxis, oft im BSI-Umfeld): Für die IT-Abteilung ist die RTO oft ein Service Level Objective (SLO), dessen Einhaltung gemessen und berichtet werden muss. In der Praxis startet die Uhr daher häufig erst, nachdem der Vorfall entdeckt, analysiert und ein Notfall formal ausgerufen wurde. Die Phasen der Detektion, Analyse und Entscheidung werden nicht in die RTO der IT eingerechnet.

Diese unterschiedlichen Startpunkte erzeugen eine "versteckte Ausfallzeit" (Hidden Downtime) – ein Zeitraum, in dem das Unternehmen bereits Schaden erleidet, die IT-Wiederherstellungsuhr aber noch gar nicht läuft.

Die fatalen Nachteile der Diskrepanz

Diese Hidden Downtime ist die Wurzel einer Kaskade von strategischen Fehlern und operativen Risiken:

• Die Illusion der Sicherheit entsteht, wenn die IT die Einhaltung ihrer 4-Stunden-RTO meldet, weil die technische Wiederherstellung nach der Notfall-Ausrufung nur 3,5 Stunden gedauert hat. Das Business hat zu diesem Zeitpunkt aber bereits 6,5 Stunden Ausfall erlitten (3 Stunden "versteckte Ausfallzeit" + 3,5 Stunden Wiederherstellung) und die in der BIA definierte maximale Toleranzgrenze längst überschritten. Die IT-Ampel steht auf Grün, während das Unternehmen rote Zahlen schreibt.

• Wertlose Business Impact Analysen und Fehlplanung bei Lösungsoptionen sind die Folge, denn wenn die Fachbereiche ihre RTO-Anforderungen definieren, gehen sie von der Gesamtausfallzeit aus. Wenn die IT diese Anforderung mit einer anderen Zeitrechnung bestätigt, basieren alle nachfolgenden Lösungsoptionen auf einer falschen Prämisse. Die BIA wird so von einem Steuerungsinstrument zu einem Instrument der Selbsttäuschung.

• Ein vorprogrammierter Krisenkonflikt ist unausweichlich, wenn im Ernstfall die unterschiedlichen Erwartungen aufeinanderprallen. Die Geschäftsführung erwartet den Wiederanlauf basierend auf dem Business-RTO, während die IT nach ihrer eigenen Zeitrechnung arbeitet. Das Ergebnis sind Vertrauensverlust, ineffektives Krisenmanagement und Schuldzuweisungen genau dann, wenn eine geschlossene Zusammenarbeit überlebenswichtig wäre.

• Unterschätzte Risiken und unzureichende Budgets sind das Resultat, da die Hidden Downtime ein nicht einkalkuliertes Risiko darstellt. Die Kosten, die in dieser Phase entstehen, werden in der Risikobewertung nicht erfasst. Folglich werden Budgets für notwendige Maßnahmen – wie schnellere Detektionsmechanismen oder manuelle Workarounds zur Überbrückung genau dieser Zeit – als z. B. unnötig abgetan.

Fazit: Ein Weckruf für Führungsebene und Verantwortliche

Die unterschiedliche Interpretation der RTO ist keine semantische Kleinigkeit, sondern ein fundamentales Governance-Problem. Die neue ISO 27031:2025 erkennt diese Realität an und fordert Konsequenzen: Kann die IT die vom Business geforderte RTO (ab Schadensereignis) nicht erfüllen, ist die Organisation verpflichtet, einen Plan zur Überbrückung dieser Lücke zu haben – den manuellen Workaround.

Handlungsempfehlungen für Führungsebene und Verantwortliche:

• Eine einheitliche Sprache zu schaffen ist entscheidend. Initiieren Sie einen Workshop zwischen Business-Verantwortlichen und der IT-Leitung mit dem einzigen Ziel, eine unternehmensweit verbindliche RTO-Definition zu verabschieden, die am Schadensereignis beginnt. Verankern Sie diese Definition in Ihrer BCM- und ITSCM-Policy.

• Die Realität zu messen ist unerlässlich. Führen Sie die Kennzahl Recovery Time Actual (RTA) ein. Messen Sie in Tests und Übungen die tatsächliche Zeit vom simulierten Vorfall bis zum Wiederanlauf. Diese RTA ist der ehrliche Maßstab für Ihre Resilienz.

• Die Lücke transparent zu machen ist ein Muss. Erstellen Sie eine Gap-Analyse, die die Anforderung des Business (RTO) der realen Leistungsfähigkeit (RTA) gegenüberstellt. Diese Methode ist die Grundlage für jede strategische Entscheidung – sei es eine Investition in schnellere IT oder in die Entwicklung robuster manueller Prozesse.

• Verantwortung zu übernehmen ist fundamental. Die Entwicklung von Workarounds ist keine IT-Aufgabe, sondern die Verantwortung der Prozessverantwortlichen in den Fachbereichen. Die Führungsebene muss hierfür die notwendigen Budgets und Ressourcen bereitstellen und eine Testkultur etablieren, die Schwachstellen als Lernchancen begreift.

Schließen Sie die Resilienz-Lücke

Die Lücke zwischen Business-Anforderungen und IT-Realität zu schließen, ist eine komplexe Herausforderung. Unser Team aus erfahrenen BCM- und IRBC-Spezialisten unterstützt Sie gezielt dabei, die Theorie in die Praxis umzusetzen. Von der Moderation eines entscheidenden RTO-Alignment-Workshops über die Durchführung einer fundierten Gap-Analyse bis hin zur Entwicklung praxistauglicher Business Continuity Pläne – wir helfen Ihnen, echte, messbare Resilienz aufzubauen.

Kontaktieren Sie uns für eine unverbindliche Erstberatung und machen Sie den ersten Schritt von einem Plan auf dem Papier zu einer gelebten, krisenfesten Strategie.

„Organisational Resilience ist mehr, als die bisherigen Standards beschreiben. Es geht nicht um die bloße Konvergenz vorhandener Managementsysteme, sondern um die Integration eines neuen Paradigmas in alle zentralen Geschäftsprozesse, damit Resilienz zum Prinzip der Unternehmenssteuerung wird,“ sagt Matthias Rosenberg, Vorstand der Controllit AG.

Schwerpunkte des Whitepapers:

• Resilience-by-Design verankern: So wird Resilienz systematisch in Strategie, Planung, operative Abläufe, Entscheidungsfindung und Kultur eingebettet.
• Kompatibel, aber nicht gleichzusetzen: Warum ORM über bestehende Standards (z. B. BCM, Krisen-, Risiko- und Informationssicherheitsmanagement) hinausgeht und diese zu einem integrierten Betriebsmodell verbindet.
• Governance & Messbarkeit: Rollen, Verantwortlichkeiten und KPIs für Resilienz – inklusive kontinuierlicher Lern- und Verbesserungszyklen.
• Praxisleitfaden zur Umsetzung: Vorgehensmodell von der Reifegrad-Analyse über Design & Embedment bis zu Übungen, Enablement und kontinuierlicher Verbesserung.
• Wertbeitrag: Resilienz als Treiber für Stabilität, Agilität, Kundenzufriedenheit und regulatorische Sicherheit.

Download & Kontakt
Das Whitepaper „Organisational Resilience Management“ steht ab sofort zum kostenlosen Download auf der Website der Controllit AG bereit.

ISO 9001:2015 – Qualitätsmanagement

Die ISO-9001-Zertifizierung bestätigt, dass die Controllit AG ein effektives Qualitätsmanagementsystem implementiert hat, das kontinuierliche Verbesserung, Kundenorientierung und Prozessoptimierung sicherstellt. Dieses Zertifikat unterstreicht, dass konsistente und qualitativ hochwertige Dienstleistungen geliefert werden, die den Anforderungen der Kunden und der relevanten gesetzlichen und regulatorischen Anforderungen entsprechen.

ISO/IEC 27001:2022 – Informationssicherheitsmanagement

Mit der Zertifizierung nach ISO 27001 demonstriert die Controllit AG ihr Engagement für den Schutz sensibler Informationen und die Gewährleistung der Informationssicherheit. Diese Norm legt die Anforderungen für die Einrichtung, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung eines dokumentierten Information-Security-Management-Systems (ISMS) fest. Damit ist gewährleistet, dass die Controllit AG Risiken systematisch bewertet und minimiert, um die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen zu schützen.

ISO 22301:2019 – Business Continuity Management

Die ISO-22301-Zertifizierung zeigt, dass die Controllit AG mögliche Störungen des Geschäftsbetriebs stetig identifiziert, bewertet und effektiv darauf reagiert. Das implementierte Business-Continuity-Management-System (BCMS) stellt sicher, dass die Controllit AG auf Notfälle vorbereitet und in der Lage ist, Dienstleistungen selbst in Krisenzeiten aufrechtzuerhalten. Diese Zertifizierung ist ein Beweis für Resilienz und das Engagement der Controllit AG, Kunden auch unter widrigen Bedingungen zuverlässige Leistungen zu bieten.

Durch die erfolgreiche Implementierung und Aufrechterhaltung dieser drei ISO-Zertifizierungen demonstriert die Controllit AG ihr umfassendes Engagement für höchste Qualitätsstandards, Informationssicherheit und Business Continuity. Dies stärkt nicht nur das Vertrauen der Kunden, sondern fördert auch die kontinuierliche Verbesserung und Effizienz der internen Prozesse.

Die Controllit AG und BCM Academy GmbH laden gemeinsam zum „Resilience Meet & Eat“ nach Köln ein.

Im Vordergrund unserer Veranstaltung stehen lockeres Netzwerken und fachlicher Austausch in gemütlicher Runde bei einem leckeren Essen à la Carte.

Unser Event in der Kölner Altstadt richtet sich an alle verantwortlichen Personen aus den Bereichen Business Continuity Management, IT Service Continuity Management, Information Security und Krisenmanagement.

Event-Termin: 23. Juni 2022 um 18 Uhr

Kommunizieren Sie untereinander als Expert*innen, pflegen Sie existierende Verbindungen und knüpfen Sie neue Kontakte zu den verschiedensten Unternehmen und Branchen aus Ihrer Region.

Alle Details zur Veranstaltung finden Sie auf www.controll-it.de/de/RME

Wir freuen uns auf Ihre Anmeldung bis zum 16. Juni 2022 per E-Mail an: events@controll-it.de

Eventdatum: Donnerstag, 23. Juni 2022 18:00 – 21:00

Eventort: Köln