In der Welt der Informationssicherheit gab es immer wieder Schlagworte, die als „Must-have“ galten: Firewalls, Virenscanner, ISO 27001, Cloud Security, Zero Trust. Jedes dieser Themen hatte seine Zeit im Rampenlicht. Heute ist der Begriff, der in Vorträgen, Strategiepapiere und Gesetzesentwürfe gleichermaßen auftaucht, Cyber-Resilienz. Er klingt modern, fast schon schick – und genau deshalb wird er oft oberflächlich behandelt. Aber hinter diesem Schlagwort steckt weit mehr als ein Marketingtrend. Cyber-Resilienz ist nicht nur eine Erweiterung klassischer IT-Sicherheit, sondern ein strategischer Ansatz, der Unternehmen widerstandsfähig gegen digitale Angriffe, technische Störungen und sogar komplexe Krisen macht. Kurz gesagt: Es geht nicht mehr nur darum, Angriffe zu verhindern, sondern darum, auch dann handlungsfähig zu bleiben, wenn sie unvermeidlich eintreten.

Von Prävention zu Anpassungsfähigkeit: Was Cyber-Resilienz wirklich bedeutet

Der zentrale Unterschied zwischen traditioneller IT-Sicherheit und Cyber-Resilienz liegt in der Perspektive. Klassische Sicherheitskonzepte fokussieren stark auf Prävention – also darauf, Angriffe zu blockieren, Schwachstellen zu schließen und Risiken zu minimieren. Das ist wichtig, aber in einer Welt, in der Angreifer immer schneller neue Taktiken entwickeln und selbst hochgesicherte Systeme kompromittieren können, reicht Prävention allein nicht mehr aus. Cyber-Resilienz ergänzt diesen Ansatz um Detektion, Reaktion, Wiederherstellung und Lernen. Das bedeutet: Wir akzeptieren, dass ein Angriff oder Ausfall passieren kann, und sorgen dafür, dass wir schnell erkennen, angemessen reagieren und uns effizient erholen – ohne dass der Geschäftsbetrieb vollständig zum Erliegen kommt.

Operational Resilience galt lange als Sonderdisziplin für Krisenmanager, als Notfallplan für seltene, extreme Ereignisse: Rechenzentrum brennt, Leitungen fallen aus, Angriff trifft die Kernsysteme, Lieferant stürzt ab. Dann kam die Dauerkrise – nicht als einzelner Paukenschlag, sondern als Takt: Cloud-Migrationswellen, Release-Kadenz im Wochenrhythmus, global vernetzte Lieferketten, Meldepflichten mit engen Fristen, Angreifer, die sich industrialisiert haben, und Kundenerwartungen, die Ausfallzeiten nicht mehr entschuldigen. Was früher Ausnahmefall war, ist heute Betriebszustand. Operational Resilience 360° bedeutet deshalb nicht, mehr Notfallpläne zu schreiben oder größere Firewall-Wälle zu ziehen. Es bedeutet, das Unternehmen so zu gestalten, dass Störungen einkalkuliert sind, Entscheidungen unter Druck zuverlässig fallen, Wiederanläufe geprüft sind, Beweise nebenbei entstehen und der Normalbetrieb bereits den Krisenbetrieb enthält. Es ist ein Kultur- und Architekturwechsel – vom heroischen Improvisieren zur geprobten Beherrschbarkeit; vom Projekt zur Betriebsleistung; vom Dokument zur Demonstration.

In der Praxis beginnt dieser Wandel mit einer unbequemen Ehrlichkeit: Niemand kann alle Risiken vermeiden, niemand alle Abhängigkeiten herauslösen, niemand ein „Null-Ausfall“-Unternehmen bauen. Die Illusion vollständiger Kontrolle ist selbst ein Risiko, denn sie verführt zu guten Geschichten statt zu belastbaren Fähigkeiten. Wer Operational Resilience 360° ernst nimmt, verabschiedet sich von makelloser Fassade und arbeitet an den Mechaniken dahinter: Wirkzeit statt Reifegrad, Übungen statt Versprechen, Anschlussfähigkeit statt Einkaufsfolklore, Evidenz statt Erinnerung, Reduktion statt Sammeltrieb, und eine Zeitlogik, die über Sicherheit hinaus das Geschäft führt. Das Ergebnis ist keine Organisation, die nicht mehr stolpert, sondern eine, die beim Stolpern nicht fällt – und wieder in den Lauf findet, ohne erst ihren Schuh suchen zu müssen.

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.