AIGN OS – DORA Readiness Assessment

🏛️

SEKTION 01 / 08

Betroffenheit, Scope & Proportionalität

Geltungsbereich, Einordnung als Finanzunternehmen und Proportionalitätslogik nach Art. 2–4 DORA

0 / 6

▾

ℹDORA ist ein sektorspezifischer Unionsrechtsakt für den Finanzsektor. Entscheidend ist zunächst, ob das Unternehmen im Geltungsbereich liegt, ob Erleichterungen oder ein vereinfachter IKT-Risikomanagementrahmen greifen und ob die Proportionalität sauber dokumentiert ist.

Scope & Anwendbarkeit

Unser Unternehmen wurde belastbar einem DORA-erfassten Typ von Finanzunternehmen zugeordnet.

→ Art. 2 DORA

+5

Ausnahmen, Schwellenwerte und vereinfachte Regime wurden rechtlich geprüft und dokumentiert.

→ Art. 2 Abs. 3–4, Art. 16 DORA

+5

Die Organisation kann begründen, wie sie den Proportionalitätsgrundsatz auf Größe, Risikoprofil und Komplexität anwendet.

→ Art. 4 DORA

+4

Gruppenstruktur, wesentliche Niederlassungen und relevante kritische Funktionen sind dokumentiert.

+4

Die Rolle von IKT-Drittdienstleistern im eigenen Operating Model wurde frühzeitig im Scope berücksichtigt.

+3

Eine verantwortliche Funktion überwacht fortlaufend die DORA-Betroffenheit und regulatorische Änderungen.

+3

🧭

SEKTION 02 / 08

Governance & Leitungsorgan

Aktive Verantwortung des Leitungsorgans nach Art. 5 DORA

0 / 6

▾

⚠DORA ist kein reines IT-Thema. Das Leitungsorgan definiert, genehmigt, überwacht und verantwortet die Umsetzung der Vorkehrungen. Genau hier entsteht realer Board-Level-Druck.

Management Accountability

Das Leitungsorgan hat den DORA-Rahmen und die wesentlichen IKT-Risikomaßnahmen formal gebilligt.

→ Art. 5 Abs. 2 DORA

+6

Die Umsetzung wird auf Management-Ebene überwacht und in einem belastbaren Reporting-Mechanismus gespiegelt.

+5

Aufgaben und Verantwortlichkeiten zwischen Leitungsorgan, IKT, Security, Compliance, Risk und Operations sind klar geregelt.

+4

Mitglieder des Leitungsorgans halten IKT-/Cyber-bezogene Kenntnisse aktiv aktuell und können diese belegen.

→ Art. 5 Abs. 4 DORA

+4

Budget, Strategie für digitale operationale Resilienz und wesentliche Eskalationspfade sind formal freigegeben.

→ Art. 5 Abs. 2 d/g DORA

+4

IKT-Drittparteienverträge und daraus resultierende Risikoexposition werden auf Management-Ebene nachvollziehbar gespiegelt.

→ Art. 5 Abs. 2 h/i DORA

+3

🛡️

SEKTION 03 / 08

IKT-Risikomanagementrahmen

Vollständiges Framework für Identifizierung, Schutz, Erkennung, Reaktion und Lernen

0 / 10

▾

🔐DORA verlangt kein loses Set an Einzelmaßnahmen, sondern einen soliden, umfassenden und dokumentierten IKT-Risikomanagementrahmen als Teil des Gesamtrisikomanagementsystems.

IKT Risk Framework

Ein dokumentierter IKT-Risikomanagementrahmen ist implementiert und Teil des Gesamtrisikomanagementsystems.

→ Art. 6 Abs. 1 DORA

+5

IKT-Assets, Informationsassets, kritische Funktionen und Abhängigkeiten werden identifiziert, klassifiziert und inventarisiert.

→ Art. 8 DORA

+5

Schutzmaßnahmen für Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten sind technisch und organisatorisch belastbar umgesetzt.

→ Art. 9 DORA

+5

Mechanismen zur Erkennung anomaler Aktivitäten, Schwachstellen und IKT-bezogener Vorfälle sind operativ etabliert.

→ Art. 10 DORA

+5

Business-Continuity-, Reaktions-, Wiederherstellungs- und Backup-Logiken sind dokumentiert, getestet und evidenzfähig.

→ Art. 11–12 DORA

+4

Lernprozesse, Incident-Reviews und Verbesserungsmaßnahmen fließen systematisch in das IKT-Risikomanagement zurück.

→ Art. 13 DORA

+4

Kommunikationsstrategien für IKT-bezogene Vorfälle gegenüber internen und externen Stakeholdern sind vorbereitet.

→ Art. 14 DORA

+3

Policies für Zugriff, Authentifizierung, Kryptografie, Änderungen, Patches und Härtung sind konsistent und nachweisbar.

→ Art. 9 Abs. 4 DORA

+4

Der Rahmen wird mindestens jährlich oder anlassbezogen überprüft und die Ergebnisse können der Aufsicht vorgelegt werden.

→ Art. 6 Abs. 5 DORA

+4

Interne Revision oder unabhängige Prüfungslogik adressiert das IKT-Risikomanagement regelhaft.

→ Art. 6 Abs. 6–7 DORA

+4

🚨

SEKTION 04 / 08

IKT-Vorfälle, Klassifizierung & Meldung

Incident-Prozess, Klassifizierung und Reporting unter DORA

0 / 6

▾

⚠DORA verlangt einen strukturierten Incident-Prozess. Kritisch ist nicht nur die Meldung selbst, sondern die Fähigkeit, schwerwiegende IKT-Vorfälle schnell korrekt zu klassifizieren, intern zu eskalieren und gegenüber zuständigen Behörden belastbar zu kommunizieren.

Incident Reporting

Ein definierter Prozess zur Behandlung IKT-bezogener Vorfälle ist eingerichtet und operativ nutzbar.

→ Art. 17 DORA

+5

Kriterien zur Klassifizierung schwerwiegender IKT-bezogener Vorfälle und erheblicher Cyberbedrohungen sind dokumentiert.

→ Art. 18 DORA

+5

Erstmeldung, Zwischenmeldung und Abschlussmeldung können fristgerecht und in standardisierter Form erstellt werden.

→ Art. 19–20 DORA

+4

Kunden und relevante Stakeholder können bei schwerwiegenden Vorfällen rechtzeitig informiert werden.

→ Art. 19 Abs. 3 DORA

+4

Meldeprozesse sind mit zuständiger Behörde, interner Eskalation und Incident-Kommunikation abgestimmt.

+4

RTS/ITS zu Klassifizierung, Inhalten, Fristen und Vorlagen wurden praktisch in die Operating Models übersetzt.

+3

🧪

SEKTION 05 / 08

Testing & digitale operationale Resilienz

Regelmäßige Tests, Programme und gegebenenfalls TLPT

0 / 7

▾

📅DORA verlangt regelmäßige Tests der digitalen operationalen Resilienz. Für bestimmte Institute kann dies bis hin zu bedrohungsorientierten Penetrationstests (TLPT) reichen. Entscheidend ist die praktische Verteidigungsfähigkeit, nicht nur das Vorhandensein von Policies.

Testing & TLPT

Ein strukturiertes Testprogramm für IKT-Systeme, Kontrollen und Prozesse ist etabliert.

→ Art. 24–25 DORA

+5

Business-Continuity- und Wiederherstellungspläne werden regelmäßig getestet und ausgewertet.

→ Art. 11 Abs. 6 DORA

+5

Es ist bewertet und dokumentiert, ob das Unternehmen in den Anwendungsbereich für fortgeschrittene Tests oder TLPT fällt.

→ Art. 26 DORA

+5

Testergebnisse führen nachvollziehbar zu Maßnahmen, Verbesserungen und Management-Entscheidungen.

+4

Externe Provider und kritische Dienstleister werden in relevante Test- und Notfallszenarien einbezogen.

+4

Die Organisation kann gegenüber Aufsicht oder Audit die Teststrategie, Frequenz und Nachverfolgung verteidigen.

+4

Die TLPT-RTS oder gleichwertige fortgeschrittene Testanforderungen werden im Zielbild bereits konkret mitgedacht.

+3

🔗

SEKTION 06 / 08

IKT-Drittparteienrisiko & Register

Verträge, Register, Konzentrationsrisiken und Exit-Fähigkeit

0 / 6

▾

🧾DORA macht deutlich: Viele Organisationen scheitern nicht an internen Controls, sondern an schwacher Drittparteiensteuerung, fehlender Registerqualität, mangelhaften Verträgen und nicht verteidigbaren Konzentrationsrisiken.

Third Party Risk

Ein vollständiges Informationsregister zu IKT-Drittdienstleistern und vertraglichen Vereinbarungen wird geführt.

→ Art. 28 ff. DORA

+5

Kritische oder wichtige Funktionen und zugehörige IKT-Dienstleistungen sind vertraglich und organisatorisch sauber zugeordnet.

+4

Verträge enthalten belastbare Audit-, Zugangs-, Unterstützungs-, Sicherheits- und Exit-Klauseln.

→ Art. 30 DORA

+4

Unterauftragsketten, Konzentrationsrisiken und kritische Provider-Abhängigkeiten sind bewertet.

+4

Eine Exit- oder Übergangsstrategie für kritische IKT-Drittdienstleistungen ist dokumentiert und realistisch umsetzbar.

+4

Die Organisation kann Third-Party-Risiko gegenüber Aufsicht, Audit und Management in Evidenzform belegen.

+3

📋

SEKTION 07 / 08

Dokumentation, Evidenz & Auditfähigkeit

Nachweisstruktur für Management, Aufsicht und Prüfungen

0 / 6

▾

⚠Unter DORA zählt nicht nur, dass etwas existiert. Entscheidend ist, ob Scope, Governance, Incident-Logik, Testing, Drittparteiensteuerung und Management-Entscheidungen unter Prüfung tatsächlich nachweisbar und verteidigbar sind.

Evidence Readiness

Policies, Freigaben, Reports, Reviews und Nachweise sind in auditierbarer Form abgelegt.

+5

Entscheidungen des Leitungsorgans zu IKT-Risiken, Budgets und Resilienzmaßnahmen sind nachvollziehbar protokolliert.

+4

Die Organisation kann der Aufsicht vollständige und aktuelle Informationen über IKT-Risiken und Rahmenwerke vorlegen.

→ Art. 6 Abs. 3/5 DORA

+4

Ein formalisiertes Follow-up für Findings aus Revision, Testing oder Vorfällen ist implementiert.

→ Art. 6 Abs. 7 DORA

+4

IKT-, Risk-, Compliance- und Rechtsfunktionen arbeiten in einem abgestimmten DORA-Governance-Modell zusammen.

+4

Die Organisation ist auf Audit, Management-Review oder aufsichtsrechtliche Anfragen kurzfristig vorbereitet.

+3

🛰️

SEKTION 08 / 08

Cross-Regulation Dependencies

DORA selten isoliert: Schnittstellen zu NIS2, EU AI Act und Data Act

0 / 5

▾

👁DORA ist für Finanzunternehmen oft der operative Einstieg. In der Praxis entstehen aber schnell weitere Abhängigkeiten: NIS2 bei übergreifender Cyber-/Kritikalitätslogik, EU AI Act bei KI-gestützten Entscheidungen und Data Act bei Cloud-, Portabilitäts- oder Lock-in-Themen.

Strategische Anschlussfähigkeit

Es ist bewertet, ob neben DORA zusätzliche NIS2-relevante Cyber- oder Kritikalitätsfragen bestehen.

+3

Der Einsatz von KI in kritischen Finanzprozessen wurde mit Blick auf den EU AI Act bewertet.

+4

Cloud-, Portabilitäts- und Datenzugangsthemen werden auch im Lichte des Data Act mitgedacht.

+3

DORA wird nicht isoliert, sondern als Teil eines Governance-Systems verstanden.

+3

Die Organisation trennt sauber zwischen DORA-Kernpflichten und ergänzenden regulatorischen Anschlusspflichten.

+2