A uf dem Papier klingt alles logisch: Ein europäischer Rahmen, der digitale Resilienz messbar macht, Meldewege harmonisiert, Drittparteien in die Pflicht nimmt und das Silo-Denken zwischen IT, Betrieb, Einkauf und Compliance aufbricht. In der Praxis prallen diese neuen Pflichten auf alte Strukturen – gewachsene Organisationen, komplexe Lieferketten, Legacy-Systeme, projektgetriebene Budgets, fragmentierte Verantwortungen. Das Ergebnis ist vielerorts dasselbe Bild: ernsthafte Bereitschaft, viel Aktivität, lange To-do-Listen – und trotzdem das Gefühl, dass DORA wie ein Wellenbrecher immer neue Lücken in den Damm schlägt. Dieser Beitrag seziert, wo DORA Unternehmen überfordert, warum das so ist und wie sich der Knoten lösen lässt, ohne Dutzende Parallelprojekte zu starten, die am Ende nur mehr Papier produzieren.

1) Der Kern des Problems: DORA verlangt Fähigkeiten, nicht Formulare

Die erste Überforderung beginnt im Kopf: Viele Organisationen behandeln DORA wie eine weitere Compliance-Checkliste. Das ist bequem, aber falsch. DORA verlangt Fähigkeiten – erkennen, entscheiden, melden, wiederanlaufen, nachweisen – in klaren Zeitfenstern und über Bereichsgrenzen hinweg. Genau hier reibt sich die Verordnung an alten Mustern:

Manche Sicherheitsgeschichten beginnen mit einem Genie an der Kommandozeile, einem Domain-Admin im Mantel der Nacht, einem perfekt orchestrierten Angriff auf Kerberos oder KMS. Die meisten beginnen anders: mit alltäglichen Rechten, die niemand für gefährlich hält. Ein „Viewer“ in der Doku-Plattform. Ein „Reporting“-Zugang im CRM. Ein „Guest“ im Kollaborationstool. Ein Servicekonto mit Leserechten auf Logdateien. Ein Praktikanten-Account, der nur Tickets lesen darf. Diese scheinbar harmlosen Berechtigungen sind die Welt des Insider light – Personen und Prozesse innerhalb (oder knapp außerhalb) der Organisation, die keine „großen“ Rechte brauchen, um große Lücken zu reißen. Nicht, weil sie Superhacker wären, sondern weil unsere Systeme Informationen großzügig streuen, Workflows automatisch auslösen und Meta­daten verräterischer sind, als uns lieb ist. Wer Sicherheit heute ernst meint, darf das kleine Licht nicht unterschätzen, denn es beleuchtet überraschend viele Wege bis ins Herz der Organisation.

Was genau ist „Insider light“?

„Insider“ weckt oft das Bild des böswilligen Mitarbeiters mit Vollzugriff. „Light“ verschiebt die Perspektive: Es geht um Akteure mit begrenzten, formal unkritischen Rechten, die dennoch kritische Wirkung entfalten – absichtlich, fahrlässig oder weil sie selbst zum Opfer werden. Das Spektrum ist breit:

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.

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.

Es gibt eine stille Revolution in Governance, Risk & Compliance (GRC). Sie steht nicht auf Folien, sie hängt nicht an Stichtagen, sie produziert keine Papierstapel. Sie läuft im Hintergrund – als permanenter, ereignisgetriebener Takt aus Regeln, Sensoren, Ereignissen und Nachweisen. Automatisierte Compliance bedeutet nicht, dass „die Maschine Verantwortung übernimmt“. Sie bedeutet, dass Regeln ausführbar werden, Kontrollen ständig laufen, Abweichungen sofort sichtbar sind und Nachweise nebenbei entstehen. In Zeiten, in denen Anforderungen, Architekturen und Angriffsflächen sich im Monatsrhythmus ändern, ist das kein Luxus, sondern die einzige Chance, wirksam zu bleiben. Dieser Beitrag zeigt, wie Organisationen den Sprung schaffen: von Dokumentationspflichten zu Controls-as-Code, von stichprobenhaften Prüfungen zu Continuous Controls Monitoring (CCM), von aufwändigen Audit-Sprints zu einem Evidence Layer, der Beweise automatisch sammelt, schützt und bereitstellt. Mit mehr Struktur, weniger Lärm – und mit Kennzahlen, die Entscheidungen auslösen statt PowerPoint zu befüllen.

Warum „mehr vom Gleichen“ nicht mehr reicht

Jahrelang war die Antwort auf zunehmende Regulierung: mehr Richtlinien, mehr Checklisten, mehr Trainings, mehr Audits. Das Ergebnis war vorhersehbar – steigende Kosten, steigende Ermüdung, sinkende Wirksamkeit. Je mehr Menschen unterschreiben müssen, dass sie etwas gelesen haben, desto weniger bleibt im Alltag erhalten. Je öfter man manuell nachweist, desto größer werden Lücken, Artefaktwüsten und Interpretationsspielräume. Automatisierung ist nicht die Flucht vor Verantwortung, sie ist die Rationalisierung von Verantwortung. Wenn das System im Moment des Handelns durchsetzt, was gilt, muss niemand erinnern, diskutieren, kopieren. Der Effekt ist doppelt: Risiken werden früher sichtbar, und Teams werden entlastet.