Wie führe ich eine Business Impact Analyse durch?

Ein Ausfall wird nicht erst dann kritisch, wenn ein Server, Lieferant oder Standort nicht verfügbar ist. Kritisch wird er, wenn Kunden nicht mehr versorgt werden, regulatorische Pflichten verletzt werden oder Entscheidungen zu spät getroffen werden. Wer eine Business Impact Analyse durchführen möchte, schafft genau für diese Lage eine belastbare Entscheidungsgrundlage: Welche Geschäftsprozesse müssen mit welcher Priorität weiterlaufen oder wieder anlaufen?

Die Business Impact Analyse, kurz BIA, ist kein reines Dokumentationsprojekt. Sie verbindet Geschäftsziele, operative Abläufe, IT-Services, personelle Ressourcen, Dienstleister und Standorte. Damit bildet sie das Fundament für Business Continuity Management (BCM), IT Service Continuity Management (ITSCM) und eine wirksame IT-Notfallvorsorge.

Was eine Business Impact Analyse leisten muss

Eine BIA beantwortet nicht nur die Frage, welche Prozesse wichtig sind. Sie macht die Folgen eines Ausfalls über die Zeit sichtbar und übersetzt sie in konkrete Anforderungen an Vorsorge und Wiederanlauf. Dazu gehören akzeptable Ausfallzeiten, Mindestbetriebsniveaus, Datenanforderungen und Abhängigkeiten.

Entscheidend ist die zeitliche Betrachtung. Ein Prozess kann nach zwei Stunden noch beherrschbar eingeschränkt sein, nach einem Arbeitstag jedoch erhebliche finanzielle, rechtliche oder reputative Schäden verursachen. Für andere Prozesse gilt das Gegenteil: Sie müssen nicht sofort vollständig verfügbar sein, benötigen aber verlässliche Datenbestände oder eine manuelle Ersatzlösung.

Das Ergebnis ist eine nachvollziehbare Priorisierung. Sie verhindert, dass Wiederanlaufmaßnahmen allein nach technischer Sicht oder nach der Lautstärke einzelner Fachbereiche geplant werden. Stattdessen richtet sich die Notfallvorsorge an der tatsächlichen Geschäftsauswirkung aus.

Business Impact Analyse durchführen: Der richtige Rahmen

Vor den Interviews und Bewertungen braucht die BIA einen klaren Auftrag. Die Geschäftsführung oder eine vergleichbar wirksame Governance-Instanz sollte Ziel, Geltungsbereich und Verantwortlichkeiten bestätigen. Ohne diese Rückendeckung geraten Fachbereiche schnell in Zielkonflikte: Das Tagesgeschäft drängt, Daten bleiben unvollständig und kritische Annahmen werden nicht entschieden.

Der Geltungsbereich muss weder zu klein noch unnötig umfassend sein. Ein Einstieg kann sich auf zentrale Wertschöpfungsprozesse, regulatorisch relevante Leistungen oder kritische IT-Services konzentrieren. Bei KRITIS-Betreibern, unter NIS-2 fallenden Organisationen oder DORA-relevanten Finanzunternehmen wird der Scope häufig durch regulatorische Anforderungen und die Bedeutung wesentlicher Dienste mitbestimmt.

Ebenso wichtig ist ein einheitliches Bewertungsmodell. Wenn ein Fachbereich einen Ausfall nach Umsatzverlust bewertet, ein anderer nach Kundenzufriedenheit und ein dritter nach gesetzlichen Fristen, lassen sich Ergebnisse kaum vergleichen. Ein abgestimmter Kriterienkatalog schafft die notwendige Konsistenz, ohne die Besonderheiten einzelner Prozesse zu nivellieren.

Kritische Prozesse und Auswirkungen belastbar bewerten

Im Mittelpunkt stehen die Geschäftsprozesse, nicht Anwendungen oder Infrastrukturkomponenten. Ein ERP-System kann für mehrere Prozesse relevant sein, aber seine Priorität ergibt sich erst aus den Folgen für Einkauf, Produktion, Rechnungsstellung oder Lieferfähigkeit. Diese Perspektive schützt vor einer rein technischen Priorisierung, die geschäftliche Konsequenzen übersieht.

Für jeden Prozess werden Prozessverantwortliche und fachkundige Vertretungen eingebunden. In strukturierten Workshops oder Interviews wird erfasst, welches Ergebnis der Prozess liefert, wer darauf angewiesen ist und welche Folgen bei Unterbrechung entstehen. Gute Fragen sind konkret: Welche Verpflichtung kann nach einem Ausfall nicht erfüllt werden? Ab wann entstehen Vertragsstrafen? Welche Frist ist verbindlich? Welche Kunden, Behörden oder internen Einheiten sind betroffen?

Die Auswirkungen sollten mindestens finanzielle, rechtliche und regulatorische, operative sowie reputationsbezogene Aspekte abdecken. Je nach Organisation kommen Auswirkungen auf Sicherheit, Gesundheit, Umwelt oder die Versorgungssicherheit hinzu. Nicht jede Dimension hat in jedem Prozess dasselbe Gewicht. In einer öffentlichen Einrichtung kann die Aufrechterhaltung hoheitlicher Aufgaben entscheidender sein als ein kurzfristiger Umsatzverlust. In der Industrie können Produktionsunterbrechung, Arbeitssicherheit und Lieferverpflichtungen im Vordergrund stehen.

Bewährt hat sich eine Bewertung entlang definierter Zeitstufen, etwa nach wenigen Stunden, einem Tag, mehreren Tagen, einer Woche, einem Monat und >einem Monat. Dadurch wird aus der abstrakten Aussage „kritisch“ eine belastbare Aussage über den Zeitpunkt, an dem die Schadensgrenze erreicht wird. Diese zeitliche Schadensentwicklung ist die Grundlage für Wiederanlaufziele.

Wiederanlaufziele und Mindestbetrieb festlegen

Aus der BIA ergeben sich Kennzahlen, die BCM und ITSCM fachlich verbinden. Die maximale tolerierbare Ausfallzeit beschreibt, wie lange ein Prozess höchstens unterbrochen sein darf, bevor nicht akzeptable Auswirkungen eintreten. Das Recovery Time Objective, kurz RTO, definiert hingegen das angestrebte Zeitfenster für den Wiederanlauf. Es muss innerhalb der maximal tolerierbaren Ausfallzeit liegen und praktisch erreichbar sein.

Für datenverarbeitende Prozesse ist zusätzlich das Recovery Point Objective, kurz RPO, relevant. Es legt fest, welcher Datenverlust maximal akzeptabel ist. Ein RTO von vier Stunden hilft wenig, wenn die wiederhergestellten Daten einen ganzen Geschäftstag zurückliegen und offene Transaktionen nicht nachvollziehbar sind.

Nicht jeder Prozess muss sofort in voller Leistungsfähigkeit verfügbar sein. Deshalb sollte die BIA auch das Mindestbetriebsniveau festlegen. Kann eine Kundenhotline zunächst mit reduzierter Besetzung arbeiten? Lässt sich die Rechnungsprüfung zeitweise manuell abwickeln? Welche Produktlinien oder Kundengruppen haben Vorrang? Solche Festlegungen machen Notfallpläne umsetzbar und verhindern überzogene Anforderungen an IT und Fachbereiche.

Ein häufiger Fehler besteht darin, RTOs aus Wunschvorstellungen abzuleiten. Sehr kurze Wiederanlaufzeiten können erhebliche Investitionen in Redundanz, Replikation, Personalbereitschaft oder Ausweichkapazitäten auslösen. Die richtige Zielsetzung ist daher nicht automatisch die kürzeste Zeit, sondern ein angemessenes Verhältnis zwischen Geschäftsauswirkung, Risiko und Aufwand.

Abhängigkeiten sichtbar machen

Ein zeitkritischer Prozess funktioniert nicht isoliert. Er benötigt qualifizierte Mitarbeitende, Anwendungen, Daten, Berechtigungen, Kommunikationswege, Räumlichkeiten, Stromversorgung oder externe Partner. Gerade bei Lieferkettenunterbrechungen und Cloud- oder Managed-Service-Modellen reichen interne Prozessbeschreibungen nicht aus.

Die BIA sollte diese Abhängigkeiten so erfassen, dass sie für Wiederanlaufplanung und Krisenmanagement nutzbar sind. Besonders relevant sind Konzentrationsrisiken: ein einzelner Dienstleister, ein nicht vertretbares Spezialwissen, ein zentraler Standort oder eine Anwendung ohne dokumentierte Wiederherstellungsfähigkeit. Auch scheinbar nachgelagerte Dienste können kritisch sein. Ohne Identity Management, Netzwerkzugang oder Kommunikationsplattform kann eine fachlich verfügbare Anwendung unter Umständen nicht genutzt werden.

Hier zeigt sich der Nutzen der Zusammenarbeit von Fachbereichen, IT, Informationssicherheit, Einkauf und Risikomanagement. Die BIA liefert nicht alle Antworten allein, sie schafft jedoch die gemeinsame Faktenbasis. Für ITSCM werden daraus Anforderungen an Recovery-Verfahren und technische Wiederherstellung. Für Krisenmanagement entstehen Prioritäten für Lagebild, Kommunikation und Entscheidungen. Für Supply-Chain-Continuity-Management werden Lieferanten sichtbar, deren Ausfall den Geschäftsbetrieb gefährdet.

Ergebnisse validieren und in Maßnahmen überführen

Eine BIA ist erst belastbar, wenn die Ergebnisse abgestimmt und plausibilisiert sind. Prozessverantwortliche prüfen fachliche Annahmen, die IT bewertet technische Abhängigkeiten und Wiederanlauffähigkeiten, während Management und Risikoverantwortliche Prioritäten sowie akzeptierte Restrisiken bestätigen. Widersprüche gehören dabei zum Prozess. Wenn mehrere Bereiche für dieselbe Ressource höchste Priorität beanspruchen, braucht es eine nachvollziehbare Entscheidung statt paralleler Wunschlisten.

Die Ergebnisse sollten in einer zentralen, versionierten Struktur geführt werden. Tabellen können für einen ersten Durchlauf ausreichen. Mit wachsendem Scope, vielen Abhängigkeiten oder regelmäßigen Aktualisierungen stoßen sie jedoch an Grenzen. Eine Plattform wie [alive-IT] unterstützt dabei, BIA-Daten, Notfallpläne, Verantwortlichkeiten und Prüfzyklen konsistent zusammenzuführen und Änderungen nachvollziehbar zu halten.

Aus den festgelegten Anforderungen folgen konkrete Maßnahmen: Wiederanlaufpläne für kritische Prozesse, IT-Notfallkonzepte für priorisierte Services, Vertretungsregelungen, alternative Arbeitsplätze, zusätzliche Lieferantenvereinbarungen oder Krisenstabsverfahren. Welche Maßnahme geeignet ist, hängt von der Ursache des Ausfalls ab. Ein Cyberangriff verlangt andere Vorkehrungen als ein Gebäudeschaden oder der Ausfall eines Logistikpartners.

Die BIA als kontinuierliche Führungsaufgabe

Eine einmalige Analyse verliert schnell an Wert. Neue Anwendungen, Outsourcing, Umstrukturierungen, neue Produkte oder veränderte regulatorische Pflichten verändern die Kritikalität und die Abhängigkeiten. Deshalb braucht die BIA feste Überprüfungszyklen sowie anlassbezogene Aktualisierungen nach wesentlichen Änderungen und Übungen.

Besonders aussagekräftig wird sie, wenn ihre Annahmen praktisch geprüft werden. Kann der priorisierte IT-Service tatsächlich innerhalb des vereinbarten RTO wiederhergestellt werden? Sind die benannten Prozessverantwortlichen erreichbar? Funktioniert der definierte Mindestbetrieb unter realistischen Einschränkungen? Übungen machen aus dokumentierten Zielen überprüfbare Resilienz.

Eine sorgfältig durchgeführte BIA ist damit keine Pflichtübung für Audits. Sie schafft die Grundlage, auf deren Basis Organisationen im Ernstfall Prioritäten vertreten, Ressourcen gezielt einsetzen und handlungsfähig bleiben können.