- A.5.29 fordert, dass die Organisation plant, wie die Informationssicherheit bei Störungen aufrechterhalten wird. A.5.30 verlangt, dass die ICT-Bereitschaft für Business Continuity sichergestellt ist.
- Die Business Impact Analyse (BIA) identifiziert geschäftskritische Prozesse und definiert für jeden Prozess die maximal tolerable Ausfallzeit (MTPD) und den Recovery Time Objective (RTO).
- Recovery-Pläne müssen für jedes kritische System konkrete Wiederherstellungsschritte, Verantwortlichkeiten und Abhängigkeiten dokumentieren.
- Tests der Notfallpläne sind nicht optional, sondern Pflicht. Tabletop-Übungen sind der pragmatische Einstieg, ergänzt durch technische Restore-Tests.
- Für ein Unternehmen mit rund 100 Mitarbeitenden reicht ein pragmatischer BCM-Ansatz, der sich auf die 5 bis 10 geschäftskritischsten Prozesse konzentriert.
Zwei Controls, ein Ziel
Die Controls A.5.29 und A.5.30 gehören inhaltlich zusammen und adressieren das gleiche übergeordnete Ziel: sicherstellen, dass die Informationssicherheit auch dann gewährleistet bleibt, wenn der normale Geschäftsbetrieb gestört ist.
A.5.29 trägt den Titel „Information security during disruption" und fordert, dass die Organisation plant, wie sie die Informationssicherheit während und nach Störungen aufrechterhält. A.5.30 heißt „ICT readiness for business continuity" und verlangt, dass die Informations- und Kommunikationstechnologie so vorbereitet ist, dass die Geschäftskontinuität gewährleistet werden kann.
Der Unterschied zwischen den beiden Controls ist subtil, aber wichtig: A.5.29 betrachtet die Informationssicherheit als Ganzes (also auch organisatorische und physische Aspekte), während A.5.30 sich spezifisch auf die technische ICT-Bereitschaft konzentriert. In der Praxis überlappen sie stark, und die meisten Unternehmen behandeln sie als zusammengehörendes Paket.
Abgrenzung: ISMS ist nicht gleich BCM
Ein häufiges Missverständnis: Die ISO 27001 fordert kein vollständiges Business Continuity Management System im Sinne der ISO 22301. Sie fordert, dass die Informationssicherheitsaspekte der Geschäftskontinuität im ISMS adressiert werden.
Das bedeutet in der Praxis: Du brauchst kein zertifiziertes BCM, aber du brauchst eine Antwort auf die Frage, wie du die Vertraulichkeit, Integrität und Verfügbarkeit deiner Informationen sicherstellst, wenn kritische Systeme ausfallen, ein Standort nicht erreichbar ist oder ein Cyberangriff den Normalbetrieb lahmlegt. Die Erstellung eines Disaster Recovery Plans gehört zu den zentralen Aufgaben in diesem Zusammenhang.
Für ein Unternehmen mit rund 100 Mitarbeitenden ist ein pragmatischer Ansatz sinnvoll: Konzentriere dich auf die geschäftskritischen Prozesse und deren IT-Abhängigkeiten. Du musst nicht für jedes erdenkliche Szenario einen Plan haben, aber für die realistischen und schadenträchtigen Szenarien schon.
Die Business Impact Analyse (BIA)
Die BIA ist das methodische Fundament für alles, was danach kommt. Sie beantwortet zwei zentrale Fragen: Welche Geschäftsprozesse sind kritisch? Und wie lange darf jeder dieser Prozesse maximal ausfallen?
Schritt 1: Geschäftsprozesse identifizieren
Liste alle wesentlichen Geschäftsprozesse auf. Für ein Unternehmen mit rund 100 Mitarbeitenden sind das typischerweise 15 bis 25 Prozesse. Einige Beispiele: Auftragsbearbeitung, Rechnungsstellung, Kundenservice, E-Mail-Kommunikation, Produktionssteuerung, Personalverwaltung, Einkauf, Logistik, Vertrieb.
Arbeite dabei nicht allein in der IT-Abteilung. Die BIA ist ein Geschäftsthema. Die Fachbereiche müssen bewerten, wie kritisch ihre Prozesse sind, nicht die IT.
Schritt 2: Auswirkungen eines Ausfalls bewerten
Für jeden Geschäftsprozess bewertest du die Auswirkungen eines Ausfalls über verschiedene Zeiträume. Was passiert, wenn der Prozess eine Stunde ausfällt? Vier Stunden? Einen Tag? Drei Tage? Eine Woche?
Die Bewertungsdimensionen umfassen typischerweise:
Finanzielle Auswirkungen: Direkte Umsatzverluste, Vertragsstrafen, Kosten für Notmaßnahmen.
Rechtliche und regulatorische Auswirkungen: Verstöße gegen Gesetze, Meldefristen, vertragliche Verpflichtungen.
Reputationsauswirkungen: Vertrauensverlust bei Kunden, negative Medienberichterstattung.
Operative Auswirkungen: Störung nachgelagerter Prozesse, Rückstau, Kapazitätsengpässe.
Schritt 3: MTPD und RTO definieren
Aus der Auswirkungsbewertung leitest du zwei zentrale Kenngrößen ab:
Maximum Tolerable Period of Disruption (MTPD): Die maximal tolerierbare Ausfallzeit, nach der die Auswirkungen für das Unternehmen nicht mehr tragbar sind. Die MTPD ist eine geschäftliche Entscheidung, keine technische.
Recovery Time Objective (RTO): Die Zielzeit, innerhalb der ein System oder Prozess nach einer Störung wiederhergestellt sein muss. Der RTO muss kleiner sein als die MTPD, idealerweise deutlich kleiner, um einen Sicherheitspuffer zu haben.
Recovery Point Objective (RPO): Der maximal tolerierbare Datenverlust, ausgedrückt als Zeitspanne. Ein RPO von 4 Stunden bedeutet: Du akzeptierst den Verlust der Daten der letzten 4 Stunden. Der RPO bestimmt die Backup-Frequenz.
Schritt 4: IT-Abhängigkeiten kartieren
Für jeden kritischen Geschäftsprozess identifizierst du die IT-Systeme, auf die er angewiesen ist. Die Auftragsbearbeitung braucht vielleicht das ERP-System, die E-Mail, den Internetzugang und den Drucker. Der Kundenservice braucht das Ticketsystem, die Telefonanlage und die Wissensdatenbank.
Diese Kartierung ist essenziell, weil sie zeigt, welche IT-Systeme für die Geschäftskontinuität kritisch sind und welche Priorität sie bei der Wiederherstellung haben.
Praxisbeispiel: BIA für einen Maschinenbauunternehmen
Ein Maschinenbauunternehmen mit 95 Mitarbeitenden hat seine BIA wie folgt durchgeführt:
| Prozess | MTPD | RTO | RPO | Kritische IT-Systeme |
|---|---|---|---|---|
| Auftragsbearbeitung | 4 Std. | 2 Std. | 1 Std. | ERP, E-Mail |
| Produktion | 8 Std. | 4 Std. | 4 Std. | CAD/CAM, Produktionssteuerung |
| Rechnungsstellung | 24 Std. | 8 Std. | 4 Std. | ERP, E-Mail |
| 4 Std. | 2 Std. | 0 Std. | Exchange/M365 | |
| Kundenservice | 8 Std. | 4 Std. | 1 Std. | Ticketsystem, Telefon |
| Personalverwaltung | 72 Std. | 24 Std. | 24 Std. | HR-System |
Aus dieser Tabelle wird sofort ersichtlich: ERP und E-Mail haben die höchste Priorität bei der Wiederherstellung, weil sie die kürzesten MTPDs haben und von den meisten kritischen Prozessen benötigt werden.
Recovery-Planung
Die BIA zeigt dir, was kritisch ist. Die Recovery-Planung beschreibt, wie du es wiederherstellst.
Recovery-Plan pro kritischem System
Für jedes kritische IT-System brauchst du einen dokumentierten Recovery-Plan. Der Recovery-Plan beantwortet folgende Fragen:
Wiederherstellungsszenario: Was genau muss wiederhergestellt werden? Der gesamte Server? Nur die Anwendung? Die Datenbank?
Wiederherstellungsschritte: Eine Schritt-für-Schritt-Anleitung, die auch ein Administrator ausführen kann, der das System nicht regelmäßig betreut. Das ist wichtig, weil im Notfall der zuständige Administrator krank, im Urlaub oder selbst betroffen sein kann.
Abhängigkeiten: Welche Systeme müssen vor diesem System wiederhergestellt werden? Ein ERP-System braucht zuerst den Datenbankserver, der wiederum das Netzwerk und den Speicher braucht.
Verantwortlichkeiten: Wer führt die Wiederherstellung durch? Wer wird informiert? Wer gibt die Wiederaufnahme des Betriebs frei?
Backup-Quellen: Wo liegen die Backups? Wie wird auf sie zugegriffen? Welche Zugangsdaten werden benötigt?
Eskalationspfad: Was passiert, wenn die Wiederherstellung nicht innerhalb des RTO gelingt? Wer wird eskaliert? Welche externen Dienstleister können hinzugezogen werden?
Redundanz und Ausfallsicherheit
Neben der Wiederherstellung nach einem Totalausfall solltest du für die kritischsten Systeme auch Redundanz-Maßnahmen vorsehen:
Server-Redundanz: Kritische Server laufen als Cluster oder haben einen Standby-Server, der bei Ausfall übernimmt.
Standort-Redundanz: Backups werden an einem anderen Standort aufbewahrt, entweder physisch oder in der Cloud. Wenn das Rechenzentrum abbrennt, bringt ein Backup im gleichen Raum wenig.
Netzwerk-Redundanz: Für den Internetzugang gibt es einen zweiten Provider oder eine Mobilfunk-Fallback-Lösung.
Strom-Redundanz: Eine USV überbrückt kurze Stromausfälle, ein Notstromaggregat längere.
Welche Redundanz-Maßnahmen sinnvoll sind, ergibt sich aus der BIA: Je kürzer der RTO, desto mehr Redundanz brauchst du, weil die reine Wiederherstellung aus einem Backup typischerweise Stunden dauert.
Informationssicherheit im Notfall
A.5.29 betont einen Aspekt, der oft vergessen wird: Die Informationssicherheit darf im Notfall nicht aufgegeben werden. In der Praxis passiert genau das regelmäßig. Unter Zeitdruck werden Passwörter geteilt, Zugriffsrechte großzügig vergeben, unverschlüsselte Kanäle für den Datentransfer genutzt und Sicherheitsmaßnahmen deaktiviert, um die Wiederherstellung zu beschleunigen.
Der Recovery-Plan sollte daher explizit festlegen, welche Sicherheitsmaßnahmen auch im Notfall gelten und welche vorübergehend gelockert werden dürfen. Jede Lockerung muss dokumentiert und nach der Wiederherstellung des Normalbetriebs zurückgenommen werden.
Tests der Notfallpläne
Ein Recovery-Plan, der nie getestet wurde, ist eine Hoffnung, kein Plan. A.5.29 und A.5.30 fordern explizit, dass die Notfallvorsorge regelmäßig getestet wird.
Testarten
Tabletop-Übung: Die Beteiligten sitzen zusammen und gehen ein Szenario gedanklich durch. „Es ist Montag, 9 Uhr, der ERP-Server ist nicht erreichbar. Was tun wir?" Diese Übung ist mit minimalem Aufwand durchführbar und deckt bereits viele Lücken in den Plänen auf.
Walkthrough-Test: Die Beteiligten gehen den Recovery-Plan Schritt für Schritt durch und prüfen, ob die beschriebenen Schritte noch aktuell sind, ob die Kontaktdaten stimmen und ob die benötigten Ressourcen verfügbar sind, allerdings ohne die Wiederherstellung tatsächlich durchzuführen.
Technischer Restore-Test: Ein Backup wird tatsächlich auf einem Testsystem wiederhergestellt, um zu verifizieren, dass das Backup vollständig und funktionsfähig ist und die Wiederherstellung innerhalb des RTO gelingt.
Simulationstest: Ein realistisches Szenario wird durchgespielt, bei dem Systeme tatsächlich heruntergefahren und aus Backups wiederhergestellt werden. Dieser Test hat die höchste Aussagekraft, aber auch das höchste Risiko und den höchsten Aufwand.
Testfrequenz für rund 100 Mitarbeitende
Ein pragmatischer Testplan sieht so aus:
- Tabletop-Übungen: Zweimal pro Jahr, jeweils mit einem anderen Szenario (z.B. Ransomware-Angriff im Frühjahr, Ausfall des Cloud-Providers im Herbst)
- Technische Restore-Tests: Vierteljährlich für die geschäftskritischsten Systeme, mindestens jährlich für alle Systeme mit definierten Recovery-Plänen
- Walkthrough-Tests: Jährlich für alle Recovery-Pläne
- Simulationstest: Alle zwei Jahre für das kritischste Szenario
Lessons Learned
Nach jedem Test ist eine Nachbereitung Pflicht. Was hat funktioniert? Was nicht? Welche Lücken wurden aufgedeckt? Welche Maßnahmen werden daraus abgeleitet? Die Ergebnisse fließen in die Aktualisierung der Recovery-Pläne ein und schließen den PDCA-Zyklus.
Typische Audit-Findings bei A.5.29 und A.5.30
Finding 1: Keine Business Impact Analyse
Das Unternehmen hat Recovery-Pläne, aber keine dokumentierte BIA. Die RTOs wurden „aus dem Bauch heraus" festgelegt, ohne die geschäftlichen Auswirkungen systematisch zu bewerten.
Vermeidung: Führe eine BIA durch, die die Fachbereiche einbezieht. Die BIA muss nicht hunderte Seiten umfassen. Eine strukturierte Tabelle mit Prozessen, Auswirkungsbewertungen und abgeleiteten RTOs/RPOs reicht für ein Unternehmen mit rund 100 Mitarbeitenden aus.
Finding 2: Recovery-Pläne veraltet
Die Recovery-Pläne stammen von vor zwei Jahren. Seitdem wurden Server migriert, Cloud-Dienste eingeführt und Ansprechpartner gewechselt. Die Pläne beschreiben Systeme, die nicht mehr existieren, und nennen Mitarbeitende, die das Unternehmen verlassen haben.
Vermeidung: Überprüfe Recovery-Pläne mindestens jährlich und nach jeder wesentlichen Änderung der IT-Infrastruktur.
Finding 3: Keine Testnachweise
Es gibt Pläne, aber keine Nachweise, dass sie jemals getestet wurden. Kein Testprotokoll, kein Übungsbericht, keine Lessons Learned.
Vermeidung: Dokumentiere jeden Test mit Datum, Szenario, Teilnehmern, Ergebnissen und abgeleiteten Maßnahmen. Ein einfaches Testprotokoll-Template reicht.
Finding 4: RPO und Backup-Frequenz passen nicht zusammen
Die BIA definiert einen RPO von 4 Stunden, aber das Backup läuft nur einmal täglich nachts. Im Ernstfall würden bis zu 24 Stunden Daten verloren gehen, obwohl nur 4 Stunden tolerierbar sind.
Vermeidung: Gleiche die Backup-Frequenz mit dem RPO ab. Ein RPO von 4 Stunden erfordert mindestens alle 4 Stunden ein Backup oder eine kontinuierliche Datensicherung (z.B. Transaction-Log-Sicherung).
Finding 5: Informationssicherheit im Notfall nicht adressiert
Es gibt Wiederherstellungspläne, aber sie enthalten keine Regelungen zur Informationssicherheit während der Wiederherstellung. Es ist unklar, ob im Notfall die gleichen Zugriffskontrollen gelten, wie mit temporären Zugängen umgegangen wird und wann der Normalbetrieb der Sicherheitsmaßnahmen wiederhergestellt wird.
Vermeidung: Ergänze jeden Recovery-Plan um einen Abschnitt zur Informationssicherheit während der Wiederherstellung.
Wie ISMS Lite den Nachweis unterstützt
BCM-Controls mit Umsetzungsempfehlungen: ISMS Lite enthält die relevanten Business-Continuity-Controls aus 11 Frameworks mit konkreten Umsetzungsempfehlungen. Für A.5.29 und A.5.30 bekommst du praxisnahe Hinweise, was dokumentiert und umgesetzt werden muss.
Strukturierte Dokumentation: Geschäftsprozesse, Auswirkungsbewertungen, RTOs/RPOs und Wiederherstellungsverfahren lassen sich in ISMS Lite strukturiert dokumentieren. Die Versionierung sorgt dafür, dass Änderungen nachvollziehbar bleiben.
KI-gestützte Richtlinienerstellung: Die lokale KI unterstützt dich dabei, BCM-Richtlinien und Verfahrensdokumente zu erstellen, die auf dein Unternehmen zugeschnitten sind.
Freigabe-Workflows: Recovery-Pläne und BCM-Dokumente durchlaufen definierte Freigabeprozesse, sodass du jederzeit nachweisen kannst, wer wann was genehmigt hat.
Weiterführende Artikel
- Business Impact Analyse (BIA): Geschäftskritische Prozesse systematisch bewerten
- Wiederanlaufplan erstellen: IT-Systeme geordnet hochfahren
- Tabletop-Übung planen: Notfälle am Konferenztisch durchspielen
- Backup-Strategie und Restore-Tests: Datensicherung, die im Ernstfall funktioniert
- Notfallhandbuch IT: Was reingehört und wie du es aktuell hältst