Die Business-Impact-Analyse im Mittelstand ist der Schritt, der aus einem allgemeinen Wunsch nach Absicherung eine begründete Notfallplanung macht. Sie beantwortet drei Fragen: Welche Geschäftsprozesse sind für das Unternehmen kritisch, welche Folgen hat ein Ausfall nach Stunden, Tagen oder Wochen, und welche Ressourcen werden zur Wiederaufnahme gebraucht. Ohne diese Grundlage werden Notfallpläne häufig nach Gefühl erstellt: Die IT sichert, was ihr wichtig erscheint, und die Fachbereiche erfahren erst im Ernstfall, dass ihre wichtigste Anwendung als nachrangig eingestuft war. Eine strukturierte Analyse schafft hier Klarheit und liefert gleichzeitig die Wiederanlaufziele, auf denen technische Maßnahmen, Budgets und Übungen aufbauen. Dieser Beitrag erläutert die normativen Grundlagen, ein praxistaugliches Vorgehen in sieben Schritten, geeignete Bewertungsmaßstäbe, eine Beispielauswertung und typische Fehler. Er richtet sich an Geschäftsführung, IT-Leitung und Notfallbeauftragte, die Prioritäten nachvollziehbar festlegen wollen und dafür ein Verfahren suchen, das auch ohne großes Projektteam und teure Spezialwerkzeuge funktioniert. Ergänzend werden Dienstleister und Lieferanten betrachtet, deren Zusagen über die Erreichbarkeit der Ziele entscheiden.
Hinweis: Dieser Beitrag gibt ausschließlich die redaktionellen Ansichten der Redaktion von cyberschutzbetrieb.de wieder. Er stellt keine Rechts- oder Steuerberatung dar und ersetzt nicht die Beratung durch qualifizierte Fachleute. Für verbindliche Auskünfte zu Ihrem konkreten Fall wenden Sie sich bitte an eine zugelassene Beratung.
Titelbild: Foto von Tyler auf Unsplash.
Wozu eine Business-Impact-Analyse dient und wo sie verankert ist
Die Business-Impact-Analyse, kurz BIA, ermittelt die Auswirkungen eines Ausfalls auf Prozesse und Ressourcen über die Zeit. Sie ist der Kern jedes Business-Continuity-Management-Systems. Die ISO 22301 fordert in Kapitel 8.2.2 ausdrücklich eine Analyse der Geschäftsauswirkungen, die Prozesse, Prioritäten, Zeitrahmen und Abhängigkeiten festlegt. Der BSI-Standard 200-4 zum Business Continuity Management beschreibt die BIA als zentralen Baustein, aus dem sich Wiederanlaufzeiten und Mindestanforderungen für den Notbetrieb ableiten lassen.
Auch im Informationssicherheitsmanagement spielt die Analyse eine Rolle. Die ISO/IEC 27001 verlangt Maßnahmen zur Aufrechterhaltung der Informationssicherheit bei Störungen, und für Unternehmen, die von der NIS-2-Richtlinie betroffen sind, gehört ein Konzept zur Betriebskontinuität zu den Risikomanagementmaßnahmen. Eine dokumentierte BIA dient dabei als Nachweis, dass Prioritäten nicht willkürlich, sondern begründet gesetzt wurden.
Abgrenzung zur Risikoanalyse
Die Risikoanalyse betrachtet Bedrohungen und Schwachstellen und fragt, wie wahrscheinlich ein Schaden ist. Die BIA fragt unabhängig von der Ursache, was passiert, wenn ein Prozess nicht mehr läuft. Ob der Auslöser ein Hackerangriff, ein Wasserschaden oder ein Ausfall des Rechenzentrumsdienstleisters ist, spielt für die Auswirkung zunächst keine Rolle. Beide Analysen ergänzen sich: Die BIA bestimmt, was geschützt werden muss und wie schnell, die Risikoanalyse bestimmt, wie wahrscheinlich Störungen sind und welche Gegenmaßnahmen angemessen erscheinen.
Zentrale Begriffe: MTPD, RTO, RPO und Mindestbetrieb
Eine BIA arbeitet mit wenigen, aber genau definierten Kennzahlen. Wer sie uneinheitlich verwendet, erhält Ergebnisse, die sich nicht vergleichen lassen.
- MTPD (Maximum Tolerable Period of Disruption): Die längste Zeit, die ein Prozess ausfallen darf, bevor der Fortbestand des Unternehmens oder wesentliche Ziele ernsthaft gefährdet sind. Im BSI-Standard wird dies als maximal tolerierbare Ausfallzeit bezeichnet.
- RTO (Recovery Time Objective): Die Zielzeit, innerhalb derer ein Prozess oder System wiederhergestellt sein soll. Sie liegt stets unterhalb der MTPD.
- RPO (Recovery Point Objective): Der maximal akzeptierte Datenverlust, gemessen als Zeitspanne zwischen letzter Sicherung und Störung.
- Mindestbetriebsniveau: Der Umfang, in dem ein Prozess im Notbetrieb mindestens laufen muss, zum Beispiel die Hälfte der üblichen Auftragsmenge.
Die Zusammenhänge zwischen RTO und RPO sind im Beitrag zu den Wiederanlaufzielen vertieft. Für die BIA genügt die Erkenntnis, dass diese Werte nicht von der IT festgelegt werden, sondern aus den Anforderungen der Fachbereiche und der Geschäftsführung entstehen.
Das Vorgehen in sieben Schritten
- Auftrag und Rahmen klären: Die Geschäftsführung legt Ziel, Umfang und Verantwortliche fest. Ohne Mandat lehnen Fachbereiche Interviews schnell als Zusatzbelastung ab.
- Prozesse erfassen: Alle wesentlichen Geschäftsprozesse werden aufgelistet, getrennt nach Kernprozessen, unterstützenden Prozessen und Führungsprozessen. Eine vorhandene Prozesslandkarte erleichtert den Einstieg.
- Bewertungsmaßstab festlegen: Schadenskategorien und Schwellenwerte werden vereinheitlicht, bevor die Befragung beginnt, damit alle Bereiche dieselbe Skala nutzen.
- Auswirkungen über die Zeit ermitteln: Für jeden Prozess wird abgeschätzt, wie sich der Schaden nach vier Stunden, einem Tag, drei Tagen, einer Woche und länger entwickelt.
- Abhängigkeiten erfassen: Für jeden kritischen Prozess werden benötigte Anwendungen, Daten, Personen, Standorte, Lieferanten und Dienstleister benannt.
- Ziele ableiten und priorisieren: MTPD, RTO, RPO und Mindestbetriebsniveau werden festgelegt und die Prozesse in Kritikalitätsklassen eingeteilt.
- Ergebnisse freigeben und dokumentieren: Die Geschäftsführung bestätigt die Ergebnisse formal. Sie bilden die Grundlage für Notfallpläne, Wiederanlaufpläne und Investitionen.
Interviews statt Fragebogen allein
Fragebögen sind effizient, liefern aber oft oberflächliche Antworten. Besser ist ein kurzes strukturiertes Interview mit jedem Prozessverantwortlichen von 45 bis 60 Minuten, ergänzt durch einen vorab versandten Erfassungsbogen. Im Gespräch zeigen sich Abhängigkeiten, die in Formularen nicht auftauchen, etwa die Tabelle, die nur ein einzelner Mitarbeiter pflegt, oder der Lieferant, der auf einem veralteten Schnittstellenformat besteht.
Leitfragen für das Prozessinterview
- Welche Ergebnisse erzeugt der Prozess, und wer wartet darauf, intern wie extern?
- Ab wann entstehen messbare Schäden, wenn der Prozess ausfällt, und wie entwickeln sie sich?
- Welche Anwendungen, Daten, Personen und Dienstleister werden benötigt?
- Gibt es manuelle Ausweichverfahren, und wie lange lassen sie sich durchhalten?
- Welche Fristen aus Gesetz oder Vertrag sind zu beachten, zum Beispiel Zahlungstermine, Meldepflichten oder Liefertermine?
- Wann im Jahr oder Monat ist der Prozess besonders sensibel, etwa bei Abschlüssen, Lohnläufen oder Saisonspitzen?
Der letzte Punkt wird häufig vergessen: Kritikalität schwankt über die Zeit. Die Lohnabrechnung ist zur Monatsmitte unkritisch, am Monatsende aber zwingend. Solche zeitlichen Spitzen sollten im Erfassungsbogen vermerkt und bei der Planung von Wartungsfenstern und Übungen berücksichtigt werden.
Bewertungsmaßstäbe: Wie Schäden vergleichbar werden
Damit Prozesse miteinander verglichen werden können, braucht es eine einheitliche Skala. Üblich sind vier bis fünf Stufen für mehrere Schadensarten. Die Schwellenwerte werden an die Größe des Unternehmens angepasst und sind hier lediglich als Beispiel zu verstehen.
| Stufe | Finanzieller Schaden | Auswirkung auf Kunden | Rechtliche Folgen |
|---|---|---|---|
| 1 gering | bis wenige Tausend Euro | kaum spürbar | keine |
| 2 mittel | im niedrigen fünfstelligen Bereich | einzelne Verzögerungen | Hinweise oder Abmahnungen möglich |
| 3 hoch | im sechsstelligen Bereich | Lieferausfälle, Beschwerden | Vertragsstrafen, Meldepflichten |
| 4 existenzgefährdend | übersteigt Rücklagen | Verlust von Schlüsselkunden | Bußgelder, Haftung der Leitung |
Wichtig ist, dass neben finanziellen auch nichtfinanzielle Folgen betrachtet werden: Vertragsstrafen, Reputationsverlust, Verstöße gegen Aufbewahrungs- und Meldepflichten oder Gefährdung von Personen. Bei personenbezogenen Daten sind insbesondere die Fristen der DSGVO zu beachten, etwa die Meldung einer Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden nach Art. 33 DSGVO.
Beispielauswertung für einen Fertigungsbetrieb
Die folgende Auswertung ist frei gewählt und zeigt, wie Ergebnisse aussehen können. Sie bildet keine Messwerte eines realen Unternehmens ab.
| Prozess | MTPD | RTO | RPO | Klasse |
|---|---|---|---|---|
| Auftragsabwicklung (ERP) | 3 Tage | 8 Stunden | 1 Stunde | A |
| Fertigungssteuerung | 1 Tag | 4 Stunden | 15 Minuten | A |
| Versand und Logistik | 2 Tage | 1 Tag | 4 Stunden | B |
| Lohn- und Gehaltsabrechnung | 10 Tage | 3 Tage | 1 Tag | C |
| Personalverwaltung | 14 Tage | 5 Tage | 1 Tag | C |
Auffällig ist, dass die Fertigungssteuerung kürzere Ziele hat als die Auftragsabwicklung. Das ist ein typisches Ergebnis, das in der Praxis überrascht, weil die Fertigung in der IT-Landschaft oft weniger Aufmerksamkeit bekommt als das ERP. Aus der Auswertung leitet sich unmittelbar ab, welche Systeme redundant ausgelegt, wie oft Datensicherungen laufen und welche Dienstleister vertraglich auf Reaktionszeiten verpflichtet werden müssen.
Von der BIA zur Maßnahme
- Klasse A: Hochverfügbarkeit oder schneller automatisierter Wiederanlauf, getestete Notfallverfahren, Rufbereitschaft
- Klasse B: Manuelle Wiederherstellung mit dokumentierten Schritten, regelmäßige Wiederherstellungstests
- Klasse C: Wiederherstellung nach Priorität im Regelbetrieb, Sicherung mit längerem Intervall
Eine Notfallplanung ohne Business-Impact-Analyse schützt nicht das Wichtigste, sondern das, was zufällig am besten sichtbar ist.
Abhängigkeiten und Ressourcen: Was ein Prozess wirklich braucht
Ein Prozess hängt selten nur an einer Anwendung. Zur Ermittlung der Abhängigkeiten werden für jeden kritischen Prozess mindestens fünf Ressourcenarten betrachtet. Dazu zählen Personen mit Schlüsselwissen, Arbeitsplätze und Standorte, IT-Systeme und Daten, Dienstleister und Lieferanten sowie Infrastruktur wie Strom, Netzwerk und Kommunikation.
Besonders heikel sind Einzelabhängigkeiten, auch Single Points of Failure genannt. Typische Beispiele sind eine Person, die als Einzige ein Altsystem betreuen kann, ein einziger Internetanschluss für mehrere Standorte oder ein Cloud-Dienst ohne Exportmöglichkeit. Diese Punkte werden in der BIA als Ergebnis markiert und anschließend in der Risikobehandlung adressiert.
Zu beachten ist die Kette der Abhängigkeiten: Wenn die Auftragsabwicklung binnen acht Stunden laufen soll, müssen auch Netzwerk, Authentifizierung, Datenbank und Druckdienste in dieser Zeit verfügbar sein. Ziele einzelner Systeme müssen daher aus den Zielen der Prozesse abgeleitet und nicht isoliert festgelegt werden.
Dienstleister und Lieferanten in die Analyse einbeziehen
Viele mittelständische Unternehmen betreiben wesentliche Teile ihrer IT nicht mehr selbst, sondern beziehen sie von Dienstleistern: ERP aus der Cloud, E-Mail im Rechenzentrum eines Anbieters, Fernwartung durch den Systemhaus-Partner. Die BIA muss diese Abhängigkeiten sichtbar machen, denn die Wiederanlaufziele des eigenen Prozesses gelten nur, wenn der Dienstleister sie ebenfalls einhalten kann.
Dazu sollten die Zielwerte mit den vertraglichen Zusagen abgeglichen werden. Enthält der Vertrag Aussagen zu Verfügbarkeit, Reaktionszeit, Wiederherstellungszeit und Datensicherung? Liegen die Zusagen unter den Anforderungen der BIA, besteht eine Lücke, die durch Nachverhandlung, zusätzliche Sicherungen oder einen Wechsel geschlossen werden muss. Bei der Verarbeitung personenbezogener Daten kommt hinzu, dass der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO Regelungen zu Verfügbarkeit und Unterstützung im Störfall enthalten sollte.
Auch Lieferanten materieller Güter gehören in die Betrachtung. Fällt ein Alleinlieferant für ein Schlüsselteil aus, kann der Produktionsprozess stillstehen, selbst wenn die gesamte IT funktioniert. Die BIA liefert hier die Begründung, Zweitquellen zu qualifizieren oder Sicherheitsbestände vorzuhalten.
Typische Fehler und wie sie sich vermeiden lassen
- Alles ist wichtig: Wenn jeder Fachbereich seine Prozesse als kritisch einstuft, entsteht keine Priorität. Gegenmittel sind der einheitliche Maßstab und die Entscheidung der Geschäftsführung bei Konflikten.
- Zu feingliedrige Erfassung: Wer jeden Arbeitsschritt einzeln bewertet, erstickt in Daten. Eine Betrachtung auf Ebene von Geschäftsprozessen genügt.
- Fokus allein auf IT: Wenn nur Systeme betrachtet werden, bleiben Personal, Gebäude und Lieferanten außen vor. Die Analyse sollte vom Prozess ausgehen und nicht vom Server.
- Einmalige Durchführung: Veränderte Prozesse, neue Software und Lieferantenwechsel machen Ergebnisse schnell unzutreffend. Eine Überprüfung mindestens jährlich und bei wesentlichen Änderungen ist üblich.
- Fehlende Verknüpfung zu Maßnahmen: Eine BIA, deren Ergebnisse in der Schublade liegen, hat keinen Wert. Jedes Ziel sollte einer Maßnahme, einem Verantwortlichen und einem Test zugeordnet werden.
Rollen und Zuständigkeiten im Analyseprojekt
Auch ein kleines Analyseprojekt profitiert von klar verteilten Rollen. Die Geschäftsführung gibt das Mandat, bestätigt den Bewertungsmaßstab und gibt die Ergebnisse frei. Die Notfallbeauftragte oder der Notfallbeauftragte koordiniert Termine, führt die Interviews und konsolidiert die Ergebnisse. Die Prozessverantwortlichen der Fachbereiche liefern die fachlichen Angaben und verantworten deren Richtigkeit. Die IT-Leitung ergänzt technische Abhängigkeiten und prüft, ob die abgeleiteten Ziele mit der vorhandenen Infrastruktur erreichbar sind.
Konflikte zwischen Fachbereichen über die Einstufung sind normal. Sie sollten nicht in Einzelgesprächen entschärft, sondern in einer gemeinsamen Abstimmungsrunde behandelt werden, in der die Geschäftsführung entscheidet. Dokumentiert werden die Ergebnisse und, soweit relevant, die Begründung für abweichende Einstufungen. Das erleichtert später die Nachvollziehbarkeit gegenüber Auditoren und Versicherern.
Hilfreich ist zudem ein Zeitplan mit Meilensteinen: Mandat und Maßstab in der ersten Woche, Interviews in den folgenden zwei bis drei Wochen, Konsolidierung und Abstimmung in der vierten Woche, Freigabe zum Monatsende. Ein solcher Rahmen verhindert, dass die Analyse zwischen Tagesgeschäft und Projektarbeit zerrieben wird.
Dokumentation und Pflege
Die Dokumentation sollte so schlank wie möglich und so ausführlich wie nötig sein. Üblich sind ein Erfassungsbogen je Prozess, eine Gesamtübersicht der Kritikalitätsklassen, eine Liste der Abhängigkeiten und ein Freigabevermerk der Geschäftsführung. Die Ergebnisse werden mit Versionsstand und Datum abgelegt, damit bei Audits nachvollziehbar ist, auf welcher Basis Entscheidungen getroffen wurden.
Für die Pflege empfiehlt sich ein fester Kreislauf. Einmal jährlich erfolgt ein kurzer Review mit den Prozessverantwortlichen, zusätzlich anlassbezogen bei Reorganisationen, Systemwechseln oder nach Notfallübungen. Erkenntnisse aus Übungen fließen zurück in die Zielwerte, denn häufig zeigt sich erst im Test, dass ein vermeintlich erreichbares RTO unrealistisch ist.
Weitere Informationen zum methodischen Vorgehen stellt das Bundesamt für Sicherheit in der Informationstechnik bereit. Der BSI-Standard 200-4 zum Business Continuity Management beschreibt die Analyse der Geschäftsauswirkungen im Detail.
Checkliste für die Durchführung
- Mandat der Geschäftsführung und Projektverantwortliche festgelegt
- Liste der Geschäftsprozesse vollständig und abgestimmt
- Einheitliche Schadensskala mit Schwellenwerten beschlossen
- Interviews mit allen Prozessverantwortlichen geführt
- MTPD, RTO, RPO und Mindestbetrieb je Prozess dokumentiert
- Abhängigkeiten von Systemen, Personal, Standorten und Dienstleistern erfasst
- Kritikalitätsklassen definiert und freigegeben
- Maßnahmen, Verantwortliche und Testtermine je Klasse zugeordnet
- Jährlicher Review und anlassbezogene Aktualisierung eingeplant
Fazit: Prioritäten begründen statt vermuten
Die Business-Impact-Analyse im Mittelstand macht sichtbar, welche Prozesse im Ernstfall zuerst laufen müssen und was ihr Ausfall kostet. Sie verbindet Geschäftsführung, Fachbereiche und IT in einem gemeinsamen Verständnis und liefert die Zielwerte für Wiederanlauf, Datensicherung und Dienstleisterverträge. Wer mit einem überschaubaren Maßstab, strukturierten Interviews und klarer Freigabe arbeitet, kommt auch ohne großes Projektteam zu belastbaren Ergebnissen. Entscheidend ist, die Analyse nicht als einmaliges Dokument, sondern als regelmäßig gepflegte Grundlage der Notfallplanung zu verstehen.
FAQ
Wie lange dauert eine Business-Impact-Analyse im Mittelstand?
Bei einem Unternehmen mit zehn bis 20 Kernprozessen sind für Vorbereitung, Interviews und Auswertung häufig einige Wochen realistisch. Der reine Zeitaufwand der Fachbereiche liegt meist bei ein bis zwei Stunden je Prozess.
Wer sollte die Analyse durchführen?
Die Federführung liegt sinnvollerweise bei einer Notfall- oder Informationssicherheitsbeauftragten Person, unterstützt von den Prozessverantwortlichen der Fachbereiche. Die Ergebnisse müssen von der Geschäftsführung freigegeben werden. Externe Unterstützung kann Methodik und Moderation beisteuern.
Worin unterscheiden sich BIA und Risikoanalyse?
Die BIA bewertet die Folgen eines Ausfalls unabhängig von der Ursache, die Risikoanalyse betrachtet Bedrohungen, Schwachstellen und Eintrittswahrscheinlichkeiten. Beide Verfahren ergänzen sich und werden im Rahmen des Notfallmanagements kombiniert.
Wie oft muss eine BIA aktualisiert werden?
Üblich ist eine Überprüfung mindestens einmal jährlich sowie bei wesentlichen Änderungen wie neuen Systemen, Standortwechseln, Reorganisationen oder veränderten Lieferbeziehungen. Auch Erkenntnisse aus Notfallübungen sollten einfließen.
Ist eine BIA für kleine Unternehmen verpflichtend?
Eine allgemeine gesetzliche Pflicht besteht für kleine Unternehmen nicht. Anforderungen können sich aus Branchenvorschriften, Kundenverträgen, Zertifizierungen oder der NIS-2-Regulierung ergeben. Unabhängig davon ist die Analyse eine wirksame Grundlage für sinnvolle Notfallmaßnahmen.
