Warum regulatorische Frameworks unterschätzt werden
Wer sich mit IT-Regulierung beschäftigt, denkt zuerst an Pflichten, Fristen und Bußgelder. Doch dieser Blickwinkel verdeckt etwas Wichtiges: Hinter DORA und NIS2 stecken jahrelang ausgearbeitete, intensiv diskutierte und praxisorientierte Governance-Modelle. Modelle, die auch dann wertvoll sind, wenn man rechtlich nicht betroffen ist.
Die Frage ist nicht: Muss ich das umsetzen? Die bessere Frage ist: Was davon würde meiner Organisation wirklich helfen?
In der Praxis beobachte ich immer wieder dasselbe Muster: Unternehmen außerhalb des regulierten Perimeters investieren viel Zeit darin, eigene interne Standards zu entwickeln – oft von Grund auf und ohne Orientierung. Dabei existieren längst fertige, rechtlich erprobte und von Experten validierte Frameworks. Kostenlos. Öffentlich. Auf Deutsch verfügbar.
Regulierung entfaltet ihren Wert nicht nur durch Pflicht. Wer DORA und NIS2 als freiwilligen Qualitätsrahmen nutzt, baut bessere Prozesse – und kann das gegenüber Kunden, Partnern und Aufsichtsbehörden sauber belegen.
Wofür stehen DORA und NIS2?
| DORA | NIS2 | |
|---|---|---|
| Vollständiger Name | Digital Operational Resilience Act | Network & Information Security Directive 2 |
| Scope | Finanzsektor: Banken, Versicherungen, ZDL, Krypto, KVGen | Sektoral breit: Energie, Gesundheit, Transport, Wasser, digitale Infrastruktur |
| Kernthemen | IKT-Risikomanagement, Drittparteimanagement, Incident Reporting, TLPT | Risikomanagement, Meldepflichten, Supply-Chain-Sicherheit, Mindestmaßnahmen |
| Gültig seit | Januar 2025 (vollständig anwendbar) | Oktober 2024 (nationale Umsetzung laufend) |
Beide Regelwerke adressieren im Kern dasselbe Ziel: digitale Resilienz. Sie tun es aus unterschiedlichen Blickwinkeln und mit unterschiedlicher Tiefe – genau das macht die Kombination interessant.
Aus DORA: Die drei wertvollsten Bausteine
1. Das IKT-Risikomanagement-Framework (Art. 6–10)
Das DORA-IKT-Risikomanagement ist eines der strukturiertesten Rahmenwerke, die ich kenne. Es definiert klare Anforderungen entlang fünf Funktionen: Identifikation, Schutz, Erkennung, Response und Recovery. DORA geht über das NIST Cybersecurity Framework hinaus: Es legt konkrete organisatorische Anforderungen fest, inklusive Governance-Verantwortung auf Vorstandsebene.
Art. 6 DORA beschreibt, was ein IKT-Risikomanagement-Framework mindestens enthalten muss. Diese Liste eignet sich hervorragend als Lückenanalyse für jede Organisation – unabhängig vom Sektor. Ein einfaches Gap-Assessment anhand dieser Anforderungen offenbart schnell, wo die eigene Governance noch unsauber ist.
2. Das Register informationspflichtiger IKT-Drittanbieter
DORA verpflichtet Finanzunternehmen dazu, alle IKT-Drittanbieter systematisch zu erfassen und zu bewerten – mit Angaben zur Kritikalität, zu vertraglichen Absicherungen und zu Ausstiegsszenarien. Die meisten Unternehmen wissen gar nicht genau, wie viele Cloud-Dienste, SaaS-Tools und externe Dienstleister sie eigentlich betreiben.
Das DORA-Drittparteiregister als Vorlage zu nutzen – auch ohne gesetzliche Pflicht – schafft erstmals Transparenz über kritische Abhängigkeiten. Und das ist in jedem Business-Continuity- oder Risikomanagement-Kontext wertvoll.
3. TLPT als Testmethodik
Threat-Led Penetration Testing (TLPT) ist kein klassischer Penetrationstest. Es geht darum, reale Angreifer-TTPs (Tactics, Techniques, Procedures) als Grundlage für Tests zu verwenden – also echte Bedrohungsszenarien statt generischer Checklisten.
Das TIBER-EU-Framework, auf dem DORA-TLPT aufbaut, ist öffentlich verfügbar. Die Methodik lässt sich adaptieren – auch für Unternehmen, die keine systemrelevanten Finanzinstitute sind.
Aus NIS2: Die drei wertvollsten Bausteine
1. Art. 21 als Security-Baseline
Artikel 21 NIS2 listet die Mindestmaßnahmen auf: Risikoanalysen, Sicherheitskonzepte, Incident-Response-Prozesse, Business-Continuity-Management, Supply-Chain-Sicherheit, Patch-Management, Multi-Faktor-Authentifizierung, Verschlüsselung – und mehr.
Wer Art. 21 NIS2 vollständig umsetzt, ist in der Informationssicherheit weiter als ein erheblicher Teil der deutschen Mittelstandsunternehmen. Das ist keine Übertreibung – es ist ein nüchternes Bild der Realität in vielen Branchen.
2. Die Meldepflicht-Logik als internes Eskalationsmodell
NIS2 schreibt ein dreistufiges Meldesystem vor: Frühwarnung innerhalb von 24 Stunden, detaillierter Bericht nach 72 Stunden, Abschlussbericht nach einem Monat. Diese Struktur ist ein exzellentes Modell für interne Eskalationsprozesse.
Viele Organisationen haben gar keine klare Vorstellung davon, wer bei einem IT-Sicherheitsvorfall wann was tun muss. Die NIS2-Meldepflicht-Logik – als internes Incident-Response-Framework adaptiert – gibt genau diese Struktur vor: schnelle Ersteinschätzung, belastbare Analyse, strukturierter Abschluss.
3. Supply-Chain-Sicherheit als Denkrahmen
NIS2 denkt Sicherheit nicht nur im eigenen Perimeter, sondern entlang der gesamten Lieferkette. Das schließt die Sicherheitspraktiken von Zulieferern, Dienstleistern und Technologiepartnern explizit ein. In einer Zeit, in der Software-Lieferketten ein primäres Angriffsziel sind (SolarWinds, XZ Utils), ist dieser Ansatz strategisch notwendig.
Das Beste aus beiden Welten
| Baustein | Quelle | Nutzen ohne Betroffenheit |
|---|---|---|
| IKT-Risikomanagement-Framework | DORA | Strukturierte Grundlage für internes Risikomanagement, besser als Eigenentwicklungen |
| IKT-Drittanbieter-Register | DORA | Transparenz über kritische Abhängigkeiten, Basis für BCM und Vendor Risk Management |
| TLPT-Methodik | DORA | Bedrohungsorientierte Penetrationstests statt generischer Checklisten |
| Art. 21 Mindestmaßnahmen | NIS2 | Kompakte, validierte Security-Baseline für jede Organisation |
| Meldepflicht-Logik (24h/72h/30d) | NIS2 | Strukturiertes Eskalations- und Incident-Response-Modell |
| Supply-Chain-Anforderungen | NIS2 | Denkrahmen für lieferkettenbezogene Risikobetrachtung |
Was das strategisch bedeutet
DORA und NIS2 sind, nüchtern betrachtet, nichts anderes als Best Practices – nur rechtlich verbindlich gemacht und damit intensiv geprüft, diskutiert und verfeinert.
Wer diese Frameworks freiwillig nutzt, signalisiert etwas: gegenüber Kunden, dass Sicherheit ernst genommen wird; gegenüber Partnern, dass man nach anerkannten Standards arbeitet; gegenüber Aufsichtsbehörden, falls man doch in den Scope gerät, dass man bereits einen reifen Ansatz verfolgt.
In Ausschreibungen, Due-Diligence-Prozessen und Partnerverhandlungen ist es zunehmend ein echtes Differenzierungsmerkmal, wenn man sagen kann: „Wir orientieren uns an DORA/NIS2-Standards – nicht weil wir müssen, sondern weil es gute Frameworks sind."
Fazit
DORA und NIS2 sind keine Bürde, die nur Betroffene tragen müssen. Sie sind öffentlich zugängliche, praxiserprobte Governance-Frameworks – und damit ein kostenloser Wissenstransfer aus Jahren regulatorischer Arbeit.
Wer sich die besten Bausteine herauspickt – das IKT-Risikomanagement aus DORA, die Security-Baseline aus NIS2, die Meldepflicht-Logik als internen Eskalationsprozess – baut eine solide, skalierbare IT-Governance auf. Ohne Eigenentwicklung. Ohne das Rad neu zu erfinden.
Regulation as a Service, sozusagen.