Zero Trust hat in den vergangenen Jahren viele Etiketten getragen: Paradigmenwechsel, neues Sicherheitsmodell, Buzzword. In der Praxis ist es weniger eine Revolution als ein Architekturprinzip, das Organisationen zwingt, ungeschriebene Annahmen sichtbar zu machen. Nicht mehr „im Netz = vertrauenswürdig“, nicht mehr „einmal angemeldet = immer berechtigt“, nicht mehr „VPN an = alles gut“. Zero Trust bedeutet, Vertrauen situativ und begründet zu vergeben, Identitäten und Kontexte fortlaufend zu prüfen und Berechtigungen so kurzlebig und eng wie möglich zu halten – ohne den Fluss der Arbeit zu bremsen. Das vermeintliche Paradox – strenge Kontrolle und hoher Komfort – löst sich auf, wenn Governance nicht als Papierdisziplin, sondern als Betriebsleistung gedacht wird: Regeln sind ausführbar, Entscheidungen fallen in Minuten, Nachweise entstehen nebenbei und die Benutzeroberfläche lädt zum Richtigen ein. Genau dort gewinnt Zero Trust seinen Wert: Es macht richtige Entscheidungen einfach, falsche teuer, und den Rest unspektakulär.

Vom Slogan zur Entscheidung: Was Zero Trust wirklich ändert

Zero Trust beginnt mit einer simplen, aber radikalen Frage: „Worauf stützen wir gerade unser Vertrauen?“ In traditionellen Architekturen war die Antwort oft unsichtbar: Standort, Segment, einmaliges Login, Administratorstatus. In Zero-Trust-Architekturen wird Vertrauen explizit: Wer ist die Identität, welcher Workload, welcher Service? Welche Rolle, welcher Gerätezustand, welches Risiko, welcher Zweck? Welche Datenklasse, welche Sensibilität, welche regulatorische Schwelle? Die Entscheidung fällt nicht einmalig am Morgen, sondern jedes Mal, wenn es darauf ankommt – in der Anmeldung, beim Zugriff auf ein Repository, beim Export eines Datensatzes, beim Starten eines privilegierten Befehls, beim Abrufen eines API-Endpunkts. Diese Mikroentscheidungen müssen zwei Kriterien erfüllen, sonst scheitert der Alltag: Sie müssen schnell und vorhersehbar sein. Schnell, damit Menschen im Fluss bleiben. Vorhersehbar, damit Teams Vertrauen in das System fassen und es nicht „umbrücken“. Governance, die Zero Trust tragen soll, legt deshalb weniger Wert auf lange Policytexte als auf unmissverständliche Schwellen und Konsequenzen, die technisch durchsetzbar sind.

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.

In fast jedem Auditbericht taucht er auf, oft irgendwo im Mittelfeld zwischen Patch-Management und Backup-Strategie: der Punkt „Awareness & Schulungen“. Ein paar Pflichtmodule pro Jahr, eine Phishing-Simulation, vielleicht ein Poster in der Teeküche – und das Thema gilt als erledigt. Das Problem: So entsteht keine Resilienz, sondern Ritual. Menschen klicken, nicken, bestehen Quizfragen – und handeln am nächsten Tag so, wie es der reale Arbeitsdruck, die Tool-Landschaft und die Teamkultur nahelegen. Awareness ist kein Wissensproblem. Sie ist eine Verhaltensleistung unter Zeitdruck, Ambiguität und sozialen Einflüssen. Wer sie als Checkbox behandelt, produziert müde Zustimmung. Wer sie als Betriebsleistung gestaltet, verändert Entscheidungen am Bildschirm – und damit die Sicherheitsbilanz des Unternehmens.

Dieser Beitrag erklärt, warum klassische Awareness-Programme scheitern, wie moderne Ansätze psychologische Realitäten ernst nehmen, warum Führung und UX mehr bewirken als Ermahnungen, welche Metriken wirklich zählen und wie sich in 180 Tagen ein spürbarer Kulturwechsel erzielen lässt – ohne Heldenmythos, dafür mit System.

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: