Business Impact Analyse: Excel-Vorlage und Beispiel

Kunden warten auf ihre Lieferung. Nach vier Stunden soll das Team wieder Aufträge bearbeiten können – doch die benötigten Auftragsdaten sind erst nach sechs Stunden verfügbar. Auf dem Papier steht ein Wiederanlaufziel. Im Ernstfall bleiben die Aufträge liegen.

Eine Business Impact Analyse (BIA) hilft dir, solche Widersprüche vor dem Ausfall zu erkennen. Du klärst, welche Leistungen zuerst wieder verfügbar sein müssen, wie lange eine Unterbrechung tragbar ist und welche Ressourcen dafür bereitstehen müssen. Dieser Guide führt dich an einem ausgefüllten Beispiel durch die Bewertung. Mit der kostenlosen Excel-Vorlage überträgst du die Schritte auf eure Prozesse.

Was entscheidet eine Business Impact Analyse?

Die BIA betrachtet die Folgen einer Unterbrechung über die Zeit. Eine Stunde ohne Auftragsbearbeitung kann überbrückbar sein. Nach einem Tag fehlen Lieferfreigaben; nach drei Tagen drohen Vertragsverletzungen. Entscheidend ist, ab wann die Folgen für euren Betrieb nicht mehr tragbar sind.

Das Ergebnis ist eine begründete Reihenfolge für den Wiederanlauf: welche Prozesse, welches Mindestleistungsniveau und welche benötigten Ressourcen. Die kurze Definition der Business Impact Analyse findest du im Glossar.

Eine Risikoanalyse beantwortet eine andere Frage: Welche Ereignisse können eintreten, wie wahrscheinlich sind sie und welche Folgen hätten sie? Eine Risikomatrix hilft bei dieser Einordnung. In der BIA darf ein schwerer Ausfallschaden dagegen nicht durch eine geringe Eintrittswahrscheinlichkeit heruntergerechnet werden.

Der BSI-Standard 200-4 beschreibt die BIA als Bestandteil des Business Continuity Managements. Unsere Vorlage ist eine eigenständige Arbeitshilfe mit Beispielskalen, keine offizielle BSI-Vorlage.

1. Beginne mit der Leistung, die ausfallen kann

„Datenbank“ ist eine Ressource. „Kunden können ihre Aufträge abrufen“ beschreibt die Leistung, deren Ausfall du bewerten willst. Beginne deshalb mit dem Geschäftsprozess und ordne anschließend Systeme, Personen, Standorte und Dienstleister zu.

Die Priorität eines Assets folgt daraus, welche Geschäftsleistung es ermöglicht. Eine Datenbank ist hier relevant, weil ohne die Auftragsdaten keine Lieferung freigegeben werden kann.

Kläre mit der prozessverantwortlichen Person:

• Welche Leistung fällt im betrachteten Szenario aus?
• Wer ist betroffen: Kunden, Beschäftigte oder andere Prozesse?
• Gibt es Spitzenzeiten, feste Fristen oder vertragliche Zusagen?
• Welcher Notbetrieb wäre möglich und wie lange hält das Team ihn durch?
• Welches Mindestleistungsniveau muss nach dem Wiederanlauf erreicht sein?

Im Beispiel fällt die Kundenplattform vollständig aus. Eine telefonische Auskunft kann einzelne Anliegen auffangen, ersetzt aber nicht die Auftragsbearbeitung. Diese Grenze gehört in die Bewertung. Sonst wird aus einer kurzfristigen Ausweichlösung eine unrealistische Dauerannahme.

In der Vorlage: Erfasse Prozess, Verantwortliche, Ausfallszenario, Verpflichtungen und Notbetrieb im Blatt „Prozesse“. Ersetze die fiktiven Beispieldaten durch eure eigene Ausgangslage.

2. Bewerte, wie die Ausfallfolgen mit der Zeit wachsen

Lege vor der Erhebung gemeinsam mit der Leitung fest, welche Folgen als nicht mehr tragbar gelten. „Hoher Schaden“ reicht nicht. Brauchbar sind konkrete Grenzen: eine verletzte Lieferfrist, eine nicht mehr erbringbare Kundenleistung oder eine nicht tolerierbare Gefährdung von Menschen.

Die Vorlage betrachtet fünf Schadensdimensionen: Betrieb, finanzielle Folgen, Vertrag und Recht, Menschen und Umwelt sowie Vertrauen und Reputation. Die sechs voreingestellten Zeitpunkte reichen von vier bis 168 Stunden. Beides dient der strukturierten Bewertung; die Zeitpunkte und Schadenskriterien müssen zu eurem Betrieb passen.

Für die Kundenplattform ergibt sich im fiktiven Beispiel:

Die höchste Schadensdimension entscheidet. Ein kritischer Schaden für Menschen darf nicht durch niedrige finanzielle Folgen im Durchschnitt verschwinden. Halte für jede Bewertung fest, worauf sie beruht: Vertrag, Prozesswissen, Ausfallhistorie oder nachvollziehbare Annahme.

Eine leere Bewertung bedeutet „unbekannt“, nicht „kein Schaden“. Deshalb weist die Vorlage unvollständige Bewertungen aus und berechnet daraus keinen scheinbar belastbaren Zielwert.

3. Leite MTPD, RTO und RPO nachvollziehbar ab

Diese drei Größen beantworten unterschiedliche Fragen:

Die Vorlage zeigt den ersten bewerteten Zeitpunkt mit untragbaren Folgen. Das ist noch keine exakt bestimmte MTPD. Liegt die Grenze beim Acht-Stunden-Messpunkt, kann sie tatsächlich schon zwischen vier und acht Stunden überschritten werden. Prüfe diesen Zwischenraum und bestätige eine fachlich begründete Grenze.

Im Beispiel bestätigt die verantwortliche Person acht Stunden MTPD. Davon werden eine Stunde für Erkennen und Notfallausruf sowie eine Stunde Puffer eingeplant. Als RTO werden vier Stunden ab Notfallausruf beschlossen:

1 Stunde Reaktion + 4 Stunden Wiederanlauf + 1 Stunde Puffer = 6 Stunden.

Das liegt unter der bestätigten Grenze von acht Stunden. Dokumentiert den Startpunkt eurer Zeitmessung ausdrücklich: Ein RTO ab Ausfallbeginn und eines ab Notfallausruf sind nicht austauschbar. Die Begriffe erläutert auch unser Glossar zu RTO und RPO.

Das RPO wird separat entschieden. Wenn höchstens 30 Minuten Auftragsdaten verloren gehen dürfen, beträgt es 0,5 Stunden. Daraus folgt noch nicht, dass die vorhandene Sicherung dieses Ziel erfüllt. Dafür braucht ihr einen belastbaren technischen Nachweis.

4. Prüfe, ob die Abhängigkeiten eure Ziele zulassen

Jetzt wird aus der Bewertung eine konkrete Betriebsfrage. Für den Start der Plattform benötigt das Team die Datenbank und danach eine Stunde für Verbindung, Prüfung und Freigabe. Bei vier Stunden RTO muss die Datenbank also spätestens drei Stunden nach Notfallausruf verfügbar sein.

Die sechs Stunden Verfügbarkeit liegen drei Stunden hinter dem Ressourcenbedarf. Die Plattform könnte mit einer weiteren Stunde Vorlauf erst nach sieben Stunden starten. Damit verfehlt sie das beschlossene RTO von vier Stunden.

Ein vorhandenes Backup löst diesen Widerspruch nicht. Testet, wann die benötigten Daten tatsächlich nutzbar sind. Warum Sicherung, Zugriff und Wiederherstellung getrennt betrachtet werden müssen, zeigt der Beitrag zum ConnectWise-/SkyKick-Vorfall.

Wird dieselbe Ressource von mehreren Prozessen benötigt, zählt der früheste begründete Bedarf. Verwendet dafür in der Vorlage dieselbe Ressourcen-ID. Prüft zusätzlich, ob Personal und Kapazitäten für parallele Wiederanläufe reichen: Die Datei bewertet direkte Beziehungen, berechnet aber keinen vollständigen Ablaufplan für mehrstufige Abhängigkeiten.

Bei externen Leistungen sollte die BIA in eure Lieferantenbewertung einfließen. Eine allgemeine Verfügbarkeitszusage beantwortet noch nicht, wann eure konkrete Leistung nach einem Notfall wieder nutzbar ist.

5. Mache aus jeder Lücke eine Entscheidung

„Wiederanlauf zu spät“ ist ein Befund. Damit sich etwas verbessert, braucht es eine verantwortliche Person, eine Frist und einen Nachweis für das Ergebnis.

Für unsere Kundenplattform könnte der nächste Schritt lauten: „IT-Betrieb testet bis zum vereinbarten Termin ein alternatives Restore-Verfahren. Gemessen werden nutzbare Datenbank, anschließende Anwendungsprüfung und erreichbarer Datenstand.“ Erst das Testergebnis zeigt, ob die Lücke kleiner geworden ist.

Es gibt mehrere mögliche Entscheidungen: technische Wiederherstellung verbessern, einen belastbaren Notbetrieb etablieren oder den Prozess verändern. Auch ein Ziel kann neu bewertet werden. Es darf aber nicht allein deshalb verlängert werden, weil die heutige IT zu langsam ist. Die betrieblichen Schadensgrenzen bleiben der Maßstab.

Im Blatt „Maßnahmen“ dokumentiert ihr die Folgearbeit. Eine Maßnahme erhält erst mit Nachweis und Freigabe den Abschlussstatus. Die Freigabe eines Wiederanlaufziels allein belegt keine funktionierende Wiederherstellung.

6. Halte die BIA bei Veränderungen aktuell

Prüfe die Bewertung erneut, wenn sich eine tragende Annahme ändert: ein neuer Großkunde mit engeren Fristen, ein anderer Dienstleister, ein zusätzlicher Standort oder ein veränderter Prozess. Auch ein fehlgeschlagener Wiederherstellungstest ist ein Anlass.

Haltet fest, wer die Bewertung überprüft und bis wann. Bewahrt die frühere Entscheidungsgrundlage auf. So könnt ihr erklären, warum ein Prozess heute kritischer ist oder ein anderes Wiederanlaufziel braucht.

Die Excel-Vorlage hilft beim Einstieg und bei einer abgegrenzten Erhebung. Sie umfasst 20 Prozessplätze, 60 direkte Abhängigkeiten und 40 Maßnahmen. Für mehr Einträge müssen die Formeln und Auswertungsbereiche gezielt erweitert und erneut geprüft werden. Bei mehreren Teams entstehen außerdem Abstimmungen über Dateistände, Änderungen und Zuständigkeiten.

Von der BIA zur laufenden Sicherheitsarbeit mit Kopexa

Wenn sich ein Prozess ändert, sollte die Bewertung nicht in einer alten Datei liegen bleiben. In Kopexa könnt ihr Geschäftsprozesse, Informationswerte und Assets im gemeinsamen Kontext betrachten und eure BIA am Prozess bearbeiten. Das Prozessmanagement in Kopexa ist dafür der Ausgangspunkt.

Aus erkannten Lücken werden Maßnahmen mit Verantwortlichen. Nachweise liegen direkt an diesen Maßnahmen; die Maßnahmen werden den passenden Controls zugeordnet. So führt ihr die Arbeit aus der Analyse weiter und könnt später nachvollziehen, welche Prüfung eine Entscheidung trägt.