DORA klingt auf dem Papier oft klar: Risiken rund um digitale Dienstleistungen beherrschbar machen, Ausfälle reduzieren, Nachweise liefern. In der Umsetzung zeigt sich aber ein Muster, das ich in Projekten immer wieder sehe: Im Alltag wirkt vieles „irgendwie geregelt“ – bis ein Audit oder eine Prüfung fragt: Wo ist das belastbar belegt? Dann tauchen Lücken auf, die vorher niemand auf dem Radar hatte.

Dieser Beitrag ist bewusst praktisch gehalten. Er beschreibt zehn typische Stolperfallen, die meist erst dann schmerzhaft werden, wenn jemand von außen den Finger in die Wunde legt – Revision, Prüfer, Aufsicht, Kunden oder ein großer Dienstleister im Vertragsgespräch. Zu jeder Stolperfalle finden Sie: ein kurzes Erkennungszeichen, warum das passiert, und was Sie konkret tun können, ohne das Unternehmen mit zusätzlichen Programmen zu überfrachten.

Die Einführung eines Informationssicherheits-Managementsystems (ISMS) gilt oft als Mammutprojekt. Viele Unternehmen schieben es vor sich her, weil sie den Aufwand scheuen, die Komplexität fürchten oder befürchten, dass der Betrieb monatelang im Ausnahmezustand laufen muss. Tatsächlich kann ein ISMS-Einführungsprojekt chaotisch verlaufen – wenn man es falsch angeht. Mit einem klaren, strukturierten Vorgehen hingegen lässt es sich in geordnete Bahnen lenken, ohne den Arbeitsalltag lahmzulegen. Der Schlüssel liegt in einer schrittweisen Umsetzung, die Orientierung gibt, Ressourcen klug einsetzt und alle Beteiligten mitnimmt. Der hier beschriebene 5-Stufen-Plan bietet genau diesen roten Faden und übersetzt ISO/IEC 27001:2022, BSI IT-Grundschutz & Co. in greifbare Arbeitspakete.

Die Logik dahinter ist einfach: erst Klarheit und Commitment, dann saubere Planung, danach eine realitätsnahe Risikoanalyse, anschließend fokussierte Umsetzung der wichtigsten Maßnahmen – und zum Schluss die Verstetigung im Regelbetrieb samt Audits und kontinuierlicher Verbesserung. So entsteht ein ISMS, das nicht nur Papier füllt, sondern tatsächlich Sicherheit erzeugt.

Die meisten Organisationen machen denselben Fehler, wenn mehrere Regelwerke gleichzeitig relevant werden: Sie bauen drei Programme. DORA bekommt ein Projekt, NIS2 bekommt ein Projekt, der EU AI Act bekommt ein Projekt. Jedes Projekt erstellt Anforderungen, Maßnahmenlisten, Richtlinien, Reportings. Und jedes Projekt hat gute Gründe, weil jede Anforderung „irgendwie“ stimmt. Das Ergebnis ist trotzdem oft enttäuschend: viel Arbeit, viel Dokumentation, aber die Betriebsfähigkeit wird nicht proportional besser. Noch schlimmer: Teams beginnen zu „optimieren“, indem sie das jeweils nächste Audit bedienen, statt das System als Ganzes stabiler zu machen.

Die Abkürzungen sind unterschiedlich, aber die Realität dahinter ist erstaunlich ähnlich. Alle drei Rahmenwerke wollen im Kern, dass Sie Entscheidungen nicht dem Zufall überlassen. Sie wollen Verantwortlichkeiten, die im Alltag funktionieren. Sie wollen, dass Störungen beherrscht werden können. Sie wollen, dass kritische Abhängigkeiten gesteuert werden. Und sie wollen, dass Sie das belegen können – nicht durch schöne Texte, sondern durch eine nachvollziehbare Spur.

Viele Unternehmen atmen auf, wenn sie die Anforderungen der NIS2-Richtlinie formal umgesetzt haben. Die Prozesse sind dokumentiert, die Technik aufgerüstet, die Schulungen durchgeführt – und der Gedanke liegt nahe, das Thema erst einmal abzuhaken. Doch genau hier lauert eine der größten Gefahren: NIS2-Compliance ist kein Abschluss, sondern ein Betriebszustand. Er muss jeden Tag hergestellt, überwacht und verbessert werden – genauso wie Verfügbarkeit oder Servicequalität. Cyberbedrohungen entwickeln sich weiter, Geschäftsmodelle ändern sich, die Lieferkette ist in Bewegung, und auch die aufsichtsrechtlichen Erwartungen werden geschärft. Wer nach der initialen Umsetzung in den Wartemodus schaltet, riskiert nicht nur Bußgelder, sondern vor allem reale Sicherheitslücken.

Dieser Beitrag zeigt, wie Sie NIS2 nicht nur „erfüllen“, sondern als belastbare Routine verankern: mit klaren Verantwortlichkeiten, einem schlanken Regelkreis, messbaren Kennzahlen, einer gelebten Sicherheitskultur und praktischen Werkzeugen, die den Aufwand senken statt ihn zu steigern.

Third-Party-Risk-Management (TPRM) galt lange als Pflichtfach: Fragebogen verschicken, Zertifikate einsammeln, Auditberichte abheften – fertig. Spätestens mit dem Digital Operational Resilience Act (DORA) ist dieses Verständnis Geschichte. TPRM wird vom statischen Kontrollpunkt zum dynamischen Kern der digitalen Widerstandsfähigkeit. Nicht mehr das „Ob“ einer Maßnahme zählt, sondern das „Hält es im Ernstfall?“. Governance rückt damit näher an den operativen Puls; Lieferantenbeziehungen werden zu gemeinsam verantworteten Resilienz-Systemen – gemessen, getestet, nachweisbar.

Dieser Beitrag zeigt, wie sich TPRM unter DORA grundlegend verschiebt: weg von Dokumentation, hin zu belastbarer Operations-Resilienz. Er ordnet die neuen Erwartungen, skizziert ein modernes Operating Model, gibt konkrete Leitplanken für Verträge, Technik und Monitoring – und benennt Anti-Patterns, die heute noch zu häufig zu sehen sind.