Business continuity planning: Leitfaden für 2026

Am Montagvormittag fällt in einem österreichischen Produktionsbetrieb das ERP aus. Die Auftragserfassung steht, der Vertrieb weicht auf Excel-Listen aus, das Lager arbeitet mit alten Ausdrucken und die IT sucht zuerst nach Zugangsdaten für ein System, das niemand mehr vollständig dokumentiert hat. Nach kurzer Zeit ist nicht mehr klar, welcher Auftrag Priorität hat, wer Kunden informiert und wer die Entscheidung über den manuellen Betrieb treffen darf.

Genau an dieser Stelle zeigt sich, ob Business Continuity Planning funktioniert. Ein Notfallordner kann Risiken beschreiben. Er hält aber keine Produktion am Laufen, stellt keine Identitäten wieder her und entscheidet nicht, welche Daten in welches Ersatzsystem übernommen werden. Für österreichische Mittelstands- und Enterprise-Teams muss ein belastbarer Plan deshalb Prozesse, Menschen, Systeme, Datenflüsse und Entscheidungsrechte zusammenbringen.

Inhaltsverzeichnis

• Warum Business Continuity Planning mehr als ein Notfallordner ist
  • Die Wahrnehmungslücke in österreichischen Unternehmen
  • Warum klassische Notfallordner versagen
• Kritische Prozesse identifizieren und Ausfallfolgen priorisieren
  • Vom Prozessnamen zur Betriebsfähigkeit
  • Ausfallfolgen mit Entscheidungslogik verbinden
• Technische Wiederherstellung von On-Prem-Systemen und AI-Connectoren
  • Recovery beginnt bei Abhängigkeiten
  • AI-Connectoren kontrolliert einsetzen
  • DORA macht die Verbindung sichtbar
• Governance-Strukturen und Krisenteams aufbauen
  • Rollen statt Organigramme
  • Eskalation muss beobachtbar sein
• Test- und Rollout-Strategien für belastbare Pläne
  • Tests mit realistischen Spannungen
  • Rollout ohne Überlastung
• Templates, Prüfkriterien und AI-gestützte Automatisierung

Warum Business Continuity Planning mehr als ein Notfallordner ist

Der erste Fehler passiert oft lange vor dem Ausfall. Ein Unternehmen erstellt eine Risikoanalyse, legt Notfallkontakte ab und verabschiedet einen Business-Continuity-Plan. Die Dokumente sehen vollständig aus, doch sie beantworten nicht die Fragen, die im Ernstfall zählen: Welche Aufträge werden zuerst bearbeitet? Wer schaltet auf den Ersatzprozess um? Welche Daten dürfen manuell erfasst werden? Wer erklärt dem Kunden, warum sich die Lieferung verschiebt?

In der Praxis entstehen dann improvisierte Übergaben. Eine Person sammelt Aufträge per E-Mail, eine zweite pflegt eine Excel-Datei, eine dritte ruft den Dienstleister an. Niemand weiß sicher, ob ein Auftrag bereits übernommen wurde. Genau diese Medienbrüche, Doppelarbeiten und unklaren Freigaben verlängern den Ausfall stärker als die ursprüngliche technische Störung.

Die Wahrnehmungslücke in österreichischen Unternehmen

Österreichische Unternehmen bewerten ihre eigene Resilienz häufig optimistischer, als ihre Steuerungsmechanismen es rechtfertigen. In einer EY/CRIF/Business-Circle-Studie schätzen sich 87,3 % als stark bis sehr stark krisenresilient ein. Gleichzeitig messen 38,2 % ihre Krisenfestigkeit nicht systematisch, und 21,8 % haben keine eigene Risikomanagement-Funktion. Diese Werte sind in der Studie zur Krisenresilienz österreichischer Unternehmen dokumentiert.

Das Problem ist nicht fehlendes Engagement. Teams handeln im Alltag pragmatisch und finden oft kurzfristige Lösungen. Ohne definierte Ownership, Kennzahlen und wiederholte Tests bleiben diese Lösungen jedoch personengebunden. Fällt die erfahrene Produktionsleiterin aus, kennt niemand den manuellen Auftragspfad. Wird ein Dienstleister kompromittiert, fehlt die Entscheidungsmatrix für Sperren, Ersatzbetrieb und Kommunikation.

Praktische Regel: Ein BCP ist erst belastbar, wenn eine andere Person den beschriebenen Prozess unter realistischen Bedingungen ausführen kann.

Warum klassische Notfallordner versagen

Die ÖNORM EN ISO 22301:2020 verankert Business Continuity in Österreich als Managementsystem. Sie beschreibt einen Ansatz, der Störungen vorbeugt, ihre Eintrittswahrscheinlichkeit senkt, Reaktionen vorbereitet und die Wiederherstellung unterstützt. Die österreichische Ausgabe wurde am 15.04.2020 veröffentlicht und umfasst 35 Seiten, wie Austrian Standards zur ÖNORM EN ISO 22301:2020 ausweist. ISO 22301 wurde international erstmals 2012 veröffentlicht und 2019 in einer zweiten Ausgabe angepasst, wie die österreichische Regierungsinformation zur Norm erläutert.

Ein solcher Rahmen ersetzt aber nicht die operative Umsetzung. Bei einem Cyberangriff darf der Plan nicht nur auf Serverwiederherstellung verweisen. Bei einem Lieferkettenausfall muss er alternative Lieferanten, Freigaben und Prioritäten abbilden. Bei einem längeren Netzausfall braucht das Unternehmen Offline-Daten, alternative Kommunikationswege und klare Grenzen für manuelle Arbeit.

Auch personelle Engpässe gehören in die Planung. Für Fragen zur Verfügbarkeit von Notfall-Personal durch BREKSTAR kann ein spezialisierter Ansprechpartner sinnvoll sein, wenn interne Teams ihre Kapazitätsgrenzen erreicht haben. Entscheidend bleibt, solche Optionen bereits vor dem Ereignis zu prüfen und in Rollen, Freigaben und Kontaktketten einzubauen.

Kritische Prozesse identifizieren und Ausfallfolgen priorisieren

Ein Unternehmen braucht keine möglichst lange Prozessliste. Es braucht eine belastbare Antwort auf eine härtere Frage: Welche Tätigkeit muss unter welchen Bedingungen weiterlaufen, damit Kunden, Mitarbeitende und regulatorische Verpflichtungen geschützt bleiben?

Ein österreichischer BCM-Leitfaden beschreibt Business Continuity Management als systematischen Ansatz, um kritische Geschäfts- und Versorgungsprozesse zu identifizieren, die Auswirkungen von Unterbrechungen zu bewerten und Präventions- sowie Wiederanlaufmaßnahmen zu etablieren. Die fachliche Reihenfolge ist damit klar, Schutzbedarf bestimmen, Ausfallfolgen bewerten, Maßnahmen festlegen und Wiederanlauf testen. Der BCM-Leitfaden der BOKU beschreibt diesen Ansatz ausführlich.

Vom Prozessnamen zur Betriebsfähigkeit

Starten Sie nicht mit Abteilungen, sondern mit Ergebnissen. „Vertrieb“ ist kein ausreichend präziser Prozess. „Kundenauftrag annehmen, prüfen, bestätigen und an die Produktion übergeben“ lässt sich dagegen analysieren. Für jeden Prozess sollten Teams mindestens folgende Punkte festhalten:

• Auslöser und Ergebnis: Wodurch beginnt der Prozess, und welches verwertbare Ergebnis muss am Ende vorliegen?
• Abhängigkeiten: Welche Mitarbeitenden, Standorte, Anwendungen, Daten, Geräte und Dienstleister sind erforderlich?
• Ausfallfolge: Was passiert bei einer Unterbrechung für Kunden, Produktion, Liquidität, Sicherheit und Compliance?
• Ersatzpfad: Welche Tätigkeit kann manuell, über ein Ersatzsystem oder mit reduzierter Funktion ausgeführt werden?
• Wiederanlauf: In welcher Reihenfolge müssen Systeme und Schnittstellen zurückkehren, damit keine inkonsistenten Daten entstehen?

Diese Analyse verhindert einen häufigen Denkfehler. Ein ERP ist nicht automatisch der wichtigste Prozess, nur weil viele Abteilungen es verwenden. Kritisch ist der konkrete Geschäftsablauf, der ohne ERP nicht fortgeführt werden kann, etwa die Freigabe eines Fertigungsauftrags oder die Prüfung einer Zahlung.

Ausfallfolgen mit Entscheidungslogik verbinden

Priorisierung gelingt besser mit nachvollziehbaren Kriterien als mit Bauchgefühl. Bewerten Sie zunächst, ob ein Prozess sofort weiterlaufen muss, ob eine begrenzte Unterbrechung tolerierbar ist oder ob die Tätigkeit später nachgeholt werden kann. Danach prüfen Sie, welche Abhängigkeit den Wiederanlauf blockiert.

Ein realistisches Modell unterscheidet zwischen drei Ebenen:

1. Betriebskritisch: Der Prozess hält Versorgung, Produktion, Kundenleistung oder gesetzliche Pflichten aufrecht. Hier braucht es einen getesteten Ersatzweg.
2. Wiederanlaufkritisch: Der Prozess muss nicht zuerst laufen, blockiert aber andere Kernabläufe, wenn er zu spät verfügbar ist. Dazu gehören Stammdaten, Identitäten oder bestimmte Freigaben.
3. Nachgelagert: Die Tätigkeit kann zunächst warten, sollte aber nach der Stabilisierung kontrolliert aufgearbeitet werden.

Die Reihenfolge muss mit dem technischen Team geprüft werden. Ein manueller Auftragseingang hilft wenig, wenn die Identitätsverwaltung nicht verfügbar ist oder die Aufträge später nicht sicher in das ERP übernommen werden können. Ebenso kann ein Ersatzsystem neue Risiken schaffen, wenn Dubletten, fehlende Freigaben oder unklare Datenverantwortung entstehen.

Entscheidend ist nicht, ob ein Workaround existiert. Entscheidend ist, ob jemand ihn unter Druck sicher und nachvollziehbar ausführen kann.

Ein guter Prozesskatalog enthält deshalb nicht nur eine Beschreibung, sondern auch eine Freigabe, einen Verantwortlichen, einen Ersatzpfad und ein Testdatum. Dokumentation ist der letzte Schritt. Erst die Übung zeigt, ob der beschriebene Ablauf im Betrieb trägt.

Technische Wiederherstellung von On-Prem-Systemen und AI-Connectoren

Ein Backup-Restore stellt noch keinen Geschäftsbetrieb her. Nach der Wiederherstellung eines Servers müssen Identitäten funktionieren, Datenflüsse wieder laufen, Schnittstellen reagieren und Fachabteilungen ihre Aufgaben ausführen können. Gerade in gewachsenen österreichischen IT-Landschaften liegen ERP, CRM, Buchhaltung, Dateifreigaben und Produktionssysteme häufig in unterschiedlichen Betriebsmodellen.

Recovery beginnt bei Abhängigkeiten

Technische Wiederherstellung sollte als Kette modelliert werden. Hardware-Redundanz schützt nicht vor einem fehlerhaften Datenmapping. Ein verfügbares ERP hilft nicht, wenn Benutzerkonten, Zertifikate oder Netzwerkrouten fehlen. Ein wiederhergestelltes CRM kann sogar zusätzlichen Schaden verursachen, wenn es veraltete Kundendaten an ein bereits bereinigtes System zurückschreibt.

Für jeden Kernprozess gehört deshalb eine technische Abhängigkeitskarte in den BCP:

• Infrastruktur: Server, Speicher, Netzwerk, Stromversorgung und relevante Endgeräte.
• Identitäten: Verzeichnisdienste, Rollen, privilegierte Konten, Mehrfaktorzugang und Notfallberechtigungen.
• Daten: Primärquellen, Sicherungen, Aufbewahrung, Konsistenz und Freigabestatus.
• Integrationen: APIs, Dateiübertragungen, Middleware, E-Mail-Flüsse und externe Plattformen.
• Betriebslogik: Reihenfolge des Starts, Validierung, Freigabe und Rückkehr vom Ersatzprozess.

Bei On-Prem-Systemen wird dieser Aufwand besonders sichtbar. Legacy-ERP, individuelle Datenbanken und manuelle Schnittstellen sind oft geschäftskritisch, aber nicht wie moderne Cloud-Dienste dokumentiert. Ein Plan, der nur „Backup einspielen“ vorsieht, lässt die schwierigste Arbeit offen, die Wiederherstellung eines konsistenten Betriebszustands.

AI-Connectoren kontrolliert einsetzen

AI-Connectoren können die Lücke zwischen Systemen und Notfallprozessen schließen. Ein Connector liest beispielsweise Auftragsdaten aus dem ERP, übergibt sie an eine freigegebene Bearbeitungslogik und schreibt das Ergebnis in ein Ersatzsystem. Ein AI-Agent kann eingehende Meldungen klassifizieren, betroffene Prozesse zuordnen und die vorbereiteten nächsten Schritte an das Krisenteam geben.

Das bedeutet nicht, dass ein Sprachmodell eigenständig Produktionsaufträge freigeben sollte. Für kritische Aktionen braucht es begrenzte Werkzeuge, rollenbasierte Berechtigungen, Protokollierung und menschliche Freigaben. Der Agent darf Daten sammeln, Prioritäten vorschlagen und Übergaben vorbereiten. Eine autorisierte Person bestätigt die Aktion, wenn sie finanzielle, rechtliche oder sicherheitsrelevante Folgen hat.

Für die Architektur ist ein MCP-Layer nützlich, wenn er Systeme kontrolliert erreichbar macht und Zugriffe zentral regelt. Der Layer sollte Werkzeuge nach Zweck trennen, Lesezugriffe von Schreibzugriffen abgrenzen und jeden Aufruf nachvollziehbar protokollieren. Bei Änderungen an On-Prem-Umgebungen kann eine dokumentierte Infrastructure-as-Code-Strategie helfen, Wiederaufbau und Konfiguration reproduzierbarer zu machen.

DORA macht die Verbindung sichtbar

Besonders im Finanzsektor verschärft DORA seit dem 17.01.2025 die Anforderungen. Betroffene Unternehmen müssen ICT-Continuity-Frameworks, Response- und Recovery-Pläne sowie jährliche Tests für alle unterstützenden Funktionen vorweisen, wie PwC Österreich zu DORA erläutert.

Die praktische Konsequenz reicht über Compliance hinaus. Ein Test muss zeigen, ob ein System wiederhergestellt, sicher bedient und in die relevanten Geschäftsabläufe eingebunden werden kann. AI-gestützte Incident-Triage und vorbereitete Datenübernahmen können dabei helfen, die Reaktionszeit zu verkürzen. Sie ersetzen aber weder Recovery-Verantwortung noch die fachliche Prüfung der Ergebnisse.

Governance-Strukturen und Krisenteams aufbauen

Im Ausfall konkurrieren nicht nur technische Probleme miteinander. Auch Entscheidungen konkurrieren. Die IT will Systeme isolieren, der Vertrieb will Kundenaufträge weiterbearbeiten, die Produktion braucht verlässliche Stammdaten und die Geschäftsführung will eine belastbare Lageeinschätzung.

Ohne festgelegte Entscheidungsrechte entsteht ein stiller Stillstand. Alle warten auf Freigabe, während mehrere Teams parallel eigene Workarounds bauen. Ein wirksames Krisenteam muss deshalb nicht nur benannt sein. Es braucht Befugnisse, Stellvertretungen, Kommunikationswege und eine gemeinsame Lageinformation.

Rollen statt Organigramme

Definieren Sie Rollen nach Entscheidungen, nicht nach Titeln. Eine Person kann mehrere Rollen übernehmen, wenn die Organisation klein ist. Die Zuständigkeit muss trotzdem eindeutig bleiben.

• Incident Lead: Aktiviert den Krisenprozess, setzt Prioritäten und beendet den Notfallmodus.
• Technology Lead: Isoliert Systeme, bewertet technische Auswirkungen und koordiniert Recovery.
• Business Owner: Entscheidet, welche Prozesse weiterlaufen und welche Aufträge Vorrang haben.
• Communications Lead: Steuert interne Informationen, Kundenmeldungen und Dienstleisterkommunikation.
• Risk und Compliance: Prüft Meldepflichten, Dokumentation und Freigaben.
• Supplier Lead: Koordiniert kritische externe Anbieter und Ersatzleistungen.

Jede Rolle braucht eine Stellvertretung. Ebenso wichtig ist eine Liste der Entscheidungen, die ohne Geschäftsführungsfreigabe getroffen werden dürfen. Dazu gehören etwa die Sperre eines Systems, die Aktivierung eines manuellen Prozesses oder die Beauftragung eines Ersatzdienstleisters.

Eskalation muss beobachtbar sein

Ein Eskalationspfad sollte an Signale gekoppelt sein, nicht an allgemeine Formulierungen wie „bei schwerwiegenden Vorfällen“. Definieren Sie, welche Symptome eine technische Analyse auslösen, wann der Business Owner übernimmt und wann externe Stellen oder die Geschäftsführung eingebunden werden.

Die österreichische Finanzmarktaufsicht verlangt ein umfassendes ICT-Risikomanagement mit resilienten Systemen, kontinuierlicher Überwachung, schneller Erkennung anomaler Aktivitäten sowie dedizierten Business-Continuity- und Disaster-Recovery-Plänen inklusive jährlicher Tests. Diese Anforderungen sind im Leitfaden zu Business Continuity Management und digitaler Resilienz zusammengefasst.

Für die Praxis reicht ein Alarmkanal nicht aus. Das Krisenteam braucht einen geschützten Kommunikationsweg, eine laufende Entscheidungsliste und eine zentrale Version der Lageinformation. Ein strukturiertes Incident-Response-Team kann dabei helfen, Verantwortlichkeiten zwischen Security, IT-Betrieb und Fachbereichen sauber zu ordnen.

Eine Eskalationsmatrix ist gut, wenn sie unter Stress eine Entscheidung beschleunigt, nicht wenn sie im Audit ordentlich aussieht.

Messen Sie außerdem die Qualität der Governance. Prüfen Sie, ob Rollen besetzt waren, ob die Lageinformationen konsistent blieben, ob Freigaben nachvollziehbar waren und ob das Team den Wechsel vom Notfallbetrieb zurück in den Regelbetrieb geregelt hat. Damit wird Resilienz von einer Selbsteinschätzung zu einer beobachtbaren Fähigkeit.

Test- und Rollout-Strategien für belastbare Pläne

Ein BCP, der nie getestet wurde, ist eine Annahme. Die Schwächen zeigen sich nicht beim Lesen, sondern beim Ausführen. Veraltete Telefonnummern, fehlende Berechtigungen, unklare Ersatzdaten und nicht dokumentierte Schnittstellen werden erst sichtbar, wenn ein Team den Prozess tatsächlich durchspielt.

Beginnen Sie mit einer begrenzten Übung für einen einzelnen Kernprozess. Wählen Sie ein Szenario, bei dem nicht nur IT, sondern auch Fachbereiche betroffen sind. Ein Ausfall des ERP sollte etwa die Auftragserfassung, die Priorisierung, die Kommunikation mit Kunden und die spätere Datenübernahme einschließen.

Tests mit realistischen Spannungen

Tabletop-Übungen eignen sich, um Rollen und Entscheidungen zu prüfen. Sie reichen aber nicht aus, wenn technische Wiederherstellung ein Bestandteil des Plans ist. Ergänzen Sie sie durch kontrollierte Tests einzelner Anwendungen, Identitätsdienste, Datenflüsse und manueller Ersatzverfahren.

Sinnvolle Szenarien decken unterschiedliche Ursachen ab:

• Cybervorfall: Ein System muss isoliert werden, während die Fachabteilung weiterarbeiten will.
• Lieferantenausfall: Ein wichtiger Dienstleister ist nicht erreichbar, und ein Ersatzprozess braucht Freigaben.
• Netzausfall: Teams müssen mit begrenzter Konnektivität arbeiten und Informationen synchronisieren.
• Personalausfall: Schlüsselwissen steht nicht zur Verfügung, die Stellvertretung übernimmt.
• Datenfehler: Ein Ersatzsystem enthält widersprüchliche oder unvollständige Datensätze.

Nach jedem Test dokumentiert das Team nicht nur Probleme, sondern konkrete Eigentümer und Fristen für die Korrektur. Der nächste Durchlauf prüft genau diese offenen Punkte. So entsteht ein Lessons-Learned-Zyklus, der den Plan mit jeder Übung verbessert.

Rollout ohne Überlastung

Rollout bedeutet nicht, den gesamten Konzern gleichzeitig zu testen. Ein besserer Ansatz beginnt mit einem kritischen Prozess, einem Standort oder einer Systemkette. Danach werden die Erkenntnisse auf verwandte Einheiten übertragen. Fachbereiche sollten ihre eigenen Ersatzprozesse mitgestalten, weil sie die tatsächlichen Arbeitsschritte und Datenprobleme kennen.

Bei physischen Standortwechseln oder temporären Ausweicharbeitsplätzen kann eine Checkliste für den Büroumzug helfen, organisatorische Abhängigkeiten sichtbar zu machen. Für IT-Teams gilt dieselbe Logik: Räume, Geräte, Zugänge, Kommunikationsmittel und Verantwortlichkeiten müssen gemeinsam geprüft werden.

Technische Deployments gehören ebenfalls in die Übungsplanung. Ein kontrollierter Kubernetes-Deployment-Prozess kann beispielsweise als Teil eines Recovery-Szenarios geprüft werden, sofern die betroffene Organisation Kubernetes tatsächlich einsetzt. Entscheidend ist die Verbindung zum Geschäftsprozess. Ein erfolgreich gestarteter Container beweist noch nicht, dass die Auftragsverarbeitung wieder funktioniert.

Templates, Prüfkriterien und AI-gestützte Automatisierung

Ein praxistauglicher Werkzeugkasten besteht aus wenigen, gut gepflegten Vorlagen. Dazu gehören eine Prozessliste, eine Abhängigkeitskarte, ein Notfallplan je Kernprozess, eine Eskalationsmatrix, eine Kommunikationsvorlage und ein Testprotokoll. Jede Vorlage braucht einen Owner, eine Version und einen konkreten Anlass für die nächste Prüfung.

Die Qualität lässt sich mit einfachen Fragen prüfen:

• Sind Prozessstart, Ergebnis und Priorität eindeutig?
• Sind Ersatzverfahren mit echten Personen und Zugängen getestet?
• Werden Identitäten, Datenflüsse und Schnittstellen berücksichtigt?
• Ist klar, wer Schreibzugriffe und Freigaben verantwortet?
• Werden Erkenntnisse aus Tests und Vorfällen in den Plan zurückgeführt?

AI-Agenten eignen sich besonders für repetitive Übergaben. Sie können Eingangsdaten strukturieren, betroffene Aufträge priorisieren, fehlende Informationen markieren, Dokumente zusammenfassen und vorbereitete Datensätze an ein Ersatzsystem übergeben. Kritische Schreibvorgänge sollten weiterhin über kontrollierte Connectoren, Berechtigungen und menschliche Freigaben laufen.

Die österreichische Finanzmarktaufsicht berichtet 2024, dass Robotic Process Automation bei zwei Dritteln der Banken und der Hälfte aller Versicherer genutzt wird, um repetitive Formulare zu verarbeiten und Datensätze in Analysesysteme zu übertragen. Diese Einordnung findet sich in der österreichischen Aufsichtsinformation zu RPA und Business-Continuity-Prozessen.

Der nächste sinnvolle Schritt ist kein allgemeiner AI-Pilot. Nehmen Sie einen kritischen Prozess, dokumentieren Sie seinen manuellen Ersatzpfad und automatisieren Sie zuerst die Übergaben, die heute am häufigsten verloren gehen. Specialty Tokens unterstützt österreichische Mittelstands- und Enterprise-Teams dabei, AI-Connectoren, MCP-Architekturen und produktive Agenten direkt in ERP-, CRM- und Backoffice-Prozesse einzubetten. Besuchen Sie Specialty Tokens, wenn Ihre Compliance-Dokumente mit den tatsächlichen technischen Wiederanlaufpfaden zusammenpassen und im Ernstfall ausführbar sein sollen.