Zum Hauptinhalt springen
CENEDRIL WIKI
EN
Starter Kit · Richtlinie

Richtlinie zur Geschäftskontinuität

Aktualisiert am 6 Min. Geprüft von: Cenedril-Redaktion
A.5.29A.5.30 ISO 27001NIS2 Art. 21(2)(c)BSI 200-4

Die Richtlinie zur Geschäftskontinuität regelt, wie deine Organisation den Betrieb aufrechterhält, wenn kritische IKT-Dienste ausfallen. Technischer Defekt, Cyberangriff, Naturkatastrophe, menschlicher Fehler, Lieferkettenausfall — die Ursache ist zweitrangig. Entscheidend ist, dass vorab definierte Pläne existieren, die sofort aktiviert werden können.

ISO 27001 widmet dem Thema zwei Annex-A-Controls: A 5.29 (Informationssicherheit bei Störungen) und A 5.30 (IKT-Bereitschaft für Geschäftskontinuität). NIS2 fordert in Art. 21(2)(c) explizit Maßnahmen zur Aufrechterhaltung des Betriebs, einschließlich Backup-Management und Krisenmanagement. Das BSI liefert mit dem Standard 200-4 einen vollständigen Leitfaden für Business Continuity Management und ergänzt in DER.4 die Notfallplanung sowie in CON.3 das Datensicherungskonzept. Weiter unten findest du die komplette Vorlage auf Deutsch und Englisch.

Worum geht es konkret?

Geschäftskontinuität beginnt lange vor dem Ernstfall. Die Richtlinie legt fest, welche Vorbereitungen deine Organisation trifft, damit ein Ausfall beherrschbar bleibt. Dazu gehören drei Ebenen: die organisatorische Struktur (wer entscheidet, wer handelt), die technische Vorbereitung (Backups, Redundanz, Wiederherstellungspläne) und die regelmäßige Überprüfung (Tests, Schulungen, Lessons Learned).

A 5.29 adressiert die Zeit während einer Störung: Wenn reguläre Sicherheitskontrollen nicht mehr greifen (weil ein System ausgefallen ist, ein Standort nicht erreichbar ist oder Notfallzugriffe nötig werden), müssen Kompensationsmaßnahmen einspringen. Wer darf im Notfall auf Systeme zugreifen, die normalerweise gesperrt sind? Welche Sicherheitsanforderungen gelten auch im Krisenmodus? Das klingt trivial, führt aber in der Praxis regelmäßig zu Chaos, wenn es nicht vorher dokumentiert ist.

A 5.30 deckt die Vorbereitung und Wiederherstellung ab: Business-Impact-Analyse, IKT-Kontinuitätspläne mit Aktivierungskriterien und Schritt-für-Schritt-Anleitungen, Kontaktlisten, Ressourcenbedarf und eine Testkadenz, die sicherstellt, dass die Pläne auch funktionieren.

Warum ist sie so wichtig?

Regulatorische Breite. NIS2 nennt Geschäftskontinuität in Art. 21(2)(c) als eine der zehn Mindestmaßnahmen. Das BSI widmet dem Thema einen eigenen Standard (200-4) und ergänzt mit DER.4 (Notfallmanagement) und CON.3 (Datensicherungskonzept) zwei weitere Bausteine. ISO 27001 verlangt mit A 5.29 und A 5.30 zwei Controls, die sich gegenseitig bedingen.

Wirtschaftliches Gewicht. Jede Stunde Ausfall kostet — direkt durch Umsatzverlust, indirekt durch Vertrauensverlust bei Kunden und Partnern. Die BIA macht diese Kosten sichtbar und liefert die Grundlage für Investitionsentscheidungen in Redundanz und Wiederherstellungsfähigkeit.

Schnittstelle zu IT-Betrieb und Incident Response. Die Geschäftskontinuitätsrichtlinie greift dort, wo der normale IT-Betrieb an seine Grenzen stößt. Sie ergänzt die Incident-Response-Prozesse um den Fokus auf Wiederherstellung und Aufrechterhaltung des Geschäftsbetriebs. Ohne diese Richtlinie fehlt die Brücke zwischen „Vorfall erkannt” und „Geschäft läuft wieder”.

Was gehört in die Richtlinie?

Die Vorlage deckt acht Kernbereiche ab — hier die wichtigsten im Überblick:

  • IKT-Kontinuitätsorganisation — BCM-Beauftragte:r, Wiederherstellungsteam-Leitungen, technische Spezialist:innen, jeweils mit Stellvertretung. Klare Eskalationswege und Entscheidungsbefugnisse.
  • Business-Impact-Analyse (BIA) — Identifikation geschäftskritischer Prozesse und der sie unterstützenden IKT-Dienste, Festlegung von RTO und RPO pro Dienst, Priorisierung nach Schadensausmass.
  • IKT-Kontinuitätspläne — Aktivierungskriterien, Schritt-für-Schritt-Wiederherstellung, Kontaktlisten, Ressourcenbedarf (Hardware, Lizenzen, Personal), Rückfallprozeduren.
  • Sicherheit während Störungen (A 5.29) — Kompensationsmaßnahmen für ausgefallene Kontrollen, Störungsmodus-Verfahren, Notfallzugriffsregelungen.
  • Frühwarnindikatoren — Kapazitätsschwellenwerte, Replikationsverzögerungen, Degradierungsmeldungen von Dienstleistern, automatisierte Alarmierung.
  • Backup-Konzept — Erstellung und Wiederherstellung, sichere Aufbewahrung an geographisch getrennten Standorten, regelmäßige Wiederherstellungstests.
  • Test- und Übungsprogramm — Planspiele vierteljährlich, technische Wiederherstellungstests halbjährlich, Vollsimulationen jährlich, dokumentierte Ergebnisse und Verbesserungsmaßnahmen.
  • Schulungen — Jährliche Schulung für Wiederherstellungspersonal, Sensibilisierung aller Beschäftigten für das Verhalten bei Störungen.

So führst du die Richtlinie ein

  1. 01

    Business-Impact-Analyse durchführen

    Identifiziere alle geschäftskritischen Prozesse und die IKT-Dienste, die sie unterstützen. Bestimme für jeden Dienst den RTO (wie schnell muss er wieder laufen?) und den RPO (wie viel Datenverlust ist tolerierbar?). Diese Analyse ist das Fundament — ohne sie sind alle weiteren Schritte Spekulation. Beziehe die Fachabteilungen ein, denn sie kennen die geschäftlichen Auswirkungen eines Ausfalls besser als die IT.

  2. 02

    Kontinuitätsorganisation aufbauen

    Benenne eine:n BCM-Beauftragte:n, Wiederherstellungsteam-Leitungen pro kritischem Dienst und technische Spezialist:innen für die Durchführung. Jede Rolle braucht eine Stellvertretung — ein Plan, der von einer einzigen Person abhängt, ist kein Plan. Dokumentiere Eskalationswege und Entscheidungsbefugnisse, damit im Ernstfall keine Zeit mit Zuständigkeitsfragen verloren geht.

  3. 03

    Wiederherstellungspläne erstellen

    Erstelle für jeden priorisierten IKT-Dienst einen Wiederherstellungsplan mit Aktivierungskriterien, Schritt-für-Schritt-Anleitung, Kontaktliste und Ressourcenbedarf. Die Pläne müssen so konkret sein, dass auch eine Stellvertretung sie ohne Rückfragen ausführen kann. Abstrakte Formulierungen wie 'System wiederherstellen' helfen im Ernstfall niemandem.

  4. 04

    Vorlage anpassen und genehmigen

    Ersetze die Platzhalter in unserer Vorlage und streiche Abschnitte, die nicht zutreffen. Lass die Richtlinie von der Geschäftsleitung genehmigen (ISO 27001, Clause 5.2) und kommuniziere sie an alle Beschäftigten. Besonders das Wiederherstellungspersonal muss den Inhalt kennen — eine E-Mail reicht dafür nicht.

  5. 05

    Testen, schulen, verbessern

    Starte mit einem Planspiel im ersten Quartal: Ein fiktives Szenario, alle Beteiligten am Tisch, Ablauf durchsprechen. Im zweiten Schritt folgt ein technischer Wiederherstellungstest für den kritischsten Dienst. Dokumentiere die Ergebnisse, identifiziere Schwachstellen und passe die Pläne an. Die jährliche Vollsimulation zeigt dann, ob das Gesamtsystem funktioniert.

Wo es in der Praxis schiefgeht

Aus Audit-Erfahrung, nach Häufigkeit sortiert:

1. BIA fehlt oder ist veraltet. Die Business-Impact-Analyse wurde einmal erstellt und seitdem nicht aktualisiert. Neue Dienste sind hinzugekommen, alte wurden abgeschaltet, aber die RTOs stammen noch aus dem Vorjahr. Ohne aktuelle BIA fehlt jede Priorisierung — im Ernstfall wird alles gleichzeitig wiederhergestellt, also effektiv nichts.

2. Pläne existieren, wurden aber nie getestet. Der Wiederherstellungsplan steht im Wiki, sieht plausibel aus und wurde vom Management abgesegnet. Beim ersten echten Test stellt sich heraus: Die Kontaktliste ist veraltet, der Backup-Server hat nicht genug Speicher, und die Schritt-für-Schritt-Anleitung setzt Software voraus, die inzwischen abgelöst wurde.

3. Keine Stellvertretungen. Der einzige Mensch, der den Datenbankserver wiederherstellen kann, ist gerade im Urlaub, krank oder selbst vom Vorfall betroffen. Jede Rolle in der Kontinuitätsorganisation braucht eine benannte Stellvertretung, die den Wiederherstellungsprozess kennt und geübt hat.

4. Backup-Wiederherstellung nie geprüft. Backups werden zuverlässig erstellt — aber niemand hat je getestet, ob sie sich tatsächlich wiederherstellen lassen. Korrupte Backups, fehlende Verschlüsselungsschlüssel oder inkompatible Softwareversionen fallen erst auf, wenn es zu spät ist.

5. Kompensationsmaßnahmen nicht definiert. Während einer Störung werden Sicherheitskontrollen aufgeweicht („Im Notfall geben wir allen Admin-Zugriff”). Ohne vorab definierte Kompensationsmaßnahmen entstehen Sicherheitslücken, die über die eigentliche Störung hinaus bestehen bleiben.

Vorlage: Richtlinie zur Geschäftskontinuität

Vollständige Richtlinie

Richtlinie zur Geschäftskontinuität

.md · DE.md · EN

Dokumentenkontrolle
Eigentümer: [RICHTLINIEN_EIGENTÜMER_ROLLE, z. B. Informationssicherheitsbeauftragte/r]
Genehmigt von: [GENEHMIGER_NAME_UND_ROLLE]
Version: [VERSION]
Gültig ab: [GÜLTIGKEITSDATUM]
Nächste Überprüfung: [NÄCHSTES_ÜBERPRÜFUNGSDATUM]

1. Rechtliche/Regulatorische Grundlage

ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Anhang A:

  • A 5.29 — Informationssicherheit während einer Störung
  • A 5.30 — IKT-Bereitschaft für die Geschäftskontinuität

BSI IT-Grundschutz:

  • DER.4 (Notfallmanagement / Business Continuity Management)
  • DER.2.1 (Behandlung von Sicherheitsvorfällen)
  • CON.3 (Datensicherungskonzept)

BSI-Standard 200-4 (Business Continuity Management).

Weitere jurisdiktionsspezifische Gesetze und Vorschriften — insbesondere NIS2, DORA und branchenspezifische Resilienzanforderungen — sind im Rechtsregister aufgeführt und werden durch Verweis einbezogen.

2. Zweck & Geltungsbereich

Diese Richtlinie legt den Rahmen für das Business Continuity Management von [IHR_ORGANISATIONSNAME] fest. Sie definiert, wie die Informationssicherheit während Störungen aufrechterhalten wird, wie IKT-Dienste auf die Geschäftskontinuität vorbereitet werden und wie die Organisation ihre Fähigkeit zur Wiederherstellung nach widrigen Ereignissen plant, testet und verbessert.

Die Richtlinie umfasst die Geschäftsauswirkungsanalyse, die Festlegung von Wiederherstellungszielen, die IKT-Kontinuitätsplanung, das Testen und Üben sowie die Aufrechterhaltung von Informationssicherheitsmaßnahmen über alle Phasen der Störung und Wiederherstellung hinweg. Sie gilt für alle Geschäftsprozesse, IKT-Dienste und Informationswerte innerhalb des Geltungsbereichs des ISMS. Alle Beschäftigten, Auftragnehmer und Drittanbieter, die an Kontinuitätsplanung, -reaktion oder -wiederherstellung beteiligt sind, unterliegen dieser Richtlinie.

Das Notfallmanagement priorisiert kritische Geschäftsprozesse. Eskalationsverfahren für Vorfälle definieren klare Schwellen für den Übergang von der Vorfallreaktion zur Notfall- und Krisenaktivierung.

3. Informationssicherheit während einer Störung (A 5.29)

Die Informationssicherheit wird während Störungen auf einem angemessenen Niveau aufrechterhalten. Sicherheitsmaßnahmen bleiben während der Vorfallreaktion, des Failover- und des Wiederherstellungsbetriebs aktiv. Wo primäre Maßnahmen nicht verfügbar sind, treten vorab genehmigte kompensierende Maßnahmen sofort in Kraft. Die Wiederherstellung aus verschiedenen Ausfallszenarien — einschließlich technischer Ausfälle, Lieferkettenstörungen, Naturkatastrophen und Cyberangriffe — wird im Voraus als Teil des Notfallmanagements geplant.

  • Sicherheitsmaßnahmen in Kontinuitätsplänen: Jeder Kontinuitätsplan dokumentiert die relevanten Informationssicherheitsmaßnahmen im Normalbetrieb und definiert, welche kompensierenden Maßnahmen während einer Störung gelten. Failover-Umgebungen erhalten dieselben Zugriffskontrollniveaus, Netzwerksegmentierung und Überwachungsfähigkeiten wie Produktionssysteme. Die Backup-Verschlüsselung wird vor der Wiederherstellung verifiziert, um Datenintegrität und -vertraulichkeit sicherzustellen.
  • Sicherheitsverfahren im Störungsmodus: Für kritische Sicherheitsmaßnahmen definieren Kontinuitätspläne Störungsmodus-Verfahren, die beschreiben, wie der Schutz aufrechterhalten wird, wenn Primärsysteme nicht verfügbar sind. Mitarbeitende mit Wiederherstellungsverantwortung erhalten jährliche Schulungen zu diesen Verfahren und nehmen an Übungen teil, die ihre Fähigkeit zur Bedienung der Maßnahmen unter eingeschränkten Bedingungen validieren.
  • Kompensierende Maßnahmen: Für Sicherheitsmaßnahmen, die während einer Störung nicht funktionieren können, dokumentieren Kontinuitätspläne kompensierende Maßnahmen, die einen gleichwertigen Schutz bieten. Jeder Eintrag kompensierender Maßnahmen spezifiziert die ersetzte Primärmaßnahme, den Aktivierungsauslöser und die verantwortliche Person. Kompensierende Maßnahmen werden während Kontinuitätsübungen getestet und nach jeder realen Aktivierung überprüft.

4. IKT-Bereitschaft für die Geschäftskontinuität (A 5.30)

Die IKT-Bereitschaft für die Geschäftskontinuität stellt sicher, dass die zur Unterstützung kritischer Geschäftsprozesse erforderlichen IKT-Dienste innerhalb definierter Zeitrahmen wiederhergestellt werden können. Das IKT-Kontinuitätsprogramm deckt den gesamten Lebenszyklus ab: Geschäftsauswirkungsanalyse, Festlegung von Wiederherstellungszielen, Planung, Umsetzung, Testen, Pflege und fortlaufende Verbesserung. Das Datensicherungskonzept deckt sowohl die Erstellung als auch die Wiederherstellung von Backups ab, regelmäßige Wiederherstellungstests sowie die sichere Backup-Lagerung an geografisch getrennten Standorten. Detaillierte Backup-Dokumentation — einschließlich Umfang, Methode, Zeitplan, Aufbewahrung, Speicherorten und Ergebnissen von Wiederherstellungstests — wird als Teil des Notfallwiederherstellungsplans jedes Systems geführt.

4.1 Geschäftsauswirkungsanalyse & Wiederherstellungsziele

  • Mindestanforderungen an Leistung & Kapazität: Jeder IKT-Kontinuitätsplan spezifiziert Mindestanforderungen an Leistung und Kapazität während einer Störung, einschließlich akzeptabler Bandbreite, Speicherkapazität, Rechenleistung und gleichzeitiger Benutzerschwellenwerte. Diese Spezifikationen werden aus der Geschäftsauswirkungsanalyse (BIA) abgeleitet und durch die Prozesseigentümer der abhängigen Geschäftsaktivitäten validiert. Dienstleistungsniveaus im reduzierten Modus werden formal dokumentiert und allen Stakeholdern kommuniziert.
  • Wiederanlaufziele (RTO): Für jeden priorisierten IKT-Dienst wird ein Wiederanlaufziel (Recovery Time Objective, RTO) definiert. Wiederherstellungsverfahren spezifizieren die genaue Abfolge der Wiederherstellungsschritte, Systemabhängigkeiten und Verifizierungsprüfpunkte. RTOs werden durch regelmäßiges Testen validiert. Jedes Testergebnis, das das definierte RTO überschreitet, löst eine Korrekturmaßnahme und eine Planrevision aus. RTO-Werte werden jährlich und nach wesentlichen Änderungen der IKT-Landschaft überprüft.
  • Wiederherstellungspunkte (RPO): Für jede priorisierte Informationsressource wird ein Wiederherstellungspunkt (Recovery Point Objective, RPO) definiert. Backup-Strategien und -Frequenzen sind darauf ausgerichtet, die RPO-Anforderungen zu erfüllen oder zu übertreffen. Die Backup-Wiederherstellung wird regelmäßig getestet, um die RPO-Erreichung zu verifizieren. Wo RPO-Anforderungen nahezu keinen Datenverlust zulassen, werden synchrone Replikation oder kontinuierliche Datenschutzmechanismen implementiert. RPO-Werte bestimmen den Backup-Zeitplan, der im Notfallwiederherstellungsplan jedes Systems dokumentiert ist.

4.2 Organisationsstruktur

  • IKT-Kontinuitätsorganisation: Eine IKT-Kontinuitätsorganisation wird mit definierten Rollen eingerichtet: IKT-Kontinuitätsmanager, Wiederherstellungsteam-Leitungen und technische Wiederherstellungsspezialisten. Für jede Rolle ist eine benannte Vertretung vorgesehen, um die Verfügbarkeit bei Abwesenheiten sicherzustellen. Kompetenzanforderungen sind dokumentiert und werden durch Schulungsnachweise verifiziert. Der IKT-Kontinuitätsmanager berichtet der Geschäftsleitung und koordiniert sich mit der/dem Informationssicherheitsbeauftragten in allen sicherheitsbezogenen Kontinuitätsangelegenheiten. Eskalationswege von der Vorfallreaktion zum Notfall- und Krisenmanagement sind definiert und dokumentiert.

4.3 IKT-Kontinuitätsplanung

  • Dokumentierte IKT-Kontinuitätspläne: Für jeden kritischen IKT-Dienst werden umfassende IKT-Kontinuitätspläne dokumentiert. Jeder Plan enthält Aktivierungskriterien, schrittweise Wiederherstellungsanweisungen, Kontaktlisten mit primären und sekundären Kontakten, Ressourcenanforderungen (Personal, Hardware, Software, Netzwerk, Räumlichkeiten) und erwartete Zeitpläne. Pläne verweisen auf die anwendbaren Sicherheitsmaßnahmen aus dem Abschnitt Informationssicherheit während einer Störung. Kommunikationsverfahren legen fest, wie interne und externe Stakeholder in jeder Phase der Störung informiert werden.
  • Managementgenehmigung: IKT-Kontinuitätspläne werden formal von der Geschäftsleitung genehmigt, bevor die Aktivierungsbereitschaft erklärt wird. Die Genehmigung umfasst die Überprüfung von Management Summaries, Kostenauswirkungen, Restrisikobewertungen und Ressourcenzusagen. Eine erneute Genehmigung wird jährlich sowie nach wesentlichen Änderungen der IKT-Umgebung, der Organisationsstruktur oder der Bedrohungslandschaft eingeholt. Genehmigungsnachweise werden als dokumentierte Informationen im ISMS aufbewahrt.

4.4 Tests & Übungen

  • Regelmäßiges Testen & Üben: IKT-Kontinuitätspläne werden in definierten Intervallen getestet: Tabletop-Übungen mindestens vierteljährlich, technische Wiederherstellungstests mindestens halbjährlich und vollständige Simulationsübungen mindestens jährlich. Testergebnisse, identifizierte Lücken und Korrekturmaßnahmen werden in Testberichten dokumentiert. Jeder Test verifiziert, dass RTOs und RPOs unter realistischen Bedingungen erreichbar sind. Die Backup-Wiederherstellung wird regelmäßig getestet, um zu bestätigen, dass gesicherte Daten innerhalb der RPO-Ziele wiederhergestellt werden können. Gewonnene Erkenntnisse fließen in Planrevisionen ein, und ungelöste Feststellungen werden über den ISMS-Korrekturmaßnahmenprozess nachverfolgt.

4.5 Kontinuitätsmanagement

  • Ursachenunabhängige Reaktion: IKT-Kontinuitätspläne adressieren Störungen unabhängig von der Ursache, einschließlich technischer Ausfälle, Naturkatastrophen, Cyberangriffe, menschlichen Fehlern und Lieferkettenversagens. Reaktionsverfahren sind wo möglich ursachenunabhängig gestaltet, mit ursachenspezifischen Ergänzungen für gezielte Szenarien wie Ransomware, Rechenzentrumsausfall oder Ausfall kritischer Lieferanten. Die Wiederherstellungsplanung deckt vielfältige Ausfallszenarien ab.
  • Unterstützung priorisierter Aktivitäten: Die in der BIA identifizierten priorisierten Geschäftsaktivitäten werden ihren erforderlichen IKT-Diensten zugeordnet, einschließlich aller Abhängigkeiten von Infrastruktur, Anwendungen, Daten und externen Dienstleistern. Lückenanalysen verifizieren, dass Kontinuitätspläne die Verfügbarkeit dieser Dienste innerhalb der definierten RTOs sicherstellen. Wo Lücken identifiziert werden, werden Behebungsmaßnahmen zugewiesen, nachverfolgt und verifiziert, bevor Pläne als einsatzbereit erklärt werden.
  • Proaktive Reaktion & Frühwarnung: Kontinuitätspläne definieren Aktivierungskriterien, die eine frühzeitige Reaktion ermöglichen, bevor eine vollständige Störung eintritt. Pläne werden bei der Erkennung von Vorfällen aktiviert, die zu einer Dienstunterbrechung eskalieren könnten, einschließlich Überschreitungen von Kapazitätsschwellen, Replikationsverzögerungswarnungen, Meldungen über Verschlechterung von Lieferantendiensten und Eskalationen von Sicherheitsvorfällen.

5. Rollen & Verantwortlichkeiten

  • Geschäftsleitung: Genehmigt diese Richtlinie, stellt Ressourcen für das Business Continuity Management bereit und stellt sicher, dass Kontinuitätsziele mit der Gesamtgeschäftsstrategie abgestimmt sind.
  • Informationssicherheitsbeauftragte/r (ISB): Stellt sicher, dass Informationssicherheitsmaßnahmen in alle Kontinuitätspläne integriert sind und dass kompensierende Maßnahmen einen angemessenen Schutz während Störungen bieten.
  • IKT-Kontinuitätsmanager: Koordiniert das IKT-Kontinuitätsprogramm, pflegt Kontinuitätspläne, plant Tests und Übungen und berichtet der Geschäftsleitung über die Programmwirksamkeit.
  • Wiederherstellungsteam-Leitungen: Steuern die Ausführung von Wiederherstellungsverfahren für die ihnen zugewiesenen IKT-Dienste, koordinieren sich mit technischen Wiederherstellungsspezialisten und berichten dem IKT-Kontinuitätsmanager über den Fortschritt.
  • Technische Wiederherstellungsspezialisten: Führen schrittweise Wiederherstellungsverfahren aus, verifizieren die Systemintegrität nach der Wiederherstellung und bestätigen, dass Sicherheitsmaßnahmen wiederhergestellt sind.
  • Prozesseigentümer: Definieren geschäftliche Anforderungen an RTOs, RPOs und Mindest-Service-Level über den BIA-Prozess. Validieren, dass Kontinuitätspläne ihre operativen Bedürfnisse erfüllen.
  • Alle Beschäftigten & Auftragnehmer: Nehmen an Kontinuitätsübungen teil, befolgen Verfahren im Störungsmodus und melden Vorfälle, die eine Aktivierung von Kontinuitätsplänen auslösen können.

6. Überprüfung & Pflege

Diese Richtlinie wird überprüft:

  • Mindestens jährlich im Rahmen des ISMS-Managementbewertungszyklus.
  • Nach wesentlichen Geschäftskontinuitätsvorfällen, einschließlich tatsächlicher Aktivierungen von Kontinuitätsplänen.
  • Wenn sich die Ergebnisse der Geschäftsauswirkungsanalyse wesentlich ändern, einschließlich Änderungen an der Priorisierung kritischer Prozesse oder an Wiederherstellungszielen.
  • Nach wesentlichen Änderungen der IKT-Infrastruktur, der Organisationsstruktur oder der Lieferantenlandschaft.
  • Nach Kontinuitätsübungen, die wesentliche Lücken oder Verbesserungsmöglichkeiten aufzeigen.
  • Wenn neue rechtliche, regulatorische oder vertragliche Anforderungen an die Geschäftskontinuität identifiziert werden.

Quellen

Abgedeckte ISO-27001-Kontrollen

A.5.29 Informationssicherheit bei Störungen A.5.30 IKT-Bereitschaft für Geschäftskontinuität

Häufig gestellte Fragen

Reicht eine einzelne Richtlinie für Geschäftskontinuität?

Ja. Unsere Vorlage deckt beide Annex-A-Controls (A 5.29 und A 5.30) in einem Dokument ab. A 5.29 regelt die Informationssicherheit während einer Störung, A 5.30 die IKT-Bereitschaft. Manche Organisationen trennen BCM und IT-DR in separate Dokumente — das kann sinnvoll sein, wenn unterschiedliche Teams verantwortlich sind. Bei den meisten KMU erzeugt ein gemeinsames Dokument weniger Pflegeaufwand.

Was ist der Unterschied zwischen RTO und RPO?

RTO (Recovery Time Objective) ist die maximale Ausfallzeit, die dein Geschäft toleriert — also wie schnell ein Dienst wieder laufen muss. RPO (Recovery Point Objective) ist der maximale Datenverlust, gemessen in Zeit — also wie alt das letzte brauchbare Backup sein darf. Beide Werte bestimmst du pro IKT-Dienst in der Business-Impact-Analyse.

Wie oft muss ich die Wiederherstellungspläne testen?

Die Richtlinie empfiehlt drei Testtypen mit unterschiedlicher Kadenz: Planspiele vierteljährlich, technische Wiederherstellungstests halbjährlich, Vollsimulationen jährlich. ISO 27001 schreibt keine exakte Frequenz vor, aber Auditor:innen erwarten dokumentierte Tests mindestens einmal pro Jahr. Häufigere Tests erhöhen die Reife und verkürzen die tatsächliche Wiederherstellungszeit.

Brauche ich einen eigenen BCM-Beauftragten?

ISO 27001 verlangt keine dedizierte Rolle, aber A 5.30 setzt voraus, dass Verantwortlichkeiten klar zugewiesen sind. In der Praxis hat sich eine dreigliedrige Struktur bewährt: ein:e BCM-Beauftragte:r koordiniert, Wiederherstellungsteam-Leitungen verantworten je einen Dienst, technische Spezialist:innen führen die Wiederherstellung durch. Jede Rolle braucht eine Stellvertretung — sonst fällt der Plan aus, wenn die Schlüsselperson gerade im Urlaub ist.

Muss die BIA auch Nicht-IT-Prozesse berücksichtigen?

Ja. Die Business-Impact-Analyse bewertet alle geschäftskritischen Prozesse, auch solche ohne direkten IT-Bezug (z.B. Logistik, Produktion, Kundenservice). Für die IKT-Kontinuitätspläne nach A 5.30 priorisierst du dann die IT-Dienste, die diese Prozesse unterstützen. Ohne diesen Bezug zwischen Geschäftsprozess und IKT-Dienst bleiben die RTOs willkürlich.