Mit der NIS2-Richtlinie rückt ein Aspekt besonders in den Fokus, der in vielen Unternehmen bisher unterschätzt wurde: die persönliche Haftung von Führungskräften. Während Cybersicherheit früher zu oft als „IT-Thema“ betrachtet wurde, macht NIS2 unmissverständlich klar: Die Verantwortung liegt an der Spitze – und sie lässt sich nicht delegieren. Das verändert Entscheidungswege, Prioritäten und auch die Art, wie über Risiken gesprochen wird.

Im Kern verpflichtet NIS2 Unternehmensleitungen, angemessene (und nachweisbar wirksame) Sicherheits- und Risikomanagementmaßnahmen zu etablieren, deren Umsetzung zu überwachen und ausreichende Ressourcen bereitzustellen. Unterbleibt dies, drohen nicht nur Unternehmenssanktionen, sondern auch persönliche Konsequenzen – zivilrechtlich, aufsichtsrechtlich und in Extremfällen strafrechtlich. Dieser Beitrag erklärt den rechtlichen Rahmen, typische Haftungsfallen, praxisnahe Schutzmechanismen und liefert konkrete Vorlagen, wie Leitungsgremien ihre Sorgfaltspflichten geordnet wahrnehmen und belegen können.

Wer DORA zum ersten Mal liest, stößt unweigerlich auf den Begriff ICT-Risikomanagement, im Deutschen meist als IKT-Risikomanagement bezeichnet. Er steht im Zentrum der gesamten Verordnung und ist weit mehr als nur eine formale Pflicht. Im Kern geht es darum, Risiken, die aus der Nutzung von Informations- und Kommunikationstechnologien entstehen, systematisch zu erkennen, zu bewerten, zu steuern und zu überwachen. Das klingt zunächst vertraut, denn Risikomanagement gehört schon lange zu den Aufgaben jedes regulierten Finanzunternehmens. Der entscheidende Unterschied unter DORA: Die Anforderungen werden einheitlich, detailliert und verbindlich für alle Marktteilnehmer definiert – und das auf einem Niveau, das deutlich über bisherige nationale Standards hinausgeht. Es reicht nicht mehr aus, einmal im Jahr eine Risikoübersicht zu erstellen oder Risiken vage zu kategorisieren. Gefordert ist ein kontinuierlicher, ganzheitlicher Ansatz, der tief in den täglichen Betrieb integriert ist und bis ins Top-Management hineinwirkt.

Was DORA als IKT-Risiko versteht

Das beginnt bei der Definition dessen, was überhaupt als IKT-Risiko gilt. DORA macht klar, dass es sich nicht nur um klassische Cyberangriffe handelt. Auch Systemausfälle, fehlerhafte Software-Updates, Konfigurationsfehler, Datenverluste, Störungen durch Dritte oder physische Schäden an Rechenzentren fallen darunter. Selbst Risiken aus der Lieferkette, etwa durch Ausfälle eines Cloud-Anbieters, eine kritische Schwachstelle in einer verbreiteten Bibliothek oder Sicherheitslücken in genutzter Standardsoftware, müssen erfasst werden. Das Ziel ist, alle Ereignisse, die die Funktionsfähigkeit kritischer Systeme oder die Verfügbarkeit wichtiger Daten beeinträchtigen können, systematisch zu berücksichtigen. Dabei sollen nicht nur technische Aspekte betrachtet werden, sondern auch organisatorische, personelle und prozessuale Faktoren. Ein System mag technisch sicher sein, doch wenn es keine klaren Eskalationswege im Störungsfall gibt, ist das Risiko dennoch hoch. DORA rückt damit das Zusammenspiel von Technik, Prozessen und Menschen ins Zentrum – also genau jene Schnittstellen, an denen es in der Praxis häufig knirscht.

Jede Organisation, egal ob kleines Start-up oder globaler Konzern, muss sich mit Risiken auseinandersetzen. Dabei geht es nicht nur um Cyberangriffe oder IT-Ausfälle, sondern um alles, was den Geschäftsbetrieb stören, den Ruf schädigen oder finanzielle Verluste verursachen kann. Die entscheidende Frage lautet: Wie viel Risiko ist akzeptabel – und ab wann wird es gefährlich?

Die Antwort darauf ist nicht so einfach, wie sie klingt. Ein Null-Risiko gibt es nicht, schon gar nicht in einer komplex vernetzten Welt. Jede Sicherheitsmaßnahme kostet Geld, Zeit und oft auch Komfort. Deshalb muss jedes Unternehmen den Punkt finden, an dem der Nutzen zusätzlicher Sicherheit den Aufwand rechtfertigt – und darüber hinaus erkennen, wann es besser ist, ein Risiko bewusst einzugehen, anstatt es um jeden Preis zu vermeiden.

Wer sich mit Informationssicherheit beschäftigt, kennt sie: die drei klassischen Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit. Sie sind das Fundament der Sicherheitsarchitektur und bilden seit Jahrzehnten den Ausgangspunkt fast jeder Sicherheitsstrategie. Doch so zeitlos diese „magischen drei“ sind – die Welt, in der sie entstanden, war eine andere. Heute sind Unternehmen global vernetzt, Datenströme kennen keine Landesgrenzen mehr, Cloud-Dienste und mobile Geräte sind allgegenwärtig, und Bedrohungen entwickeln sich in rasantem Tempo. Diese neue Realität hat dazu geführt, dass die klassische Triade nicht mehr alle Facetten der Informationssicherheit abdeckt. Aus dieser Lücke entstand eine erweiterte Sichtweise: Schutzziele 2.0. Sie ersetzen die Triade nicht, sondern ergänzen sie – um Dimensionen, die Vertrauen, Nachvollziehbarkeit, Widerstandsfähigkeit und rechtliche Wirksamkeit in der digitalen Gegenwart absichern.

Vom Dreiklang zum Orchester: Das Denkmodell hinter Schutzzielen 2.0

Die CIA-Triade beantwortet drei Kernfragen: Wer darf sehen, ob das Gesehene stimmt, und ob das System funktioniert, wenn es gebraucht wird. In modernen Ökosystemen kommen jedoch weitere Fragen hinzu. Woher stammt die Information wirklich? Darf jemand später bestreiten, etwas getan zu haben? Wer trägt Verantwortung für eine Aktion, wenn Menschen, Bots und KI-Modelle gemeinsam handeln? Wie beweise ich in fünf Jahren, dass ein Datensatz unverändert geblieben ist? Wie schnell kann der Betrieb nach einem Ransomware-Angriff wieder anlaufen? Wie schütze ich Privatsphäre über den gesamten Datenlebenszyklus? Und wie stelle ich sicher, dass Sicherheitsentscheidungen erklärbar und überprüfbar sind? Schutzziele 2.0 geben strukturierte Antworten auf diese Fragen.

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.