DORA einfach erklärt: Abkürzungen & Begriffe aus der EU-Verordnung

DORA einfach erklärt: Begriffe, Abkürzungen & Zusammenhänge
Die DORA-Verordnung (EU 2022/2554) – offiziell Digital Operational Resilience Act – ist ein Meilenstein der EU für mehr digitale Stabilität im Finanzsektor. Doch der Text ist nicht nur lang und technisch, sondern voll von Abkürzungen, englischen Fachbegriffen und juristischen Formeln.
Dieser Beitrag hilft dabei, Klarheit zu schaffen: Was bedeutet TLPT, IKT oder RPO? Wer oder was ist ENISA? Und warum ist es wichtig, das zu wissen?
Wir ordnen die Begriffe nicht nur alphabetisch, sondern stellen sie in den praktischen Kontext der DORA-Pflichten.
Warum braucht es eine Begriffserklärung?
Regulatorische Texte wie DORA verwenden bewusst klare und eindeutige Sprache – allerdings aus Sicht von Jurist:innen und Aufsichtsbehörden. Für Praktiker:innen im IT-, Risiko- oder Einkaufsbereich wirken diese Begriffe oft abstrakt.
Ein Beispiel: Der Begriff “kritischer Drittanbieter” ist in DORA exakt geregelt – die Einstufung erfolgt durch die europäischen Aufsichtsbehörden und hat rechtliche Konsequenzen. Für einen IT-Einkäufer ist jedoch die zentrale Frage: “Gilt das auch für meinen Cloud-Anbieter?”
Ziel dieser Übersicht ist es daher, nicht nur Definitionen zu liefern, sondern auch ein Gefühl für Relevanz, Bedeutung und Auswirkungen der Begriffe zu schaffen.
Wichtige Begriffe & Abkürzungen in DORA
Abkürzung | Begriff | Erklärung & Kontext |
---|---|---|
DORA | Digital Operational Resilience Act | EU-Verordnung zur digitalen Resilienz im Finanzsektor. Gilt ab 2025 verbindlich. |
IKT | Informations- und Kommunikationstechnik | Sammelbegriff für IT-Systeme, Netzwerke, Cloud, Kommunikation. |
BCP | Business Continuity Plan | Notfall- und Wiederanlaufplanung für Ausfallsszenarien. Pflicht nach DORA. |
RTO | Recovery Time Objective | Zeitspanne, in der Systeme nach Störung wiederhergestellt sein müssen. |
RPO | Recovery Point Objective | Maximal tolerierter Datenverlust (zeitlich) im Wiederanlauf. |
TLPT | Threat-led Penetration Testing | Angriffssimulation unter Aufsicht, z. B. durch externe Red Teams. Pflicht für manche DORA-Unternehmen. |
ESA | European Supervisory Authorities | Gemeinsamer Begriff für EBA, EIOPA und ESMA. |
EBA | European Banking Authority | Aufsichtsbehörde für Banken und Kreditinstitute in der EU. |
EIOPA | Insurance and Occupational Pensions Authority | EU-Aufsicht für Versicherungen und Pensionsfonds. |
ESMA | European Securities and Markets Authority | Zuständig für Kapitalmärkte und Wertpapierhandel. |
ENISA | European Union Agency for Cybersecurity | Unterstützt mit Lagebildern, Analysen, Methodik. Keine Aufsichtsrolle. |
CSIRT | Computer Security Incident Response Team | Reagiert auf Sicherheitsvorfälle, organisiert Meldung und technische Eindämmung. |
TIBER-EU | Threat Intelligence-Based Ethical Red Teaming | EU-Rahmen für koordinierte TLPT-Tests unter Aufsicht. |
NIS2 | Network and Information Security Directive 2 | Neue Cybersicherheitsrichtlinie für KRITIS & Betreiber wesentlicher Dienste. |
GDPR / DSGVO | Datenschutz-Grundverordnung | Relevanz: Datenvorfälle können Meldepflichten nach DSGVO und DORA gleichzeitig auslösen. |
SLA | Service Level Agreement | Leistungsvereinbarung mit Dienstleistern, z. B. zu Verfügbarkeit und Meldedauer. |
KPI | Key Performance Indicator | Messgröße für IT-Resilienz, z. B. MTTD oder MTTR. |
Begriffe mit besonderem Risiko- oder Vertragsbezug
Manche Begriffe haben unmittelbare Auswirkungen auf Vertragsgestaltung und Pflichten:
-
Auditrecht: Muss explizit in Verträgen mit IT-Dienstleistern geregelt sein. Aufsichtsbehörden dürfen sonst nicht prüfen.
-
Exit-Strategie: Pflicht für Finanzunternehmen, jederzeit aus kritischer IT-Dienstleistung auszusteigen. Technisch und vertraglich.
-
Meldeschwelle: Wann muss ein Vorfall überhaupt gemeldet werden? Die Kriterien sind komplex – und müssen im Unternehmen bekannt sein.
-
Systemrelevanz: Wer als „systemrelevant“ eingestuft wird, muss z. B. TLPT durchführen und besondere Meldepflichten erfüllen.
Anwendung in der Praxis – einige typische Szenarien
Ein Cloud-Anbieter hostet die Kundendaten eines Versicherers:
- Wenn der Anbieter in mehreren EU-Ländern tätig ist und kritische Funktionen übernimmt, kann er von den ESAs als kritisch eingestuft werden. Folge: Auditrecht, Exit-Szenario, eigene Prüfpflichten.
Ein Zahlungsdienstleister nutzt eine Plattform für seine App:
- DORA verlangt, dass auch technische Ketten betrachtet werden. Nicht nur direkte Verträge sind relevant, sondern auch Subdienstleister („Fourth Parties“).
Eine Bank meldet einen IT-Vorfall:
- Der Vorfall muss innerhalb von 4 Stunden an die Aufsicht gemeldet werden – auch wenn Ursache, Umfang oder Dauer noch unklar sind.
Wie oft kommen diese Begriffe in der Praxis vor?
Im Alltag vieler Organisationen kommen die Begriffe häufig vor – aber oft nicht in der DORA-spezifischen Bedeutung. Deshalb ist es wichtig, diese Begrifflichkeiten kontextsensibel zu betrachten:
Begriff | Umgangssprachlich bekannt? | In DORA besonders definiert? |
---|---|---|
Incident | Ja | Ja |
Audit | Ja | Ja (mit konkreten Pflichten) |
Service Level | Ja | Ja (konkret im Vertrag gefordert) |
Red Teaming | Eher nicht | Ja |
RTO / RPO | Nur bei IT / BCM | Ja (Pflichtdokumentation) |
Fazit: Klarheit schafft Resilienz
DORA bringt viele bekannte Begriffe in einen neuen Zusammenhang – und macht sie verbindlich. Wer die Akronyme versteht, versteht auch die dahinterliegenden Prozesse und Pflichten.
Für Unternehmen lohnt es sich, eine eigene „DORA-Terminologie“ aufzubauen – als Glossar, als Teil der Schulung, oder eingebettet in ITSM-Tools. Denn letztlich hängt erfolgreiche Resilienzarbeit nicht nur von Technologie oder Budget ab, sondern vor allem von gemeinsamer Sprache und Verantwortlichkeit.
Quellen & weiterführende Links
- Verordnung (EU) 2022/2554 – EUR-Lex
- ENISA – EU-Agentur für Cybersicherheit
- TIBER-EU Framework – EZB
- EBA – Europäische Bankenaufsicht
Du willst deinen DORA-Fahrplan erstellen oder bist selbst IT-Dienstleister? Dann melde dich – ich helfe gerne weiter.