Wissensraum · Deep Dive 9 von 22
Board-Governance und regulatorische Verantwortung
Drei Regulierungsregime, ein integrierter Governance-Rahmen — DORA, NIS2, AI Act
DORA Art. 5 · NIS2 Art. 20 · AI Act Art. 26 · Drei Haftungslogiken · Schweizer Dimension (OR Art. 716a) · Governance-Lücken
Was dieser Deep Dive zeigt
Moderne Boards können mehreren Regulierungsregimen zugleich unterliegen. Der Deep Dive zeigt, wie DORA, NIS2 und AI Act unterschiedliche Governance-Anforderungen stellen – und wie ein integrierter Governance-Rahmen Lücken vermeidet. Ob und wie jedes Regime greift, ist für jedes Regime getrennt zu prüfen.
1. Die neue Board-Realität: Mehrschichtige Regulierungsregime
Regulatorische Verantwortung ist nicht mehr ein Einzelthema, sondern ein strategisches Governance-Problem. Der Grund: DORA, NIS2 und AI Act schaffen neue, potenziell überlagernde Haftungslogiken.
Ein Finanzunternehmen mit Cybersecurity-Anforderungen und KI-Einsatz kann — je nach Einordnung — nicht nur einem, sondern mehreren, potenziell überlagernden Verantwortungsregimen unterliegen. Ob alle drei greifen, ist für jedes Regime getrennt zu prüfen (DORA-Finanzentität? Anwendungsbereich von NIS2 bzw. des nationalen Umsetzungsgesetzes? Adressat des AI Act — und überhaupt ein Hochrisiko-System?). Jedes setzt unterschiedliche Prioritäten:
- DORA (Digital Operational Resilience Act): Zentrales ICT-Risiko-Management-Framework, Genehmigung durch das Board, operative Governance
- NIS2 (Network and Information Systems Directive 2): Cybersecurity-Maßnahmen, Training für Verwaltungsräte, explizite Kompetenzanforderungen
- AI Act: Risikobewertung von High-Risk-Systemen, Human Oversight, Monitoring und Incident Reporting
Das Problem: Die meisten Boards verstehen diese Regime nicht als kumulativ. Sie genehmigen ein DORA-Framework, trainieren nicht im NIS2-Kontext und wissen nicht, dass ihre KI-Systeme unter den AI Act fallen können. Das ergibt drei separate Compliance-Fehler aus einer fehlenden strategischen Governance.
2. DORA Art. 5: Finanzsektor, strikte Managementverantwortung
DORA begründet aktive Board-Verantwortung im Finanzsektor. Das ist nicht Compliance, sondern Governance. Das Board muss:
- Das ICT-Risiko-Management-Framework genehmigen
- Risiken verstehen, nicht nur formal akzeptieren
- Kritische Third-Party-Abhängigkeiten bewerten
- Entscheidungen dokumentiert treffen
Das Besondere: DORA verlangt aktive Genehmigung, nicht nur passive Kontrolle. Ein Board, das ein Framework akzeptiert, ohne es zu verstehen, erfüllt die Anforderung nicht.
3. NIS2 Art. 20: Cybersecurity im kritischen Infrastruktur-Kontext
NIS2 erweitert die Haftung auf alle wesentlichen und wichtigen Entitäten – nicht nur Finanzsektor, sondern Energie, Verkehr, Gesundheit und weitere kritische Bereiche. Die Anforderungen sind ähnlich wie DORA, aber mit einem zusätzlichen Element:
Art. 20(2) NIS2: Mitglieder des Leitungsorgans müssen an Schulungen teilnehmen. Soweit das Unternehmen dem nationalen NIS2-Umsetzungsrecht unterliegt, sind die dort vorgesehenen Cybersecurity-Schulungen verpflichtend.
"Verwaltungsräte müssen nach NIS2 das Cybersecurity-Framework genehmigen, dessen Umsetzung überwachen und in der Lage sein, die zugeordneten Risiken und Risikomanagementpraktiken zu beurteilen."
NIS2 gilt sektor- und tätigkeitsbezogen: Sektoren und Einrichtungsarten der Anhänge, Größe, konkrete Tätigkeit, besondere Einstufungen und nationale Umsetzung entscheiden über den Anwendungsbereich. Das schafft ein anderes Governance-Problem als DORA: Viele Unternehmen wissen nicht, dass sie unter NIS2 fallen.
4. AI Act Art. 26: Betreiberpflichten bei High-Risk-Systemen
Der AI Act verschiebt die Verantwortung stärker auf die organisatorische Ebene. Deployer von High-Risk-AI-Systemen müssen sicherstellen, dass:
- wirksame menschliche Aufsicht organisiert ist – kompetente Aufsichtspersonen, Interventions- und Stopprechte (nicht bloß „nicht automatisiert")
- der Betrieb entsprechend Gebrauchsanweisung und Risikoprofil angemessen überwacht wird
- relevante Informationen an den Anbieter weitergegeben werden; die behördliche Meldung schwerwiegender Vorfälle trifft insbesondere den Anbieter (Art. 73)
Die Haftungslogik ist weniger direkt persönlich, stärker organisational und risikoklassifizierungsabhängig. Das Board muss wissen, welche Systeme High-Risk sind – und es muss dokumentiert sein.
5. Vergleichende Analyse: Drei unterschiedliche Haftungslogiken
| Dimension | DORA | NIS2 | AI Act |
|---|---|---|---|
| Wer ist haftbar | Board+Management (Finanzsektor) | Board+Management (kritische Entitäten) | Deployer/Organisation (alle) |
| Wofür | ICT-Framework, Risiko-Governance | Cybersecurity-Maßnahmen, Training | Human Oversight, Monitoring, Compliance |
| Art der Haftung | Persönlich + organisational | Persönlich + organisational | Organisational (mit Delegierungsoption) |
| Sanktion | Geldbuße, Sperre, persönliche Haftung | Geldbuße, persönliche Haftung (national) | Geldbußen gestaffelt: 7 % / 35 Mio. € (verbotene Praktiken), 3 % / 15 Mio. € (u. a. Hochrisiko-/Deployer-Pflichten, Art. 26), 1 % / 7,5 Mio. € (Falschauskunft) |
| Training | Implizit, aber nicht explizit | Explizit (Art. 20(2)) | Nur für Oversight-Personal |
| Dokumentation | Framework, Risiko-Register | Risk Assessment, Nachweis | Risk Assessment, Audit Trail, Incidents |
6. DORA-Governance in der Praxis: Drei operative Ebenen
DORA unterscheidet drei Ebenen der Verantwortlichkeit – jede mit unterschiedlichen Anforderungen:
| Ebene | Wer | Verantwortlichkeiten |
|---|---|---|
| Strategisch | Board / Geschäftsleitung | ICT-Strategie, Framework-Genehmigung, Überwachung kritischer Prozesse, Third-Party-Konzepte |
| Operativ | Management / Abteilungsleitungen | Umsetzung der Vorgaben, Steuerung von ICT-Risiken, Incident Management, Koordination |
| Technisch | IT, Engineering, Security | Technische Kontrollen, Logging, Monitoring, Nachweise |
Neu unter DORA: Das Board muss nachweisen können, dass Entscheidungen auf informierter Grundlage getroffen wurden – nicht nur formal, sondern inhaltlich.
Das bedeutet konkret:
- Strukturiertes Management-Briefing vor Projektstart: Darstellung von Risiken, Architektur, Abhängigkeiten und Kontrollen
- Dokumentierte Entscheidungen: Genehmigungen auf Basis klarer, nachvollziehbarer Fakten
- Integration in laufende Governance: Regelmäßige Überprüfung durch Board oder Geschäftsleitung
- Nachvollziehbare Risikobewertung: Pro Prozess, pro System und pro Schnittstelle
7. Governance wird prüfbar: Was die Aufsicht verlangt
DORA stärkt ausdrücklich die Prüf- und Eingriffsrechte der Aufsicht. In einem Audit kann verlangt werden:
- Sitzungs- und Entscheidungsprotokolle (mit welcher Gründlichkeit?)
- Architektur- und Abhängigkeitsübersichten
- Dokumentierte Entscheidungsgrundlagen
- Data-Flow- und Schnittstellendokumentationen
- Nachweise zur Bewertung und Akzeptanz von Risiken
Governance ist damit nicht mehr nur organisatorisch, sondern dokumentations- und beweisfähig auszugestalten.
8. Die Governance-Lücke: Fehlende Harmonisierung
Das zentrale Problem: Viele Verwaltungsräte verstehen nicht, dass sie nicht unter einer, sondern unter mehreren parallelen Haftungsregimen operieren. Ein Finanzunternehmen mit kritischen Infrastrukturfunktionen und KI-Einsatz kann unter DORA und NIS2 und AI Act stehen — sofern es jeweils in deren Anwendungsbereich fällt. Dabei sind vier Ebenen zu unterscheiden, die nicht ineinanderfallen dürfen: die unionsrechtliche Organisationspflicht, die aufsichtsrechtliche Verantwortlichkeit, die nationale Organhaftung und die persönliche Sanktion. Aus einer Pflicht nach EU-Recht folgt nicht automatisch eine persönliche Haftung — das richtet sich nach der nationalen Umsetzung.
9. Schweizer Dimension: OR Art. 716a und die Regulatory-Gap
Die Schweiz hat keinen direkten NIS2- oder AI-Act-Äquivalent, aber das hält nicht von Haftung ab:
- OR Art. 716a verlangt Sorgfalt und Verantwortung vom VR bei Risikomanagement
- FINMA-Zirkuläre (u.a. zu Cybersecurity) schreiben vor, dass die Bank einen VR-genehmigten Cybersecurity-Governance hat
- Marktdruck und Kontraktualität: Großbanken und Regulatoren verlangen, dass Schweizer Unternehmen DORA/NIS2-konform agieren, auch ohne direktes Schweizer Gesetz
- AI Act Exposure: Systeme, die in der EU oder mit EU-Effekt deployed sind, unterliegen dem AI Act
10. Fallstudie: Der überraschte Verwaltungsrat
Situation: Ein deutsch-schweizer Finanzdienstleister (ca. 500 Mitarbeiter, grenzübergreifend tätig) wird von der deutschen Aufsicht einer Routineprüfung unterzogen.
Befund 1 (DORA): Das ICT-Framework war dokumentiert, aber niemals vom VR formal genehmigt. Die IT-Abteilung hatte es entworfen; das Management bestätigte informell. Das ist nicht DORA-konform. Konsequenz: Verwaltungsmaßnahme, Nachbesserung.
Befund 2 (NIS2): Das Unternehmen war als "wichtige Entität" klassifiziert, aber das Board hatte kein strukturiertes Training zu Cybersecurity-Risiken. Art. 20(2) NIS2 wird verletzt. Der deutsche Staat eröffnet ein Verfahren.
Befund 3 (AI Act): Das Unternehmen nutzt ein KI-basiertes Bonitäts-Scoring-System (High-Risk nach Art. 26). Die Implementierung hat keinen formalen "Human-Oversight-Prozess". Nicht konforme Dokumentation.
Kernproblem: Drei parallele Verstöße aus einer fehlenden Board-Governance. Nicht drei separate technische Fehler, sondern ein systematisches Governance-Problem: Der VR wusste nicht, dass er unter drei Regimen operierte.
11. Praktische Empfehlungen: Ein integrierter Governance-Rahmen
11.1 Vereinigte Governance-Architektur
Statt drei separate Compliance-Regimes zu pflegen, sollte der VR eine integrierte Governance-Architektur etablieren:
- Single Risk-Framework: Ein Board-genehmigtes "Digital Risk Governance Framework", das DORA, NIS2 und AI Act vereint
- Quartalsweise Board-Session zu den drei Dimensionen: ICT Risk, Cybersecurity, AI Compliance
- Dedizierter "Audit&Risk"-Ausschuss oder Task-Force mit klaren Mandaten
11.2 Training und Board-Kompetenz
NIS2 Art. 20(2) macht es explizit: Das Board muss trainiert sein. Dasselbe sollte für DORA und AI Act gelten:
- Initiales Board-Training: 1–2 Tage zu Digital Risk, Cybersecurity, AI Governance
- Halbjährliche Updates zu Regulatory Changes
- Dokumentation der Schulung (Trainer, Inhalte, Teilnehmer, Daten)
11.3 Dokumentations-Architektur
Drei Regimes bedeuten drei potenzielle Audits. Die Dokumentation muss wechselseitig sein:
- Board-Resolutionen (genehmigt, datiert, unterzeichnet)
- Risk Register (ICT + Cyber + AI)
- Implementierungs-Nachweise (z.B. Human-Oversight-Prozess für KI)
- Training-Protokolle (Namen, Daten, Inhalte)
- Audit-Trail (wer hat was genehmigt, wann)
12. Klassische Governance-Fehler und wie man sie vermeidet
Fünf typische Lücken, die bei Audits auffallen:
- Formale Genehmigung ohne Verständnis der Architektur: Das Board gibt seinen Namen, kennt aber nicht die Risiken. Lösung: Management-Briefing mit Risiko-Szenarios.
- Generische Risikoanalysen ohne Systembezug: "ICT-Risiken sind hoch" ist keine Analyse. Lösung: Pro System, pro Schnittstelle, nachvollziehbar.
- Nicht nachvollziehbare Entscheidungswege: Keine Sitzungsprotokolle, keine Begründung. Lösung: Strukturierte Entscheidungsdokumentation.
- Fehlende Verbindung zwischen Governance-Strukturen und Technik: Das Board genehmigt, die IT arbeitet parallel. Lösung: Transparente Governance-Ebenen mit klaren Schnittstellen.
- Unklare Verantwortlichkeiten: "IT kümmert sich darum." Lösung: Explizite Rollen pro Ebene, mit Unterschriften.
Was bleibt
Mehrschichtige Verantwortung: Je nach Geschäftsmodell können mehrere Regime nebeneinander anwendbar sein. Anwendungsbereich, Adressat und konkrete Organverantwortung sind für jedes Regime getrennt zu bestimmen. Wo ein Regime greift, kann sein Versäumnis Enforcement auslösen.
Unterschiedliche Haftungslogiken: DORA verlangt Framework-Genehmigung. NIS2 verlangt Training + Genehmigung. AI Act verlangt Risiko-Klassifizierung + Oversight. Ein generisches Governance-Modell reicht nicht.
Dokumentation als Kernbeweis: Bei Enforcement verlassen sich Regulatoren auf Dokumentation. Board-Resolutionen, Training-Nachweise, Risk Assessments und Audit-Trails müssen wasserdicht sein.
Swiss Exposure trotz Regulatory Gap: Schweizer Unternehmen können unmittelbar, extraterritorial oder lediglich vertraglich und mittelbar betroffen sein. Diese drei Formen der Betroffenheit sind für jedes Regime (DORA, NIS2, AI Act) getrennt zu prüfen. OR 716a bleibt der gesellschaftsrechtliche Unterbau.