DORA-IKT-Risikobereitschaft: Leitfaden zur Genehmigung durch das Leitungsorgan für 2026

Es ist 08:15 Uhr an einem Dienstag, und der CISO eines mittelgroßen Zahlungstechnologieunternehmens steht vor dem Sitzungsraum des Leitungsorgans. Auf seinem Tablet sind drei Dokumente geöffnet.

Das erste ist das IKT-Risikoregister. Es enthält 137 Zeilen, farbcodierte Bewertungen und mehrere hohe Risiken im Zusammenhang mit Cloud-Konzentration, Privileged Access Management, Ransomware-Wiederherstellung, Exponierung von Kundendaten und Incident-Response bei Lieferanten. Das zweite ist der DORA-Readiness-Tracker. Er zeigt, dass das Unternehmen Richtlinien, Verfahren für das Management von Informationssicherheitsvorfällen, Drittparteienregister und Pläne für Resilienztests besitzt. Das dritte sind die Sitzungsunterlagen für einen Termin mit der Aufsicht.

Die Vorsitzende hat eine Frage, und sie ist nicht technischer Natur:

„Welches Ausmaß an IKT-Risiko haben wir tatsächlich akzeptiert?“

Im Raum wird es still, denn das Unternehmen hat Risikobeurteilungen, aber keine durch das Leitungsorgan genehmigte IKT-Risikobereitschaft. Es hat Auswirkungsbewertungen, aber keine messbaren Toleranzschwellen. Es hat Eskalationsrunden, aber keinen formalen Auslöser, der festlegt, wann ein Cyberrisiko dem Leitungsorgan zur Entscheidung vorgelegt werden muss. Es hat akzeptierte Restrisiken, aber einige davon werden als „Geschäftsentscheidungen“ begründet, ohne klaren Bezug zu Risikokriterien, zur Verhältnismäßigkeit nach GDPR Article 32, zu den DORA-Erwartungen an Toleranzen oder zur Management-Rechenschaftspflicht nach NIS2.

Diese Lücke wird 2026 immer sichtbarer. DORA gilt seit dem 17. Januar 2025 und verlangt von Finanzunternehmen die Aufrechterhaltung eines Governance- und Kontrollrahmens für IKT-Risiken, einschließlich der Verantwortung des Leitungsorgans für das Rahmenwerk für das IKT-Risikomanagement, die Strategie zur digitalen operationalen Resilienz und die IKT-Risikotoleranz. NIS2 verpflichtet Leitungsorgane dazu, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen und deren Umsetzung zu überwachen. GDPR Article 32 verlangt angemessene technische und organisatorische Sicherheitsmaßnahmen auf Risikobasis. ISO/IEC 27001:2022 liefert die Mechanik des Managementsystems: Kontext, interessierte Parteien, Risikokriterien, Behandlungspläne, dokumentierte Information und Managementbewertung.

Die fehlende Brücke ist eine Erklärung zur IKT-Risikobereitschaft und Risikotoleranz, die ein Leitungsorgan verstehen, genehmigen, hinterfragen und anwenden kann.

Dieser Leitfaden erläutert, wie diese Brücke mit Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, Clarysecs Risk Management Policy, Clarysecs Risk Management Policy-sme und Zenith Controls: Der Cross-Compliance-Leitfaden aufgebaut wird.

Warum Risikoregister keine Risikobereitschaft sind

Viele Organisationen verwechseln ein Risikoregister mit Risiko-Governance. Ein Risikoregister zeigt, welche Risiken bestehen, wie sie bewertet sind, wem sie zugeordnet sind und welche Behandlung geplant ist. Es beantwortet jedoch nicht automatisch die Fragen auf Ebene des Leitungsorgans, die DORA, NIS2, GDPR und ISO/IEC 27001:2022 von Führungskräften erwarten.

Eine ausgereifte Erklärung zur IKT-Risikobereitschaft beantwortet Fragen wie:

• Welche IKT-Risiken sind unabhängig von den Kosten inakzeptabel?
• Welche betriebliche Ausfallzeit kann das Unternehmen für eine kritische oder wichtige Funktion tolerieren?
• Welches Ausmaß an Datenverlust oder Beeinträchtigung der Datenintegrität liegt außerhalb der Risikobereitschaft?
• Welches Konzentrationsrisiko bei Drittparteien erfordert die Befassung des Leitungsorgans?
• Wer darf Restrisiken im IKT-Bereich akzeptieren, und bis zu welcher Höhe?
• Wann muss ein Risiko an das obere Management oder das Leitungsorgan eskaliert werden?
• Wie werden gesetzliche, regulatorische und vertragliche Anforderungen in Risikokriterien verankert?

Unter DORA ist dies keine optionale Veredelung der Governance. Article 5 verlangt, dass das Leitungsorgan das Rahmenwerk für das IKT-Risikomanagement definiert, genehmigt, überwacht und dafür verantwortlich ist, einschließlich der Strategie zur digitalen operationalen Resilienz und der IKT-Risikotoleranz. Article 6 verlangt ein dokumentiertes Rahmenwerk für das IKT-Risikomanagement, eine jährliche Überprüfung für Nicht-Kleinstunternehmen, interne Revision, Behebung kritischer Audit-Feststellungen und eine Strategie zur digitalen operationalen Resilienz mit IKT-Zielen, Risikotoleranz, Auswirkungstoleranz, Architektur, Tests und Strategie zur Vorfallkommunikation.

NIS2 ergänzt ein paralleles Modell der Rechenschaftspflicht. Article 20 verlangt von den Leitungsorganen wesentlicher und wichtiger Einrichtungen, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen, die Umsetzung zu überwachen und Schulungen zu erhalten. Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen auf Basis eines All-Gefahren-Ansatzes, einschließlich Risikoanalyse, Verfahren für das Management von Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sicherer Entwicklung, Kontrollwirksamkeit, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und MFA, soweit angemessen.

Für Finanzunternehmen gilt DORA als sektorspezifischer Rechtsakt der Union, soweit überschneidende NIS2-Verpflichtungen bestehen. In der Praxis verdrängt DORA für Finanzunternehmen in ihrem Geltungsbereich im Allgemeinen überschneidende NIS2-Anforderungen an Risikomanagement und Vorfallmeldung, während NIS2 für die Koordination und für Anbieter außerhalb der unmittelbaren DORA-Verpflichtungen für Finanzunternehmen weiterhin wichtig bleibt. Für SaaS-, Cloud-, Managed-Service- und Managed-Security-Anbieter kann NIS2 unmittelbar gelten, wenn die Voraussetzungen des Geltungsbereichs erfüllt sind.

Deshalb ist eine durch das Leitungsorgan genehmigte IKT-Risikobereitschaft kein Artefakt des Finanzrisikomanagements mehr. Sie ist eine Governance-Kontrolle für Cybersicherheit.

ISO/IEC 27001:2022 als Betriebssystem nutzen

DORA und NIS2 geben Führungskräften vor, was gesteuert werden muss. ISO/IEC 27001:2022 gibt Organisationen ein praktisches Betriebssystem dafür, wie diese Steuerung erfolgen kann.

ISO/IEC 27001:2022 Klauseln 4.1 bis 4.4 verlangen, dass die Organisation Kontext, interessierte Parteien, Anforderungen, ISMS-Geltungsbereich und ISMS-Prozesse definiert. Das ist relevant, weil DORA, NIS2, GDPR, Verträge, Erwartungen der Aufsicht, Kunden, Cloud-Anbieter und Auslagerungsvereinbarungen sämtlich zu Anforderungen werden, die Risikokriterien beeinflussen.

Klauseln 5.1 bis 5.3 verlangen Führungsverpflichtung, Ausrichtung der Richtlinien, Ressourcen, Verantwortlichkeiten und Berichterstattung zur ISMS-Leistung an die oberste Leitung. Klauseln 6.1.1 bis 6.1.3 verlangen risikobasierte Planung, einen dokumentierten Prozess zur Risikobeurteilung, Kriterien für die Risikoakzeptanz, konsistente Bewertungskriterien, Risikoverantwortliche, Abgleich mit Risikokriterien, Behandlungsplanung, eine Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) und die Genehmigung von Restrisiken.

Dies ist die Grundlage für die DORA-IKT-Risikotoleranz.

In der Phase Risikomanagement weist Schritt 10 des Zenith Blueprint Organisationen an, Risikokriterien vor der Bewertung von Risiken festzulegen:

„Risikokriterien sind die Regeln und Referenzwerte, die Ihre Organisation verwendet, um die Bedeutung jedes Risikos zu bewerten. Die frühzeitige Festlegung dieser Kriterien stellt sicher, dass alle dieselbe Risikosprache sprechen.“

Derselbe Schritt weist darauf hin, dass regulatorische Auswirkungen in Risikodefinitionen eingebaut werden müssen:

„Jedes Risiko, das zu einer Nichteinhaltung anwendbarer Gesetze (GDPR usw.) führen könnte, ist nicht akzeptabel und muss gemindert werden.“

Der Zenith Blueprint gibt außerdem praktische Hinweise zur Skalierung von Auswirkungen:

„Bei der Definition von Auswirkungen ist es sinnvoll, die Stufen auf Ihre konkrete Unternehmensgröße zu beziehen. Beispiel: ‚Erhebliche finanzielle Auswirkung = Verlust > 100.000 USD‘ (an Ihren Kontext anpassen). Berücksichtigen Sie auch regulatorische Auswirkungen: Eine Datenschutzverletzung personenbezogener Daten könnte beispielsweise aufgrund von GDPR-Bußgeldern und Meldepflichten automatisch als ‚Major‘ oder ‚Severe‘ einzustufen sein, selbst wenn der direkte finanzielle Verlust unklar ist. Ebenso kann ein Vorfall mit Serviceunterbrechung, wenn Sie in den Geltungsbereich von NIS2 fallen (wesentliche Dienste), aufgrund rechtlicher Implikationen mindestens ‚Major‘ sein. Nehmen Sie solche Erwägungen in Ihre Definitionen auf.“

Diese Anleitung verhindert ein häufiges Versagen: Ein Cyberrisiko wird als moderat bewertet, weil der unmittelbare finanzielle Verlust gering erscheint, während gesetzliche Auswirkungen, Auswirkungen auf die operationale Resilienz, Auswirkungen auf betroffene Personen oder Kundenauswirkungen ignoriert werden.

Ein für das Leitungsorgan geeignetes Modell sollte vier Ebenen trennen:

Diese Struktur macht Risikobereitschaft auditierbar, weil jede Aussage auf Risikokriterien, Kontrollen, Nachweise und Entscheidungen zurückgeführt werden kann.

Eine für das Leitungsorgan geeignete DORA-Erklärung zur IKT-Risikobereitschaft

Eine belastbare Erklärung zur IKT-Risikobereitschaft ist kurz genug, damit das Leitungsorgan sie genehmigen kann, konkret genug, damit das Management sie anwenden kann, und messbar genug, damit Auditoren sie prüfen können. Sie sollte Fachjargon vermeiden, darf aber nicht vage sein.

Eine praktische übergeordnete Aussage könnte lauten:

„Unser Unternehmen hat eine geringe Bereitschaft zur Übernahme von IKT-Risiken, die zu wesentlichen Schäden für Kunden, zur Störung kritischer oder wichtiger Funktionen, zur unbefugten Offenlegung oder Veränderung regulierter Daten, zur Nichterfüllung gesetzlicher Verpflichtungen oder zum Verlust der Resilienz kritischer IKT-Drittdienstleistungen führen könnten.“

Diese Aussage benötigt anschließend messbare Toleranzschwellen und Eskalationsauslöser.

Diese Tabelle verändert die Diskussion. Das Leitungsorgan genehmigt keinen Slogan mehr. Es genehmigt operative Grenzen für Verfügbarkeit, Vertraulichkeit, Integrität, Lieferanten, Schwachstellen, Wiederherstellung und Compliance.

Clarysecs Risk Management Policy unterstützt dieses Governance-Modell. Die Unternehmensrichtlinie legt fest:

„Genehmigt das Risikomanagementrahmenwerk und definiert akzeptable Risikobereitschaft und Toleranzschwellen.“

Klausel 6.2.1 macht die Messanforderung ausdrücklich:

„Risiken sind anhand einer standardisierten Risikomatrix mit klar definierten Bewertungsskalen für Eintrittswahrscheinlichkeit und Auswirkung zu bewerten.“

Klausel 6.3.4 schafft die Akzeptanzregel, die Auditoren erwarten:

„Risiken, die ohne Behandlung akzeptiert werden, sind schriftlich zu begründen, mit der Risikobereitschaft der Organisation zu verknüpfen und auf der geeigneten Ebene zu genehmigen.“

Für SMEs hält die Risk Management Policy-sme dasselbe Governance-Prinzip in schlankerer Form fest:

„Sicherstellen, dass das Management an der Genehmigung der Risikotoleranz und wesentlicher Risikobehandlungspläne beteiligt ist.“

Sie verlangt außerdem die Eskalation hoher Risiken:

„Hohe Risiken müssen zur Entscheidung an den General Manager (GM) eskaliert werden.“

Das ist Verhältnismäßigkeit in der Praxis. DORA Article 4 verlangt, dass Anforderungen verhältnismäßig zu Größe, Risikoprofil sowie Art, Umfang und Komplexität der Services angewendet werden. ISO/IEC 27001:2022 ermöglicht dasselbe Prinzip über Geltungsbereich, Kontext, Risikokriterien und Behandlungsentscheidungen. Der Governance-Standard besteht nicht darin, dass jede Organisation dieselbe Ausschussstruktur benötigt. Der Governance-Standard besteht darin, dass Risikobereitschaft, Toleranz, Eskalation und Akzeptanz definiert, genehmigt, nachgewiesen und angewendet werden.

GDPR Article 32 verändert die Risikodiskussion

GDPR Article 32 wird häufig als technische Sicherheitsklausel behandelt. Aus Governance-Sicht ist er auch eine Klausel zur Risikobereitschaft.

Article 32 verlangt von Verantwortlichen und Auftragsverarbeitern die Umsetzung geeigneter technischer und organisatorischer Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Dieser risikobasierte Ansatz berücksichtigt den Stand der Technik, die Implementierungskosten, Art, Umfang, Umstände und Zwecke der Verarbeitung sowie Risiken für die Rechte und Freiheiten natürlicher Personen.

Dies wirkt sich in drei Punkten auf die IKT-Risikobereitschaft aus.

Erstens kann die Auswirkung auf personenbezogene Daten nicht auf finanziellen Verlust reduziert werden. Die Exponierung einer kleinen Datenbank kann begrenzte unmittelbare Kosten verursachen, aber schwerwiegende Folgen für Vertraulichkeit, Identität, Betrug, Diskriminierung oder Rechte betroffener Personen haben. Wenn besondere Kategorien personenbezogener Daten betroffen sind, etwa Gesundheits-, biometrische oder genetische Daten, sollte die Risikobereitschaft wesentlich niedriger sein.

Zweitens müssen Rollen in der Verarbeitung mit Risikoverantwortung verknüpft werden. GDPR unterscheidet Verantwortliche und Auftragsverarbeiter. DORA unterscheidet Finanzunternehmen und IKT-Drittdienstleister. NIS2 unterscheidet wesentliche und wichtige Einrichtungen. ISO/IEC 27001:2022 verlangt Risikoverantwortliche. Eine ausgereifte Erklärung zur Risikobereitschaft sollte festlegen, wer Risikoentscheidungen mit Bezug zu personenbezogenen Daten, ausgelagerter Verarbeitung, kritischen Services und grenzüberschreitenden Abhängigkeiten verantwortet.

Drittens sollte die Verhältnismäßigkeit nach Article 32 in der Kontrollauswahl sichtbar sein. Verschlüsselung, Pseudonymisierung, Zugriffskontrolle, Backup, Protokollierung, Überwachung, Incident-Response und Resilienz sind keine isolierten technischen Aufgaben. Es sind Behandlungsmaßnahmen, die ausgewählt werden, weil ein Risiko die Risikobereitschaft oder Toleranz überschritten hat.

Clarysecs Risk Management Policy stellt diese Verbindung ausdrücklich her:

„Article 32: Schreibt einen risikobasierten Ansatz für Sicherheitsmaßnahmen vor, der durch auswirkungsbasierte Risikobewertungen und Kontrollauswahl erfüllt wird.“

Das ist die operative Verbindung, nach der Auditoren suchen: Anforderung aus Article 32, Risikobeurteilung, Risikobewertung, Behandlungsplan, Kontrollauswahl, Restrisiko und Genehmigung.

Wie Zenith Controls Nachweise für Cross-Compliance unterstützt

Eine durch das Leitungsorgan genehmigte Erklärung zur Risikobereitschaft wird wirksam, wenn sie Kontrollen zugeordnet wird. Zenith Controls dient als Cross-Compliance-Leitfaden von Clarysec und hilft Teams, Nachweise über ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF und COBIT-orientierte Assurance hinweg wiederzuverwenden.

Drei Kontrollbereiche aus ISO/IEC 27002:2022 sind besonders wichtig:

Dies ist keine Papierübung zur Zuordnung. Es verändert, wie Entscheidungen getroffen werden.

Wenn ein Geschäftsinhaber eine verzögerte MFA-Einführung für Administratoren akzeptieren möchte, hilft Zenith Controls dem CISO zu zeigen, warum dies nicht nur eine Frage der Zugriffskontrolle ist. Es berührt Richtlinien-Governance, Managementverantwortung, gesetzliche und regulatorische Anforderungen, Sicherheit der Verarbeitung nach GDPR, DORA-IKT-Risikomanagement, NIS2-Cybersicherheitsmaßnahmen, Vorfallauswirkungen und Auditnachweise.

Wenn ein Produktteam in einem neuen EU-Markt mit einem neuen Cloud-Service starten möchte, rückt ISO/IEC 27002:2022 control 5.31 die Prüfung gesetzlicher und regulatorischer Anforderungen in den ISMS-Geltungsbereich. ISO/IEC 27001:2022 Klausel 4.2 verlangt die Identifikation der Anforderungen interessierter Parteien, einschließlich gesetzlicher, regulatorischer und vertraglicher Verpflichtungen. Klausel 8.1 verlangt operative Planung und Steuerung, einschließlich Steuerung extern bereitgestellter Prozesse, Produkte oder Services, die für das ISMS relevant sind.

Das Ziel ist eine einheitliche Risikosprache, nicht getrennte Compliance-Dialekte.

Genehmigungs-Workflow: Wer entscheidet was

Ein CISO kann die IKT-Risikobereitschaft vorschlagen, aber das Leitungsorgan muss sie verantworten. Diese Verantwortung benötigt einen Workflow.

Dies steht auch im Einklang mit NIST CSF 2.0. Die Funktion GOVERN, insbesondere GV.RM, erwartet vereinbarte Risikomanagementziele, Erklärungen zu Risikobereitschaft und Risikotoleranz, in das unternehmensweite Risikomanagement integrierte Risikotätigkeiten, definierte Optionen zur Risikobehandlung, Kommunikationswege und standardisierte Methoden zur Berechnung, Dokumentation, Kategorisierung und Priorisierung von Cybersicherheitsrisiken. GV.RR erwartet Rechenschaftspflicht der Führung, Rollen, Befugnisse und Ressourcen, die an der Risikostrategie ausgerichtet sind. GV.PO erwartet, dass Richtlinien festgelegt, kommuniziert, durchgesetzt, überprüft und aktualisiert werden.

COBIT 19- und ISACA-orientierte Assurance-Fachleute werden fragen, ob Risikobereitschaft in die Governance von Information und Technologie integriert ist und nicht lediglich als Anhang an eine Cyberrichtlinie angefügt wurde.

Ein IKT-Risikobereitschaftspaket in einer Arbeitssitzung erstellen

Ein praxisnaher Workshop zur IKT-Risikobereitschaft kann eine Organisation von verstreuten Registern zu auditierbaren Unterlagen für das Leitungsorgan führen.

Schritt 1: Die richtigen Eingaben sammeln

Bereiten Sie das aktuelle IKT-Risikoregister, die Business Impact Analysis (BIA), Wiederherstellungsziele, die Liste kritischer oder wichtiger Funktionen, das IKT-Asset-Inventar, das IKT-Serviceinventar, das Register für Lieferanten- und Cloud-Abhängigkeiten, Kriterien zur Vorfallklassifizierung, das GDPR-Verarbeitungsinventar, DPIAs, soweit relevant, das Register rechtlicher Verpflichtungen, Richtlinien, die Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) und die bestehende Erklärung zur unternehmensweiten Risikobereitschaft vor.

Dies entspricht ISO/IEC 27001:2022 Klauseln 4, 6 und 8 sowie NIST CSF-Profilmethoden, die mit Geschäftsprioritäten, Risikoprioritäten, Anforderungen, Schutzmaßnahmen und Rollen beginnen.

Schritt 2: Auswirkungsskalen definieren, die Regulierung einbeziehen

Definieren Sie mit Zenith Blueprint Schritt 10 Eintrittswahrscheinlichkeit und Auswirkung in Geschäftssprache. Beziehen Sie finanziellen Verlust, Betriebsunterbrechung, Kundenauswirkung, Reputationsschaden, gesetzliche und regulatorische Auswirkung, Schaden für betroffene Personen und Auswirkungen auf kritische Funktionen ein.

Beispielsweise kann eine „Major“-Auswirkung einen längeren Ausfall eines kritischen Services, eine bestätigte meldepflichtige Verletzung des Schutzes personenbezogener Daten, die Nichterfüllung einer DORA-Pflicht zur Vorfallmeldung oder einen Lieferantenausfall betreffen, der eine kritische oder wichtige Funktion beeinträchtigt.

Schritt 3: Risikobereitschaft je Domäne formulieren

Erstellen Sie keine generische Cyber-Risikobereitschaft. Definieren Sie Domänen wie Verfügbarkeit kritischer Services, Vertraulichkeit personenbezogener Daten, Datenintegrität, privilegierter Zugriff, IKT-Abhängigkeit von Drittparteien, Cloud-Konzentration, Schwachstellenexposition, Bereitschaft zur Vorfallmeldung, Backup und Wiederherstellung sowie Änderungsrisiko in der sicheren Entwicklung.

Formulieren Sie für jede Domäne eine Aussage zur Risikobereitschaft, eine oder mehrere Toleranzschwellen und Eskalationsauslöser.

Schritt 4: Risikobehandlung mit der Erklärung zur Anwendbarkeit verbinden

Schritt 13 des Zenith Blueprint weist Organisationen an, Optionen zur Risikobehandlung zu wählen: mindern, vermeiden, übertragen oder akzeptieren. Er betont außerdem die Genehmigung durch das Management:

„Risikobehandlungsentscheidungen und die SoA sollten durch die oberste Leitung überprüft und genehmigt werden.“

Für DORA und NIS2 ist dies ein Nachweis dafür, dass das Leitungsorgan oder die delegierte Führung wesentliche Risiken, Behandlungen und akzeptierte verbleibende Expositionen überprüft hat. Für GDPR unterstützt es die Rechenschaftspflicht, indem es zeigt, warum ausgewählte Maßnahmen dem Risiko angemessen waren.

Schritt 5: Akzeptanz mit Ablaufdatum und Bedingungen dokumentieren

Jedes akzeptierte mittlere oder hohe Restrisiko sollte Folgendes enthalten:

• Risiko-Kennung und Verantwortlicher
• Geschäftliche Begründung
• Referenz auf die Aussage zur Risikobereitschaft
• Betroffene Toleranzschwelle
• Gesetzliche und regulatorische Analyse
• Kompensierende Kontrollen
• Ablauf- oder Überprüfungsdatum
• Genehmigende Person
• Speicherort der Nachweise
• Auslöser für die Wiederaufnahme der Entscheidung

Die Risk Management Policy-sme legt fest:

„Jede Entscheidung, die Behandlung eines hohen oder mittleren Risikos zu akzeptieren oder zurückzustellen, muss im Risikoregister dokumentiert werden. Diese Dokumentation muss Folgendes enthalten:“

In Unternehmensumgebungen wird daraus ein Genehmigungs-Workflow und ein Paket für den Risikoausschuss. In kleineren Organisationen kann es ein strukturiertes Registerblatt im Risikoregister mit Managementfreigabe sein. Es geht nicht um Bürokratie. Es geht um Belastbarkeit.

Vorfalltoleranz: Wo Risikobereitschaft auf die Uhr trifft

Risikobereitschaft wird während Vorfällen real.

DORA Article 17 verlangt von Finanzunternehmen, einen Managementprozess für IKT-bezogene Vorfälle einzurichten, um Vorfälle zu erkennen, zu steuern und zu melden, alle Vorfälle und erheblichen Cyberbedrohungen aufzuzeichnen, Ursachen zu identifizieren, Frühwarnindikatoren zu nutzen, Vorfälle nach Priorität, Schweregrad und Servicekritikalität zu klassifizieren, Rollen zuzuweisen, mit Interessenträgern zu kommunizieren, mindestens schwerwiegende IKT-bezogene Vorfälle an das obere Management und das Leitungsorgan zu eskalieren und den sicheren Betrieb zeitnah wiederherzustellen.

DORA Article 18 klassifiziert Vorfälle anhand von Faktoren wie betroffenen Kunden, Dauer, Ausfallzeit, geografischer Ausbreitung, Datenverlusten mit Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit, Kritikalität betroffener Services und wirtschaftlicher Auswirkung. Article 19 verlangt, dass schwerwiegende IKT-bezogene Vorfälle an die zuständige Behörde gemeldet werden; Kunden sind zu informieren, wenn ihre finanziellen Interessen betroffen sind.

NIS2 Article 23 sieht eine gestufte Berichterstattung für erhebliche Vorfälle vor, einschließlich Frühwarnung ohne unangemessene Verzögerung und gegebenenfalls innerhalb von 24 Stunden, Vorfallmeldung ohne unangemessene Verzögerung und gegebenenfalls innerhalb von 72 Stunden, Zwischenmeldungen auf Anforderung sowie eines Abschlussberichts spätestens einen Monat nach der Vorfallmeldung. Erhebliche Vorfälle umfassen solche, die schwerwiegende Betriebsstörungen, finanzielle Verluste oder materielle oder immaterielle Schäden bei anderen verursachen.

Die Erklärung zur Risikobereitschaft sollte Eskalationsschwellen definieren, bevor der Vorfall eintritt.

Annex A-Kontrollen zu Vorfallplanung, Bewertung von Informationssicherheitsereignissen, Incident-Response, Lernen aus Vorfällen, Beweissicherung, Aufrechterhaltung der Informationssicherheit während Störungen und IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs unterstützen diese Schwellen. NIST CSF-Ergebnisse über IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER unterstützen dasselbe Betriebsmodell, einschließlich Backups, Überwachung, Vorfallerklärung, Eskalation, Ursachenanalyse, Kommunikation mit Interessenträgern und Verifikation der Wiederherstellung.

Lieferanten- und Cloud-Toleranzen, die Leitungsorgane oft übersehen

DORA macht IKT-Drittparteienrisiken zu einer zentralen Compliance-Verpflichtung. Article 28 verlangt von Finanzunternehmen, IKT-Drittparteienrisiken als Teil des Rahmenwerks für das IKT-Risikomanagement zu steuern, während sie vollständig für die Einhaltung verantwortlich bleiben. Er verlangt eine Strategie für IKT-Drittparteienrisiken, Register vertraglicher Vereinbarungen über IKT-Services, die Unterscheidung von Services zur Unterstützung kritischer oder wichtiger Funktionen, jährliche Berichterstattung, Benachrichtigung über geplante Vereinbarungen, Vorvertragsprüfungen, gebotene Sorgfalt, Audit- und Inspektionsrechte, Kündigungsrechte und dokumentierte Exit-Strategien.

Article 29 ergänzt die Analyse von Konzentrationsrisiken, einschließlich fehlender Ersetzbarkeit, mehrfacher Abhängigkeiten von denselben oder verbundenen Anbietern, Risiken aus Unterauftragsvergabe, Unterauftragnehmern in Drittländern, Einhaltung des Datenschutzes, Durchsetzbarkeit und komplexen Unterauftragsketten. Article 30 verlangt schriftliche vertragliche Rechte und Pflichten, Servicebeschreibungen, Standorte, Sicherheitsvorkehrungen, Datenzugriff und -rückgabe, Service Levels, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechte, getestete Notfallpläne, Überwachung und Exit-Regelungen.

Eine durch das Leitungsorgan genehmigte Aussage zur Lieferantentoleranz könnte lauten:

„Wir haben eine geringe Bereitschaft, Abhängigkeiten kritischer oder wichtiger Funktionen von einem IKT-Drittdienstleister zu akzeptieren, wenn uns vertragliche Auditrechte, getestete Exit-Regelungen, Pflichten zur Vorfallmeldung, Service-Level-Ziele, Datenrückgaberechte oder Transparenz über wesentliche Unterauftragsvergabe fehlen.“

Dieser Satz gibt der Beschaffung eine praktische Regel. Wenn der Vertrag die Schwelle nicht erfüllt, kann das Risiko nicht stillschweigend durch das Projektteam akzeptiert werden.

Wie Auditoren Ihre IKT-Risikobereitschaft prüfen werden

Eine belastbare Erklärung zur Risikobereitschaft wird mit Blick auf Audits gestaltet.

Schritt 28 des Zenith Blueprint in der Phase Audit, Review and Improvement stärkt die Managementbewertungsebene. Er weist Organisationen an, Eingaben wie Änderungen externer und interner Themen, ISMS-Leistung, Auditergebnisse, Überwachung und Messung, Vorfälle, Nichtkonformitäten, Verbesserungsmöglichkeiten und Ressourcenbedarf zu sammeln. Er stellt außerdem klar, dass die Managementbewertung zu Entscheidungen und Maßnahmen führen muss, nicht lediglich zu Präsentationen.

Mindestens jährlich und bei wesentlichen Änderungen sollte das Management überprüfen, ob Toleranzschwellen weiterhin zum Geschäftsmodell passen, Vorfälle die Risikobereitschaft überschritten haben, akzeptierte Risiken innerhalb genehmigter Grenzen bleiben, neue DORA-, NIS2-, GDPR- oder vertragliche Anforderungen die Baseline verändert haben, Lieferanten innerhalb der Konzentrationstoleranzen bleiben und KRIs rechtzeitig Eskalationen auslösen.

Wenn die Antwort nein lautet, muss die Erklärung zur Risikobereitschaft geändert werden – oder die Kontrollen müssen geändert werden.

Häufige Fehlermuster in der Readiness-Arbeit 2026

In DORA-, NIS2-, GDPR- und ISO/IEC 27001:2022-Projekten treten dieselben Schwächen immer wieder auf:

• Risikobereitschaft ohne Schwellen, bei der das Leitungsorgan eine Aussage genehmigt, aber niemand sagen kann, wann sie verletzt wurde.
• Schwellen ohne Befugnis, bei denen Schweregrade existieren, Risikoverantwortliche aber Ausnahmen ohne Genehmigung des oberen Managements akzeptieren können.
• Rechtliches Risiko außerhalb des Bewertungsmodells, bei dem GDPR, DORA, NIS2 und Verträge getrennt aufgeführt, aber nicht in Auswirkungskriterien eingebettet werden.
• Fehlende Lieferantentoleranz in den Unterlagen des Leitungsorgans, obwohl kritische IKT-Abhängigkeiten der Beschaffung oder IT bekannt sind.
• Managementbewertung als Theater, bei der Folien präsentiert werden, Entscheidungen, Maßnahmen, Ressourcenbedarf und Risikoakzeptanzen aber nicht dokumentiert sind.
• Fragmentierte Auditnachweise, bei denen Richtlinien, Register, KRIs, Vorfallsberichte, Lieferantenüberprüfungen und Sitzungsprotokolle des Leitungsorgans an unterschiedlichen Orten liegen und keine Querverweise bestehen.

Clarysecs Ansatz ist darauf ausgelegt, diese Lücken zu schließen. Der Zenith Blueprint stellt den phasenbasierten Implementierungspfad bereit. Die Risk Management Policy und die Risk Management Policy-sme liefern Governance-Klauseln, skaliert für Unternehmens- und SME-Umgebungen. Zenith Controls ordnet die Kontrollbasis über Informationssicherheitsleitlinie, Managementverantwortung sowie gesetzliche oder regulatorische Anforderungen hinweg zu und macht Nachweise über ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF und COBIT-orientierte Assurance wiederverwendbar.

Absichten des Leitungsorgans in auditierbare IKT-Risiko-Governance überführen

Wenn Ihre Organisation ein Risikoregister besitzt, aber keine durch das Leitungsorgan genehmigte IKT-Risikobereitschaft, keine messbaren Toleranzschwellen, keine Eskalationsauslöser und keine formalen Akzeptanzregeln nachweisen kann, ist die Lücke nicht kosmetisch. Sie betrifft DORA-Governance, NIS2-Management-Rechenschaftspflicht, die Belastbarkeit nach GDPR Article 32 und die Auditbereitschaft nach ISO/IEC 27001:2022.

Ein praktischer nächster Schritt ist die Durchführung eines fokussierten Workshops zur IKT-Risikobereitschaft mit dem Toolkit von Clarysec:

1. Verwenden Sie Zenith Blueprint Schritt 10, um Risikokriterien und Auswirkungsskalen zu definieren.
2. Verwenden Sie Zenith Blueprint Schritt 13, um Behandlungsoptionen, Restrisiko und Genehmigung der Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) zu verknüpfen.
3. Verwenden Sie Zenith Blueprint Schritt 14, um GDPR-, NIS2- und DORA-Verpflichtungen querzuverweisen.
4. Verwenden Sie Zenith Blueprint Schritt 28, um Risikobereitschaft, KRIs, akzeptierte Risiken und Ressourcenentscheidungen in die Managementbewertung einzubringen.
5. Wenden Sie Risk Management Policy oder Risk Management Policy-sme an, um Genehmigungs- und Akzeptanzregeln zu formalisieren.
6. Verwenden Sie Zenith Controls, um Governance-Kontrollen Auditnachweisen und Cross-Compliance-Erwartungen zuzuordnen.

Clarysec kann Ihnen helfen, verstreute Risikoartefakte in ein durch das Leitungsorgan genehmigtes, aufsichtsbereites Modell der IKT-Risikobereitschaft zu überführen, das Ihre Teams nutzen können, wenn der nächste Cloud-Ausfall, Lieferantenausfall, die nächste Offenlegung von Schwachstellen oder der nächste Datenschutzvorfall die tatsächliche Toleranz der Organisation auf die Probe stellt.