ISO 22301: Managementsystem für Betriebskontinuität in der Praxis

Was ISO 22301 ist und für wen sie relevant ist

ISO 22301:2019, Security and resilience - Business continuity management systems - Requirements, ist die zweite Ausgabe und ersetzte die Version von 2012. In Polen wurde sie als PN-EN ISO 22301 übernommen. Sie enthält Anforderungen und kann daher als Grundlage einer Managementsystemzertifizierung dienen. Weitere Dokumente der 223xx-Familie enthalten ergänzende Leitlinien:^[1]

• ISO 22313 - Leitlinien zur Anwendung von ISO 22301;^[2]
• ISO/TS 22317 - Leitlinien zur Business Impact Analysis (BIA);^[3]
• ISO/TS 22318 - Business Continuity in der Lieferkette;
• ISO 22331 - Auswahl von Kontinuitätsstrategien;
• ISO 22398 - Programme für Übungen und Tests.

Stand August 2026. Maßgeblich bleibt ISO 22301:2019 zusammen mit ISO 22301:2019/Amd 1:2024, der im Februar 2024 veröffentlichten Klimaänderung für Managementsystemnormen. Die Änderung ergänzt in den Abschnitten 4.1 und 4.2 die Prüfung, ob Klimawandel für den Kontext der Organisation relevant ist und ob interessierte Parteien entsprechende Anforderungen haben. Für Business Continuity ist dies unmittelbar nachvollziehbar: Überschwemmungen, Hitze, Energieausfälle und andere Umweltbedingungen können Störungsszenarien direkt beeinflussen. ISO kennzeichnet die Norm inzwischen als zur Überarbeitung vorgesehen; bis zur Veröffentlichung einer neuen Ausgabe gilt weiterhin die Ausgabe 2019 mit Amendment 1:2024.^[1]

Wer die Norm in der Praxis nutzt

Die Norm ist sektorneutral. Typische Anwendungsfälle sind:

• Einrichtungen im Geltungsbereich von KSC/NIS2. Business Continuity, Backup-Management, Disaster Recovery und Krisenmanagement gehören ausdrücklich zu den Risikomanagementmaßnahmen von Artikel 21 NIS2.^[5]
• Finanzunternehmen unter DORA, die IKT-Kontinuitätsrichtlinien, Reaktions- und Wiederherstellungspläne sowie Tests benötigen.^[6]
• Anbieter kritischer Dienste, deren Kunden Nachweise zur Kontinuität und Lieferkettenresilienz verlangen, teilweise einschließlich vertraglicher Zertifizierungsanforderungen.
• Öffentliche Stellen unter dem polnischen KRI. KRI verlangt ein Managementsystem für Informationssicherheit; ISO 22301 kann dieses dort vertiefen, wo Kontinuitätsrisiken dies rechtfertigen, ist aber durch KRI nicht selbst verpflichtend vorgeschrieben.^[8]

Struktur der Norm - Abschnitte 4-10

ISO 22301 nutzt die harmonisierte Struktur von Managementsystemnormen, die auch ISO/IEC 27001 und andere Normen verwenden. Eine Organisation mit bestehendem ISMS kann BCMS-Governance daher integrieren, statt ein vollständig paralleles Managementsystem aufzubauen.

• Abschnitt 4 - Kontext der Organisation. Geltungsbereich, interessierte Parteien sowie rechtliche und regulatorische Anforderungen.
• Abschnitt 5 - Führung. Kontinuitätsrichtlinie, Rollen, Verantwortlichkeiten und Verpflichtung der Leitung.
• Abschnitt 6 - Planung. Risiken und Chancen, Kontinuitätsziele und geplante Änderungen.
• Abschnitt 7 - Unterstützung. Ressourcen, Kompetenz, Bewusstsein, Kommunikation und dokumentierte Information.
• Abschnitt 8 - Betrieb. Operativer Kern mit BIA, Risikobewertung, Kontinuitätsstrategien und -lösungen, Plänen, Reaktionsstruktur, Übungen und Tests.
• Abschnitt 9 - Bewertung der Leistung. Monitoring, Messung, internes Audit und Managementbewertung.
• Abschnitt 10 - Verbesserung. Nichtkonformitäten, Korrekturmaßnahmen und fortlaufende Verbesserung.

Der operative Schwerpunkt liegt in Abschnitt 8, ist aber von den vorherigen Entscheidungen zu Kontext, Verantwortung, Ressourcen und Zielen abhängig. Wer Pläne schreibt, bevor BIA und akzeptable Unterbrechungen geklärt sind, plant leicht für die falschen Prioritäten.

BIA und vier zentrale Parameter

Die Business Impact Analysis untersucht, wie sich die Auswirkungen einer Unterbrechung über die Zeit entwickeln und welche Ressourcen für die Wiederaufnahme erforderlich sind. Entscheidend ist nicht der Bericht selbst, sondern die daraus abgeleitete Entscheidung.^[3]

MTPD - Maximum Tolerable Period of Disruption

Der Zeitpunkt, nach dem die Auswirkungen einer Unterbrechung für die Organisation nicht mehr akzeptabel sind, etwa wegen finanzieller, rechtlicher, vertraglicher, sicherheitsbezogener oder dienstlicher Folgen. MTPD ist eine Business-Entscheidung, keine IT-Einstellung.

RTO - Recovery Time Objective

Die Zielzeit, innerhalb der ein Prozess, Dienst oder System wiederhergestellt werden soll. Sie muss mit der tolerierbaren Unterbrechung und den tatsächlichen Prioritäten der Organisation konsistent sein.

RPO - Recovery Point Objective

Das maximal tolerierbare Datenverlustfenster, ausgedrückt in Zeit. RPO muss zur Backup-, Replikations- und Datenschutzarchitektur passen. Ein RPO von 15 Minuten bei ausschließlich nächtlichem Backup ist keine Strategie, sondern eine offene Designlücke.

MBCO - Minimum Business Continuity Objective

Das minimale akzeptable Leistungsniveau während einer Störung. Es kann deutlich unter der normalen Produktionskapazität liegen. Dadurch kann eine Übergangslösung kritische Ergebnisse aufrechterhalten, ohne die gesamte Produktionsumgebung zu duplizieren.

Ein häufiger Fehler besteht darin, RTO und RPO aus dem abzuleiten, was die vorhandene Infrastruktur bereits leisten kann. Die Reihenfolge sollte umgekehrt sein: Business-Toleranzen definieren Anforderungen; die Differenz zur heutigen Fähigkeit wird als Risiko- und Investitionsentscheidung sichtbar.

Strategien und Kontinuitätspläne

Sind die Wiederherstellungsziele bekannt, wählt die Organisation geeignete Strategien und dokumentiert sie in ausführbaren Plänen. NIST SP 800-34 bietet ergänzende Leitlinien.^[7] Typische Ansätze sind:

• Redundanz - Zweitstandort, Cluster oder Replikation. Kann Wiederherstellungszeiten reduzieren, erhöht aber Kosten und Komplexität.
• Wiederherstellung aus Backup - einschließlich Offline- oder unveränderbarer Kopien, wenn das Ransomware-Risiko dies rechtfertigt.
• Manueller oder alternativer Betrieb - eingeschränkter Betrieb bis zur Wiederherstellung des Systems.
• Verlagerung zu einem anderen Anbieter - Nutzung einer vorab vereinbarten Alternative, nicht erst Verhandlung während der Krise.
• Akzeptanz - dokumentierte Leitungsentscheidung, dass ein Prozess nicht kurzfristig wiederhergestellt wird.

Ein Kontinuitätsplan sollte auch von einer Person ausführbar sein, die ihn nicht geschrieben hat, unter Druck und möglicherweise ohne Zugriff auf das ausgefallene Umfeld. Deshalb braucht er klare Aktivierungskriterien, Rollen, Kontaktdaten, Kommunikationsverfahren und eine Kopie außerhalb der wiederherzustellenden Umgebung.

Übungen, Tests und internes Audit

Abschnitt 8 verlangt ein Programm aus Übungen und Tests. ISO 22301 legt kein universelles Intervall fest. Häufigkeit und Testart sollten sich nach Kritikalität, Änderungen, Risikobewertung und den Ergebnissen früherer Übungen richten. Ein Programm kann Tabletop-Übungen, technische Wiederherstellungstests und umfassendere Failover-Übungen kombinieren; der Zeitplan muss im Kontext der Organisation begründbar sein.

Jede Übung sollte Nachweise und Erkenntnisse erzeugen. Ein Test, der nur das erwartete Ergebnis bestätigt, ohne Annahmen zu hinterfragen, hat begrenzten Wert. Erkenntnisse müssen in Korrekturmaßnahmen und Planänderungen überführt werden.

Das interne Audit nach Abschnitt 9 bewertet Konformität und Funktionsfähigkeit des Managementsystems. Auditoren sollten gegenüber dem geprüften Bereich ausreichend objektiv sein. Kleinere Organisationen nutzen häufig externe Unterstützung, wenn intern keine angemessene Funktionstrennung möglich ist.

Verhältnis zu ISO 27001, KSC/NIS2, DORA und KRI

ISO 22301 und ISO/IEC 27001

ISO/IEC 27001 fokussiert Informationssicherheit - Vertraulichkeit, Integrität und Verfügbarkeit. ISO 22301 fokussiert die Fähigkeit der Organisation, priorisierte Tätigkeiten und Dienste auch bei Störungen weiterzuführen, einschließlich Ausfällen von Personal, Gebäuden, Lieferanten oder Technologie. Die Themen überschneiden sich: ISO/IEC 27001:2022 enthält in Anhang A unter anderem A.5.29 Information security during disruption und A.5.30 ICT readiness for business continuity.^[4]

Eine Organisation mit funktionierendem ISMS kann BCMS-Elemente schrittweise integrieren. Kontext, Führung, Kompetenz, internes Audit und Managementbewertung sind strukturell ähnlich; BIA, Strategien, Pläne und Übungen ergänzen die kontinuitätsspezifische Ebene.

ISO 22301 und KSC/NIS2

Das 2026 novellierte polnische KSC setzt NIS2-Anforderungen um, darunter Business Continuity, Backup-Management, Disaster Recovery und Krisenmanagement. Eine ISO-22301-Zertifizierung befreit nicht von gesetzlichen Pflichten, kann aber belastbare Nachweise für Audits und Aufsicht liefern.^[5]

ISO 22301 und DORA

DORA verlangt im Finanzsektor IKT-Business-Continuity-Richtlinien, Reaktions- und Wiederherstellungspläne sowie deren Tests. ISO 22301 bietet eine geeignete Managementsystemstruktur, deckt jedoch nicht alle DORA-spezifischen Pflichten ab, etwa das Informationsregister zu IKT-Verträgen, regulatorische Incident-Meldungen oder TLPT.^[6]

ISO 22301 und KRI

Das polnische KRI verlangt im Geltungsbereich ein Managementsystem für Informationssicherheit und mindestens jährlich interne Audits der Informationssicherheit. Ein auf PN-ISO/IEC 27001 basierendes ISMS ist ein Weg zu der in KRI vorgesehenen Anerkennung, keine Pflicht zur Zertifizierung. Kontinuität ist Teil des breiteren Managementsystems; ISO 22301 kann diesen Bereich vertiefen.^[8]

Zertifizierung

Die Zertifizierung erfolgt durch eine geeignete Zertifizierungsstelle und nicht durch den Berater, der das System entworfen hat. Typischerweise umfasst der Prozess:

1. Stage 1 - Prüfung von Dokumentation und Bereitschaft einschließlich Geltungsbereich, Richtlinie, BIA, Plänen und Nachweisen interner Bewertung.
2. Stage 2 - Bewertung der tatsächlichen Umsetzung durch Interviews, Aufzeichnungen und Nachweise aus Übungen.
3. Zertifizierungsentscheidung und Ausstellung des Zertifikats.
4. Überwachungsaktivitäten innerhalb des Zertifizierungszyklus.
5. Rezertifizierung am Ende des Zyklus.

Eine universelle Dauer der Einführung lässt sich nicht seriös angeben. Sie hängt von BCMS-Geltungsbereich, Zahl der Prozesse und Standorte, Qualität vorhandener Pläne, notwendigen technischen Änderungen und Verfügbarkeit fachlicher Verantwortlicher ab. Die BIA sollte wesentlichen Investitionsentscheidungen vorausgehen, weil RTO und RPO die Wiederherstellungsarchitektur begründen sollten - nicht umgekehrt.

Häufige Fehler

• Ein ausschließlich von IT für IT geschriebener Kontinuitätsplan, der Server wiederherstellt, aber den eigentlichen Dienst nicht beschreibt.
• RTO und RPO aus bestehenden Infrastrukturmöglichkeiten statt aus Business-Toleranzen.
• Backups ohne Wiederherstellungstest. Der erfolgreiche Backup-Job allein beweist keine Wiederherstellbarkeit.
• Ein Plan, der nur in der gerade ausgefallenen Umgebung verfügbar ist.
• Nicht berücksichtigte Lieferanten und externe Abhängigkeiten.
• Übungen, die Erfolg demonstrieren sollen, statt Schwächen zu finden.
• Das Zertifikat als Ziel statt tatsächlicher Resilienz.