Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten

Was die BIA leistet und warum sie an erster Stelle steht

Wenn du ein Business Continuity Management aufbaust, steht die Business Impact Analyse ganz am Anfang. Nicht weil es eine Vorschrift sagt (obwohl ISO 22301 und NIS2 sie fordern), sondern weil ohne BIA alle weiteren Entscheidungen auf Annahmen basieren statt auf Fakten.

Die zentrale Frage der BIA lautet: Was passiert, wenn ein Geschäftsprozess ausfällt - nach einer Stunde, nach einem Tag, nach einer Woche? Und welche Prozesse müssen deshalb zuerst wieder laufen?

Diese Fragen klingen simpel, aber die Antworten sind es selten. Ein Maschinenbauer mit 150 Mitarbeitern hat vielleicht 30 identifizierbare Geschäftsprozesse. Welche davon sind wirklich geschäftskritisch? Der Vertrieb würde sagen: Auftragserfassung. Die Produktion: Fertigungssteuerung. Die Buchhaltung: Zahlungsverkehr. Und alle haben irgendwie Recht. Die BIA bringt Struktur in diese Diskussion und liefert eine faktenbasierte Priorisierung, die alle Beteiligten nachvollziehen können.

Ohne BIA passiert Folgendes: Im Ernstfall entscheidet derjenige über die Wiederherstellungsreihenfolge, der am lautesten ruft oder zufällig am nächsten Morgen als Erster im Büro sitzt. Die IT stellt vielleicht den Mailserver zuerst wieder her, weil die Beschwerden dort am schnellsten kommen, während die Produktionsplanung steht und jeden Tag 50.000 Euro Umsatz verloren gehen.

BIA vs. Risikoanalyse - der Unterschied

Eine häufige Verwechslung: Die BIA ist nicht dasselbe wie eine Risikoanalyse. Beide Methoden sind Teil eines ISMS oder BCM, aber sie beantworten unterschiedliche Fragen.

Die BIA fragt nicht, ob etwas passiert, sondern was passiert, wenn es passiert. Sie betrachtet den Impact isoliert von der Eintrittswahrscheinlichkeit. Für die Betrachtung der Wahrscheinlichkeiten brauchst du eine separate Risikobewertung. Ein Prozess kann ein sehr hohes Impact haben, auch wenn die Ausfallwahrscheinlichkeit gering ist. Genau das macht die BIA wertvoll: Sie deckt Abhängigkeiten und Auswirkungen auf, die in einer reinen Risikobetrachtung untergehen können.

In der Praxis ergänzen sich beide Methoden. Die Risikoanalyse zeigt dir, welche Bedrohungen realistisch sind. Die BIA zeigt dir, welche Auswirkungen diese Bedrohungen auf dein Geschäft haben. Zusammen ergeben sie ein vollständiges Bild.

Schritt 1: Geschäftsprozesse identifizieren

Der erste Schritt der BIA ist die systematische Erfassung aller relevanten Geschäftsprozesse. Das klingt nach einer Fleißaufgabe, ist aber entscheidend, denn was du hier vergisst, taucht später in keinem Wiederanlaufplan auf.

Wie du Geschäftsprozesse findest

Am effektivsten funktioniert ein Top-down-Ansatz: Du startest bei den Geschäftsbereichen und arbeitest dich zu den einzelnen Prozessen vor.

Beispiel für einen Maschinenbauer:

Granularität: Wie tief musst du gehen?

Die richtige Granularität ist wichtig. Zu grob ("Produktion" als ein Prozess) hilft nicht bei der Priorisierung. Zu fein ("Einzelteil X auf Maschine Y fräsen") macht die Analyse unhandlich und liefert keinen Mehrwert.

Eine gute Faustregel: Jeder Prozess sollte einem klar identifizierbaren Verantwortlichen zugeordnet werden können und von einem identifizierbaren Set an IT-Systemen abhängen. Wenn du bei einem Prozess drei verschiedene Verantwortliche hast, ist er wahrscheinlich zu grob. Wenn du 50 Prozesse in einem Geschäftsbereich hast, bist du wahrscheinlich zu fein.

Für ein mittelständisches Unternehmen mit 100 bis 300 Mitarbeitern landest du typischerweise bei 20 bis 40 Geschäftsprozessen. Das ist eine handhabbare Menge für die weitere Analyse.

Datenerhebung: Workshops und Interviews

Die Prozesse kannst du nicht allein am Schreibtisch identifizieren. Du brauchst das Wissen der Fachbereiche. Zwei Methoden haben sich bewährt:

Workshops: Lade die Leiter der Geschäftsbereiche zu einem gemeinsamen Workshop ein. Vorteil: Alle sehen die Gesamtliste und können Lücken identifizieren. Nachteil: Workshops dauern lang und Terminkoordination ist aufwändig.

Einzelinterviews: Sprich mit jedem Bereichsleiter einzeln, 30 bis 45 Minuten pro Gespräch. Vorteil: Tiefere Einblicke, weniger Gruppendynamik. Nachteil: Du musst die Ergebnisse selbst konsolidieren.

In der Praxis funktioniert eine Kombination am besten: Interviews zur Erhebung, ein gemeinsamer Workshop zur Validierung und Priorisierung.

Schritt 2: Auswirkungen bei Ausfall bewerten

Jetzt wird es konkret. Für jeden identifizierten Geschäftsprozess bewertest du, welche Auswirkungen ein Ausfall hat - und zwar über verschiedene Zeiträume hinweg.

Auswirkungskategorien

Die Auswirkungen eines Ausfalls sind selten nur finanzieller Natur. Eine BIA betrachtet typischerweise vier bis sechs Kategorien:

Zeitgestaffelte Bewertung

Das Besondere an der BIA: Du bewertest die Auswirkungen nicht pauschal, sondern über die Zeit. Der Ausfall eines Systems hat nach einer Stunde andere Konsequenzen als nach drei Tagen.

Typische Zeitintervalle:

Ausfallkosten pro Stunde berechnen

Die Quantifizierung in Euro macht die BIA für die Geschäftsführung greifbar. Nicht jeder Schaden lässt sich exakt beziffern, aber eine fundierte Schätzung ist besser als keine Zahl.

Direkte Kosten:

• Entgangener Umsatz pro Stunde: Jahresumsatz / Arbeitsstunden pro Jahr
• Personalkosten für Leerlauf: Betroffene Mitarbeiter × Stundensatz
• Vertragsstrafen bei Lieferverzug: Aus Kundenverträgen ableiten
• Kosten für externe Hilfe: IT-Dienstleister im Notfallmodus (oft doppelter Stundensatz)

Indirekte Kosten:

• Überstunden für Nacharbeit: Aufgelaufene Aufträge müssen abgearbeitet werden
• Kundenabwanderung: Schwer zu beziffern, aber real
• Reputationsschaden: Langfristige Auswirkung auf Auftragslage

Rechenbeispiel für einen Maschinenbauer:

Jahresumsatz:           25.000.000 €
Arbeitstage:            250 pro Jahr
Umsatz pro Tag:         100.000 €
Umsatz pro Stunde:      12.500 € (bei 8h Arbeitstag)

Ausfall Auftragsabwicklung (ERP):
- Stunde 1-4:     Personalleerlauf, ca. 2.000 €/h (40 betroffene MA × 50 €/h)
- Stunde 5-8:     + Entgangener Umsatz, ca. 14.500 €/h
- Tag 2-3:        + Vertragsstrafen (geschätzt 5.000 €/Tag) + Expresslieferungskosten
- Tag 4-7:        + Kundenreklamationen, beginnende Abwanderung
- > 7 Tage:       + Reputationsschaden, mögliche Kündigung von Rahmenverträgen

Diese Zahlen sind Schätzungen, und das ist in Ordnung. Es geht nicht um buchhalterische Genauigkeit, sondern um eine belastbare Größenordnung, die Priorisierungsentscheidungen ermöglicht. Wenn der Ausfall der Auftragsabwicklung 14.500 Euro pro Stunde kostet und der Ausfall des internen Wikis 500 Euro pro Tag, ist die Priorität klar.

Schritt 3: RTO, RPO und MTD bestimmen

Aus der Auswirkungsbewertung leitest du drei zentrale Kennzahlen ab, die den gesamten weiteren BCM-Prozess steuern.

Recovery Time Objective (RTO)

Das RTO gibt an, wie lange ein Geschäftsprozess (und die ihn unterstützenden IT-Systeme) maximal ausfallen darf, bevor der Schaden inakzeptabel wird. "Inakzeptabel" definierst du gemeinsam mit der Geschäftsführung - typischerweise der Punkt, an dem die Auswirkungen von "schmerzhaft, aber handhabbar" zu "ernsthaft geschäftsschädigend" kippen.

Das RTO bestimmt, wie schnell du wiederherstellen musst. Es ist die zentrale Vorgabe für deinen Wiederanlaufplan.

Recovery Point Objective (RPO)

Das RPO gibt an, wie viel Datenverlust tolerierbar ist, gemessen in Zeit. Ein RPO von 4 Stunden bedeutet: Du darfst maximal auf den Datenstand von vor 4 Stunden zurückfallen. Das RPO bestimmt direkt deine Backup-Strategie. Wenn das RPO für die Buchhaltung bei 1 Stunde liegt, brauchst du mindestens stündliche Backups oder eine kontinuierliche Replikation.

Maximum Tolerable Downtime (MTD)

Die MTD ist die absolute Obergrenze: der Zeitpunkt, ab dem der Ausfall existenzbedrohend wird. Die MTD liegt immer über dem RTO. Das RTO ist der Zielwert, die MTD die harte Grenze.

Zusammenhang der drei Kennzahlen:

|------ RPO ------|------------ RTO ------------|--- WRT ---|
                  ^                              ^           ^
            Letztes Backup              System wiederhergestellt  Validiert, Normalbetrieb

|-------------------------------- MTD -----------------------------------|
                                                                         ^
                                                            Absolute Schmerzgrenze

Beispielhafte RTO/RPO-Bestimmung

*E-Mail in der Cloud: RPO 0h durch Provider-Redundanz

Wie du RTO und RPO festlegst

Die Bestimmung ist ein Verhandlungsprozess zwischen Business und IT. Der Fachbereich sagt, was er braucht. Die IT sagt, was technisch und finanziell machbar ist.

Was der Fachbereich einbringt:

• Ab wann wird der Ausfall für den Geschäftsbetrieb kritisch?
• Wie viel Datenverlust kann toleriert werden, bevor manuelle Nacharbeit überhandnimmt?
• Gibt es vertragliche Verpflichtungen (SLAs mit Kunden)?

Was die IT einbringt:

• Welche Wiederherstellungszeiten sind mit der aktuellen Infrastruktur realistisch?
• Welche Backup-Frequenz ist technisch umsetzbar?
• Was würde es kosten, die RTO/RPO-Ziele zu erreichen?

Oft zeigt sich in dieser Diskussion eine Lücke: Der Fachbereich wünscht ein RTO von 2 Stunden, aber die aktuelle Backup- und Recovery-Infrastruktur schafft bestenfalls 8 Stunden. Diese Lücke ist ein wichtiges Ergebnis der BIA, und ISMS Lite berechnet die GAP-Analyse zwischen Soll-RTO und tatsächlicher Recovery-Fähigkeit automatisch aus deinen Eingaben. Sie zeigt, wo investiert werden muss, und macht den Investitionsbedarf für die Geschäftsführung nachvollziehbar.

Schritt 4: Kritikalitätsstufen definieren

Nicht jeder Geschäftsprozess braucht dasselbe Schutzniveau. Kritikalitätsstufen vereinfachen die Priorisierung und machen die BIA-Ergebnisse handhabbar.

Ein bewährtes Modell mit vier Stufen:

Stufe 1: Kritisch

• RTO: bis 4 Stunden
• RPO: bis 1 Stunde
• Auswirkung bei Ausfall: Sofortiger, erheblicher finanzieller Schaden. Kerngeschäft steht still.
• Beispiele: ERP-System, Produktionssteuerung, Online-Shop (bei E-Commerce)
• Anforderung an Backup/Recovery: Hochverfügbarkeit oder Rapid Recovery, ggf. redundante Systeme

Stufe 2: Hoch

• RTO: 4 bis 24 Stunden
• RPO: 1 bis 4 Stunden
• Auswirkung bei Ausfall: Erhebliche Beeinträchtigung des Tagesgeschäfts. Mitarbeiter können teilweise nicht arbeiten.
• Beispiele: E-Mail, Zahlungsverkehr, CRM, VPN für Außendienst
• Anforderung an Backup/Recovery: Tägliches Full-Backup, getestete Restore-Prozedur

Stufe 3: Mittel

• RTO: 1 bis 3 Tage
• RPO: 4 bis 24 Stunden
• Auswirkung bei Ausfall: Spürbare Einschränkung, aber Kerngeschäft läuft weiter. Workarounds möglich.
• Beispiele: Lagerverwaltung, Angebotserstellung, Dokumentenmanagement
• Anforderung an Backup/Recovery: Tägliches Backup, Wiederherstellung innerhalb definierter Frist

Stufe 4: Niedrig

• RTO: 3 bis 7 Tage
• RPO: 24 Stunden
• Auswirkung bei Ausfall: Geringe Auswirkung auf Geschäftsbetrieb. Unangenehm, aber nicht geschäftskritisch.
• Beispiele: Internes Wiki, Zeiterfassung, Archiv-Systeme
• Anforderung an Backup/Recovery: Regelmäßiges Backup, keine besonderen Recovery-Anforderungen

Die Kritikalitätsstufe ergibt sich aus der Auswirkungsbewertung in Schritt 2. Sie ist kein Bauchgefühl, sondern basiert auf der Analyse der finanziellen, operativen und regulatorischen Konsequenzen.

Schritt 5: Abhängigkeiten zu IT-Assets aufdecken

Hier wird es technisch. Jeder Geschäftsprozess hängt von IT-Systemen ab, und diese IT-Systeme hängen wiederum voneinander ab. Diese Abhängigkeitskette aufzudecken ist einer der wertvollsten Beiträge der BIA.

Prozess-zu-Asset-Mapping

Für jeden Geschäftsprozess dokumentierst du, welche IT-Assets benötigt werden:

Asset-zu-Asset-Abhängigkeiten

Die zweite Ebene ist mindestens genauso wichtig: Welche IT-Assets hängen von welchen anderen ab?

Netzwerk (Switches, Firewall, DNS)
  └── Active Directory
       ├── ERP-System (SAP B1)
       │    ├── MES-System (Schnittstelle)
       │    └── Banking-Software (Schnittstelle)
       ├── Fileserver
       ├── VPN / Remote Access
       └── Interne Webanwendungen
  └── Internet-Anbindung
       ├── Exchange Online
       ├── Cloud-Backup
       └── Banking-Software (Online-Banking)

Dieses Mapping zeigt dir Abhängigkeitsketten, die auf den ersten Blick nicht offensichtlich sind. Wenn Active Directory ausfällt, funktioniert nicht nur die Anmeldung nicht - es fallen auch alle Systeme aus, die AD für die Authentifizierung nutzen. Ein gepflegtes IT-Asset-Management liefert die Datenbasis für dieses Mapping. Damit ist AD ein Single Point of Failure, der möglicherweise redundant ausgelegt sein sollte.

Warum Abhängigkeiten so wichtig sind

Die Abhängigkeitsanalyse liefert drei entscheidende Erkenntnisse:

1. Wiederherstellungsreihenfolge: Du kannst das ERP-System nicht wiederherstellen, bevor Active Directory läuft. Die Abhängigkeiten diktieren die Reihenfolge im Wiederanlaufplan.

2. Single Points of Failure: Systeme, von denen viele andere abhängen und die nicht redundant sind, stellen ein besonderes Risiko dar. Die BIA macht sie sichtbar.

3. Kaskadeneffekte: Ein Ausfall in einer tiefen Ebene (z. B. Storage) kann sich auf alle darüberliegenden Systeme auswirken. Die BIA quantifiziert diesen Effekt.

Praxisbeispiel: BIA für einen Maschinenbauer

Lass uns eine BIA exemplarisch durchspielen. Unser fiktiver Maschinenbauer hat 150 Mitarbeiter und 25 Millionen Euro Jahresumsatz.

Ausgangslage

• Lokales Rechenzentrum mit VMware-Virtualisierung
• SAP Business One als ERP-System
• MES-System für die Produktionssteuerung
• Exchange Online für E-Mail
• Veeam Backup auf lokales NAS + wöchentliches Offsite-Tape
• 60 % der Mitarbeiter arbeiten zeitweise remote (VPN)

BIA-Ergebnis: Prozessbewertung

Erkenntnisse aus dem Beispiel

Einige Punkte, die in diesem fiktiven Beispiel auffallen:

1. Die Fertigungssteuerung verursacht pro Stunde mehr Kosten als die Auftragsabwicklung. Das ist bei einem produzierenden Unternehmen typisch. Steht die Produktion, stehen 80 Mitarbeiter in der Halle, und die laufenden Kosten (Personal, Maschinen, Materialbereitstellung) akkumulieren sich schnell.

2. E-Mail hat ein RPO von 0 Stunden, weil Exchange Online in der Microsoft-Cloud läuft und Microsoft selbst für Redundanz sorgt. Das vereinfacht die Backup-Planung für dieses Asset erheblich.

3. Die Lücke zwischen RTO und aktueller Recovery-Fähigkeit ist das eigentliche Ergebnis. Wenn die IT für den ERP-Restore realistisch 8 bis 12 Stunden braucht, das Business aber ein RTO von 4 Stunden fordert, muss investiert werden - z. B. in Instant VM Recovery, in eine standby-Umgebung oder in schnellere Storage-Systeme.

4. Die Ausfallkosten machen den Business Case für Investitionen. Wenn der Ausfall der Fertigungssteuerung 100.000 Euro pro Tag kostet, relativiert sich die Investition von 30.000 Euro für ein redundantes System.

BIA in der Praxis durchführen: Der Prozess

Vorbereitung (1-2 Wochen)

• Scope definieren: Welche Bereiche des Unternehmens werden analysiert?
• Bestandsaufnahme der Geschäftsprozesse (grob, wird in den Interviews verfeinert)
• Interview-Leitfaden vorbereiten
• Termine mit Fachbereichsleitern vereinbaren
• IT-Asset-Liste zusammenstellen (aus CMDB, Inventar oder manuell). Die Schutzbedarfsfeststellung ergänzt die BIA um die Sicherheitsperspektive

Erhebung (2-4 Wochen)

• Interviews mit allen Fachbereichsleitern (je 45-60 Minuten)
• Fragen: Welche Prozesse verantwortest du? Welche IT-Systeme brauchst du dafür? Was passiert bei Ausfall nach 1h/8h/1Tag/3Tagen? Gibt es manuelle Workarounds?
• IT-Abteilung befragen: Abhängigkeiten, Backup-Status, realistische Recovery-Zeiten
• Finanzdaten zusammentragen: Umsatz pro Tag, Personalkosten, bekannte Vertragsstrafen

Analyse (1-2 Wochen)

• Ergebnisse konsolidieren und plausibilisieren
• Kritikalitätsstufen zuordnen
• RTO/RPO/MTD pro Prozess ableiten
• Abhängigkeiten zwischen Prozessen und IT-Assets kartieren
• GAP-Analyse: Gewünschtes RTO vs. tatsächlich erreichbares RTO

Validierung und Freigabe (1 Woche)

• Ergebnisse im Workshop mit Fachbereichsleitern vorstellen und validieren
• Geschäftsführung über Ergebnisse informieren, insbesondere über identifizierte Lücken
• BIA-Report finalisieren und freigeben
• Maßnahmen ableiten (Input für Wiederanlaufplan, Backup-Strategie, Investitionsplanung)

Gesamtdauer

Für ein mittelständisches Unternehmen mit 100 bis 300 Mitarbeitern dauert eine vollständige BIA erfahrungsgemäß 4 bis 8 Wochen. Das ist kein Vollzeitprojekt - der tatsächliche Aufwand liegt bei 40 bis 80 Personenstunden, verteilt über den Zeitraum. Der größte Zeitfresser sind die Termine mit den Fachbereichen.

Häufige Fehler bei der BIA

Fehler 1: Die IT macht die BIA allein

Die BIA ist kein IT-Projekt. Die IT kann die technischen Abhängigkeiten und Recovery-Zeiten beisteuern, aber die Bewertung der geschäftlichen Auswirkungen muss aus den Fachbereichen kommen. Nur der Vertriebsleiter weiß, welche Vertragsstrafen bei Lieferverzug drohen. Nur die Produktionsleitung kann beziffern, was ein Tag Produktionsstillstand kostet.

Fehler 2: Auswirkungen werden zu optimistisch geschätzt

Fachbereiche neigen dazu, die Auswirkungen eines Ausfalls zu unterschätzen, weil sie ihn noch nie erlebt haben. Hier hilft es, mit konkreten Szenarien zu arbeiten: "Stell dir vor, dein ERP fällt morgen früh komplett aus. Deine 40 Mitarbeiter in der Auftragsabwicklung können nicht arbeiten. Kein Zugriff auf Kundendaten, keine Auftragserfassung, keine Lieferscheine. Was passiert nach 4 Stunden? Was nach einem Tag?"

Fehler 3: Abhängigkeiten werden oberflächlich behandelt

"Das ERP braucht einen Server" - ja, aber welchen genau? Und welche anderen Dienste braucht dieser Server? Active Directory? DNS? Storage? Wenn du bei den Abhängigkeiten zu oberflächlich bleibst, fehlt dir die Grundlage für eine sinnvolle Wiederherstellungsreihenfolge.

Fehler 4: Die BIA wird einmal gemacht und dann vergessen

Unternehmen verändern sich. Neue Systeme kommen hinzu, alte werden abgelöst, Geschäftsprozesse ändern sich. Eine BIA, die vor zwei Jahren erstellt wurde, bildet die aktuelle Realität möglicherweise nicht mehr ab. Plane eine jährliche Aktualisierung ein, und aktualisiere die BIA anlassbezogen bei wesentlichen Änderungen.

Fehler 5: Kein Management-Buy-in

Ohne die Unterstützung der Geschäftsführung wird die BIA ein Papiertiger. Die Fachbereichsleiter nehmen sich nur dann Zeit für Interviews und Workshops, wenn das Thema von oben priorisiert wird. Und die Investitionen, die aus der BIA-GAP-Analyse resultieren, brauchen eine Freigabe der Geschäftsführung.

Vom BIA-Ergebnis zum Wiederanlaufplan

Die BIA ist kein Selbstzweck. Ihre Ergebnisse fließen direkt in mehrere operative Dokumente und Entscheidungen:

Wiederanlaufplan: Die BIA liefert die priorisierte Liste der Geschäftsprozesse und IT-Assets, die RTO/RPO-Vorgaben und die Abhängigkeiten. Der Wiederanlaufplan setzt diese Vorgaben in konkrete Recovery-Schritte um.

Backup-Strategie: Die RPO-Werte bestimmen die erforderliche Backup-Frequenz. Wenn ein System ein RPO von 1 Stunde hat, müssen mindestens stündliche Backups laufen. Die BIA liefert also die Anforderungen an die Backup-Strategie.

Investitionsplanung: Die GAP-Analyse (Soll-RTO vs. Ist-Recovery-Zeit) zeigt, wo Investitionen nötig sind. Die Ausfallkosten pro Stunde liefern den Business Case für diese Investitionen.

Notfallhandbuch: Die BIA-Ergebnisse fließen in das Notfallhandbuch ein, das als übergeordnetes Dokument alle relevanten Informationen für den Notfall bündelt.

Risikomanagement: Die in der BIA identifizierten Single Points of Failure und kritischen Abhängigkeiten fließen als Risiken in die Risikoanalyse ein.

BIA und Regulierung

Sowohl NIS2 als auch ISO 27001 fordern eine BIA - direkt oder indirekt.

NIS2: Artikel 21 fordert "Aufrechterhaltung des Betriebs" und "Krisenmanagement". Eine fundierte BIA ist die Voraussetzung, um diese Anforderung sinnvoll umzusetzen. Ohne BIA weißt du nicht, welche Prozesse du priorisieren musst.

ISO 27001 / ISO 22301: ISO 22301 (Business Continuity Management) fordert die BIA explizit in Abschnitt 8.2.2. ISO 27001 referenziert über Annex A.5.29 und A.5.30 die Notwendigkeit, die Auswirkungen von Störungen zu analysieren und darauf basierend Kontinuitätspläne zu erstellen.

BSI-Standard 200-4: Der deutsche BSI-Standard für Business Continuity Management beschreibt die BIA als zentrales Element und liefert eine detaillierte Methodik.

Nächste Schritte

Nach der BIA hast du eine fundierte Grundlage für dein gesamtes BCM. Die nächsten Schritte:

1. Wiederanlaufplan erstellen - auf Basis der BIA-Ergebnisse definierst du die konkreten Recovery-Schritte pro Asset.
2. Backup-Strategie überprüfen - stimmen Backup-Frequenz und -Methode mit den RPO-Anforderungen überein?
3. Notfallhandbuch aufbauen - die BIA-Ergebnisse fließen als Grundlage in das übergeordnete Notfallhandbuch ein.
4. GAP-Maßnahmen umsetzen - wo das aktuelle Recovery-Niveau nicht zum RTO passt, muss investiert werden.
5. Jährliche Aktualisierung einplanen - die BIA lebt nur, wenn sie gepflegt wird.

Weiterführende Artikel

• Wiederanlaufplan erstellen: Anleitung mit Vorlage für den Mittelstand
• IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung
• Schutzbedarfsfeststellung: Vertraulichkeit, Integrität und Verfügbarkeit bewerten
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• Notfallhandbuch für die IT: Aufbau, Inhalt und PDF-Vorlage

In ISMS Lite kannst du die BIA direkt in der Anwendung durchführen. Geschäftsprozesse, IT-Assets und Abhängigkeiten werden in einer strukturierten Oberfläche erfasst, die Kritikalitätsstufen und RTO/RPO-Werte berechnet das System auf Basis deiner Eingaben, und der fertige BIA-Report lässt sich als PDF exportieren.