Business Impact Analyse (BIA): Leitfaden für österreichische Unternehmen

Ein Ransomware-Angriff legt am Montagmorgen die Auftragsbearbeitung still, ein Wasserschaden trifft den Serverraum, der Cloud-Dienstleister hat einen mehrstündigen Ausfall: Für die Geschäftsführung zählt in diesen Momenten nur eine Frage — was müssen wir zuerst wieder zum Laufen bringen, und wie viel Zeit haben wir dafür? Wer diese Frage erst im Ernstfall stellt, verliert wertvolle Stunden. Die Business Impact Analyse (BIA) beantwortet sie im Voraus.

Dieser Leitfaden richtet sich an österreichische kleine und mittlere Unternehmen (KMU) und zeigt den Prozess: wie Sie eine BIA in vier nachvollziehbaren Phasen durchführen, welche Kennzahlen dabei entstehen, wie eine schlanke Vorlage aussieht und welche Fehler Sie vermeiden sollten. Was eine BIA im Ergebnis alles liefert — von der Prozess-Priorisierung bis zum Abschlussbericht — ist ausführlich im Glossar unter Was ist eine Business Impact Analyse (BIA) beschrieben; dieser Beitrag konzentriert sich auf die Umsetzung.

Was eine BIA leistet — und wo sie im Business Continuity Management steht

Die Business Impact Analyse ist die Bestandsaufnahme, auf der jede Notfall- und Wiederanlaufplanung aufbaut. Sie identifiziert die Geschäftsprozesse, die für das Überleben des Unternehmens kritisch sind, bewertet die Folgen ihres Ausfalls im Zeitverlauf und leitet daraus konkrete Wiederanlaufziele ab.

Im Business Continuity Management (BCM) — dem Managementsystem, das die Fortführung des Betriebs bei Störungen sicherstellt — steht die BIA ganz am Anfang. Sie ist die Analyse-Grundlage, aus der Kontinuitätsstrategien, Notfallpläne und Wiederanlaufprozeduren erst abgeleitet werden. Vereinfacht gilt: Ohne BIA kein belastbares BCM — man würde Notfallpläne schreiben, ohne zu wissen, welche Prozesse sie überhaupt zuerst schützen müssen. Der Begriff und der Managementzyklus des Business Continuity Management (BCM) sind im Glossar gesondert erläutert.

Wichtig ist die Abgrenzung der Rollen: Die BIA misst und priorisiert, sie löst noch nichts. Sie stellt fest, dass die Lohnverrechnung maximal drei Tage stillstehen darf — welche technische oder organisatorische Maßnahme diesen Wiederanlauf sicherstellt, entscheidet erst die nachgelagerte Kontinuitätsplanung.

Warum die BIA für österreichische Unternehmen 2026 zur Pflicht wird

Für viele Betriebe war Business Continuity lange eine freiwillige Kür. Mit der Umsetzung der NIS2-Richtlinie in Österreich ändert sich das. Das NISG 2026 (Netz- und Informationssystemsicherheitsgesetz 2026, BGBl I 94/2025) tritt am 1. Oktober 2026 in Kraft und verpflichtet tausende österreichische Unternehmen — wesentliche und wichtige Einrichtungen in 18 Sektoren — zu konkreten Risikomanagementmaßnahmen. Wer betroffen ist und welche Fristen gelten, klärt der Leitfaden NIS2 umsetzen sowie die Fahrplan-Übersicht NISG 2026.

Entscheidend für die BIA ist eine bestimmte Maßnahme aus dem Pflichtenkatalog. NIS2 Art. 21 Abs. 2 lit. c verlangt Maßnahmen zur „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement”. Österreich übernimmt diese Vorgabe wortgleich in § 32 Abs. 4 lit. c NISG 2026. Business Continuity ist damit keine Empfehlung mehr, sondern gesetzliche Pflicht.

Das Wort „Business Impact Analyse” steht in beiden Rechtstexten zwar nicht. Aber die geforderte Aufrechterhaltung des Betriebs lässt sich nicht seriös planen, ohne vorher zu wissen, welche Prozesse überhaupt aufrechterhalten werden müssen und in welcher Reihenfolge. Genau das leistet die BIA. Sie ist der methodische Unterbau der gesetzlich geforderten Business Continuity — der Punkt, an dem die Compliance-Pflicht auf eine anerkannte Methode trifft.

Zwei weitere Vorgaben machen deutlich, dass die BIA nicht als einmaliges Dokument taugt:

• § 32 Abs. 4 lit. f NISG 2026 verlangt Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen. Eine BIA, die einmal erstellt und dann vergessen wird, kann diese Wirksamkeit nicht belegen.
• § 33 NISG 2026 fordert einen Wirksamkeitsnachweis: Betroffene Einrichtungen müssen der Cybersicherheitsbehörde innerhalb von zwölf Monaten nach Eintritt der Registrierungspflicht Informationen zu ihren umgesetzten Maßnahmen und den Ergebnissen ihrer Risikoanalyse übermitteln (Selbstdeklaration). Eine aktuelle, dokumentierte BIA ist hier ein handfester Baustein.

Für Geschäftsführer kommt hinzu: Die Verantwortung für diese Maßnahmen ist nicht delegierbar — mehr dazu im Ratgeber Geschäftsführerhaftung und Cybersicherheit.

BIA vs. Risikoanalyse — die Abgrenzung, die oft schiefgeht

Der häufigste konzeptionelle Fehler in KMU ist, BIA und Risikoanalyse zu verwechseln oder zu vermengen. Beide gehören zum Risikomanagement, beantworten aber unterschiedliche Fragen:

	Risikoanalyse	Business Impact Analyse
Kernfrage	Was kann passieren — und wie wahrscheinlich?	Was passiert, wenn ein Prozess ausfällt?
Blickrichtung	Ursache: Bedrohung × Schwachstelle	Wirkung: Folgen über die Zeit
Eintrittswahrscheinlichkeit	zentral (Wahrscheinlichkeit × Auswirkung)	bewusst ausgeblendet
Ergebnis	priorisierte Risiken, Maßnahmen	kritische Prozesse, RTO/RPO/MTD
Steuert …	welche Bedrohungen zuerst reduziert werden	welche Prozesse zuerst wiederhergestellt werden

Der springende Punkt: Die BIA interessiert sich nicht dafür, warum ein Prozess ausfällt. Ob Ransomware, Stromausfall, Wasserschaden oder ein ausgefallener Zulieferer — die Folgen eines dreitägigen Stillstands der Produktion sind dieselben. Genau deshalb bewertet die BIA die Auswirkungen unabhängig von der Eintrittswahrscheinlichkeit. Diese „All-Hazards”-Sicht deckt sich mit dem gefahrenübergreifenden Ansatz, den auch das NISG 2026 in § 32 Abs. 4 vorschreibt.

Die Risikoanalyse hingegen arbeitet mit Wahrscheinlichkeiten und Szenarien. Wie ein strukturierter Risikomanagement-Prozess nach ISO 27005 aufgebaut ist, beschreibt der Leitfaden für ein effektives Risikomanagement. In der Praxis liefern sich beide Analysen gegenseitig zu: Die BIA sagt, welche Prozesse besonders schützenswert sind; die Risikoanalyse untersucht dann, welche Bedrohungen genau diese Prozesse gefährden.

Die vier Phasen einer BIA

Eine BIA lässt sich in vier aufeinander aufbauende Phasen gliedern. Für ein KMU ist keine davon ein Großprojekt — entscheidend ist die Reihenfolge und die Einbindung der richtigen Personen.

Phase 1 — Scoping und Vorbereitung

Bevor Sie eine einzige Kennzahl erheben, legen Sie den Rahmen fest. Diese Phase entscheidet über die Qualität der gesamten BIA.

• Geltungsbereich abgrenzen: Welche Standorte, Abteilungen und Prozesse werden betrachtet? Für die erste BIA eines KMU ist es klüger, sich auf die Kernprozesse eines Standorts zu beschränken, als alles auf einmal zu erfassen.
• Prozesslandkarte erstellen: Listen Sie die Geschäftsprozesse auf und trennen Sie Kernprozesse (die direkt Wertschöpfung erzeugen: Produktion, Auftragsabwicklung, Leistungserbringung) von Unterstützungsprozessen (IT, Buchhaltung, HR). Nur so vermeiden Sie den klassischen Fehler, die BIA rein aus IT-Sicht zu führen.
• Schadenskategorien und Bewertungsskala definieren: Legen Sie fest, in welchen Dimensionen Sie Ausfallfolgen messen — typischerweise finanziell, rechtlich/regulatorisch, Reputation/Kundenvertrauen und je nach Branche Personensicherheit/Gesundheit. Definieren Sie eine einheitliche Skala (z. B. gering / spürbar / schwer / existenzbedrohend), damit Prozesse vergleichbar bewertet werden.
• Beteiligte festlegen: Wer liefert die Einschätzung? Das sind die Prozessverantwortlichen in den Fachbereichen, nicht allein die IT. Sichern Sie sich vorab den Auftrag und die nötigen Ressourcen von der Geschäftsführung.

Phase 2 — Erhebung der Ausfallfolgen

Jetzt erheben Sie für jeden Prozess im Scope: Was passiert, wenn dieser Prozess ausfällt — und wie entwickeln sich die Folgen über die Zeit?

Der Zeitverlauf ist der wichtigste und am häufigsten übersehene Aspekt. Der Schaden wächst selten linear. Beispiele:

• Ein Ausfall der Lohnverrechnung ist am ersten Tag unkritisch, wird aber zum gesetzlichen und arbeitsrechtlichen Problem, wenn der Auszahlungstermin näher rückt.
• Ein Stillstand der Produktion verursacht ab der ersten Stunde Kosten, kann aber bei Just-in-time-Lieferverträgen sprunghaft in Vertragsstrafen und Kundenverlust umschlagen.
• Der Ausfall des Webshops eines Online-Händlers trifft am „Black Friday” ungleich härter als in einer ruhigen Woche — Saisonalität gehört in die Bewertung.

Erheben Sie sowohl finanzielle Folgen (entgangener Umsatz, Vertragsstrafen, Wiederherstellungskosten, Behördenstrafen) als auch nicht-finanzielle Folgen (Reputationsschaden, Vertrauensverlust, rechtliche Konsequenzen). Als Methode eignen sich strukturierte Interviews und Workshops mit den Fachbereichen, ergänzt um einen einheitlichen Fragebogen. Halten Sie die Folgen jeweils für gestaffelte Zeitpunkte fest — etwa nach 1 Stunde, 4 Stunden, 1 Tag, 3 Tagen und 1 Woche.

Phase 3 — Kennzahlen ableiten: MTD, RTO und RPO

Aus dem Zeitverlauf der Ausfallfolgen ergeben sich die drei zentralen Planungskennzahlen. Sie sind das eigentliche „Messergebnis” der BIA.

• MTD (Maximum Tolerable Downtime) — auch als MTPD (Maximum Tolerable Period of Disruption) bezeichnet: die maximale Ausfalldauer, die ein Prozess verkraftet, bevor untragbarer Schaden entsteht. Sie lesen die MTD dort ab, wo die Schadenskurve die Grenze zum „nicht mehr tragbar” überschreitet.
• RTO (Recovery Time Objective): die Zielzeit für den Wiederanlauf. Das RTO muss immer kürzer als die MTD sein — es lässt einen Puffer, damit der Prozess wieder läuft, bevor der untragbare Schaden eintritt.
• RPO (Recovery Point Objective): der maximal tolerierbare Datenverlust, ausgedrückt als Zeitspanne. Ein RPO von 4 Stunden bedeutet: Es darf höchstens die Arbeit der letzten 4 Stunden verloren gehen — die Backups müssen also mindestens alle 4 Stunden laufen.

Diese Kennzahlen ordnet der Glossar-Eintrag Cybersecurity Kennzahlen, die zählen in den größeren Zusammenhang ein.

Phase 4 — Priorisierung und Integration ins BCM/ISMS

Zum Abschluss verdichten Sie die Ergebnisse zu einer Prioritätenreihenfolge: Welche Prozesse werden im Ernstfall zuerst wiederhergestellt? Ordnen Sie jedem kritischen Prozess seine Abhängigkeiten zu — IT-Systeme, Anwendungen, Schlüsselpersonen, Lieferanten und Dienstleister. Ein Prozess ist nur so schnell wiederherstellbar wie seine langsamste Abhängigkeit.

Das Ergebnis fließt anschließend in drei Richtungen weiter: in die Kontinuitätsstrategien und Notfallpläne des BCM, in die Risikobehandlung des ISMS und in einen BIA-Bericht ans Management, der die Priorisierung und den Ressourcenbedarf zusammenfasst.

Kennzahlen richtig setzen: ein KMU-Rechenbeispiel

Kennzahlen werden erst durch ein konkretes Beispiel greifbar. Nehmen wir eine österreichische Steuerberatungskanzlei mit drei Kernprozessen. Die Werte sind illustrativ und dienen der Veranschaulichung der Methode:

Prozess	Schaden bei Ausfall	MTD	RTO	RPO
Lohnverrechnung (zum Monatsende)	Fristversäumnis, arbeitsrechtliche Folgen	3 Tage	24 Std.	24 Std.
Laufende Mandantenbuchhaltung	Verzögerung, aber aufholbar	5 Tage	48 Std.	24 Std.
E-Mail / Mandantenkommunikation	Vertrauensverlust, Terminchaos	8 Std.	4 Std.	1 Std.

Was die Tabelle zeigt: Die Mandantenkommunikation hat die kürzeste MTD und damit die höchste Wiederanlaufpriorität — obwohl der direkte finanzielle Schaden geringer ist als bei der Lohnverrechnung. Nicht die Höhe des Schadens allein entscheidet, sondern wie schnell er untragbar wird.

Aus den Werten folgen sofort technische Konsequenzen: Ein RPO von 1 Stunde für die E-Mail-Kommunikation bedeutet, dass ein tägliches Backup nicht ausreicht — hier braucht es kontinuierlichere Sicherung. Ein RTO von 4 Stunden erfordert eine Wiederanlauflösung, die tatsächlich in vier Stunden greift. Genau an dieser Stelle deckt die BIA oft eine Lücke auf: Der gewünschte RTO steht dem, was die vorhandene Backup- und Recovery-Fähigkeit real hergibt, gegenüber. Diese Differenz ist eine der wertvollsten Erkenntnisse der ganzen Analyse.

Ein zweites Beispiel zeigt, wie stark die Werte vom Geschäftsmodell abhängen: Ein metallverarbeitender Zulieferbetrieb mit Just-in-time-Verträgen an die Automobilindustrie bewertet den Ausfall seiner Fertigungssteuerung völlig anders als eine Kanzlei. Hier läuft der Schaden nicht in Tagen, sondern in Stunden auf — verpasst eine Lieferung das Zeitfenster beim Kunden, drohen Vertragsstrafen und im Extremfall die Auslistung als Lieferant. Die MTD des Steuerungssystems kann dann bei wenigen Stunden liegen, mit einem entsprechend aggressiven RTO. Gleichzeitig zeigt die Abhängigkeitsanalyse, dass der eigene Wiederanlauf wenig nützt, wenn ein vorgelagerter Rohstofflieferant ausfällt — die BIA muss also über die eigene Werkshalle hinaus denken.

BIA-Vorlage: Schritt-für-Schritt-Checkliste für KMU

Sie brauchen für eine erste BIA kein teures Tool — eine strukturierte Tabelle genügt. Die folgende Checkliste führt durch den Ablauf und benennt das jeweilige Ergebnis-Artefakt:

#	Schritt	Ergebnis-Artefakt
1	Geltungsbereich und Ziele festhalten	Scope-Dokument (½ Seite)
2	Kern- und Unterstützungsprozesse auflisten	Prozessliste
3	Schadenskategorien + Bewertungsskala definieren	Bewertungsschema
4	Prozessverantwortliche je Prozess benennen	Verantwortlichkeiten-Matrix
5	Ausfallfolgen im Zeitverlauf erheben (Interview/Workshop)	ausgefüllte BIA-Erhebungsbögen
6	Finanzielle und nicht-finanzielle Folgen bewerten	Schadensbewertung je Prozess
7	MTD, RTO und RPO ableiten	Kennzahlen-Tabelle
8	Abhängigkeiten je Prozess dokumentieren	Abhängigkeits-Übersicht
9	Prozesse nach Wiederanlaufpriorität ranken	Priorisierungsliste
10	Ergebnisse und Ressourcenbedarf zusammenfassen	BIA-Bericht ans Management
11	Review-Termin und Auslöser für Aktualisierung festlegen	Review-Plan (min. jährlich)

Eine sinnvolle Spaltenstruktur für den Erhebungsbogen je Prozess: Prozessname · Verantwortlicher · Beschreibung · Ausfallfolgen (1 h / 4 h / 1 Tag / 3 Tage / 1 Woche) · MTD · RTO · RPO · Abhängigkeiten (Systeme, Personen, Lieferanten) · Priorität. Wer strukturiert startet, kann die Vorlage über die Jahre verfeinern, statt sie jedes Mal neu zu erfinden.

Typische Fehler bei der BIA — und wie KMU sie vermeiden

Die meisten gescheiterten BIA-Projekte scheitern nicht an der Methode, sondern an denselben wiederkehrenden Mustern:

• IT-zentriert statt prozesszentriert. Wer nur nach Servern und Systemen fragt, erhält eine Systemliste, keine BIA. Setzen Sie am Geschäftsprozess an — die IT-Abhängigkeiten ergeben sich daraus, nicht umgekehrt.
• Fachbereiche nicht eingebunden. Die IT kann nicht wissen, ab wann ein Fristversäumnis in der Buchhaltung teuer wird. Nur die Prozessverantwortlichen kennen die tatsächlichen Ausfallfolgen. Ohne ihre Einschätzung bleibt die BIA Spekulation.
• BIA als Einmal-Dokument. Prozesse, Systeme und Lieferanten ändern sich. Eine BIA, die nach der Erstellung in der Schublade verschwindet, ist nach einem Jahr wertlos — und erfüllt die geforderte Wirksamkeitsbewertung nach § 32 Abs. 4 lit. f NISG 2026 nicht. Legen Sie einen festen Review-Zyklus fest.
• Wunsch-RTOs ohne Realitätscheck. Ein RTO von zwei Stunden auf dem Papier nützt nichts, wenn die Wiederherstellung real zwei Tage dauert. Gleichen Sie die BIA-Zielwerte immer mit der tatsächlichen Wiederanlauffähigkeit ab.
• Zu großer Scope beim ersten Durchlauf. Der Versuch, sofort alle Abteilungen lückenlos zu erfassen, führt zu Monaten ohne Ergebnis. Starten Sie mit den fünf bis zehn wichtigsten Prozessen und wachsen Sie iterativ.
• Abhängigkeiten und Lieferanten übersehen. Der eigene Prozess mag schnell wiederanlaufen — wenn aber ein kritischer Cloud-Dienst oder Zulieferer ausfällt, hilft das wenig. Die Lieferketten-Perspektive ist auch regulatorisch relevant (§ 32 Abs. 4 lit. d NISG 2026).

Von der BIA zum Notfallplan und ISMS

Die BIA ist kein Selbstzweck. Ihr Wert entsteht erst, wenn ihre Ergebnisse in die operative Vorsorge und in das Managementsystem einfließen.

Zum Notfallplan: Die Priorisierung und die RTO-/RPO-Werte aus der BIA sind die direkte Vorlage für die Wiederanlaufreihenfolge im Ernstfall. Wie ein solcher Plan für Cyberangriffe konkret aussieht, zeigt der Notfallplan für Cyberangriffe. Die BIA sagt was zuerst und wie schnell — der Notfallplan sagt wie.

Zum ISMS und zur Risikobehandlung: In einem Informationssicherheits-Managementsystem fließen die BIA-Ergebnisse in die Risikobehandlung ein — die Kombination aus niedriger Eintrittswahrscheinlichkeit und hoher Auswirkung ist der klassische Fall für Business-Continuity-Maßnahmen. Die Verzahnung mit dem Risikomanagement beschreibt der Leitfaden für ein effektives Risikomanagement.

Zu den Normen: International ist ISO 22301 der Standard für Business Continuity Management; die BIA ist dort der methodische Ausgangspunkt des Managementsystems. Auch ISO/IEC 27001:2022 verankert die Anbindung: Annex A.5.29 („Information security during disruption”) und der 2022 neu aufgenommene Control A.5.30 („ICT readiness for business continuity”) behandeln die Fortführung des Betriebs. A.5.30 macht die BIA sogar ausdrücklich zur Grundlage — die Anforderungen an die IKT-Kontinuität samt der Kennzahlen RTO und RPO leiten sich laut Norm aus der BIA ab. Wer ohnehin ein ISMS aufbaut, hat mit der BIA also gleich mehrere Controls im Blick; der Weg dorthin ist im Ratgeber ISMS aufbauen beschrieben.

Der Aufbau von BIA, BCM und ISMS bindet gerade in KMU knappe Ressourcen — und die Verantwortung dafür liegt bei der Leitungsebene. Wo intern die Kapazität oder die Erfahrung fehlt, übernimmt ein externer CISO diese Steuerung: von der BIA über die Business-Continuity-Strategie bis zum Wirksamkeitsnachweis. Die Schwester-Marke wermescher.com bündelt das in der Leistung Externer CISO (vCISO) ↗, die Incident Response und Business Continuity als eigene Säule führt.

Der beste Zeitpunkt für die erste BIA ist übrigens nicht der Tag nach dem ersten Vorfall — sondern jetzt, solange Sie die Reihenfolge in Ruhe festlegen können.