Daten waren lange das stille Versprechen der Digitalisierung: mehr Wissen, bessere Entscheidungen, neue Geschäftsmodelle. Heute sind sie zugleich größter Hebel und größtes Haftungsfeld. Zwischen Datenschutz, Compliance und aggressivem Einsatz von KI spannt sich ein Raum, in dem Chancen und Risiken stündlich neu verteilt werden. Governance, die hier wirksam sein soll, muss zwei Dinge gleichzeitig leisten: Vertrauen sichern – gegenüber Kunden, Aufsichten, Partnern, Mitarbeitenden – und Wert freisetzen – durch analytische Exzellenz, Automatisierung, Produkte, die Daten intelligent nutzen. Das gelingt nicht mit Parolen („Data is the new oil“) und auch nicht mit Verboten („Data Sharing nur im Ausnahmefall“), sondern mit einer Betriebsleistung, die Datenflüsse sichtbar, steuerbar und beweisbar macht: von der Erhebung über Speicherung, Verarbeitung, Training von KI-Systemen, Bereitstellung in APIs bis zur Löschung. Dieser Beitrag zeigt, wie Governance diesen Spagat schafft – ohne Illusionen, aber mit praktikablen Mechaniken, Kennzahlen und Entscheidungen, die nicht auf dem Papier, sondern im Alltag tragen.

1. Vom Asset zur Haftung: Warum Daten heute anders zählen

Daten galten einst als „kostenloser Rohstoff“: Sammeln, speichern, irgendwann nutzen. Diese Haltung hat sich überholt – aus drei Gründen. Erstens wandern Daten über SaaS-Landschaften und Cloud-Regionen, die rechtlich, technisch und organisatorisch verschieden ticken. Jeder neue Dienst ist eine weitere Angriffs- und Haftungsfläche. Zweitens entwerten KI-Modelle schlechte oder unklare Daten – Garbage in, turbo-Garbage out. Bias, Halluzinationen, Fehlentscheidungen sind keine Nebensache, sondern Produkt- und Reputationsrisiko. Drittens hat sich das Regelwerk verdichtet: Datenschutzrecht, branchenbezogene Aufsicht, Sicherheitsverordnungen, Produkthaftungsregime für digitale Komponenten und KI-Systeme. Zusammen erzeugen sie eine Pflicht zur Daten-Disziplin: Wer nicht weiß, welche Daten wo, warum, wie lange und unter wessen Kontrolle liegen, riskiert Bußgelder, Vertragsstrafen, Vertrauensbrüche und Stopps bei Zulassungen oder Audits.

Lange war C5 der pragmatische Schlüssel, um mit Hyperscalern auf Augenhöhe zu sprechen: klare Kontrollziele, nachvollziehbare Prüfberichte, eine Sprache, die Entwicklung, Betrieb, Einkauf, Recht und Revision zusammenbringt. Mit DORA – dem Digital Operational Resilience Act – verschiebt sich der Rahmen. Was zuvor „Best Practice“ oder „kundenseitige Due Diligence“ war, wird nun aufsichtliche Erwartung: belastbare Nachweise, risikobasierte Steuerung, Meldefähigkeit in Stunden, Wiederherstellbarkeit unter Druck, gelebte Lieferantenkontrolle. Kurz: Cloud-Prüfung wird regulatorisch. Dieser Beitrag zeigt, wie C5 und DORA zusammenpassen, wo sie sich ergänzen – und wie man die beiden Welten so verbindet, dass aus Compliance keine Bremse, sondern ein betriebliches Beschleunigungsprogramm wird.

Von der Komfortzone in den Ernstfall: Was sich mit DORA ändert

C5 hat Unternehmen befähigt, die Provider-Seite systematisch zu prüfen: Mandantentrennung, Kryptostrategien, physische und logische Sicherheit, Logging-Optionen, Incident-Prozesse, Subprozessoren, Notfallkonzepte. DORA dreht die Kamera und zentriert die Kundenseite: Wie sind kritische Prozesse definiert? Welche Zeiten gelten (Erkennen, Entscheiden, Begrenzen, Wiederherstellen)? Wie laufen Vorfälle durch die Organisation – und durch die Lieferkette? Welche Evidenz liegt wann vor? Wie werden Risiken bei IKT-Dritten gesteuert? Wie werden Tests geplant, durchgeführt, ausgewertet? Damit reicht es nicht mehr, „einen C5-Bericht im Ordner zu haben“. DORA erwartet, dass Cloud-Einsatz in die Resilienz-Mechanik eingebaut ist – prüfbar, wiederholbar, anschlussfähig.

Der Digital Operational Resilience Act (DORA) ist mehr als nur ein weiteres EU-Regelwerk. Er ist ein Paradigmenwechsel in der Art und Weise, wie Finanzunternehmen und ihre Dienstleister digitale Resilienz verstehen und umsetzen müssen. Mit dem Stichtag 17. Januar 2025 rückt die Frist für die vollständige Umsetzung näher, und in vielen Organisationen ist die Erkenntnis gereift: Wer jetzt nicht mit einem strukturierten Fahrplan startet, wird später unter Zeitdruck geraten und riskieren, halbherzige Lösungen einzuführen, die weder den regulatorischen Anforderungen noch den eigenen Sicherheitsbedürfnissen gerecht werden. DORA-Compliance ist kein „Ordner mit Policies“, sondern die Fähigkeit, unter massiven digitalen Störungen handlungsfähig zu bleiben – messbar, prüfbar, wiederholbar.

DORA in 60 Sekunden

DORA harmonisiert europaweit die Anforderungen an die digitale Betriebsstabilität (Operational Resilience) im Finanzsektor. Der Kern lässt sich in fünf Säulen einordnen:

Wer sich mit Informationssicherheit beschäftigt, stößt früher oder später auf die Rolle des Informationssicherheitsbeauftragten (ISB). In vielen Unternehmen ist diese Position gesetzlich oder regulatorisch vorgeschrieben, in anderen wird sie freiwillig geschaffen, um dem Thema einen festen Platz zu geben. Der ISB ist dabei ein merkwürdiges Zwitterwesen: Er ist weder reiner Technikexperte noch bloßer Verwalter von Richtlinien. Er ist Übersetzer zwischen Welten, Vermittler zwischen Geschäftsleitung und IT, Wächter über Regeln – und manchmal auch Feuerwehrmann, wenn etwas brennt. Gleichzeitig ist er Architekt, der langfristige Strukturen entwirft, um das Haus der Informationssicherheit stabil und zukunftsfähig zu machen. Genau diese Doppelrolle macht die Funktion anspruchsvoll – und für den Unternehmenserfolg essenziell.

Auftrag, Mandat und rechtlicher Rahmen: Wofür der ISB wirklich verantwortlich ist

Der ISB ist kein „nice to have“, sondern Träger eines klaren Auftrags. Je nach Branche und Größe des Unternehmens ergibt sich dieser aus Normen, Gesetzen und Aufsichtsanforderungen. In Deutschland sind vor allem ISO/IEC 27001, der BSI IT-Grundschutz sowie aufsichtsrechtliche Leitlinien relevant (z. B. BAIT für Banken, VAIT für Versicherungen, KAIT für Kapitalverwaltungsgesellschaften). Hinzu kommen horizontale Anforderungen wie NIS2 (Sicherheits- und Meldepflichten für wichtige/besonders wichtige Einrichtungen), DORA (Resilienz im Finanzsektor), DSGVO (TOMs, 72-Stunden-Meldepflicht bei Datenschutzvorfällen) und – je nach Geschäftsmodell – branchenspezifische Rahmenwerke wie TISAX (Automotive) oder IEC 62443 (OT/Industrie).

Die neue NIS2-Richtlinie gilt als Meilenstein in der europäischen Cybersicherheitsgesetzgebung. Sie weitet den Anwendungsbereich deutlich aus, erhöht die Anforderungen und sieht spürbare Sanktionen vor. Für viele Unternehmen ist NIS2 jedoch nicht nur eine regulatorische Vorgabe, sondern auch eine ernsthafte organisatorische und technische Herausforderung. Denn zwischen dem Verständnis der Richtlinie und ihrer praktischen Umsetzung liegen oft Welten. Viele starten motiviert, geraten aber auf halber Strecke ins Stocken – nicht aus bösem Willen, sondern weil die Stolpersteine dort liegen, wo man sie zunächst gar nicht vermutet.

Dieser Beitrag zeigt die häufigsten Fallstricke, erklärt, warum sie gefährlich sind, und beschreibt konkrete Gegenmaßnahmen. Ziel ist, NIS2 nicht nur als Pflicht zu betrachten, sondern als Chance, die eigene Cyber-Resilienz nachhaltig zu stärken – mit klaren Verantwortlichkeiten, gelebten Prozessen und belastbaren Nachweisen.