Business Impact Analysis für ISO 27001, NIS2 und DORA

Die Auditfrage, die die tatsächliche Kontinuitätslücke offenlegt

Es ist Montagmorgen, und Maria, CISO eines schnell wachsenden FinTech-Unternehmens, bereitet sich auf eine Sitzung des Risikoausschusses des Leitungsorgans vor. Die Betreffzeile ist kurz: „DORA- und NIS2-Bereitschaft: BIA-Überprüfung“.

Ihr Team hat aufgebaut, was die meisten Führungskräfte erwarten würden. Es gibt ein zertifiziertes ISO/IEC 27001:2022-ISMS, Incident-Response-Playbooks, Backup-Screenshots, Schwachstellenberichte, Lieferantenfragebögen, Cloud-Architekturdiagramme und ein aktualisiertes Risikoregister. Unternehmenskunden senden NIS2-Fragebögen. Kunden aus dem Finanzsektor nehmen DORA-Klauseln in Verträge auf. Das ISO/IEC 27001:2022-Überwachungsaudit ist nur noch einen Monat entfernt.

Dann stellt der externe Auditor die Frage, die den Raum verändert:

„Wenn Ihre Plattform für das Kunden-Onboarding 18 Stunden lang nicht verfügbar ist: Welche regulierten Services sind betroffen, welche Lieferanten sind beteiligt, welche Wiederherstellungspriorität wurde genehmigt, und wo ist der Nachweis, dass der Geschäftsbereich RTO und RPO akzeptiert hat?“

Der Raum wird still.

Der Backup-Zeitplan sagt das eine. Der Disaster-Recovery-Plan sagt etwas anderes. Der Lieferantenvertrag enthält einen Verfügbarkeits-SLA, aber keine Nachweise aus Wiederherstellungstests. Das Risikoregister erwähnt Verfügbarkeit, erklärt aber nicht, warum ein Service schneller wiederhergestellt werden muss als ein anderer. Das Management hat die Sicherheitsrichtlinie genehmigt, nicht jedoch die geschäftlichen Auswirkungen von Ausfallzeiten.

Das ist das Problem der Business Impact Analysis im Jahr 2026.

Eine Business Impact Analysis, kurz BIA, ist nicht mehr nur eine Tabelle als Anlage zu einem Kontinuitätsplan. Sie ist die Nachweisbrücke zwischen Geschäftsservices, IKT-Assets, Lieferanten, Wiederherstellungsprioritäten, RTO/RPO, Schwellenwerten für Sicherheitsvorfälle, Resilienztests und der Rechenschaftspflicht des Leitungsorgans. Für Organisationen, die ISO/IEC 27001:2022 mit NIS2-Kontinuitätsanforderungen und DORA-IKT-Resilienz ausrichten, ist die BIA der Punkt, an dem Compliance operativ wird.

Die stärksten Organisationen verfügen bereits über viele der richtigen Kontrollen. Ihre Schwäche liegt in der Nachvollziehbarkeit. Die BIA macht aus verstreuten Nachweisen eine auditfähige Darstellung: was wichtig ist, warum es wichtig ist, wie schnell es wiederhergestellt werden muss, welche Abhängigkeiten es stützen, was getestet wurde, was fehlgeschlagen ist, was verbessert wurde und wer das Restrisiko genehmigt hat.

Warum alte BIA-Tabellen inzwischen ein Risiko darstellen

NIS2 und DORA haben den Maßstab für die Erfüllung von Kontinuitätsanforderungen verändert. Sie behandeln Business Continuity, Disaster Recovery, Incident Response, Lieferantenresilienz und Governance nicht als getrennte Dokumente. Sie erwarten, dass diese Elemente als ein System funktionieren.

Für NIS2-Einrichtungen verlangt Article 21 technische, operative und organisatorische Maßnahmen, um Risiken für Netz- und Informationssysteme zu steuern und Auswirkungen von Vorfällen auf Empfänger ihrer Dienste und andere Dienste zu verhindern oder zu minimieren. Zu den Mindestmaßnahmen gehören Risikoanalyse, Verfahren zur Behandlung von Sicherheitsvorfällen, Business Continuity einschließlich Backup-Management, Disaster Recovery und Krisenmanagement, Sicherheit der Lieferkette, Umgang mit Schwachstellen, Bewertung der Wirksamkeit von Risikomanagementmaßnahmen, Schulung, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management, MFA und sichere Kommunikation.

NIS2 Article 20 verlagert das Thema in den Verantwortungsbereich des Leitungsorgans. Leitungsorgane müssen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und können für Verstöße haftbar gemacht werden. Ein nicht belegtes RTO von vier Stunden ist daher nicht nur eine technische Inkonsistenz. Es ist eine Governance-Schwäche.

DORA gilt seit dem 17. Januar 2025 und schafft einen einheitlichen EU-Rahmen für das Management von IKT-Risiken, die Meldung von Sicherheitsvorfällen, Tests der digitalen operationalen Resilienz, das Management von IKT-Drittparteienrisiken, vertragliche Anforderungen und die Aufsicht über kritische IKT-Drittdienstleister. Für Finanzunternehmen und für Technologieanbieter, die diese vertraglich unterstützen, macht DORA operative Resilienz zu einer strukturierten Nachweisanforderung.

DORA Articles 5 und 6 verlangen Governance und einen dokumentierten IKT-Risikomanagementrahmen. Articles 7 bis 14 behandeln zuverlässige und resiliente IKT-Systeme, die Identifikation von Assets und Abhängigkeiten, Schutz, Erkennung, IKT-Business-Continuity, Backup, Wiederherstellung, Recovery, Lernen aus Vorfällen, Sensibilisierung, Schulung und Krisenkommunikation. Articles 24 bis 26 verlangen Tests der digitalen operationalen Resilienz für Finanzunternehmen, die keine Kleinstunternehmen sind. Articles 28 bis 30 formalisieren IKT-Drittparteienrisiken, Register für IKT-Serviceverträge, Exit-Strategien, Service Levels, Auditrechte und Anforderungen an Notfallmaßnahmen.

ISO/IEC 27001:2022 bildet das Rückgrat des Managementsystems. Die Klauseln verlangen, dass die Organisation Kontext, interessierte Parteien, gesetzliche und vertragliche Verpflichtungen, Geltungsbereich, Führung, Richtlinie, Rollen, Risikobeurteilung, Risikobehandlung, die Anwendbarkeitserklärung (SoA), operative Planung, Leistungsbewertung und kontinuierliche Verbesserung definiert.

Das fehlende Bindeglied ist häufig die BIA. Ohne sie sind Kontinuitätspläne nicht eindeutig risikobasiert, Backup-Ziele nicht durch den Geschäftsbereich genehmigt, Lieferanten nicht kritischen Services zugeordnet, und das Management kann nicht belastbar nachweisen, dass Resilienzentscheidungen auf geschäftlichen Auswirkungen beruhten.

Die BIA als Steuerungsebene für Resilienznachweise

Eine belastbare BIA beantwortet sieben Fragen, die Auditoren, Aufsichtsbehörden, Kunden und Leitungsorgane zunehmend stellen:

1. Welche Geschäftsservices sind kritisch?
2. Welche IKT-Assets, Datenspeicher, Personen, Lieferanten und Versorgungsleistungen unterstützen jeden Service?
3. Welche operativen, finanziellen, rechtlichen, vertraglichen, kundenbezogenen, sicherheitsbezogenen und reputationsbezogenen Auswirkungen hat eine Störung im Zeitverlauf?
4. Was ist die Maximum Tolerable Downtime, kurz MTD?
5. Was sind das genehmigte Recovery Time Objective, kurz RTO, und das Recovery Point Objective, kurz RPO?
6. Machen Backup-, Redundanz-, Cloud-, Lieferanten-, Personal- und Kommunikationsregelungen diese Ziele erreichbar?
7. Hat die Organisation den Wiederherstellungspfad getestet und die Ergebnisse überprüft?

Clarysecs unternehmensweite Richtlinie für Business Continuity und Disaster Recovery P32 Business Continuity Policy and Disaster Recovery Policy formuliert die Anforderung klar:

Die Business Impact Analysis (BIA) ist mindestens jährlich für alle kritischen Geschäftsbereiche durchzuführen und bei wesentlichen Änderungen an Systemen, Prozessen oder Abhängigkeiten zu überprüfen. BIA-Ergebnisse müssen definieren: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Kritische Abhängigkeiten (Systeme, Lieferanten, Personal)

Diese Klausel gibt Auditoren einen praktischen Ausgangspunkt. Sie verhindert außerdem den häufigen Fehler, dass Business-Continuity-Plan, Disaster-Recovery-Plan, Backup-Zeitplan, Lieferantenregister und Incident-Response-Prozess jeweils eine andere Definition von „kritisch“ verwenden.

Dieselbe Richtlinie verlangt einen integrierten Managementansatz:

Die Organisation muss ein integriertes Business-Continuity-Managementsystem (BCMS) betreiben, das an ISO 22301 und ISO/IEC 27001 ausgerichtet ist und die Integration folgender Elemente sicherstellt: 5.1.1. Business Impact Analysis (BIA) 5.1.2. Risikobewertung der Informationssicherheit für Bedrohungen der Business Continuity 5.1.3. Business-Continuity-Pläne (BCPs) 5.1.4. IKT-Disaster-Recovery-Pläne (DRPs) 5.1.5. Test- und Übungsprogramme 5.1.6. Dokumentation und kontinuierliche Verbesserung

Darin liegt der Unterschied zwischen Checklisten-Compliance und auditfähiger Resilienz. Die BIA ist kein einmaliges Dokument. Sie wird Teil der Nachweiskette von ISMS und BCMS.

Wie ISO/IEC 27001:2022 die BIA in auditfähige Nachweise überführt

ISO/IEC 27001:2022 verlangt nicht, dass jede Organisation den Begriff „Business Impact Analysis“ in jeder Klausel verwendet. Die Anforderungen machen BIA-Nachweise jedoch ausgesprochen wertvoll.

Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen, interessierte Parteien, gesetzliche und regulatorische Verpflichtungen, vertragliche Anforderungen, Schnittstellen, Abhängigkeiten und den ISMS-Geltungsbereich versteht. Eine BIA ist häufig der praktikabelste Nachweis für diese Schnittstellen und Abhängigkeiten. Sie zeigt, welcher Cloud-Service, Zahlungsdienstleister, Identitätsanbieter, Telekommunikationsanbieter, Managed Security Service, welches Rechenzentrum oder welches ausgelagerte Supportteam einen kritischen Service ermöglicht.

Die Klauseln 5.1 bis 5.3 verlangen Führung durch die oberste Leitung, Ressourcenzuweisung, Kommunikation, Rollenzuweisung und Berichterstattung. Eine BIA gibt der Leitung eine geschäftliche Grundlage für Investitionen in Kontinuität. Ohne sie sind RTO- und RPO-Ziele technische Wunschwerte, keine genehmigten Geschäftsanforderungen.

Die Klauseln 6.1.1 bis 6.1.3 verlangen eine wiederholbare Risikobeurteilung und Risikobehandlung der Informationssicherheit. Die Organisation muss Risiken für Vertraulichkeit, Integrität und Verfügbarkeit identifizieren, Auswirkungen und Eintrittswahrscheinlichkeit analysieren, Risikostufen bestimmen, Behandlungen priorisieren, Kontrollen auswählen, ausgewählte Kontrollen mit Annex A vergleichen, eine Anwendbarkeitserklärung (SoA) erstellen, einen Risikobehandlungsplan erstellen und die Genehmigung des Risikoverantwortlichen einholen. Eine BIA stärkt die „Auswirkungsseite“ der Risikobeurteilung. Sie erklärt, warum ein zweistündiger Ausfall eines Systems tolerierbar ist, während ein zweistündiger Ausfall eines anderen Systems Kundenschäden, regulatorische Exponierung, Vertragsverletzungen oder erhebliche Umsatzauswirkungen verursacht.

Annex A stellt den Kontrollkatalog bereit. Für BIA und Kontinuität gehören zu den relevantesten ISO/IEC 27001:2022 Annex A-Kontrollen:

In Zenith Controls: The Cross-Compliance Guide Zenith Controls beschreibt Clarysec die ISO/IEC 27002:2022-Kontrolle 5.30, IKT-Bereitschaft für Business Continuity, als korrektive Kontrolle mit Schwerpunkt Verfügbarkeit, zugeordnet zum Cybersicherheitskonzept Respond, zur operativen Fähigkeit Kontinuität und zur Sicherheitsdomäne Resilienz. Kontrolle 5.29, Informationssicherheit während Störungen, wird als präventiv und korrektiv beschrieben und schützt Vertraulichkeit, Integrität und Verfügbarkeit. Kontrolle 8.13, Informationssicherung, wird als korrektiv beschrieben und unterstützt Integrität und Verfügbarkeit durch Wiederherstellung.

Diese Unterscheidung ist wesentlich. Eine BIA darf nicht nur fragen: „Können wir wiederherstellen?“ Sie muss auch fragen: „Können wir während einer Störung sicher bleiben?“ Während eines Ransomware-Ereignisses, eines Cloud-Ausfalls, eines Lieferantenausfalls oder eines Rechenzentrumsvorfalls benötigt die Organisation weiterhin Zugriffskontrolle, Protokollierung, Überwachung, Nachweissicherung, sichere Kommunikation und Datenschutzmaßnahmen.

Das praktische BIA-Nachweismodell

Eine starke BIA verbindet Geschäftssprache mit technischem Nachweis. Clarysec strukturiert das Nachweismodell typischerweise in fünf Ebenen.

Dieses Nachweismodell funktioniert, weil es der Denkweise von Auditoren folgt. Zuerst fragen sie, was kritisch ist. Dann fragen sie, was es unterstützt. Dann fragen sie, wer das Wiederherstellungsziel genehmigt hat. Anschließend fragen sie, ob technische und lieferantenbezogene Regelungen das Ziel erreichen können. Schließlich fragen sie, ob die Organisation die Fähigkeit getestet und verbessert hat.

NIST CSF 2.0 ist als Kommunikationsebene nützlich. Die Methode der CSF Profiles fordert Organisationen dazu auf, den Geltungsbereich zu definieren, Inputs wie Richtlinien, Unternehmensrisikoprioritäten, BIA-Register, Cybersicherheitsanforderungen, Standards, Verfahren, Sicherheitsmaßnahmen und Arbeitsrollen zu erfassen, aktuelle und Zielprofile zu erstellen, Lücken zu analysieren, einen priorisierten Maßnahmenplan zu erstellen, diesen Plan umzusetzen und das Profil zu aktualisieren. Genau so sollte eine BIA in eine Roadmap für mehrere Compliance-Anforderungen einfließen.

Eine einwöchige BIA-Übung, die echte Nachweise schafft

Angenommen, ein SaaS-Anbieter unterstützt Kunden aus der Finanzdienstleistungsbranche. Seine Plattform unterstützt Kunden-Onboarding, Dokumentenprüfung und Kundenbenachrichtigungen. Er ist selbst keine Bank, aber seine Kunden senden DORA-getriebene vertragliche Anfragen und NIS2-Lieferantenfragebögen.

Eine fokussierte einwöchige Übung kann schnell verwertbare Nachweise schaffen.

Tag 1: Kritische Services und Auswirkungsfenster identifizieren

Beginnen Sie mit Services, nicht mit Servern. Binden Sie Geschäftsverantwortliche, IT, Sicherheit, Recht, Support, Datenschutz und Lieferantenmanagement ein.

Diese Rahmung ist wichtig. Aufsichtsbehörden und Kunden erkennen Services und Funktionen. Anwendungen sind relevant, weil sie diese Services unterstützen.

Tag 2: Abhängigkeiten kartieren

Kartieren Sie für jeden Service Anwendungen, Datenbanken, Infrastruktur, Cloud-Services, Identitätsanbieter, Überwachung, Backup-Werkzeuge, Personen, Lieferanten und unterstützende Versorgungsleistungen.

Hier beginnt die BIA, Wert zu schaffen. Sie zeigt den unsichtbaren Wiederherstellungspfad, einschließlich der Abhängigkeiten, die in einem technischen DR-Plan häufig fehlen.

Tag 3: MTD, RTO und RPO genehmigen

Der Geschäftsverantwortliche schlägt die MTD vor. IT und Sicherheit validieren, ob die vorgeschlagenen RTO- und RPO-Werte technisch erreichbar sind. Das Management genehmigt die endgültigen Ziele.

Für kleinere Organisationen bietet Clarysecs Richtlinie für Business Continuity und Disaster Recovery - SME P32S Business Continuity Policy and Disaster Recovery Policy - SME dieselbe Disziplin in einfacherer Sprache. Sie verlangt BCP/DR-Pläne, die den Ansatz zur Wiederherstellung wesentlicher Funktionen darlegen:

Der General Manager (GM) muss Business-Continuity- und Disaster-Recovery-Pläne (BCP/DRP) genehmigen und pflegen, die den Ansatz der Organisation zur Wiederherstellung wesentlicher Funktionen klar festlegen.

Außerdem muss der Plan enthalten:

priorisierte Services und Systeme (kritische Geschäftsfunktionen)

Und:

Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) für jedes System

Entscheidend ist nicht übermäßige Dokumentation. Entscheidend sind Nachvollziehbarkeit, Genehmigung und der Nachweis, dass Wiederherstellungsziele auf tatsächlichen geschäftlichen Auswirkungen beruhen.

Tag 4: Backup mit geschäftlichen Auswirkungen abgleichen

Viele Organisationen scheitern an dieser Stelle. Die BIA kann ein RPO von vier Stunden festlegen, während Backups nur alle 24 Stunden laufen. Oder das Backup-Werkzeug schützt Produktivdatenbanken, aber nicht Konfigurationen, Geheimnisse, Infrastructure-as-Code-Repositories, Objektspeicher, DNS-Einträge, Identitätseinstellungen oder API-Gateway-Konfigurationen.

Clarysecs Richtlinie für Backup und Wiederherstellung P15 Backup and Restore Policy verlangt einen Master Backup Schedule, der an BIA-Ergebnisse gekoppelt ist:

Ein Master Backup Schedule ist zu pflegen und jährlich zu überprüfen. Er muss Folgendes festlegen: 5.1.1 Backup-Häufigkeit (zum Beispiel tägliche inkrementelle Backups und wöchentliche vollständige Backups) 5.1.2 Aufbewahrungsfristen nach System oder Datentyp 5.1.3 Verschlüsselungsanforderungen und Angaben zum Speicherort 5.1.4 RTO/RPO-Ziele, die mit den Ergebnissen der Bewertung geschäftlicher Auswirkungen verknüpft sind

Diese Klausel ist für Audits besonders wertvoll. Sie zwingt das Backup-Design dazu, geschäftliche Auswirkungen widerzuspiegeln, nicht Speicherbequemlichkeit.

Tag 5: Einen Wiederherstellungspfad testen und Korrekturmaßnahmen eröffnen

Testen Sie nicht alles auf einmal. Wählen Sie einen kritischen Service und führen Sie einen fokussierten Wiederherstellungstest durch. Stellen Sie die Datenbank wieder her. Bauen Sie die Anwendungskonfiguration neu auf. Validieren Sie die Authentifizierung. Bestätigen Sie, dass Protokolle verfügbar sind. Prüfen Sie die Fähigkeit zur Kundenbenachrichtigung. Erfassen Sie benötigte Zeit, Datenverlust, Mängel, Entscheidungen und Korrekturmaßnahmen.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt die Phase „Controls in Action“, Schritt 23, organisatorische Kontrollen einschließlich der IKT-Bereitschaft für Business Continuity. Sie stellt die Frage, die jedes Auditteam stellen sollte:

Können Ihre Systeme Ihre Business-Continuity-Ziele unterstützen, wenn das Licht flackert, Netzwerke ausfallen oder eine Katastrophe eintritt?

Derselbe Schritt gibt eine praktische Anweisung:

Verifizieren Sie, dass Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) für kritische Systeme mit den Business-Continuity-Erwartungen übereinstimmen (5.30). Führen Sie mindestens einen technischen Wiederherstellungstest oder eine Failover-Simulation durch und dokumentieren Sie die Ergebnisse.

Das ist der Unterschied zwischen einer vorhandenen BIA und belastbaren BIA-Nachweisen. Das Ziel ist nicht nur dokumentiert. Es ist getestet.

Zuordnung von BIA-Nachweisen zu NIS2, DORA, GDPR, NIST und COBIT 2019

Eine gut aufgebaute BIA wird zu einem Asset für mehrere Compliance-Anforderungen. Ein Nachweissatz kann viele Fragen beantworten.

GDPR wird in BIA-Diskussionen häufig übersehen. GDPR Article 5 verlangt jedoch, dass personenbezogene Daten mit Integrität und Vertraulichkeit verarbeitet werden, einschließlich Schutz vor unbeabsichtigtem Verlust, unbeabsichtigter Zerstörung oder unbeabsichtigter Schädigung durch geeignete technische oder organisatorische Maßnahmen. Rechenschaftspflicht verlangt, dass der Verantwortliche die Einhaltung nachweisen kann. Wenn eine Plattform mit personenbezogenen Daten nicht innerhalb eines genehmigten und getesteten Zeitrahmens wiederhergestellt werden kann, betrifft das Datenschutzrisiko Verfügbarkeit, Integrität, Bewertung von Verstößen und Kundenvertrauen.

Die NIS2-Vorfallmeldung ergänzt eine weitere Dimension. Article 23 verlangt, dass erhebliche Vorfälle unverzüglich gemeldet werden, einschließlich einer Frühwarnung innerhalb von 24 Stunden, einer Vorfallmeldung innerhalb von 72 Stunden und eines Abschlussberichts innerhalb eines Monats. Eine BIA hilft bei der Schweregradklassifizierung, weil sie betroffene Services, Empfänger der Dienste, operative Störungen und potenzielle grenzüberschreitende Auswirkungen definiert.

Auch die DORA-Vorfallklassifizierung berücksichtigt betroffene Kunden oder Transaktionen, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität der betroffenen Services und wirtschaftliche Auswirkungen. Das sind BIA-Felder. Wenn die BIA schwach ist, wird die Vorfallklassifizierung genau im schlechtesten Moment subjektiv.

Lieferantenkontinuität ist der Punkt, an dem die BIA auf Vertragsrealität trifft

Für NIS2 und DORA ist Lieferantenkontinuität nicht mehr optional. NIS2 Article 21 umfasst Sicherheit der Lieferkette und verlangt Aufmerksamkeit für Lieferantenschwachstellen, Produktqualität und Resilienz, Cybersicherheitspraktiken von Lieferanten und sichere Entwicklungsverfahren. DORA verlangt, dass IKT-Drittparteienrisiken innerhalb des IKT-Risikomanagementrahmens gesteuert werden, einschließlich Registern für IKT-Serviceverträge, Due Diligence, Konzentrationsrisiko, Exit-Strategien, Audit- und Zugriffsrechten, Unterstützung bei Vorfällen, Service Levels und Anforderungen an Notfallmaßnahmen.

Die unternehmensweite Richtlinie für Business Continuity und Disaster Recovery verlangt:

Abhängigkeiten von Drittparteien und Lieferketten 6.5.1. Verträge mit kritischen Lieferanten müssen Kontinuitätsverpflichtungen und Zusagen zu Wiederherstellungszeiten enthalten. 6.5.2. Wesentliche Serviceanbieter müssen auf Anfrage regelmäßige Kontinuitätstests und die Teilnahme an Incident-Response-Übungen nachweisen.

Die SME-Version verlangt außerdem:

Kontaktstellen für Lieferantenkontinuität

Dieses kleine Feld kann in einem echten Vorfall entscheidend sein. Wenn Ihr Wiederherstellungsplan „Cloud-Provider-Support kontaktieren“ sagt, aber niemand Eskalationsweg, Vertragsreferenz, Schweregradprozess oder Kontakt außerhalb der Geschäftszeiten kennt, ist das RTO Fiktion.

Diese Tabelle ersetzt kein Lieferantenrisikomanagement. Sie macht Lieferantenrisiken operativ.

Wie Auditoren Ihre BIA prüfen werden

Ein ISO/IEC 27001:2022-Auditor beginnt üblicherweise mit Geltungsbereich, Kontext, Risikobeurteilung, Risikobehandlung, Anwendbarkeitserklärung (SoA), Annex A-Kontrollen, dokumentierter Information, operativer Planung, Leistungsbewertung und Verbesserung. Er wird die BIA mit der Risikobeurteilung und der SoA vergleichen. Wenn A.5.30, A.5.29 oder A.8.13 einbezogen sind, wird er Nachweise zur Umsetzung und zu Tests anfordern.

Ein DORA-Prüfer wird sich auf kritische oder wichtige Funktionen, IKT-Assets, IKT-Drittparteienabhängigkeiten, Resilienztests, Vorfallklassifizierung, vertragliche Anforderungen, Exit-Strategien und Aufsicht durch das Leitungsorgan konzentrieren. Er wird erwarten, dass die BIA mit dem IKT-Risikomanagementrahmen, der Strategie für digitale operationale Resilienz, den IKT-Business-Continuity-Plänen, den Response- und Recovery-Plänen sowie dem Testprogramm übereinstimmt.

Eine NIS2-Aufsicht wird nach Maßnahmen zu Business Continuity, Backup-Management, Disaster Recovery, Krisenmanagement, Sicherheit der Lieferkette, Governance-Genehmigung und der Fähigkeit zur Meldung erheblicher Vorfälle fragen. Die BIA muss nachweisen, dass diese Maßnahmen auf Serviceauswirkungen und genehmigten Prioritäten beruhen.

Ein NIST CSF 2.0-Assessor wird fragen, wie die BIA das Current Profile, Target Profile, die Lückenanalyse und den Maßnahmenplan informiert. Er wird Govern-Ergebnisse zu gesetzlichen, regulatorischen, vertraglichen, risiko-, rollen-, richtlinien-, aufsichts- und lieferantenrisikobezogenen Entscheidungen betrachten. Außerdem wird er Identify-, Protect-, Detect-, Respond- und Recover-Ergebnisse prüfen.

Ein COBIT 2019- oder ISACA-orientierter Auditor konzentriert sich üblicherweise auf Governance. Wer ist Serviceverantwortlicher? Wer hat das Risiko akzeptiert? Sind Ziele an Unternehmenszielen ausgerichtet? Werden Lieferanten überwacht? Sind Nutzen, Risiken und Ressourcen ausgewogen? Werden Korrekturmaßnahmen bis zum Abschluss verfolgt?

Clarysecs Richtlinie zur Audit- und Compliance-Überwachung Audit and Compliance Monitoring Policy macht die BIA zum Bestandteil des Auditplanungszyklus:

Ein risikobasierter Auditplan ist jährlich zu entwickeln und zu genehmigen; dabei sind zu berücksichtigen: 5.2.1 Die Ergebnisse der jüngsten Risikobeurteilungen und der Business Impact Analysis (BIA) 5.2.2 Frühere Audit-Feststellungen und Status der Korrekturmaßnahmen 5.2.3 Änderungen an Prozessen, IT-Infrastruktur, Systemen oder Lieferanten 5.2.4 Externe Verpflichtungen wie DORA Article 25 oder Kundenverträge

Dies ist ein Reifeschritt, den viele Organisationen verpassen. Die BIA sollte nicht außerhalb der Assurance stehen. Sie sollte den Auditplan steuern.

Häufige BIA-Schwächen aus realen Bewertungen

Dieselben Schwächen treten immer wieder auf.

Erstens listet die BIA Anwendungen statt Services auf. Kunden und Aufsichtsbehörden interessieren sich für Serviceunterbrechungen. Anwendungen sind relevant, weil sie diese Services unterstützen.

Zweitens werden RTO- und RPO-Ziele aus Vorlagen kopiert. Ein RTO von vier Stunden kann plausibel wirken, bis ein Wiederherstellungstest zeigt, dass es neun Stunden dauert, die Identitätsintegration neu aufzubauen, Konfigurationen wiederherzustellen, Daten wiederherzustellen, Integrität zu validieren und die Überwachung wieder zu aktivieren.

Drittens sind Backups nicht mit geschäftlichen Auswirkungen verknüpft. Häufigkeit, Aufbewahrung, Verschlüsselung, Speicherort, Wiederherstellungspriorität und Tests müssen genehmigte Wiederherstellungsziele widerspiegeln.

Viertens werden Lieferanten als Fragebogenpositionen behandelt, nicht als Wiederherstellungsabhängigkeiten. Zusagen zur Lieferantenkontinuität, Eskalationskontakte, Wiederherstellungsnachweise und Teilnahme an Vorfallübungen müssen an kritische Services gekoppelt sein.

Fünftens fehlt die Managementfreigabe. Unter NIS2 und DORA ist die Rechenschaftspflicht des Managements ausdrücklich. Unter ISO/IEC 27001:2022 sind Führung, Rollen, Genehmigung durch Risikoverantwortliche und Leistungsberichterstattung Kernanforderungen.

Sechstens ist das Testen zu eng gefasst. Die Wiederherstellung einer einzelnen Datei ist nützlich, belegt aber keine Servicewiederherstellung. Ein Wiederherstellungspfad für einen kritischen Service kann DNS, Identität, Geheimnisse, Infrastructure-as-Code, API-Gateways, Überwachung, Protokollierung, Lieferanteneskalation, Kundenkommunikation und Datenschutzprüfung umfassen.

Der Zenith Blueprint fasst in der Phase „Controls in Action“, Schritt 19, die Audit-Erwartung an Backups zusammen:

Testen Sie Ihre Backups?

Die Antwort muss „ja, mit Nachweisen“ lauten, und diese Nachweise müssen zur BIA zurückverfolgt werden können.

Das auditbereite BIA-Nachweispaket

Ein praktikables BIA-Programm sollte ein kompaktes Nachweispaket erzeugen, das für Audits, Kunden-Due-Diligence, Berichterstattung an das Leitungsorgan und Resilienzverbesserung genutzt werden kann.

Dieses Paket erzählt eine konsistente Geschichte. Es macht Resilienz außerdem messbar.

Nächster Schritt: Ihre BIA in Compliance-Nachweise überführen

Maria braucht keine größere Tabelle. Sie braucht eine lebendige Nachweiskette.

Beginnen Sie mit einem kritischen Service. Kartieren Sie seine IKT-Assets, Daten, Personen, Lieferanten und Versorgungsleistungen. Genehmigen Sie MTD, RTO und RPO. Stimmen Sie den Backup-Zeitplan ab. Prüfen Sie die Wiederherstellungszusagen von Lieferanten. Führen Sie einen Wiederherstellungstest durch. Erfassen Sie Lücken. Aktualisieren Sie den Risikobehandlungsplan. Präsentieren Sie das Ergebnis dem Management.

Dann wiederholen Sie den Prozess.

Clarysec kann diesen Prozess mit der Richtlinie für Business Continuity und Disaster Recovery, der Richtlinie für Business Continuity und Disaster Recovery - SME, der Richtlinie für Backup und Wiederherstellung, der Richtlinie zur Audit- und Compliance-Überwachung, dem Zenith Blueprint und den Zenith Controls beschleunigen.

Ihre BIA sollte keine für ein Audit erstellte Ablageware sein. Sie sollte der operative Nachweis sein, dass Ihre wichtigsten Services Störungen überstehen, Kunden- und regulatorische Erwartungen erfüllen und innerhalb der Grenzen wiederhergestellt werden können, die Ihre Führung tatsächlich genehmigt hat.

Wenn Ihre Organisation sich auf ISO/IEC 27001:2022-Überwachung, NIS2 Customer Assurance, DORA-IKT-Drittparteienprüfungen oder Resilienzberichte auf Ebene des Leitungsorgans vorbereitet, beginnen Sie damit, die BIA belastbar zu machen. Laden Sie die Clarysec-Kontinuitäts- und Audit-Richtlinien herunter, prüfen Sie die Zenith-Implementierungsroadmap oder fordern Sie eine Bewertung Ihrer Resilienznachweise an, um verstreute Kontrollen in eine auditfähige Darstellung zu überführen.