Wie man eine Business Impact Analyse durchführt

Johannes Humbert
vor 3 Tagen
20 Min. Lesezeit

Die Business Impact Analyse (BIA) ist ein wichtiges Werkzeug, um kritische Geschäftsprozesse zu identifizieren und deren Auswirkungen bei Ausfällen zu bewerten. Sie hilft Unternehmen, Wiederherstellungsmaßnahmen zu priorisieren, finanzielle Verluste zu minimieren und gesetzliche Vorgaben wie ISO 22301 oder BSI-Standards einzuhalten.

Kernpunkte der BIA:

Ziele: Kritische Prozesse priorisieren, Kennzahlen wie MTD, RTO und RPO definieren.
Schritte: Prozesse identifizieren, Auswirkungen bewerten, Kennzahlen festlegen, Ressourcen analysieren.
Ergebnisse: Minimierung von Ausfallzeiten und Schäden, klare Notfallpläne.
Wichtig: Regelmäßige Überprüfung und Anpassung der Analyse.

Die BIA ist unverzichtbar für Unternehmen jeder Größe, besonders in Zeiten zunehmender Digitalisierung und komplexer Lieferketten.

Schritt 1: Planung und Vorbereitung

Die Planungs- und Vorbereitungsphase ist das Fundament einer erfolgreichen Business Impact Analyse (BIA). Ohne klare Ziele, einen definierten Umfang und ein passendes Team bleibt die Analyse oft oberflächlich und liefert wenig verwertbare Erkenntnisse. Diese Phase entscheidet also maßgeblich über den späteren Erfolg.

Umfang und Ziele definieren

Der erste Schritt bei einer BIA ist, drei bis fünf konkrete Ziele festzulegen. Diese Ziele lenken den gesamten Prozess und geben vor, welche Daten gesammelt und analysiert werden müssen. Typische Ziele in deutschen Unternehmen sind:

Priorisierung kritischer Prozesse: Welche Abläufe müssen im Störungsfall zuerst wiederhergestellt werden?
Definition von Kennzahlen wie Maximum Tolerable Downtime (MTD), Recovery Time Objective (RTO) und Recovery Point Objective (RPO).
Entwicklung von Maßnahmen für das Notfallmanagement und IT-Notfallpläne.
Erfüllung regulatorischer Vorgaben wie BAIT, MaRisk, KRITIS oder BSI-Standard 200-4.

Diese Ziele sollten auf einer maximal einseitigen Dokumentation festgehalten werden. Darin sollten der Zweck der BIA, die erwarteten Ergebnisse (z. B. ein BIA-Report, priorisierte Prozesslisten oder Kennzahlenübersichten) und die Verknüpfung zu bestehenden Business-Continuity- oder Risikomanagement-Prozessen beschrieben sein. Ein Abgleich mit bestehenden Sicherheits- und Datenschutzsystemen verhindert doppelte Arbeit und erleichtert Prüfungen.

Der Scope (Umfang) definiert, welche Organisationsteile, Standorte und Prozesse betrachtet werden. Wichtig ist, kritische Prozesse klar abzugrenzen und den Fokus auf deren Auswirkungen zu legen. Ein häufiger Fehler ist ein zu breiter Scope – wenn versucht wird, alle Prozesse auf einmal zu analysieren, wird das Projekt schnell unüberschaubar und liefert keine zeitnahen Ergebnisse. Stattdessen sollte die erste BIA auf ein bis drei besonders kritische Bereiche wie Produktion, Zahlungsverkehr oder Kundenservice beschränkt werden. Die Auswahl kann sich an Faktoren wie Umsatzanteil, regulatorischer Relevanz oder Kundenkritikalität orientieren.

Ein Scope-Statement sollte genau dokumentieren, was eingeschlossen und was ausgeschlossen ist – inklusive Begründung. Dieses Dokument benötigt die Freigabe des Managements, um spätere Diskussionen zu vermeiden. Häufige Fehler bei der Scope-Definition sind das Übersehen von Shared Services wie IT oder HR und unklare Annahmen über das analysierte Störungsszenario (z. B. Ausfall eines Rechenzentrums, eines Lieferanten oder eines Gebäudes).

Mit einem klaren Scope und definierten Zielen kann nun das passende Team zusammengestellt werden.

Ein interdisziplinäres Team zusammenstellen

Eine BIA liefert nur dann umfassende Ergebnisse, wenn Vertreter aus verschiedenen Fachbereichen eingebunden sind. Ein rein IT-getriebenes Projekt scheitert oft daran, dass es die operativen Realitäten von Produktion, Vertrieb oder Kundenservice nicht berücksichtigt. Gleichzeitig ist technisches Know-how notwendig, um Systemabhängigkeiten und Wiederanlaufmöglichkeiten realistisch einzuschätzen.

Das Team sollte aus einem Projektleiter, Experten aus kritischen Fachbereichen, IT-Spezialisten sowie – je nach Bedarf – Vertretern aus den Bereichen Recht, Compliance und Datenschutz bestehen. Bereichsleiter nominieren geeignete Personen, die sowohl fachlich kompetent als auch zeitlich verfügbar sind. Wichtige Auswahlkriterien sind:

Tiefes Wissen über tägliche Abläufe.
Zugang zu relevanten Kennzahlen (z. B. Tagesoutput, Umsatz).
Entscheidungsbefugnis für Priorisierungen.
Bereitschaft, an Interviews oder Workshops teilzunehmen.

In größeren Unternehmen hat sich eine zweistufige Struktur bewährt: Ein zentrales BIA-Kernteam, das für Methodik und Koordination zuständig ist, sowie lokale Prozessverantwortliche je Standort oder Geschäftsbereich (z. B. Werk A, Werk B, Shared Service Center). Um sicherzustellen, dass alle relevanten Bereiche abgedeckt sind, sollte die Teamzusammensetzung anhand des Organigramms und der Prozesslandkarte überprüft werden. So wird gewährleistet, dass IT, Kernprozesse, Supportprozesse und kritische Lieferketten berücksichtigt werden.

Eine RACI-Matrix kann dabei helfen, Rollen und Verantwortlichkeiten klar zu definieren. Für jede Hauptaktivität (z. B. Scope definieren, Fragebögen erstellen, Interviews durchführen, Ergebnisse konsolidieren, Management-Freigabe) wird festgelegt, wer verantwortlich (Responsible), entscheidend (Accountable), beratend (Consulted) und zu informieren (Informed) ist. Für mittelständische Unternehmen in Deutschland ist es außerdem ratsam, den Betriebsrat und den Datenschutzbeauftragten frühzeitig einzubinden, um Konflikte – etwa im Umgang mit Mitarbeiterdaten oder bei Schichtmodellen – zu vermeiden.

Externe Berater, wie etwa makematiq, können bei der Methodik, der Moderation von Workshops oder der Bereitstellung von Best-Practice-Templates unterstützen. Dies ist besonders hilfreich, wenn die BIA mit Themen wie digitaler Transformation oder komplexen IT-Architekturen verbunden ist.

Stakeholder identifizieren

Neben dem Kernteam müssen auch alle relevanten internen und externen Stakeholder identifiziert werden, die entweder zur Analyse beitragen oder von den Ergebnissen betroffen sind. Eine bewährte Methode ist die Analyse entlang zweier Achsen: der Einfluss auf die BIA-Ergebnisse und die Betroffenheit durch mögliche Störungen oder Maßnahmen. Abschließend werden die Stakeholder basierend auf diesen Kriterien eingeordnet, um sicherzustellen, dass niemand übersehen wird.

Schritt 2: Identifikation kritischer Geschäftsprozesse

Nachdem die Vorbereitung abgeschlossen ist, geht es nun darum, die kritischen Geschäftsprozesse zu identifizieren. Dieser Schritt ist der Kern der Business Impact Analysis (BIA). Ohne eine klare und umfassende Übersicht über die wichtigsten Prozesse des Unternehmens können spätere Maßnahmen unvollständig oder fehlgeleitet sein.

Ein kritischer Geschäftsprozess ist nicht einfach jeder alltägliche Ablauf. Es handelt sich vielmehr um Prozesse, die entscheidend für die Umsatzgenerierung sind, die Betriebskosten stark beeinflussen oder wesentliche Risiken minimieren. Ziel ist es, jene Abläufe zu identifizieren, deren Ausfall das Unternehmen empfindlich treffen würde.

Wie man kritische Prozesse identifiziert

Die Identifikation dieser Prozesse erfordert einen systematischen Ansatz. Drei bewährte Methoden kommen dabei zum Einsatz: Dokumentenanalyse, Interviews und abteilungsübergreifende Workshops.

Dokumentenanalyse: Der erste Schritt ist das Durchsehen vorhandener Unterlagen wie Prozessdokumentationen, Organigramme und Betriebshandbücher. Diese liefern einen Überblick über die Unternehmensstruktur und dokumentierte Abläufe. Ein Prozess umfasst dabei die gesamte Reise eines Produkts oder einer Dienstleistung – von der Entstehung bis zur Auslieferung. Inputs wie Rohstoffe oder Daten werden in Outputs umgewandelt, die andere Prozesse unterstützen. Allerdings sind viele kritische Abläufe oft nicht oder nur unvollständig dokumentiert.
Geplante Interviews: Ergänzend zur Dokumentenanalyse führt das BIA-Team strukturierte Gespräche mit Schlüsselpersonen aus allen relevanten Abteilungen. Dabei wird gezielt gefragt: Welche Prozesse sind entscheidend? Welche Ressourcen werden benötigt? Was passiert bei einem Ausfall? Diese Interviews decken oft informelle, aber unverzichtbare Prozesse auf, die in offiziellen Dokumenten fehlen. Fragen wie „Was tun Sie, wenn der Standardprozess ausfällt?" liefern oft überraschende Einblicke.
Abteilungsübergreifende Workshops: In Workshops kommen Vertreter aus Bereichen wie IT, Finanzen, Produktion oder Marketing zusammen, um Prozesse gemeinsam zu bewerten. Dieser Ansatz deckt Abhängigkeiten auf, die in Einzelgesprächen oft übersehen werden. Dabei entstehen oft Prozessflussdiagramme, die formelle und informelle Abläufe sichtbar machen.

Für jeden identifizierten Prozess sollte das Team detaillierte Informationen festhalten: Name, Beschreibung, Verantwortliche, benötigte Ressourcen, erzeugte Outputs, beteiligte Mitarbeiter, genutzte Technologien und geschätzter Wertbeitrag. Diese Daten bilden die Grundlage für die weiteren Schritte.

Bewertung der Prozessrelevanz

Nicht alle Prozesse sind gleich wichtig. Deshalb folgt auf die Identifikation eine Bewertung ihres Beitrags zum Unternehmenserfolg. Diese erfolgt anhand mehrerer Dimensionen:

Finanzielle Dimension: Hier wird analysiert, wie viel Umsatz ein Prozess direkt oder indirekt generiert und welche Kosten ein Ausfall verursachen würde. Prozesse wie Vertrieb oder Auftragsabwicklung haben oft direkte finanzielle Auswirkungen, während Bereiche wie IT oder Personalwesen indirekt unterstützen.
Kundendimension: Diese Dimension bewertet, wie stark ein Prozess die Kundenzufriedenheit, Lieferzeiten oder Produktqualität beeinflusst. Prozesse mit direktem Kundenkontakt – etwa Kundenservice oder Lieferung – spielen hier eine zentrale Rolle.
Strategische Dimension: Hier wird geprüft, wie ein Prozess die langfristigen Ziele des Unternehmens unterstützt. Auch wenn ein Forschungs- und Entwicklungsprozess kurzfristig keinen Umsatz generiert, kann er für die zukünftige Wettbewerbsfähigkeit entscheidend sein.

Eine Bewertungsmatrix hilft, diese Faktoren objektiv zu gewichten. Prozesse werden auf einer Skala von 1 bis 5 in den genannten Kategorien bewertet. Je nach Unternehmensprioritäten können die Dimensionen unterschiedlich gewichtet werden, z. B. 40 % finanzielle Auswirkungen, 30 % Kundeneinfluss und 30 % strategische Bedeutung. Die Gesamtscores ergeben eine Rangliste der kritischsten Prozesse.

Diese Methode minimiert subjektive Verzerrungen, da Abteilungen oft dazu neigen, ihre eigenen Prozesse als besonders wichtig einzustufen. Eine transparente Bewertungsmatrix schafft Klarheit und liefert fundierte Argumente für spätere Priorisierungen. Die so erstellte Rangliste ist eine unverzichtbare Grundlage für die nächsten Schritte, wie die Analyse von Risiken und die Planung der Wiederherstellung.

Schritt 3: Bewertung der Auswirkungen und Risiken

Nachdem die kritischen Prozesse identifiziert wurden, ist es an der Zeit, ihre Risiken und Auswirkungen zu bewerten – und zwar aus finanzieller, operativer, rechtlicher und reputationsbezogener Sicht. Dabei geht es darum, konkrete und messbare Dimensionen zu analysieren.

Finanzielle Auswirkungen

Die finanziellen Folgen eines Ausfalls lassen sich in drei Hauptkategorien einteilen: direkte Umsatzverluste, zusätzliche Kosten und langfristige Effekte.

Direkte Umsatzverluste: Wenn ein Prozess stillsteht, fallen Einnahmen weg. Beispiel: Eine Produktionslinie mit einem Wochenumsatz von 500.000 € verliert bei einem 24-stündigen Ausfall etwa 71.000 €. Zieht man variable Kosten von 200.000 € pro Woche ab, ergibt sich ein Deckungsbeitragsverlust von rund 43.000 € pro Tag. Je nach Bereich variieren die Berechnungen. Im Vertrieb könnten entgangene Abschlüsse oder verzögerte Rechnungsstellungen ins Gewicht fallen, während im IT-Bereich Vertragsstrafen greifen können, z. B. 5 % der monatlichen Gebühr pro Ausfalltag laut SLA. Auch im E-Commerce sind Umsatzeinbußen, etwa bei einem Plattformausfall in der Hauptsaison, leicht über historische Verkaufsdaten zu quantifizieren.
Zusätzliche Kosten: Dazu gehören Überstunden, Notfallmaßnahmen, externe Dienstleistungen oder Express-Lieferungen. Solche Kosten werden oft unterschätzt, können aber schnell erheblich werden.
Langfristige Effekte: Kundenverluste, Vertragsstrafen oder höhere Kosten für die Neukundengewinnung können die Folge sein. Nach einem größeren Vorfall ist eine Kundenabwanderung von 10–15 % keine Seltenheit und sollte in die Analyse einfließen.

Zur Bewertung können Buchhaltungsdaten oder konservative Schätzungen herangezogen werden. Wichtig ist, alle Annahmen klar zu dokumentieren.

Operative Auswirkungen

Die operativen Folgen eines Ausfalls sind direkt im Arbeitsalltag spürbar: Prozesse funktionieren nur eingeschränkt, die Produktivität sinkt, und Rückstände häufen sich. Diese Folgen sollten anhand messbarer Kennzahlen bewertet werden.

Ausfalldauer: Die Dauer eines Ausfalls ist ein zentraler Faktor. Typische Zeitfenster sind z. B. 4–8 Stunden für die erste Störungsphase, 24 Stunden für einen kompletten Geschäftstag oder 7+ Tage für längere Unterbrechungen. Für jedes Szenario sollte analysiert werden, wie sich die Auswirkungen mit der Zeit verändern.
Leistungseinbußen: Diese lassen sich prozessspezifisch messen. Ein Kundenservice-Center könnte z. B. ohne Zugriff auf das CRM-System eine Verlängerung der Bearbeitungszeit von 5 auf 15 Minuten pro Anruf erleben, während die Erstlösungsquote von 80 % auf 30 % sinkt. In der Logistik könnte eine Systemstörung dazu führen, dass 50 % der täglichen Sendungen verspätet ankommen.
Rückstau: Mit jedem Tag des Ausfalls wächst der Rückstand. Nach Wiederherstellung der Prozesse müssen diese Rückstände abgearbeitet werden, was die Erholungsphase verlängert und zusätzliche Ressourcen bindet.
SLA-Verletzungen: Werden vereinbarte Servicezeiten oder Verfügbarkeitsgarantien nicht eingehalten, können Vertragsstrafen oder sogar Kündigungen drohen. Diese Risiken sollten für jeden kritischen Prozess dokumentiert werden.

Die Bewertung dieser Kennzahlen erfolgt in enger Abstimmung mit den Prozessverantwortlichen, die die operativen Grenzen realistisch einschätzen können. Diese Schwellenwerte sind später entscheidend für die Festlegung der Maximum Tolerable Downtime (MTD).

Rechtliche und reputationsbezogene Folgen

Ein Prozessausfall kann auch rechtliche und reputationsbezogene Probleme mit sich bringen. In Deutschland sind hier besonders folgende Bereiche relevant:

Datenschutzrechtliche Risiken: Die DSGVO und das Bundesdatenschutzgesetz fordern strenge Maßnahmen zum Schutz personenbezogener Daten. Ein Datenverlust oder unbefugter Zugriff kann Bußgelder von bis zu 4 % des weltweiten Jahresumsatzes nach sich ziehen. Prozesse, die mit personenbezogenen Daten arbeiten, bergen daher ein hohes Risiko.
Vertragliche Verpflichtungen: Werden Liefertermine, SLA-Vorgaben oder andere Zusagen nicht eingehalten, drohen Vertragsstrafen, Schadensersatzforderungen oder sogar der Verlust wichtiger Kundenbeziehungen.
Branchenspezifische Vorgaben: In vielen Branchen gelten zusätzliche Anforderungen. Finanzdienstleister müssen strenge regulatorische Auflagen erfüllen, Gesundheitseinrichtungen sind an hohe Versorgungsstandards gebunden, und Energieversorger unterliegen spezifischen gesetzlichen Regelungen. Diese Vorgaben erhöhen das Risiko rechtlicher Konsequenzen bei einem Ausfall und sollten bei der Analyse berücksichtigt werden.

Die Ergebnisse dieser Bewertung fließen in die Festlegung relevanter Kennzahlen ein und bilden eine Grundlage für die weiteren Schritte.

Schritt 4: Definition kritischer Kennzahlen

Nach der bisherigen Analyse werden nun messbare Kennzahlen wie MTD, RTO und RPO festgelegt. Diese übersetzen die identifizierten Risiken in konkrete Vorgaben und bilden die Grundlage für alle weiteren Maßnahmen.

Dabei ist Konsistenz entscheidend: Das RTO liegt immer unter der MTD und beeinflusst sowohl die erforderlichen Maßnahmen als auch die damit verbundenen Kosten. Eine realistische und risikobasierte Festlegung hilft, unnötige Ausgaben oder unzureichende Investitionen zu vermeiden.

Maximum Tolerable Downtime (MTD)

Die Maximum Tolerable Downtime (MTD) beschreibt die maximal tolerierbare Ausfallzeit eines Geschäftsprozesses, bevor die Auswirkungen für das Unternehmen nicht mehr akzeptabel sind. Wird diese Grenze überschritten, drohen schwerwiegende Konsequenzen wie erhebliche Umsatzeinbußen, dauerhafte Reputationsschäden, Vertragsstrafen oder rechtliche Probleme.

Die MTD wird aus der Auswirkungsanalyse (Schritt 3) abgeleitet. Für jeden kritischen Prozess wird gefragt: Wie lange kann dieser Prozess ausfallen, bevor finanzielle, operative, rechtliche oder reputationsbezogene Schäden untragbar werden? Die Antwort wird in Minuten, Stunden oder Tagen festgehalten und mit Management und Fachbereichen abgestimmt.

Ein Beispiel: Ein Online-Händler definiert für sein Bestellsystem eine MTD von 6 Stunden. Bei einem durchschnittlichen Stundenumsatz von 10.000 € würde ein 6-stündiger Ausfall zu einem direkten Verlust von 60.000 € führen. Hinzu kämen potenzielle Kundenabwanderung, negative Bewertungen und Vertragsstrafen. Überschreitet der Ausfall diese Grenze, wird er geschäftskritisch.

Die MTD dient als Obergrenze für Wiederherstellungsmaßnahmen. Sie ist kein technisches Ziel, sondern eine geschäftliche Toleranzgrenze, die den Übergang vom „Problem“ zur „Krise“ markiert. Diese Werte werden für jeden kritischen Prozess individuell ermittelt und dokumentiert, da die Toleranzgrenzen je nach Geschäftsbereich variieren.

Nach der MTD werden operative Ziele wie RTO und RPO definiert.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO)

Während die MTD die absolute Schmerzgrenze beschreibt, geben RTO und RPO konkrete Zielvorgaben für die Wiederherstellung – sowohl in Bezug auf Zeit als auch auf Datenstand.

Recovery Time Objective (RTO): Das RTO gibt an, wie schnell ein Prozess oder System nach einer Störung wieder funktionsfähig sein muss. Es liegt immer unter der MTD, um einen Sicherheitspuffer zu gewährleisten. Hat ein Kundenservice-Portal eine MTD von 8 Stunden, wird das RTO häufig auf 4 Stunden festgelegt. Diese 4 Stunden bestimmen, wie schnell IT und Fachbereiche den Prozess wiederherstellen müssen – etwa durch Backups, Ausweicharbeitsplätze oder manuelle Notfallverfahren.
Recovery Point Objective (RPO): Das RPO definiert den maximal akzeptablen Datenverlust, gemessen in Zeit. Es beantwortet die Frage: Wie alt dürfen die wiederhergestellten Daten maximal sein? Ein RPO von 30 Minuten bedeutet, dass höchstens Daten der letzten halben Stunde verloren gehen dürfen. Diese Vorgabe beeinflusst direkt die Backup-Strategie: Tägliche Sicherungen führen zu einem RPO von bis zu 24 Stunden, während kontinuierliche Replikation ein RPO nahe null ermöglicht.

Die Unterscheidung zwischen RTO und RPO ist entscheidend. So könnte ein Zahlungsverkehrssystem ein RTO von 30 Minuten und ein RPO von 5 Minuten haben, während ein HR-Berichtssystem mit einem RTO und RPO von jeweils 24 Stunden auskommt. Die Anforderungen hängen stark von der Kritikalität des Prozesses ab.

Die Festlegung realistischer RTO- und RPO-Werte erfolgt durch Workshops mit Stakeholdern, die Analyse historischer Vorfälle und finanzielle Modellierungen. Prozessverantwortliche bewerten, welche Ausfallzeiten und Datenverluste akzeptabel sind, während IT-Teams prüfen, was technisch möglich ist. Auch rechtliche Vorgaben wie die DSGVO oder vertragliche SLAs fließen in die Bewertung ein.

Ein häufiger Fehler besteht darin, RTO und RPO zu optimistisch anzusetzen, ohne die technische Machbarkeit oder entstehende Kosten zu berücksichtigen. Zum Beispiel ist ein RTO von 15 Minuten für ein älteres System, das mindestens 4 Stunden zur Wiederherstellung benötigt, unrealistisch und führt im Ernstfall zu Problemen. Ebenso wenig sollte man Kennzahlen ausschließlich für IT-Systeme definieren, ohne die betroffenen Geschäftsprozesse einzubeziehen.

Die Kennzahlen werden in der BIA-Dokumentation tabellarisch erfasst, zum Beispiel:

Prozessname	MTD	RTO	RPO	Kritikalitätsstufe
Zahlungsverkehr	2 Stunden	30 Minuten	5 Minuten	Hoch
HR-Berichtssystem	24 Stunden	24 Stunden	24 Stunden	Niedrig

Zusätzlich können Heatmaps oder Prioritätsmatrizen Prozesse nach RTO-Klassen gruppieren (z. B. <1 Stunde, 1–4 Stunden, >4 Stunden), um Wiederherstellungsprioritäten sichtbar zu machen.

Die Werte sind keine fixen Größen. Sie sollten mindestens einmal jährlich oder bei wesentlichen Änderungen – wie neuen Systemen, Cloud-Migrationen oder Fusionen – überprüft und angepasst werden. Moderne Ansätze setzen verstärkt auf dynamische, datenbasierte BIAs, bei denen Kennzahlen kontinuierlich mit Monitoring- und Incident-Daten abgeglichen werden.

Schritt 5: Ressourcen- und Abhängigkeitsanalyse

Nachdem die kritischen Kennzahlen festgelegt sind, steht nun eine gründliche Untersuchung der unterstützenden Ressourcen an. Dabei geht es darum, alle notwendigen Ressourcen und Abhängigkeiten systematisch zu erfassen, die für den Betrieb jedes kritischen Prozesses erforderlich sind. Ohne diesen Schritt bleiben Wiederherstellungspläne unvollständig, da nicht klar ist, welche Systeme, Personen und Partner im Ernstfall verfügbar sein müssen. Diese Analyse bildet – zusammen mit den Kennzahlen – die Grundlage, um gezielt Engpässe und Risiken zu erkennen.

Die Ressourcenanalyse liefert Antworten auf essenzielle Fragen: Welche IT-Systeme stützen den Prozess? Wie viele Mitarbeitende mit welchen Qualifikationen sind erforderlich? Welche externen Dienstleister spielen eine unverzichtbare Rolle?

Für jeden kritischen Prozess sollten mindestens folgende Ressourcenkategorien berücksichtigt werden:

Gebäude und Standorte
IT-Systeme und Anwendungen
Daten und Schnittstellen
Maschinen und Anlagen
Personal und Schlüsselrollen
Externe Dienstleister und Lieferanten
Kommunikationsmittel
Unterstützende Infrastruktur

Die Ergebnisse dieser Analyse werden in einer standardisierten Prozess-Steckbrief-Vorlage festgehalten. Diese Vorlage enthält unter anderem Ressourcenlisten, Abhängigkeiten, Single Points of Failure, MTD/RTO/RPO und Notfall-Workarounds.

Technologie und IT-Systeme

Die Analyse kritischer IT-Ressourcen beginnt mit einem Abgleich zwischen den identifizierten Prozessen und dem IT-Service-Katalog oder der Configuration Management Database (CMDB). Für jeden Prozess werden alle relevanten Anwendungen, Datenbanken, Server und Schnittstellen zugeordnet.

Wichtige Informationen, die für jedes System dokumentiert werden sollten, umfassen:

Zweck und unterstützte Prozesse
Hosting-Art (z. B. On-Premises, Cloud innerhalb oder außerhalb der EU)
Technische Abhängigkeiten
Lizenz- und Wartungsverträge
Vorhandene Redundanzen

Diese Daten lassen sich aus Asset-Listen, Anwendungsverzeichnissen oder Architektur-Repositories gewinnen.

Die Priorisierung der IT-Ressourcen erfolgt anhand verschiedener Kriterien, wie z. B.:

Umsatzverlust bei Ausfall (pro Stunde oder Tag in Euro)
Anzahl betroffener Kunden
Regulatorische Anforderungen
MTD der abhängigen Prozesse
Nutzerzahl in Spitzenzeiten
Verfügbarkeit alternativer Lösungen oder Workarounds

Ein Beispiel: Für einen deutschen Online-Händler gehören das Shop-System, Zahlungsdienst-Anbindungen, Warenwirtschaft und Logistik-Schnittstellen zu den höchstpriorisierten Systemen. Bereits eine Stunde Ausfall könnte hier zu Umsatzeinbußen von mehreren zehntausend Euro führen.

Ein bewährter Ansatz zur Abhängigkeitsanalyse kombiniert Workshops mit Fachbereichen und IT, Architekturdiagramme sowie die Auswertung von Monitoring- und Ticket-Daten. In Architekturdiagrammen werden Prozesse, Fachanwendungen, Datenbanken, Middleware und Infrastruktur-Services wie DNS, Active Directory, VPN, Netzwerk oder Backup visualisiert. Abhängigkeiten werden dabei nach Kritikalität (hoch/mittel/niedrig) markiert.

Single Points of Failure (SPOF) lassen sich durch die Prüfung identifizieren, welche Komponenten ohne Redundanz mehrere kritische Prozesse gleichzeitig unterstützen. Beispiele hierfür sind zentrale Filesysteme, einzelne Netzwerkanbindungen oder ein Lock-In bei einer Cloud-Region. Cloud-basierte Abhängigkeiten – etwa SaaS-Lösungen – sollten mit SLA-Daten, RPO-/RTO-Zusagen und Exit-Optionen ergänzt werden, um Risiken bei Ausfällen oder Anbieterwechseln zu bewerten.

In regulierten Branchen wie dem Finanzwesen oder bei kritischen Infrastrukturen empfiehlt es sich, die BSI-Vorgaben heranzuziehen. Diese fordern eine genaue Identifikation kritischer IT-Ressourcen sowie die Definition von Wiederanlaufzeiten nach Unterbrechungen.

Neben technologischen Abhängigkeiten spielt auch die Verfügbarkeit von qualifiziertem Personal eine entscheidende Rolle.

Personal und Kompetenzen

Für jeden kritischen Prozess sollte ein Rollen- und Kapazitätsprofil erstellt werden, das folgende Punkte abdeckt:

Wichtige Rollen (z. B. Sachbearbeiter, Produktionsplaner, SAP-Key-User)
Erforderliche Kompetenzen und Qualifikationen
Mindestanzahl an Personen pro Rolle für den Notbetrieb
Vertretungsregelungen
Besondere Anforderungen (z. B. Sprachkenntnisse oder Compliance)

Die Dokumentation sollte Rollen und Funktionen statt individueller Namen enthalten, um unabhängig von einzelnen Personen zu bleiben. Dabei ist es wichtig, die minimale Besetzung und die Wiederherstellungszeit für Personal zu berücksichtigen: Wie lange dauert es, bis ausreichend qualifizierte Mitarbeitende verfügbar sind, um den Prozess wieder aufzunehmen? Aspekte wie Schichtpläne, Rufbereitschaften und Schulungsdauer spielen hier eine Rolle.

Risiken durch Schlüsselpersonen werden sichtbar, wenn nur wenige Mitarbeitende über kritisches Wissen verfügen und es keine dokumentierten Vertretungen oder Übergabeszenarien gibt. Solche Fälle werden in der BIA als SPOF markiert. Maßnahmen wie Cross-Training, Job-Rotation oder eine bessere Dokumentation können hier Abhilfe schaffen. Eine einfache Checkliste hilft: Was passiert, wenn diese Person heute ausfällt? Gibt es Alternativen? Wie lange dauert es, diese zu aktivieren?

Eine praxisnahe Methode zur Berechnung des Mindestpersonalbedarfs ist die Prozesszeit-Analyse. Hierbei werden Volumenkennzahlen wie die Anzahl der täglichen Vorgänge, die durchschnittliche Bearbeitungszeit pro Vorgang und das Service Level ermittelt. Diese Daten ermöglichen die Berechnung der benötigten FTE-Zahl für den Normal- und Notbetrieb.

Diese umfassende Ressourcen- und Abhängigkeitsanalyse ergänzt die zuvor definierten Kennzahlen und liefert ein vollständiges Bild der Wiederherstellungsfähigkeit kritischer Prozesse.

Schritt 6: Dokumentation und Berichterstattung der Ergebnisse

Nach Abschluss der Ressourcen- und Abhängigkeitsanalyse werden die Erkenntnisse der Business Impact Analysis (BIA) in einem strukturierten Bericht zusammengefasst. Dieser Bericht ist das zentrale Werkzeug, um das Management bei der Entscheidungsfindung zu unterstützen, Notfallpläne zu entwickeln und Investitionen in die Geschäftskontinuität gezielt zu priorisieren. Ohne eine klare und prägnante Dokumentation können selbst die besten Analysen nicht in konkrete Maßnahmen umgesetzt werden.

Der Bericht sollte so gestaltet sein, dass alle relevanten Zielgruppen – von der Geschäftsführung bis zu den Fachbereichen und IT-Verantwortlichen – die wichtigsten Risiken, Prioritäten und Maßnahmenvorschläge auf einen Blick verstehen. Es geht nicht darum, ein umfangreiches Nachschlagewerk zu erstellen, sondern ein präzises, handlungsorientiertes Dokument zu liefern. Beispiele für empfohlene Maßnahmen könnten die Einrichtung redundanter Systeme, Änderungen bei Vertretungsregelungen oder neue Verhandlungen mit Lieferanten sein.

Die Dokumentation erfolgt auf Deutsch und orientiert sich an der landesüblichen Zahlen- und Datumsformatierung (TT.MM.JJJJ). Besonders in regulierten Branchen ist es wichtig, die Einhaltung deutscher und europäischer Standards detailliert zu dokumentieren.

Kernbestandteile des BIA-Berichts

Ein umfassender BIA-Bericht besteht aus mehreren klar strukturierten Abschnitten, die unterschiedliche Zielgruppen ansprechen:

Management Summary: Auf maximal zwei Seiten werden die wichtigsten Erkenntnisse zusammengefasst. Dazu gehören die kritischsten Prozesse, finanzielle Risiken und empfohlene Maßnahmen. Zum Beispiel: „Ein Ausfall des Shop-Systems verursacht nach 4 Stunden einen Umsatzverlust von 85.000,00 € pro Tag."
Ziele und Umfang: Dieser Abschnitt beschreibt den Rahmen der Analyse: Welche Standorte, Geschäftsbereiche und Prozessgruppen wurden betrachtet? In welchem Zeitraum fand die Analyse statt? Zudem wird dargestellt, wie die BIA in das übergeordnete Notfall- oder Business Continuity Management eingebettet ist.
Methodik: Hier wird erläutert, wie die Daten erhoben wurden – etwa durch Interviews, Workshops oder standardisierte Fragebögen. Es sollten auch die Bewertungsskalen erklärt werden, z. B. zur Klassifizierung finanzieller Auswirkungen (< 50.000 €, 50.000–250.000 €, > 1.000.000 € pro Tag) oder operativer, rechtlicher und reputationsbezogener Folgen (gering, mittel, hoch, sehr hoch). Eine transparente Methodik sorgt für Nachvollziehbarkeit.
Hauptteil: Für jeden kritischen Prozess wird ein detaillierter Steckbrief erstellt. Dieser enthält eine Beschreibung des Prozesses, Verantwortlichkeiten, Auswirkungen sowie relevante Kennzahlen und Ressourcenübersichten. Besonders wichtig ist die Kennzeichnung von Single Points of Failure – etwa ein zentrales IT-System ohne Redundanz oder eine Schlüsselperson ohne Vertretung. Solche Schwachstellen sollten visuell hervorgehoben werden.
Priorisierung und Empfehlungen: Hier werden die Prozesse nach ihrer Wiederherstellungsdringlichkeit geordnet. Es wird aufgezeigt, welche Maßnahmen und Ressourcen notwendig sind, um die definierten RTO- und RPO-Ziele zu erreichen. Beispiele für Empfehlungen könnten sein: „Einrichtung eines zweiten Rechenzentrums in Deutschland für das ERP-System“ oder „Schulung von drei weiteren Mitarbeitenden für die Rolle des SAP-Key-Users“.
Verbindung zu Notfall- und Continuity-Plänen: Abschließend wird dargestellt, wie die BIA-Ergebnisse in konkrete Notfallhandbücher, IT-Disaster-Recovery-Pläne und Lieferkettenstrategien integriert werden. Diese Verknüpfung baut auf den zuvor definierten Kennzahlen (MTD, RTO, RPO) und Ressourcenanalysen auf und zeigt, wie die BIA als Grundlage für das Business Continuity Management dient.

Um sicherzustellen, dass die Ergebnisse verbindlich sind, sollte der Bericht durch relevante Stakeholder und das Management formell freigegeben werden. Diese Freigabe signalisiert, dass die empfohlenen Maßnahmen und Prioritäten in der Praxis umgesetzt werden.

Visuelle Hilfsmittel und Vorlagen

Die Präsentation der BIA-Ergebnisse wird durch visuelle Darstellungen deutlich vereinfacht. Tabellen, Diagramme und Prozesslandkarten helfen dabei, komplexe Zusammenhänge verständlich darzustellen und die Entscheidungsfindung zu beschleunigen.

Eine Übersichtstabelle der kritischen Prozesse könnte folgende Spalten enthalten:

Prozessname
Verantwortlicher
Kritikalitätsstufe (z. B. A/B/C)
MTD, RTO, RPO
Geschätzte finanzielle Auswirkung pro Tag (in Euro)

Eine farbliche Kodierung (z. B. Rot für sehr kritisch, Gelb für mittel, Grün für gering) erleichtert die Orientierung – besonders für Entscheider ohne technischen Hintergrund.

Um die wichtigsten Kennzahlen wie MTD, RTO und RPO übersichtlich darzustellen, empfiehlt sich ein kompaktes, visuell ansprechendes Format, das diese Informationen auf einen Blick vermittelt.

Für Unternehmen, die ihre Berichterstellung weiter optimieren möchten, bietet makematiq maßgeschneiderte Beratung an. Durch die Integration standardisierter Vorlagen in digitale GRC- oder BCM-Plattformen können BIA-Ergebnisse effizient dokumentiert, visualisiert und in übergeordnete Strategien eingebunden werden.

Diese visuell aufbereiteten Ergebnisse bilden die Basis für die weiteren Schritte im Business Continuity Management.

Schritt 7: Validierung und kontinuierliche Verbesserung

Eine Business Impact Analyse (BIA) ist kein statisches Dokument, das einmal erstellt und dann vergessen werden kann. Die Geschäftswelt ist dynamisch – IT-Systeme, Prozesse und regulatorische Anforderungen ändern sich ständig. Damit die BIA ihren Zweck erfüllt und als belastbare Grundlage für das Business Continuity Management (BCM) dient, muss sie regelmäßig überprüft, validiert und aktualisiert werden.

Die Validierung stellt sicher, dass die zugrunde liegenden Daten korrekt sind und die Annahmen realistisch bleiben. Gleichzeitig sorgt die kontinuierliche Verbesserung dafür, dass die BIA mit den Veränderungen im Unternehmen Schritt hält und potenzielle Schwachstellen frühzeitig erkannt werden. Eine Überprüfung durch interne und externe Expert:innen sichert dabei die Praxisnähe und Relevanz der Analyse.

Validierung durch interne und externe Expert:innen

Nach der Fertigstellung der Dokumentation sollten Fachleute aus verschiedenen Bereichen die Ergebnisse der BIA prüfen. So wird sichergestellt, dass die Analyse in Hinblick auf Genauigkeit, Vollständigkeit und Plausibilität als Grundlage für Entscheidungen im BCM geeignet ist.

Interne Validierung: Die IT-Abteilung prüft technische Abhängigkeiten und Systeme, während die Finanzabteilung die finanziellen Auswirkungen bewertet. Compliance- und Rechtsabteilungen nehmen regulatorische Anforderungen unter die Lupe, und Fachbereichsleiter:innen bestätigen die Prozessbeschreibungen sowie operative Auswirkungen. Diese tiefergehende Prüfung ergänzt die in Schritt 6 beschriebene Freigabe.
Externe Validierung: Unabhängige Berater:innen oder Wirtschaftsprüfer:innen bieten eine objektive Perspektive. Sie erkennen oft übersehene Schwachstellen und vergleichen die Ergebnisse mit Best Practices. Besonders hilfreich ist diese externe Expertise bei der erstmaligen Erstellung der BIA, vor regulatorischen Audits oder nach wesentlichen Veränderungen im Unternehmen.

Viele Unternehmen kombinieren beide Ansätze: Während interne Expert:innen für regelmäßige Reviews sorgen, übernehmen externe Berater:innen alle zwei bis drei Jahre eine unabhängige Überprüfung.

Darüber hinaus sollte die Validierung auch die Wirksamkeit der BIA selbst überprüfen. Werden die definierten RTO- und RPO-Werte tatsächlich erreicht? Sind die identifizierten Single Points of Failure wirklich kritisch? Solche Fragen können durch Tests und Übungen beantwortet werden. Wenn beispielsweise ein Test zeigt, dass die Wiederherstellung eines Systems länger dauert als geplant, muss die BIA entsprechend angepasst werden.

Regelmäßige Überprüfungen und Aktualisierungen

Ohne regelmäßige Aktualisierung verliert eine BIA schnell an Wert. Standards wie das BSI IT-Grundschutz-Kompendium und ISO 22301 fordern daher einen zyklischen Verbesserungsprozess nach dem Plan-Do-Check-Act-Prinzip. Diese kontinuierliche Anpassung stellt sicher, dass das BCM stets auf aktuelle Herausforderungen vorbereitet ist.

Als Mindeststandard sollte die BIA einmal jährlich komplett überprüft werden. In Branchen mit schnellen Veränderungen oder in Unternehmen, die sich in der digitalen Transformation befinden, können halbjährliche oder sogar vierteljährliche Reviews sinnvoll sein. Der Rhythmus sollte in einer BCM-Richtlinie festgelegt und vom Management verbindlich vorgegeben werden.

Neben den geplanten Überprüfungen gibt es auch Ereignisse, die eine sofortige Aktualisierung der BIA erfordern:

Organisatorische Veränderungen: Fusionen, Übernahmen, Umstrukturierungen oder neue Geschäftsfelder.
Technologische Änderungen: Einführung neuer ERP-Systeme, Migration in die Cloud oder der Einsatz kritischer Automatisierungslösungen.
Regulatorische Neuerungen: Zum Beispiel die DORA-Verordnung oder aktualisierte BaFin-Rundschreiben.
Wesentliche Vorfälle: Störfälle, Cyberangriffe oder Beinahe-Vorfälle, die wertvolle Erkenntnisse liefern. Diese sollten systematisch ausgewertet und in die BIA integriert werden.
Änderungen bei Lieferanten und Partnern: Wechsel eines Cloud-Anbieters, Verlust eines Zulieferers oder neue Outsourcing-Vereinbarungen.

Diese anlassbezogenen Anpassungen ergänzen die regelmäßigen Reviews und sind ein integraler Bestandteil des BCM. Um den Überblick über fällige Überprüfungen und Aktualisierungen zu behalten, empfiehlt sich der Einsatz digitaler Tools und klar definierter Workflows. Unternehmen wie makematiq können dabei helfen, BIA-Prozesse in GRC-Plattformen (Governance, Risk, Compliance) zu integrieren und automatisierte Review-Zyklen zu etablieren.

Fazit

Eine Business Impact Analyse (BIA) ist nicht einfach nur eine Pflichtaufgabe – sie ist die Grundlage für die Widerstandsfähigkeit Ihres Unternehmens. Die sieben Schritte, die in diesem Leitfaden beschrieben wurden, helfen dabei, ein klares Bild davon zu bekommen, welche Prozesse wirklich geschäftskritisch sind, welche Folgen Störungen haben können und wie schnell diese behoben werden müssen.

Mit einer klaren Strategie im Hinterkopf und einem systematischen Vorgehen – von der Planung über die Identifikation kritischer Prozesse bis hin zur Festlegung von MTD, RTO und RPO – lassen sich die entscheidenden Schwachstellen und Abhängigkeiten im Unternehmen aufdecken. Die Analyse zeigt, wo Ressourcen fehlen, wo Single Points of Failure existieren und welche Maßnahmen notwendig sind. Eine gut dokumentierte BIA sorgt dafür, dass diese Erkenntnisse leicht verständlich und für das Management sowie alle Stakeholder nutzbar sind.

Wichtig ist: Eine BIA ist kein einmaliges Projekt, das nach Fertigstellung abgehakt wird. Die Geschäftswelt entwickelt sich ständig weiter – neue Technologien, veränderte Lieferketten oder verschärfte gesetzliche Vorgaben erfordern regelmäßige Anpassungen. Ohne kontinuierliche Updates verliert die Analyse schnell an Aussagekraft. Mindestens einmal im Jahr sollte die BIA überprüft und bei Bedarf aktualisiert werden. Auch nach wesentlichen Veränderungen im Unternehmen, wie einer Umstrukturierung oder der Einführung neuer IT-Systeme, ist eine Anpassung notwendig. Diese regelmäßige Pflege sorgt dafür, dass Ihre Notfallplanung stets auf dem neuesten Stand bleibt. Zudem können externe Berater bei der Umsetzung unterstützen und neue Perspektiven sowie bewährte Methoden einbringen.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) sieht die BIA als den ersten formalen Schritt im Notfallmanagement. Erst wenn die kritischen Prozesse und ihre Ausfallkosten bekannt sind, können Bedrohungen und Gegenmaßnahmen sinnvoll priorisiert werden.

Gerade für Unternehmen ohne eigene Expertise im Bereich Business Continuity Management (BCM) oder für solche, die sich inmitten großer Transformationsprojekte befinden, kann externe Unterstützung äußerst wertvoll sein. Besonders bei komplexen Vorhaben wie Cloud-Migrationen, der Modernisierung von IT-Architekturen oder KI-Projekten profitieren Unternehmen von Partnern, die Technologie, Strategie und organisatorischen Wandel miteinander verbinden. Anbieter wie makematiq bieten genau diesen umfassenden Ansatz, um BIA-Erkenntnisse in konkrete, messbare Ergebnisse zu übersetzen.

„Unser integrierter Ansatz verbindet Technologie, Strategie und organisatorischen Wandel zu messbaren Transformationsergebnissen." – makematiq

Warten Sie nicht, bis eine Krise Sie dazu zwingt – starten Sie Ihre BIA jetzt. Legen Sie fest, welche 10 bis 20 Prozesse zuerst analysiert werden sollen. Ein pragmatischer Einstieg ist besser als gar kein Schritt. Mit jeder Iteration können Sie den Reifegrad Ihrer Analyse steigern. Wer systematisch vorgeht und seine BIA regelmäßig aktualisiert, schafft die Grundlage für eine zukunftssichere Organisation.

Unternehmen, die eine strukturierte BIA und Business-Continuity-Planung implementieren, haben nachweislich bessere Chancen, schwere Störungen zu überstehen. Diese Stärke basiert auf klaren Analysen, gut gesetzten Prioritäten und vorbereiteten Wiederanlaufstrategien. Investieren Sie in die Widerstandsfähigkeit Ihres Unternehmens – bevor Sie sie dringend brauchen.

FAQs

Welche häufigen Fehler sollten bei der Durchführung einer Business Impact Analyse vermieden werden?

Wenn es um die Durchführung einer Business Impact Analyse (BIA) geht, gibt es einige Stolperfallen, die unbedingt vermieden werden sollten, um verlässliche Ergebnisse zu erzielen.

Einer der häufigsten Fehler ist die Verwendung von unvollständigen oder ungenauen Daten. Solche Daten können die Analyse verfälschen und zu fehlerhaften Schlussfolgerungen führen. Um dies zu vermeiden, ist es entscheidend, alle relevanten Geschäftsbereiche und Prozesse in die Analyse einzubeziehen.

Ein weiterer kritischer Punkt ist das Unterschätzen der Zusammenarbeit mit den Fachabteilungen. Die Einbindung von Stakeholdern aus verschiedenen Unternehmensbereichen stellt sicher, dass die Analyse praxisnah bleibt und alle wesentlichen Abhängigkeiten berücksichtigt werden. Ohne diese Zusammenarbeit können wichtige Details übersehen werden.

Ein oft übersehener Fehler ist, die BIA als einmalige Aufgabe zu betrachten. Unternehmen und Märkte verändern sich ständig, und die BIA sollte regelmäßig aktualisiert werden, um diesen Veränderungen gerecht zu werden und weiterhin nützliche Erkenntnisse zu liefern.

Mit einer gründlichen Planung, präziser Datenerhebung und enger Abstimmung mit den relevanten Teams lassen sich diese Fehler vermeiden – und die Grundlage für eine effektive Business Impact Analyse wird geschaffen.

Wie bleibt eine Business Impact Analyse aktuell und anpassungsfähig?

Um sicherzustellen, dass eine Business Impact Analyse (BIA) stets relevant bleibt und flexibel auf Veränderungen reagieren kann, sind regelmäßige Überprüfungen unerlässlich. Dabei sollte man nicht nur die ursprünglichen Annahmen kritisch hinterfragen, sondern auch Anpassungen an veränderte Geschäftsbedingungen vornehmen und die Bewertung von Risiken sowie potenziellen Auswirkungen aktualisieren.

Ein strukturierter Ansatz, wie ein jährlicher Überprüfungszyklus oder Anpassungen bei wesentlichen Veränderungen im Unternehmen, kann dabei helfen, die Analyse aktuell und nützlich zu halten. So bleibt die BIA ein zuverlässiges Instrument für fundierte Entscheidungen.

Wie können externe Berater eine Business Impact Analyse effektiver gestalten?

Externe Berater spielen eine entscheidende Rolle, wenn es darum geht, eine präzise und detaillierte Business Impact Analyse in Unternehmen durchzuführen. Sie bringen nicht nur tiefgehendes Fachwissen mit, sondern auch bewährte Ansätze und eine unvoreingenommene Sichtweise – etwas, das interne Teams oft schwer allein leisten können.

Dank ihrer Expertise in Bereichen wie digitaler Transformation, Prozessoptimierung und Datenanalyse können sie dabei helfen, die wichtigsten Geschäftsprozesse zu analysieren, potenzielle Risiken aufzudecken und fundierte Empfehlungen auszusprechen. Das Ergebnis? Klare, messbare Fortschritte und eine strategischere, zukunftsorientierte Planung für das Unternehmen.