DORA Umsetzung

DORA-Sollmaßnahmenkatalog

Ein strukturierter Maßnahmenkatalog für Finanzinstitute: governancefähig, auditierbar und auf ISO/IEC 27001:2022 ausgerichtet.

Management-Zusammenfassung

103 priorisierte Sollmaßnahmen bilden einen umsetzbaren DORA-Kernkatalog für Finanzinstitute.
16 Themenbereiche verbinden Governance, Risikomanagement, Vorfallmanagement, Resilienztests, Drittparteien und weitere regulatorische Schwerpunkte.
ISO-Anker ermöglichen konsistentes Mapping in bestehende ISMS-Strukturen und reduzieren doppelte Dokumentation.
Jede Maßnahme enthält Sollzustand, Umsetzungsschritte und Evidenzbeispiele für auditierbare Nachweise.

Maßnahmen

103

Themenfelder

ISO-Anchor

Review-Status

reviewed

CSV JSON

initial 29 defined 48 implemented 1 managed 25

Filter

Themenbereich

103 Maßnahmen angezeigt

DORA-GOV-001 reviewed defined

Leitungsorgan verankert Resilienzstrategie im Jahreszielprozess

Resilienzprioritäten werden vom Leitungsorgan gesteuert und budgetwirksam beschlossen.

Themenbereich: Governance & Verantwortung
Sollzustand: Strategie, Risikoappetit und Umsetzungsziele sind pro Jahr formal freigegeben und nachverfolgbar.
DORA / MaRisk: DORA Kapitel II (Governance) | MaRisk AT 4.3.1

Umsetzungsschritte

Resilienzstrategie als festen Tagesordnungspunkt im Leitungsorgan verankern.
Jahresziele mit Risikoindikatoren und Budgetpositionen verknüpfen.
Quartalsweise Zielerreichung inklusive Abweichungsbehandlung berichten.

Beispielnachweise

Beschlussprotokoll des Leitungsorgans mit Zielkatalog.
Budgetfreigabe mit Zuordnung zu Resilienzinitiativen.

ISO/IEC 27001 Anker

A.5.1 A.5.4 A.5.36

ID: DORA-GOV-001

DORA-GOV-002 reviewed managed

Rollenmodell für Three-Lines-Resilienzsteuerung

Verantwortlichkeiten für Umsetzung, Überwachung und Prüfung sind eindeutig abgegrenzt.

Themenbereich: Governance & Verantwortung
Sollzustand: Ein verbindliches Rollenmodell definiert Aufgaben, Eskalationsrechte und Stellvertretung.
DORA / MaRisk: DORA Kapitel II (Interne Organisation) | MaRisk AT 4.4.1

Umsetzungsschritte

RACI-Matrix für Business, IT, Compliance und Revision erstellen.
Eskalationsschwellen und Entscheidungswege je Kontrollprozess festlegen.
Rollenmodell in Richtlinie und Schulung verbindlich machen.

Beispielnachweise

Freigegebene RACI-Matrix mit Versionshistorie.
Schulungsnachweise für Rolleninhaber.

ISO/IEC 27001 Anker

A.5.2 A.5.3 A.5.37

ID: DORA-GOV-002

DORA-GOV-003 reviewed managed

Management-Reporting mit Frühwarnindikatoren

Leitungsentscheidungen basieren auf konsistenten Resilienzkennzahlen und Trends.

Themenbereich: Governance & Verantwortung
Sollzustand: Monatliches Reporting mit KRI, Schwellwerten und Maßnahmenstatus ist etabliert.
DORA / MaRisk: DORA Kapitel II (Steuerungsinformationen) | MaRisk BT 3.1

Umsetzungsschritte

KRI-Katalog mit Ampellogik und Datenquellen definieren.
Datenqualitätsprüfung für Kennzahlen automatisieren.
Management-Deck mit Risiken, Ursachen und Gegenmaßnahmen standardisieren.

Beispielnachweise

Monatsreport mit KRI-Entwicklung.
Nachweis über Schwellwertverletzungen und Eskalationen.

ISO/IEC 27001 Anker

A.5.7 A.5.35 A.8.16

ID: DORA-GOV-003

DORA-GOV-004 reviewed defined

Resilienzkompetenz für Entscheidungsträger ausbauen

Entscheidungsträger verstehen operationale Risiken, Abhängigkeiten und regulatorische Wirkung.

Themenbereich: Governance & Verantwortung
Sollzustand: Kompetenzprofile und Trainingspfad für Leitungsorgan und Schlüsselrollen sind umgesetzt.
DORA / MaRisk: DORA Kapitel II (Ressourcen und Fähigkeiten) | MaRisk AT 7.1

Umsetzungsschritte

Kompetenzlueckenanalyse für relevante Rollen durchführen.
Pflichttrainings mit Fallbeispielen aus dem Institut aufsetzen.
Wirksamkeit per Wissenscheck und Entscheidungsqualitaet nachhalten.

Beispielnachweise

Trainingsplan mit Teilnahmequote.
Auswertung der Kompetenzchecks je Rolle.

ISO/IEC 27001 Anker

A.6.3 A.6.4 A.5.36

ID: DORA-GOV-004

DORA-RISK-001 reviewed defined

Institutsspezifische IKT-Risikotaxonomie etablieren

IKT-Risiken werden einheitlich erfasst und vergleichbar bewertet.

Themenbereich: IKT-Risikomanagement
Sollzustand: Taxonomie, Bewertungslogik und Risikokriterien sind konzernweit konsistent dokumentiert.
DORA / MaRisk: DORA Kapitel II (IKT-Risikomanagementrahmen) | MaRisk AT 4.3.2

Umsetzungsschritte

Risikokategorien für Verfügbarkeit, Integrität, Vertraulichkeit und Lieferketten definieren.
Einheitliche Bewertungsskala für Eintritt, Auswirkung und Restrestrisiko festlegen.
Taxonomie in Risiko-Tool und Kontrollprozesse integrieren.

Beispielnachweise

Freigegebene Risikotaxonomie mit Definitionen.
Beispielbewertung inkl. Begruendung je Kategorie.

ISO/IEC 27001 Anker

A.5.9 A.5.12 A.8.2

ID: DORA-RISK-001

DORA-RISK-002 reviewed managed

Risikobewertung für kritische Geschaeftsservices priorisieren

Steuerungsmaßnahmen orientieren sich an den kritischsten Serviceketten.

Themenbereich: IKT-Risikomanagement
Sollzustand: Jeder kritische Service besitzt dokumentiertes Risikoexposure und priorisierte Maßnahmen.
DORA / MaRisk: DORA Kapitel II (Kritische Funktionen) | MaRisk AT 7.2

Umsetzungsschritte

Kritische Services mit maximaler tolerierbarer Ausfallzeit bestimmen.
Abhängigkeiten zu Anwendungen, Daten und Providern erfassen.
Maßnahmen nach Risikoauswirkung priorisieren und terminieren.

Beispielnachweise

Servicekritikalitaetsliste mit Schwellenwerten.
Maßnahmenbacklog mit Priorität und Verantwortlichen.

ISO/IEC 27001 Anker

A.5.30 A.8.9 A.8.13

ID: DORA-RISK-002

DORA-RISK-003 reviewed managed

Kontrollüberwachung auf Wirksamkeit statt nur Vollständigkeit ausrichten

Kontrollen reduzieren reale Risiken nachweisbar im Betrieb.

Themenbereich: IKT-Risikomanagement
Sollzustand: Kontrollen sind mit Wirksamkeitsmetriken, Testfrequenz und Verbesserungszyklen versehen.
DORA / MaRisk: DORA Kapitel II (Kontrollrahmen) | MaRisk AT 4.4.2

Umsetzungsschritte

Top-Kontrollen je Risiko mit erwarteter Wirkung definieren.
Regeltest mit klaren Pass/Fail-Kriterien einführen.
Defizite in einen verbindlichen Verbesserungsprozess überfuehren.

Beispielnachweise

Kontrollkatalog mit Wirksamkeitskennzahl.
Abweichungsprotokoll mit Korrekturmaßnahmen.

ISO/IEC 27001 Anker

A.5.35 A.8.16 A.10.2

ID: DORA-RISK-003

DORA-RISK-004 reviewed defined

Risikoreviews mit Change-Management koppeln

Wesentliche Architektur- und Prozessaenderungen werden risikobasiert freigegeben.

Themenbereich: IKT-Risikomanagement
Sollzustand: Jeder High-Impact-Change beinhaltet eine aktualisierte Risikoanalyse vor Go-live.
DORA / MaRisk: DORA Kapitel II (Aenderungssteuerung) | MaRisk AT 8.2

Umsetzungsschritte

Triggerkriterien für risikorelevante Changes definieren.
Risikoprüfung als Pflichtschritt im Freigabeworkflow hinterlegen.
Post-Implementation-Review mit Soll-Ist-Abgleich durchführen.

Beispielnachweise

Change-Tickets mit Risiko-Checkliste.
Freigabeprotokolle inklusive Restrestrisiko.

ISO/IEC 27001 Anker

A.8.32 A.8.33 A.8.34

ID: DORA-RISK-004

DORA-PDR-001 reviewed defined

Schutzbedarfsgerechte Härtung kritischer Systeme

Kritische Systeme werden nach verbindlichen Sicherheitsbaselines betrieben.

Themenbereich: Schutz, Erkennung & Reaktion
Sollzustand: Baselines, Ausnahmen und Nachhaertungen sind technisch nachvollziehbar gesteuert.
DORA / MaRisk: DORA Kapitel II (Schutzmaßnahmen) | MaRisk AT 7.2

Umsetzungsschritte

Systemklassen und zugehoerige Hardening-Standards definieren.
Automatisierte Baseline-Prüfung in den Betriebsprozess integrieren.
Ausnahmen zeitlich befristen und aktiv nachverfolgen.

Beispielnachweise

Hardening-Standard pro Systemklasse.
Compliance-Report mit offenen Abweichungen.

ISO/IEC 27001 Anker

A.8.9 A.8.20 A.8.21

ID: DORA-PDR-001

DORA-PDR-002 reviewed managed

Detektion mit Use-Case-gestuetztem Monitoring verbessern

Sicherheitsrelevante Anomalien werden früh erkannt und priorisiert bearbeitet.

Themenbereich: Schutz, Erkennung & Reaktion
Sollzustand: Monitoring-Use-Cases sind risikobasiert priorisiert und mit Reaktionsfristen versehen.
DORA / MaRisk: DORA Kapitel II (Erkennungsfähigkeiten) | MaRisk BT 3.2

Umsetzungsschritte

Top-Risikoszenarien in überwachte Detection-Use-Cases überfuehren.
Alarmqualitaet über False-Positive-Rate und Erkennungszeit messen.
Use-Cases quartalsweise anhand neuer Bedrohungen aktualisieren.

Beispielnachweise

Use-Case-Backlog mit Priorisierung.
SOC-Kennzahlenreport zu MTTD und Alarmqualitaet.

ISO/IEC 27001 Anker

A.8.16 A.8.7 A.5.7

ID: DORA-PDR-002

DORA-PDR-003 reviewed managed

Reaktionsplaybooks für priorisierte Angriffspfade

Sicherheitsvorfälle werden wiederholbar und innerhalb definierter Fristen bearbeitet.

Themenbereich: Schutz, Erkennung & Reaktion
Sollzustand: Playbooks mit Rollen, Entscheidungspunkten und Kommunikationswegen sind geuebt.
DORA / MaRisk: DORA Kapitel II (Reaktionsfähigkeit) | MaRisk BT 3.2

Umsetzungsschritte

Playbooks für Ransomware, Datenabfluss und Lieferantenausfall entwickeln.
Freigabe durch Technik, Fachbereich und Kommunikation einholen.
Halbjährliche Übungen mit Lessons Learned durchführen.

Beispielnachweise

Versionierte Incident-Playbooks.
Uebungsprotokolle mit Nachverfolgung der Findings.

ISO/IEC 27001 Anker

A.5.24 A.5.26 A.5.29

ID: DORA-PDR-003

DORA-PDR-004 reviewed defined

Wiederherstellung mit priorisierten Recovery-Routen absichern

Kritische Services werden in tolerierbarer Zeit wiederhergestellt.

Themenbereich: Schutz, Erkennung & Reaktion
Sollzustand: Recovery-Routen, technische Abhängigkeiten und Wiederanlaufkriterien sind testbar dokumentiert.
DORA / MaRisk: DORA Kapitel II (Wiederherstellung) | MaRisk AT 7.3

Umsetzungsschritte

Recovery-Ziele je Service verbindlich festlegen.
Abhängigkeiten für Daten, Infrastruktur und externe Dienste dokumentieren.
Wiederherstellungstests nach priorisierten Szenarien durchführen.

Beispielnachweise

Service-Recovery-Blueprints mit RTO/RPO.
Testberichte mit Ist-Zeiten und Maßnahmenplan.

ISO/IEC 27001 Anker

A.5.30 A.8.14 A.8.13

ID: DORA-PDR-004

DORA-INC-001 reviewed defined

Klassifikation für IKT-Vorfälle mit Meldebezug

Vorfälle werden einheitlich eingestuft und regulatorisch korrekt behandelt.

Themenbereich: IKT-Vorfälle
Sollzustand: Klassifikation enthält Schweregrade, Meldefristen und Eskalationspfade.
DORA / MaRisk: DORA Kapitel III (IKT-bezogene Vorfälle) | MaRisk BT 3.2

Umsetzungsschritte

Kriterien für signifkante Vorfälle und Beinahevorfälle definieren.
Meldepflichtlogik in den Incident-Prozess integrieren.
Eskalationszeiten je Schweregrad verbindlich machen.

Beispielnachweise

Incident-Klassifikationsschema mit Entscheidungshilfe.
Historie eskalierter Vorfälle.

ISO/IEC 27001 Anker

A.5.24 A.5.25 A.5.26

ID: DORA-INC-001

DORA-INC-002 reviewed managed

Vollständige Vorfallsdokumentation über den Lebenszyklus

Entscheidungen und Maßnahmen sind für Aufsicht und Revision transparent.

Themenbereich: IKT-Vorfälle
Sollzustand: Jeder wesentliche Vorfall besitzt Timeline, Ursachenanalyse und Abschlussbewertung.
DORA / MaRisk: DORA Kapitel III (Dokumentation und Analyse) | MaRisk AT 4.4.2

Umsetzungsschritte

Pflichtfelder für Incident-Tickets definieren.
Post-Incident-Review mit Root-Cause-Methodik standardisieren.
Abschlussfreigabe an Nachweis der Gegenmaßnahmen koppeln.

Beispielnachweise

Abgeschlossene Incident-Tickets mit Vollständigkeitsscore.
Root-Cause-Reports mit Verantwortlichen.

ISO/IEC 27001 Anker

A.5.28 A.5.35 A.10.2

ID: DORA-INC-002

DORA-INC-003 reviewed managed

Aufsichtsreporting für Vorfälle fristgenau orchestrieren

Erst-, Zwischen- und Abschlussmeldungen erfolgen konsistent und termingerecht.

Themenbereich: IKT-Vorfälle
Sollzustand: Meldeprozess ist mit klaren Freigaben, Datenquellen und Vertretungen hinterlegt.
DORA / MaRisk: DORA Kapitel III (Meldepflichten) | MaRisk BT 3.2

Umsetzungsschritte

Meldekalender und Trigger für Meldephaasen definieren.
Freigabeprozess zwischen Technik, Recht und Compliance abstimmen.
Qualitätskontrolle für meldepflichtige Inhalte einführen.

Beispielnachweise

Meldeprozessdiagramm mit Rollen.
Archiv fristgerechter Meldungen.

ISO/IEC 27001 Anker

A.5.5 A.5.6 A.5.24

ID: DORA-INC-003

DORA-INC-004 reviewed defined

Vorfallschleifen in nachhaltige Verbesserungen überfuehren

Wiederkehrende Ursachen werden systematisch reduziert.

Themenbereich: IKT-Vorfälle
Sollzustand: Lessons Learned sind priorisiert, terminiert und auf Wirksamkeit geprüft.
DORA / MaRisk: DORA Kapitel III (Kontinuierliche Verbesserung) | MaRisk AT 4.4.2

Umsetzungsschritte

Vorfallcluster nach Ursache und Wirkung analysieren.
Top-Ursachen in ein institutweites Verbesserungsprogramm überfuehren.
Wirksamkeit über Trend-KPI und Revisionsfeedback messen.

Beispielnachweise

Lessons-Learned-Backlog mit Reifegradstatus.
Trendbericht wiederkehrender Ursachen.

ISO/IEC 27001 Anker

A.10.1 A.10.2 A.5.27

ID: DORA-INC-004

DORA-TST-001 reviewed defined

Risikobasierte Teststrategie für digitale Resilienz

Tests decken die kritischsten Ausfallszenarien und Angriffspfade ab.

Themenbereich: Digitale Resilienztests
Sollzustand: Mehrjahres-Testplan ist risikobasiert priorisiert und mit Governance abgestimmt.
DORA / MaRisk: DORA Kapitel IV (Testprogramm) | MaRisk AT 4.3.5

Umsetzungsschritte

Testinventar nach Szenario, Tiefe und Frequenz strukturieren.
Priorisierung anhand Kritikalität, Bedrohung und Veraenderungsdynamik durchführen.
Abweichungen und Verschiebungen mit Managementfreigabe dokumentieren.

Beispielnachweise

Freigegebener Resilienz-Testplan.
Priorisierungsmatrix mit Bewertungslogik.

ISO/IEC 27001 Anker

A.8.8 A.5.30 A.9.1

ID: DORA-TST-001

DORA-TST-002 reviewed managed

Szenariobasierte Übungen für technische und fachliche Teams

Zusammenspiel von Fachbereich, IT und Krisenorganisation wird realitätsnah validiert.

Themenbereich: Digitale Resilienztests
Sollzustand: Uebungsszenarien umfassen technische Stoerung, Lieferantenausfall und Kommunikationsdruck.
DORA / MaRisk: DORA Kapitel IV (Szenariobasierte Tests) | MaRisk AT 7.3

Umsetzungsschritte

Szenarien mit institutsspezifischen Angriffspfaden entwickeln.
Uebungsteam und Beobachterrollen verbindlich benennen.
Ergebnisse mit klaren Umsetzungsfristen nachverfolgen.

Beispielnachweise

Uebungsdrehbuch und Teilnehmerliste.
Maßnahmenprotokoll aus der Uebungsnachbereitung.

ISO/IEC 27001 Anker

A.5.29 A.5.30 A.5.24

ID: DORA-TST-002

DORA-TST-003 reviewed defined

TLPT-Vorbereitung mit klarer Scope- und Sicherheitssteuerung

Threat-Led-Tests liefern verwertbare Erkenntnisse ohne unkontrolliertes Betriebsrisiko.

Themenbereich: Digitale Resilienztests
Sollzustand: Scope, Sicherheitsgrenzen und Kommunikationskaskaden für TLPT sind abgestimmt.
DORA / MaRisk: DORA Kapitel IV (TLPT-Anforderungen) | MaRisk AT 4.3.5

Umsetzungsschritte

Kritische Assets und Testgrenzen mit Fachbereich abstimmen.
Rules of Engagement mit internen und externen Parteien fixieren.
Notfallstopp und Entscheidungswege vor Teststart verifizieren.

Beispielnachweise

TLPT-Scope-Dokument und RoE.
Freigabeprotokoll des Steuerungsgremiums.

ISO/IEC 27001 Anker

A.5.7 A.8.20 A.8.31

ID: DORA-TST-003

DORA-TST-004 reviewed managed

Testbefunde in Architektur- und Prozessverbesserung überfuehren

Testresultate fuehren messbar zu robusteren Kontrollen und Betriebsablaeufen.

Themenbereich: Digitale Resilienztests
Sollzustand: Findings sind priorisiert, budgetiert und bis Wirksamkeitsnachweis geschlossen.
DORA / MaRisk: DORA Kapitel IV (Folgemaßnahmen) | MaRisk AT 4.4.2

Umsetzungsschritte

Findings nach Kritikalität, Aufwand und Risikoabbau priorisieren.
Maßnahmen in Portfolio- und Budgetsteuerung übernehmen.
Retests für kritische Findings verbindlich terminieren.

Beispielnachweise

Finding-Register mit Status und Fristen.
Retest-Berichte mit Closure-Entscheid.

ISO/IEC 27001 Anker

A.10.1 A.10.2 A.5.35

ID: DORA-TST-004

DORA-TPR-001 reviewed defined

Drittparteieninventar für kritische Services konsolidieren

Alle wesentlichen Dienstleister und Abhängigkeiten sind transparent erfasst.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Zentrales Inventar mit Kritikalität, Servicebezug und Verantwortlichen ist aktuell.
DORA / MaRisk: DORA Kapitel V (IKT-Drittparteienrisiko) | MaRisk AT 9

Umsetzungsschritte

Dienstleisterdaten aus Einkauf, IT und Fachbereich zusammenfuehren.
Kritikalitätsmodell für Servicebeitrag und Substituierbarkeit anwenden.
Pflegeprozess mit Fristen und Kontrollpunkten etablieren.

Beispielnachweise

Drittparteieninventar mit Aktualisierungsdatum.
Qualitätsreport zur Datenvollständigkeit.

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.23

ID: DORA-TPR-001

DORA-TPR-002 reviewed managed

Risikobasierte Due Diligence vor Beauftragung verbindlich machen

Nur Anbieter mit tragfähigem Sicherheits- und Betriebsmodell werden beauftragt.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Due-Diligence-Prüfung deckt Sicherheit, Betrieb, Exit und Konzentrationsrisiko ab.
DORA / MaRisk: DORA Kapitel V (Vorausgehende Bewertung) | MaRisk AT 9 Tz. 2

Umsetzungsschritte

Prüfbausteine je Kritikalitätsstufe definieren.
Mindestanforderungen für Sicherheitsnachweise festlegen.
Freigabeentscheidung mit dokumentiertem Restrestrisiko treffen.

Beispielnachweise

Due-Diligence-Checklisten mit Bewertungsresultat.
Freigabevermerk inkl. Risikoauflagen.

ISO/IEC 27001 Anker

A.5.21 A.5.22 A.5.36

ID: DORA-TPR-002

DORA-TPR-003 reviewed managed

Vertragsklauseln für Resilienz und Auditierbarkeit standardisieren

Verträge sichern notwendige Informations-, Prüf- und Interventionsrechte ab.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Standardklauseln zu Meldepflicht, Testing, Suboutsourcing und Exit sind verpflichtend.
DORA / MaRisk: DORA Kapitel V (Vertragliche Anforderungen) | MaRisk AT 9 Tz. 7

Umsetzungsschritte

Musterklauseln mit Recht, Einkauf und IT abstimmen.
Klausel-Compliance im Vertragsprozess technisch prüfbar machen.
Abweichungen nur mit dokumentierter Genehmigung zulassen.

Beispielnachweise

Vertragsbausteinkatalog mit Pflichtklauseln.
Abweichungsregister mit Freigabestatus.

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.31

ID: DORA-TPR-003

DORA-TPR-004 reviewed defined

Laufendes Dienstleistermonitoring und Exit-Readiness etablieren

Leistungsabfall und Risiken bei kritischen Providern werden früh erkannt und beherrscht.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Monitoring-KPI, Review-Zyklen und Exit-Plan sind je kritischem Provider aktiv.
DORA / MaRisk: DORA Kapitel V (Laufende Überwachung) | MaRisk AT 9 Tz. 8

Umsetzungsschritte

KPI-Set für Verfügbarkeit, Sicherheit und Eskalationen festlegen.
Quartalsreviews mit Provider und internen Stakeholdern durchführen.
Exit- und Substitutionsszenarien regelmäßig prüfen.

Beispielnachweise

Provider-Scorecards mit Trendanalyse.
Exit-Playbook mit Testhistorie.

ISO/IEC 27001 Anker

A.5.23 A.5.30 A.8.14

ID: DORA-TPR-004

DORA-REG-001 reviewed defined

Informationsregister-Datenmodell für Aufsichtsanfragen harmonisieren

Aufsichtsrelevante Informationen koennen konsistent und schnell bereitgestellt werden.

Themenbereich: Informationsregister
Sollzustand: Registerdaten folgen einem einheitlichen Datenmodell mit klaren Eigentuemern.
DORA / MaRisk: DORA Kapitel V (Informationsregister) | MaRisk AT 9 Tz. 6

Umsetzungsschritte

Pflichtdatenfelder und Datenherkunft je Registerobjekt definieren.
Datenverantwortliche in Fachbereichen verbindlich benennen.
Abgleichregeln zwischen Quellsystemen und Register etablieren.

Beispielnachweise

Datenmodell mit Felddefinitionen.
Owner-Liste für Registerobjekte.

ISO/IEC 27001 Anker

A.5.9 A.5.36 A.8.12

ID: DORA-REG-001

DORA-REG-002 reviewed managed

Register-Aktualisierung an Beschaffungs- und Change-Prozesse koppeln

Neuerungen bei Services und Providern werden ohne Zeitverzug im Register sichtbar.

Themenbereich: Informationsregister
Sollzustand: Events aus Einkauf und Change Management triggern automatische Registerprüfungen.
DORA / MaRisk: DORA Kapitel V (Datenaktualitaet) | MaRisk AT 9

Umsetzungsschritte

Prozessereignisse mit Register-Update-Pflichten verknüpfen.
Pflichtkontrolle vor Vertragsfreigabe und Produktivsetzung einführen.
SLA für Registeraktualisierung und Eskalation definieren.

Beispielnachweise

Workflow-Regelwerk für Update-Trigger.
SLA-Report zur Aktualisierungsfrist.

ISO/IEC 27001 Anker

A.8.32 A.8.33 A.5.37

ID: DORA-REG-002

DORA-REG-003 reviewed managed

Datenqualität des Registers messbar steuern

Registereintraege sind vollständig, korrekt und prüfbar.

Themenbereich: Informationsregister
Sollzustand: Qualitätskennzahlen und Korrekturprozess für Registerdaten sind etabliert.
DORA / MaRisk: DORA Kapitel V (Registerintegrität) | MaRisk AT 4.4.2

Umsetzungsschritte

Qualitätskriterien für Vollständigkeit, Konsistenz und Plausibilität festlegen.
Regelmaessige Datenqualitätsjobs mit Fehlerklassifikation einführen.
Abweichungen mit Fristen an Datenowner zurückspielen.

Beispielnachweise

Datenqualitätsdashboard für Registerobjekte.
Fehler- und Korrekturprotokoll.

ISO/IEC 27001 Anker

A.8.15 A.8.16 A.5.35

ID: DORA-REG-003

DORA-REG-004 reviewed defined

Aufsichtsfähige Register-Exports standardisieren

Anfragen der Aufsicht koennen fristgerecht in gefordertem Format beantwortet werden.

Themenbereich: Informationsregister
Sollzustand: Exportlogik, Freigabeprozess und Archivierung sind formal definiert.
DORA / MaRisk: DORA Kapitel V (Aufsichtskommunikation) | MaRisk AT 4.4.3

Umsetzungsschritte

Standardexporte für wiederkehrende Aufsichtsanfragen bereitstellen.
Freigabe- und Vier-Augen-Prinzip vor Versand implementieren.
Versand- und Inhaltsnachweise revisionssicher archivieren.

Beispielnachweise

Exportvorlagen mit Feldmapping.
Archivierte Auskunftsfaelle mit Freigabevermerk.

ISO/IEC 27001 Anker

A.5.31 A.5.33 A.5.34

ID: DORA-REG-004

DORA-EVD-001 reviewed defined

Nachweisarchitektur für Kontrollen und Entscheidungen aufbauen

Kontrollwirkung und Managemententscheidungen sind jederzeit belegbar.

Themenbereich: Nachweise & Auditfähigkeit
Sollzustand: Nachweise folgen einem einheitlichen Klassifikations- und Ablageschema.
DORA / MaRisk: DORA querschnittlich (Dokumentation und Nachweise) | MaRisk AT 4.4.2

Umsetzungsschritte

Nachweiskategorien für Kontrollen, Tests, Vorfälle und Freigaben definieren.
Ablageorte mit Zugriffsschutz und Aufbewahrungsfristen standardisieren.
Verlinkung zwischen Nachweis und zugrunde liegendem Prozess sicherstellen.

Beispielnachweise

Nachweiskatalog mit Klassifikationsregeln.
Ablagestruktur mit Berechtigungsmatrix.

ISO/IEC 27001 Anker

A.5.33 A.5.34 A.5.35

ID: DORA-EVD-001

DORA-EVD-002 reviewed managed

Prüfpfad für zentrale Resilienzentscheidungen etablieren

Prüfer koennen den Entscheidungsweg von Risiko bis Massnahme eindeutig nachvollziehen.

Themenbereich: Nachweise & Auditfähigkeit
Sollzustand: Entscheidungsprotokolle enthalten Kontext, Optionen, Beschluss und Umsetzungsergebnis.
DORA / MaRisk: DORA querschnittlich (Governance-Nachweis) | MaRisk AT 4.4.3

Umsetzungsschritte

Standardtemplate für Entscheidungsprotokolle definieren.
Verknuepfung zu Risiko, Kontrolltest und Budgetmassnahme herstellen.
Regelmaessige Stichprobenprüfung auf Nachvollziehbarkeit durchführen.

Beispielnachweise

Entscheidungsprotokolle mit Referenzobjekten.
Stichprobenbericht der Quality Assurance.

ISO/IEC 27001 Anker

A.5.37 A.9.2 A.9.3

ID: DORA-EVD-002

DORA-EVD-003 reviewed managed

Readiness-Checks für interne und externe Audits betreiben

Auditanfragen koennen fristgerecht mit validen Belegen beantwortet werden.

Themenbereich: Nachweise & Auditfähigkeit
Sollzustand: Vorbereitete Kontrollpakete und Ansprechpartner sind für Top-Themen gepflegt.
DORA / MaRisk: DORA querschnittlich (Prüffestigkeit) | MaRisk AT 4.4.2

Umsetzungsschritte

Auditrelevante Themenfelder in standardisierte Evidence-Pakete überfuehren.
Verantwortliche für jedes Paket und Vertretungen benennen.
Halbjährliche Readiness-Checks mit Gap-Liste durchführen.

Beispielnachweise

Evidence-Pakete pro Themenfeld.
Readiness-Protokoll mit Maßnahmenfortschritt.

ISO/IEC 27001 Anker

A.9.1 A.9.2 A.10.1

ID: DORA-EVD-003

DORA-EVD-004 reviewed defined

Review-Zyklus für Richtlinien und Nachweise institutionalieren

Dokumentation bleibt aktuell und spiegelt den realen Steuerungszustand.

Themenbereich: Nachweise & Auditfähigkeit
Sollzustand: Richtlinien und Nachweise werden nach festen Zyklen geprüft und freigegeben.
DORA / MaRisk: DORA querschnittlich (Dokumentensteuerung) | MaRisk AT 4.3.1

Umsetzungsschritte

Reviewkalender für alle kernrelevanten Dokumente aufsetzen.
Änderungen mit Impact-Bewertung und Freigabeprozess koppeln.
Überfaellige Reviews automatisiert eskalieren.

Beispielnachweise

Reviewkalender mit Status je Dokument.
Aenderungsnachweise mit Freigabekette.

ISO/IEC 27001 Anker

A.5.1 A.5.35 A.5.36

ID: DORA-EVD-004

DORA-TPR-005 reviewed managed

CTPP-Konzentrationsrisiken mit Szenarioanalysen steuern

Abhängigkeiten von kritischen IKT-Dienstleistern werden früh erkannt und aktiv reduziert.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Konzentrationskennzahlen und Exit-Szenarien für CTPP-relevante Services sind etabliert und managementwirksam berichtet.
DORA / MaRisk: DORA Kapitel V (IKT-Drittparteienrisiko, CTPP-Oversight) | MaRisk AT 9, BT 3.3

Umsetzungsschritte

Konzentrationsmetriken je Provider, Servicefamilie und Kritikalität definieren.
Szenarioanalysen für Provider-Ausfall und Leistungseinschraenkung halbjährlich durchführen.
Maßnahmenplan für Diversifizierung, Architekturhaertung und Exit-Readiness priorisieren.

Beispielnachweise

Konzentrationsreport mit Schwellenwerten und Trendanalyse.
Szenario- und Maßnahmenprotokolle für CTPP-Ausfaelle.

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.30 A.8.13

ID: DORA-TPR-005

DORA-TST-005 reviewed defined

Testprogramm mit Recovery- und Kommunikationszielen koppeln

Resilienztests prüfen nicht nur Technik, sondern auch Wiederherstellung, Eskalation und externe Kommunikation.

Themenbereich: Resilienztests
Sollzustand: Das Testprogramm enthält pro Szenario technische, organisatorische und kommunikative Erfolgskriterien mit Management-Abnahme.
DORA / MaRisk: DORA Kapitel IV (Digitale operationale Resilienztests) | MaRisk AT 7.3, BT 3.2

Umsetzungsschritte

Szenario-Templates mit RTO/RPO-, Entscheidungs- und Kommunikationskriterien erweitern.
Testdurchführung mit Business, IT, Compliance und Kommunikation gemeinsam planen.
Findings mit Fristen und Wirksamkeitsnachtest in den Verbesserungszyklus überfuehren.

Beispielnachweise

Testkatalog mit kombinierten Erfolgsmetriken.
Abnahmeprotokolle und Nachtest-Nachweise zu kritischen Findings.

ISO/IEC 27001 Anker

A.5.24 A.5.29 A.5.30 A.8.34

ID: DORA-TST-005

DORA-EXT-001 needs_review defined

Exit-Strategie und Ausstiegsplanung nach DORA Art. 28

Die Exit-Fähigkeit für kritische Dienstleister ist jederzeit nachweisbar und operativ umsetzbar.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Für jeden kritischen IKT-Dienstleister existiert ein dokumentierter und getesteter Exit-Plan, der Szenarien, Verantwortlichkeiten, Datenportabilität und Zeitpläne umfasst.
DORA / MaRisk: DORA Artikel 28 (IKT-Drittparteienrisikomanagement) | MaRisk AT 9, EBA/GL/2019/02

Umsetzungsschritte

Inventarisierung aller kritischen Dienstleister und Bewertung der Exit-Relevanz.
Erstellung von Exit-Plänen je Dienstleister mit Szenarien, Datenportabilität und Migrationspfaden.
Regelmäßige Tests der Exit-Pläne durch Dry-Runs und Simulationen.
Dokumentation der Testergebnisse und Nachbesserung identifizierter Lücken.
Berichterstattung an das Leitungsorgan über Exit-Readiness und offene Risiken.

Beispielnachweise

Exit-Plan-Dokumentation je kritischem Dienstleister
Dry-Run-Protokolle und Testergebnisse
Nachweis der Datenportabilität und Integritätstests
Board-Beschlüsse zu Exit-Entscheidungen

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.30 A.8.14

ID: DORA-EXT-001

DORA-EXT-002 needs_review defined

Datenportabilität und Vendor-Lock-in-Prävention

Vendor-Lock-in-Risiken werden frühzeitig erkannt und durch vertragliche und technische Maßnahmen minimiert.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Datenportabilitätsanforderungen sind vertraglich vereinbart, technisch umsetzbar und regelmäßig getestet.
DORA / MaRisk: DORA Artikel 28 (Datenportabilität und Exit), DSGVO Art. 20 | MaRisk AT 9, EBA/GL/2019/02

Umsetzungsschritte

Analyse von Vendor-Lock-in-Risiken je kritischem Dienstleister.
Vertragliche Sicherstellung von Datenexport, Standardschnittstellen und Übergabefristen.
Technische Prüfung der Datenportabilität inklusive Formate, Volumen und Integrität.
Regelmäßige Tests des Datenexports und der Datenübernahme durch Zielsysteme.

Beispielnachweise

Vendor-Lock-in-Risikoanalyse je Dienstleister
Vertragsklauseln zu Datenportabilität und Exit
Datenexport-Testprotokolle
Datenintegritätsnachweise

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.21 A.5.31

ID: DORA-EXT-002

DORA-TPR-001 reviewed implemented

IKT-Dienstleisterinventar aufbauen und aktuell halten

Das Institut kann alle relevanten IKT-Drittdienstleistungen, Dienstleister, Verträge und zugehörigen Verantwortlichkeiten vollständig und aktuell nachvollziehen.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Ein zentrales IKT-Dienstleisterinventar verbindet Dienstleister, Verträge, IKT-Dienstleistungen, interne Verantwortliche, betroffene Funktionen, Kritikalität, Risikobewertung und Registerrelevanz. Das Inventar wird regelmässig überprüft und mit Vertrags-, Auslagerungs- und Informationsregisterdaten abgeglichen.
DORA / MaRisk: DORA Kapitel V, Art. 28 Abs. 2 (Informationsregister) | MaRisk AT 9, BT 4

Umsetzungsschritte

Datenquellen für Dienstleister, Verträge und IKT-Dienstleistungen identifizieren.
IKT-Dienstleistungen von sonstigen Leistungen abgrenzen.
Verantwortliche Rollen für Datenpflege und Review festlegen.
Kritikalität, Funktionsbezug und Registerrelevanz ergänzen.
Regelmässigen Abgleich mit Vertragsbestand und Informationsregister etablieren.

Beispielnachweise

IKT-Dienstleisterinventar (vollständig)
Vertragsliste mit IKT-Bezug
Dienstleistungsklassifikation
Datenqualitätsbericht
Review-Protokoll
Informationsregisterauszug

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.23 A.5.33

ID: DORA-TPR-001

DORA-TPR-002 reviewed defined

Abgrenzung von IKT-Dienstleistungen gegenüber sonstigen Leistungen

Das Institut kann IKT-Dienstleistungen eindeutig von sonstigen Fremdleistungen abgrenzen und damit den Anwendungsbereich der DORA-Drittparteienregelungen bestimmen.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Eine verbindliche Abgrenzungsrichtlinie definiert Kriterien für IKT-Dienstleistungen, die unter DORA fallen. Die Abgrenzung wird bei Vertragsaufnahme und regelmässigen Reviews angewendet.
DORA / MaRisk: DORA Art. 3 Ziffer 18–21 (Definition IKT-Dienstleistung) | MaRisk AT 9 (Fremdbezug)

Umsetzungsschritte

Abgrenzungskriterien basierend auf DORA-Definitionen (Art. 3) entwickeln.
Richtlinie zur Abgrenzung von IKT-Dienstleistungen verabschieden.
Bestandsverträge auf IKT-Dienstleistungscharakter prüfen.
Neubewertung bei wesentlichen Vertragsänderungen institutionalisieren.

Beispielnachweise

Abgrenzungsrichtlinie für IKT-Dienstleistungen
Bewertungsmatrix je Vertrag
Protokoll der Bestandsprüfung

ISO/IEC 27001 Anker

A.5.19 A.5.33

ID: DORA-TPR-002

DORA-TPR-003 reviewed defined

Kritische oder wichtige Funktionen zuordnen

IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, werden identifiziert und besonders gesteuert.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Jede IKT-Drittdienstleistung ist einer Funktion zugeordnet und hinsichtlich ihrer Kritikalität bewertet. Kritische Funktionen unterliegen verstärkten Anforderungen an Verträge, Überwachung, Exit und Register.
DORA / MaRisk: DORA Art. 28 Abs. 3 (Kritische oder wichtige Funktionen) | MaRisk AT 9 Tz. 3 (Wesentlichkeit)

Umsetzungsschritte

Kriterien für kritische oder wichtige Funktionen institutsspezifisch definieren.
IKT-Dienstleistungen den Funktionen zuordnen.
Kritikalitätsbewertung dokumentieren und regelmässig aktualisieren.
Verstärkte Anforderungen für kritische Funktionen umsetzen.

Beispielnachweise

Funktionslandkarte mit IKT-Dienstleistungszuordnung
Kritikalitätsbewertung je Dienstleistung
Übersicht der kritischen IKT-Drittdienstleistungen

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.23 A.5.30

ID: DORA-TPR-003

DORA-TPR-004 reviewed managed

Dienstleisterrisikobewertung vor Beauftragung und laufend

Risiken durch IKT-Drittdienstleister werden vor Vertragsabschluss und während der gesamten Vertragslaufzeit bewertet.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Eine standardisierte Risikobewertung prüft Sicherheit, Betriebsstabilität, Finanzlage, Abhängigkeiten und Exit-Fähigkeit vor Beauftragung und jährlich.
DORA / MaRisk: DORA Art. 28 Abs. 1, Art. 29 Abs. 1 (Risikobewertung) | MaRisk AT 9 Tz. 2, BT 4 Tz. 2

Umsetzungsschritte

Risikobewertungsmatrix für IKT-Drittdienstleister entwickeln.
Bewertung vor Vertragsabschluss (Due Diligence) durchführen.
Laufende Risikobewertung mindestens jährlich wiederholen.
Ergebnisse mit Maßnahmen und Fristen dokumentieren.

Beispielnachweise

Risikobewertungsmatrix je Dienstleister
Due-Diligence-Bericht
Jährliche Risikobewertung mit Aktualisierung
Maßnahmenübersicht aus Risikobewertungen

ISO/IEC 27001 Anker

A.5.21 A.5.22 A.5.36

ID: DORA-TPR-004

DORA-TPR-005 reviewed managed

Vertragsmindestinhalte nach DORA sicherstellen

Verträge mit IKT-Drittdienstleistern enthalten alle nach DORA erforderlichen Mindestklauseln.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Eine standardisierte Klauselprüfung stellt sicher, dass Verträge vollständige Leistungsbeschreibungen, Sicherheitsanforderungen, Meldepflichten, Kontrollrechte, SLA-Regelungen, Kündigungsfristen und Exit-Bestimmungen enthalten.
DORA / MaRisk: DORA Art. 28 Abs. 2 (Vertragsanforderungen) | MaRisk AT 9 Tz. 7, BT 4 Tz. 3

Umsetzungsschritte

DORA-Mindestklauselkatalog aus Art. 28 Abs. 2 ableiten.
Vertragsprüfprozess mit Checkliste und Freigabestufen etablieren.
Bestandsverträge auf Klausellücken prüfen und nachbessern.
Abweichungen dokumentieren und managementseitig freigeben.

Beispielnachweise

Klauselkatalog mit DORA-Mindestanforderungen
Vertragsprüf-Checkliste
Abweichungsregister mit Freigabevermerk
Nachgebesserte Verträge

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.31

ID: DORA-TPR-005

DORA-TPR-006 reviewed defined

Kontroll- und Zugangsrechte vertraglich sichern

Das Institut hat vertraglich gesicherte Prüfungs-, Zugangs- und Interventionsrechte bei IKT-Drittdienstleistern.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Verträge mit kritischen IKT-Drittdienstleistern enthalten umfassende Audit-, Kontroll- und Zugangsrechte sowie das Recht auf Vor-Ort-Prüfungen und die Einsichtnahme in Unterauftragnehmerverhältnisse.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. f–h (Kontroll- und Zugangsrechte) | MaRisk AT 9 Tz. 7, BT 4 Tz. 4

Umsetzungsschritte

Audit-, Kontroll- und Zugangsrechte als Pflichtklauseln definieren.
Ausübungskonzept für Kontrollrechte (Häufigkeit, Umfang, Eskalation) erstellen.
Kontrollrechte regelmässig ausüben und Ergebnisse dokumentieren.
Verweigerung von Kontrollrechten als Risikoindikator eskalieren.

Beispielnachweise

Vertragsklauseln zu Audit- und Kontrollrechten
Jährlicher Kontrollplan
Durchgeführte Audits und Prüfberichte
Eskalationsvermerk bei verweigerten Rechten

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.36 A.9.2

ID: DORA-TPR-006

DORA-TPR-007 reviewed defined

Unterauftragnehmer und Leistungsketten transparent machen

Das Institut hat Transparenz über Unterauftragnehmer und Leistungsketten kritischer IKT-Drittdienstleister.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Vertragliche Regelungen verpflichten Dienstleister zur Offenlegung wesentlicher Unterauftragnehmer. Ein aktuelles Leistungskettenverzeichnis zeigt Abhängigkeiten und Konzentrationsrisiken auf.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. e, Art. 29 Abs. 4 (Leistungsketten) | MaRisk AT 9 Tz. 5, BT 4 Tz. 2

Umsetzungsschritte

Vertragliche Verpflichtung zur Offenlegung von Unterauftragnehmern aufnehmen.
Leistungsketten für kritische IKT-Dienstleistungen erfassen.
Unterauftragnehmer auf Konzentrationsrisiken prüfen.
Änderungen im Unterauftragnehmerverhältnis meldepflichtig machen.

Beispielnachweise

Leistungskettenübersicht je kritischer Dienstleistung
Vertragsklauseln zu Unterauftragnehmern
Konzentrationsrisikoanalyse
Änderungsmeldungen und Freigaben

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.21

ID: DORA-TPR-007

DORA-TPR-008 reviewed defined

Exit-Strategien für kritische IKT-Drittdienstleistungen

Das Institut kann kritische IKT-Drittdienstleistungen geordnet beenden, übertragen oder ersetzen, ohne die digitale operationale Resilienz unangemessen zu gefährden.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Für kritische oder wichtige IKT-Drittdienstleistungen bestehen dokumentierte, realistische und überprüfte Exit-Strategien. Sie berücksichtigen Datenrückgabe, Übergangsfristen, Ersatzdienstleister, interne Verantwortlichkeiten, technische Abhängigkeiten, regulatorische Anzeige- oder Informationspflichten und Managementfreigaben.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. i, Art. 29 Abs. 5 (Exit) | MaRisk AT 9 Tz. 9, BT 4 Tz. 6

Umsetzungsschritte

Kritische oder wichtige IKT-Drittdienstleistungen identifizieren.
Exit-Szenarien und Auslöser definieren.
Technische, vertragliche und operative Abhängigkeiten dokumentieren.
Ersatz- oder Übergangsoptionen bewerten.
Exit-Strategien regelmässig prüfen und, wenn angemessen, testen.
Ergebnisse und offene Risiken managementfähig berichten.

Beispielnachweise

Exit-Strategie je kritischer Dienstleistung
Exit-Testprotokoll
Abhängigkeitsanalyse
Gremienfreigabe
Maßnahmenverfolgung

ISO/IEC 27001 Anker

A.5.19 A.5.29 A.5.30 A.5.36

ID: DORA-TPR-008

DORA-TPR-009 reviewed initial

Exit-Test und Exit-Fähigkeit regelmässig überprüfen

Die praktische Umsetzbarkeit von Exit-Strategien wird regelmässig getestet und nachgewiesen.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Exit-Tests für kritische IKT-Drittdienstleistungen werden mindestens jährlich durchgeführt. Sie prüfen Datenrückgabe, Systemmigration, Kommunikationswege und die Einhaltung von Übergangsfristen.
DORA / MaRisk: DORA Art. 29 Abs. 5 (Test der Exit-Fähigkeit) | MaRisk AT 7.3, BT 3.3

Umsetzungsschritte

Test-Szenarien für Exit-Fälle definieren (Datenrückgabe, Migration, Löschung).
Jährlichen Testplan für Exit-Übungen erstellen.
Testergebnisse dokumentieren und Verbesserungen ableiten.
Nicht bestandene Tests mit Maßnahmen und Fristen versehen.

Beispielnachweise

Exit-Testplan für das laufende Jahr
Durchgeführte Exit-Tests mit Ergebnissen
Verbesserungsmaßnahmen aus Tests
Management-Freigabe der Testergebnisse

ISO/IEC 27001 Anker

A.5.29 A.5.30 A.8.34

ID: DORA-TPR-009

DORA-TPR-010 reviewed defined

Konzentrationsrisiken durch IKT-Drittdienstleister analysieren

Risiken aus der Konzentration auf einzelne Dienstleister, Regionen oder Technologien werden identifiziert und gesteuert.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Eine regelmässige Konzentrationsrisikoanalyse prüft Abhängigkeiten auf Dienstleister-, Branchen-, Regional- und Technologieebene und leitet Maßnahmen zur Risikominderung ab.
DORA / MaRisk: DORA Art. 29 Abs. 3 (Konzentrationsrisiko) | MaRisk AT 9 Tz. 4, BT 4 Tz. 2

Umsetzungsschritte

Konzentrationsdimensionen definieren (Dienstleister, Region, Technologie, Branche).
Konzentrationsrisikoanalyse mindestens jährlich durchführen.
Kritische Konzentrationen mit Maßnahmenplänen versehen.
Ergebnisse in das gesamtinstitutische Risikomanagement einsteuern.

Beispielnachweise

Konzentrationsrisikoanalyse (aktuell)
Maßnahmenplan für identifizierte Konzentrationsrisiken
Reporting an das Leitungsorgan
Monitoring kritischer Konzentrationen

ISO/IEC 27001 Anker

A.5.19 A.5.21 A.5.22

ID: DORA-TPR-010

DORA-TPR-011 reviewed managed

Laufende Überwachung von IKT-Drittdienstleistern

Die Leistungs- und Risikoentwicklung kritischer IKT-Drittdienstleister wird kontinuierlich überwacht.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Ein Überwachungsprozess mit definierten Kennzahlen, Berichtsintervallen und Eskalationsschwellen ist für alle kritischen IKT-Drittdienstleister etabliert.
DORA / MaRisk: DORA Art. 29 Abs. 1–2 (Laufende Überwachung) | MaRisk AT 9 Tz. 8, BT 4 Tz. 5

Umsetzungsschritte

Überwachungskennzahlen je Dienstleister (Verfügbarkeit, Sicherheitsvorfälle, SLA-Einhaltung) definieren.
Regelmässige Leistungs- und Risikoberichte von Dienstleistern einfordern.
Abweichungen systematisch erfassen, eskalieren und nachverfolgen.
Steuerungsgespräche mit kritischen Dienstleistern institutionalisieren.

Beispielnachweise

Überwachungskonzept mit Kennzahlen
Dienstleister-Scorecards mit Trend
Abweichungsprotokoll mit Eskalation
Steuerungsgesprächsprotokolle

ISO/IEC 27001 Anker

A.5.19 A.5.23 A.5.35 A.8.16

ID: DORA-TPR-011

DORA-TPR-012 reviewed defined

Informationsregisterfähigkeit für IKT-Drittdienstleistungen sicherstellen

Das Institut kann jederzeit ein vollständiges, richtiges und aktuelles Informationsregister über alle IKT-Drittdienstleistungen vorlegen.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Das Informationsregister enthält alle geforderten Angaben zu IKT-Drittdienstleistungen, Dienstleistern, Verträgen, Funktionen, Kritikalität und Unterauftragnehmern. Die Datenqualität wird regelmässig geprüft.
DORA / MaRisk: DORA Art. 28 Abs. 3 (Informationsregister) | MaRisk AT 9 Tz. 6

Umsetzungsschritte

Registerdatenmodell mit allen DORA-Pflichtfeldern definieren.
Datenquellen mit automatisierten Schnittstellen anbinden.
Datenqualitätsregeln und Korrekturprozesse etablieren.
Register periodisch auf Vollständigkeit und Aktualität prüfen.

Beispielnachweise

Informationsregisterauszug (vollständig)
Datenqualitätsbericht
Schnittstellendokumentation
Review-Protokoll der Registerdaten

ISO/IEC 27001 Anker

A.5.19 A.5.33 A.5.34 A.5.36

ID: DORA-TPR-012

DORA-TPR-013 reviewed defined

Incident-Kommunikation mit IKT-Drittdienstleistern

IKT-bezogene Vorfälle bei Dienstleistern werden dem Institut zeitnah gemeldet und institutsintern korrekt behandelt.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Vertragliche Meldefristen, Eskalationswege und Kommunikationsschnittstellen sind mit allen kritischen Dienstleistern vereinbart. Eingehende Meldungen werden im institutseigenen Incident-Prozess aufgenommen und weiterverarbeitet.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. c, Art. 29 Abs. 2 (Meldepflichten) | MaRisk AT 9 Tz. 8, BT 3.2

Umsetzungsschritte

Meldepflichten und -fristen für Sicherheitsvorfälle vertraglich regeln.
Kommunikationsschnittstellen und Ansprechpartner benennen.
Eingehende Dienstleister-Meldungen in den Incident-Prozess integrieren.
Regelmässige Kommunikationsübungen mit kritischen Dienstleistern durchführen.

Beispielnachweise

Vertragsklauseln zu Meldefristen
Kommunikationsmatrix je Dienstleister
Eingegangene Meldungen und Bearbeitungsnachweise
Übungsprotokolle zur Incident-Kommunikation

ISO/IEC 27001 Anker

A.5.19 A.5.24 A.5.25 A.5.26

ID: DORA-TPR-013

DORA-TPR-014 reviewed managed

Management Reporting zu IKT-Drittparteienrisiken

Das Leitungsorgan erhält regelmässig entscheidungsrelevante Informationen über IKT-Drittparteienrisiken.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Ein standardisiertes Reporting informiert das Leitungsorgan vierteljährlich über Dienstleisterbestand, Risikobewertungen, wesentliche Vorfälle, Konzentrationsrisiken, Kontrollstatus und Exit-Readiness.
DORA / MaRisk: DORA Art. 29 Abs. 1, Art. 5 (Berichtspflichten) | MaRisk AT 4.3.1, BT 3.1

Umsetzungsschritte

Reporting-Kennzahlen für IKT-Drittparteienrisiko definieren.
Standardisiertes Reporting-Template entwickeln.
Reporting-Rhythmus (quartalsweise) und Eskalationsschwellen festlegen.
Reporting mit dem gesamtinstitutischen Risikobericht abstimmen.

Beispielnachweise

Quarterly TPR-Report an das Leitungsorgan
Kennzahlen-Dashboard (Dienstleister, Risiken, Maßnahmen)
Eskalationsnachweise bei Schwellwertverletzungen
Sitzungsprotokolle mit TPR-Tagesordnungspunkt

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.5.37

ID: DORA-TPR-014

DORA-TPR-015 reviewed defined

Maßnahmen- und Befundverfolgung im TPR-Umfeld

Alle identifizierten Mängel, Risiken und Verbesserungsmaßnahmen im IKT-Drittparteienbereich werden systematisch verfolgt und bis zum Wirksamkeitsnachweis geschlossen.

Themenbereich: IKT-Drittparteienrisiko
Sollzustand: Ein Maßnahmen-Tracking-System erfasst alle Befunde aus Audits, Risikobewertungen, Vertragsprüfungen und Kontrollen. Jede Massnahme hat einen Verantwortlichen, eine Frist und einen Wirksamkeitsnachweis.
DORA / MaRisk: DORA Art. 29, Art. 4 (Kontinuierliche Verbesserung) | MaRisk AT 4.4.2, BT 4

Umsetzungsschritte

Maßnahmenkategorien für TPR-spezifische Befunde definieren.
Tracking-System mit Fristen, Verantwortlichen und Status aufsetzen.
Regelmässige Review-Termine zur Maßnahmenverfolgung institutionalisieren.
Überfällige Maßnahmen eskalieren und managementseitig nachsteuern.

Beispielnachweise

Maßnahmen- und Befundtracking (aktuell)
Review-Protokolle mit Status je Massnahme
Eskalationsnachweise bei überfälligen Maßnahmen
Wirksamkeitsnachweise abgeschlossener Maßnahmen

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.10.1 A.10.2

ID: DORA-TPR-015

DORA-IRM-001 reviewed defined

Governance-Rahmen für IKT-Risikomanagement etablieren

Das Institut verfügt über einen dokumentierten Governance-Rahmen, der IKT-Risikomanagement als integralen Bestandteil des gesamtinstitutischen Risikomanagements verankert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein vom Leitungsorgan freigegebener Governance-Rahmen definiert Ziele, Prinzipien, Verantwortlichkeiten, Entscheidungswege, Eskalationsschwellen und Berichtslinien für das IKT-Risikomanagement. Der Rahmen wird mindestens jährlich überprüft und bei wesentlichen Änderungen aktualisiert.
DORA / MaRisk: DORA Art. 5 Abs. 1 (Governance), Art. 6 Abs. 1 (Rahmen für IKT-Risikomanagement) | MaRisk AT 4.3.1, AT 4.4.1

Umsetzungsschritte

IST-Governance für IKT-Risikomanagement aufnehmen und gegen DORA-Anforderungen mappen.
Governance-Rahmen mit Leitungsorgan-Verantwortung, Ausschüssen, Rollen und Entscheidungswegen entwerfen.
Eskalationsschwellen für IKT-Risiken in Zusammenarbeit mit Risikocontrolling festlegen.
Rahmen durch Leitungsorgan freigeben und in der Organisation kommunizieren.
Jährlichen Review-Prozess für den Governance-Rahmen institutionalisieren.

Beispielnachweise

Freigegebener Governance-Rahmen (aktuell)
Gremienbeschluss zur Verabschiedung
Eskalationsmatrix für IKT-Risiken
Review-Protokoll mit Änderungshistorie

ISO/IEC 27001 Anker

A.5.1 A.5.2 A.5.3 A.5.36

ID: DORA-IRM-001

DORA-IRM-002 reviewed managed

Rollen und Verantwortlichkeiten im IKT-Risikomanagement definieren

Rollen, Aufgaben, Kompetenzen und Verantwortlichkeiten für das IKT-Risikomanagement sind institutsweit eindeutig zugeordnet und dokumentiert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein verbindliches Rollenmodell weist Verantwortlichkeiten für IKT-Risikoidentifikation, -bewertung, -behandlung, -überwachung und -berichterstattung zu. Dritte-Verteidigungslinie (Revision) prüft die Wirksamkeit des Gesamtsystems.
DORA / MaRisk: DORA Art. 5 Abs. 2 (Rollen), Art. 6 Abs. 3 (Personal) | MaRisk AT 4.4.1 (Aufbauorganisation), AT 7.1 (Personal)

Umsetzungsschritte

RACI-Matrix für IKT-Risikomanagement mit Fachbereichen, IT, Risikocontrolling, Informationssicherheit und Revision erstellen.
Stellvertretungsregelungen für jede Schlüsselrolle festlegen.
Rollen in Stellenbeschreibungen und Zielvereinbarungen integrieren.
Rollenverständnis durch Schulungen und Kommunikation sicherstellen.

Beispielnachweise

Rollen- und Verantwortungsmatrix (RACI)
Stellenbeschreibungen mit IKT-Risikobezug
Schulungsnachweise für Rolleninhaber
Review-Protokoll der Rollenverteilung

ISO/IEC 27001 Anker

A.5.2 A.5.3 A.5.37

ID: DORA-IRM-002

DORA-IRM-003 reviewed defined

IKT-Risikostrategie und Risikoappetit festlegen

Das Institut verfügt über eine dokumentierte IKT-Risikostrategie, die den Risikoappetit, die Risikotragfähigkeit und strategische Ziele für IKT-Risiken definiert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Die IKT-Risikostrategie ist mit der Geschäftsstrategie und dem gesamtinstitutischen Risikoappetit abgestimmt. Sie definiert quantitative und qualitative Risikoschwellen, Prioritäten und Maßnahmen bei Schwellwertverletzungen.
DORA / MaRisk: DORA Art. 6 Abs. 1 lit. a–b (Strategie), Art. 6 Abs. 4 (Dokumentation) | MaRisk AT 4.2.1 (Risikostrategie), AT 4.3.2 (Risikotragfähigkeit)

Umsetzungsschritte

IKT-Risikoappetit aus gesamtnstitutischem Risikoappetit ableiten und operationalisieren.
IKT-Risikostrategie mit Zielen, Schwellenwerten und Überwachungskennzahlen formulieren.
Strategie durch Leitungsorgan freigeben und jährlich überprüfen.
Abweichungen von der Strategie als Eskalationsereignis definieren.

Beispielnachweise

Freigegebene IKT-Risikostrategie (aktuell)
Risikoappetit-Erklärung mit Schwellenwerten
Jährlicher Strategie-Review mit Beschluss
Abweichungsbericht bei Strategieverletzung

ISO/IEC 27001 Anker

A.5.1 A.5.4 A.5.36

ID: DORA-IRM-003

DORA-IRM-004 reviewed defined

IKT-Risikoinventar aufbauen und aktuell halten

Alle identifizierten IKT-Risiken werden in einem zentralen Risikoinventar erfasst, bewertet und aktuell gehalten.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein vollständiges IKT-Risikoinventar erfasst jede identifizierte Gefährdung mit Risikobeschreibung, Eintrittswahrscheinlichkeit, Schadenshöhe, Risikowert, Verantwortlichem, Behandlungsoption, Frist und Status. Das Inventar wird mindestens quartalsweise aktualisiert.
DORA / MaRisk: DORA Art. 6 Abs. 1 lit. c (Risikoidentifikation), Art. 7 (Risikobewertung) | MaRisk AT 4.3.3 (Risikoinventar), BT 1 (IKT-Risiken)

Umsetzungsschritte

Risikokategorien für IKT-Risiken definieren (strategisch, operativ, Compliance, Reputation).
Risikoinventar-Vorlage mit Pflichtfeldern entwickeln.
Ersterfassung durch Fachbereiche, IT und Informationssicherheit durchführen.
Regelmässige Aktualisierung (quartalsweise) und Konsolidierung institutionalisieren.
Inventar mit Kontrollsystem und Maßnahmentracking verknüpfen.

Beispielnachweise

IKT-Risikoinventar (vollständig, aktuell)
Risikoklassifikation und -kategorien
Aktualisierungsprotokolle je Quartal
Abgleich mit Kontroll- und Maßnahmensystem

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.5.9 A.8.8

ID: DORA-IRM-004

DORA-IRM-005 reviewed defined

Schutzbedarfsfeststellung für IKT-Assets durchführen

Der Schutzbedarf aller IKT-Assets wird hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit systematisch festgestellt und dokumentiert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Eine vollständige Schutzbedarfsfeststellung liegt für alle IKT-Assets (Anwendungen, Systeme, Daten, Netzwerke, Infrastruktur) vor. Die Einstufung erfolgt einheitlich anhand definierter Kriterien und wird bei wesentlichen Änderungen aktualisiert.
DORA / MaRisk: DORA Art. 7 Abs. 2 (Schutzbedarf), Art. 8 (Schutzmaßnahmen) | MaRisk BT 1.1 (Informationssicherheit), BT 3.1 (Notfallmanagement)

Umsetzungsschritte

Schutzbedarfskategorien (normal, hoch, sehr hoch) für Vertraulichkeit, Integrität und Verfügbarkeit definieren.
Bewertungsmatrix mit Kriterien je Kategorie entwickeln.
IKT-Assets identifizieren und Schutzbedarf je Asset bestimmen.
Ergebnisse dokumentieren und regelmässig (mindestens jährlich) aktualisieren.

Beispielnachweise

Schutzbedarfsfeststellung für alle IKT-Assets
Bewertungsmatrix und Kriterienkatalog
Aktualisierungsprotokoll
Abweichungsanalyse bei geändertem Schutzbedarf

ISO/IEC 27001 Anker

A.5.9 A.5.10 A.8.1 A.8.2

ID: DORA-IRM-005

DORA-IRM-006 reviewed managed

IKT-Risikoanalyse und -bewertung durchführen

IKT-Risiken werden systematisch analysiert, bewertet und priorisiert, um risikobasierte Entscheidungen zu ermöglichen.

Themenbereich: IKT-Risikomanagement
Sollzustand: Eine standardisierte Risikoanalyse bewertet identifizierte IKT-Risiken nach Eintrittswahrscheinlichkeit und Schadenshöhe. Die Ergebnisse werden in einer Risikomatrix visualisiert und priorisiert. Wesentliche Risiken werden mit Behandlungsoptionen und Fristen versehen.
DORA / MaRisk: DORA Art. 7 (Risikoanalyse und -bewertung) | MaRisk AT 4.3.3 (Risikoanalyse), BT 1.2

Umsetzungsschritte

Risikoanalyse-Methodik (quantitativ/qualitativ) institutsspezifisch festlegen.
Risikomatrix mit Eintrittswahrscheinlichkeit, Schadenshöhe und Risikoklassen definieren.
Risikoanalyse für alle erfassten IKT-Risiken durchführen.
Ergebnisse priorisieren und in Risikobericht aufnehmen.

Beispielnachweise

Risikoanalysebericht (aktuell)
Risikomatrix mit Bewertung aller IKT-Risiken
Priorisierungsliste mit Behandlungskategorien
Risikobericht an Leitungsorgan

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.8.8

ID: DORA-IRM-006

DORA-IRM-007 reviewed managed

IKT-Risikobehandlung steuern und dokumentieren

Für jedes identifizierte und bewertete IKT-Risiko wird eine Behandlungsoption festgelegt und umgesetzt.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein Risikobehandlungsplan dokumentiert für jedes wesentliche IKT-Risiko die gewählte Option (Vermeiden, Reduzieren, Übertragen, Akzeptieren), zugehörige Maßnahmen, Verantwortliche, Fristen und den Status der Umsetzung. Risikoakzeptanz erfolgt auf der dafür vorgesehenen Management-Ebene.
DORA / MaRisk: DORA Art. 8 (Schutzmaßnahmen), Art. 9 (Risikobehandlung) | MaRisk AT 4.3.4 (Risikobehandlung), BT 2

Umsetzungsschritte

Behandlungsoptionen institutsweit verbindlich definieren.
Risikobehandlungsplan mit Maßnahmen, Verantwortlichen und Fristen erstellen.
Akzeptanzkriterien und Genehmigungsstufen für Risikoakzeptanz festlegen.
Umsetzung der Maßnahmen verfolgen und Wirksamkeit nachweisen.
Restrisiken dokumentieren und managementseitig freigeben.

Beispielnachweise

Risikobehandlungsplan (aktuell)
Maßnahmenübersicht mit Status und Fristen
Risikoakzeptanzdokumentation mit Genehmigung
Wirksamkeitsnachweise umgesetzter Maßnahmen

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.5.29 A.8.3

ID: DORA-IRM-007

DORA-IRM-008 reviewed defined

Kontrollsystem für IKT-Risikomanagement aufbauen

Ein dokumentiertes Kontrollsystem stellt die Wirksamkeit der IKT-Risikomanagement-Maßnahmen sicher.

Themenbereich: IKT-Risikomanagement
Sollzustand: Das Kontrollsystem umfasst risikobasierte Kontrollziele, Kontrollen (präventiv, detektiv, korrektiv), Kontrollfrequenzen, Verantwortliche, Nachweise und Review-Zyklen. Kontrollergebnisse werden dokumentiert und bei Abweichungen eskalieren.
DORA / MaRisk: DORA Art. 8 (Kontrollsystem), Art. 10 (Wirksamkeit) | MaRisk AT 4.4.2 (Kontrollsystem), BT 2.1

Umsetzungsschritte

Kontrollziele aus IKT-Risikoinventar und Schutzbedarf ableiten.
Kontrolltypen (präventiv/detektiv/korrektiv) und -frequenzen festlegen.
Kontrollen in Verantwortung der Fachbereiche, IT und Informationssicherheit betreiben.
Kontrollergebnisse dokumentieren und bei Abweichungen Maßnahmen einleiten.

Beispielnachweise

Kontrollsystem-Dokumentation mit Kontrollmatrix
Durchgeführte Kontrollen mit Ergebnissen
Abweichungsberichte und Maßnahmen
Kontroll-Review-Protokoll

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.8.8 A.8.15

ID: DORA-IRM-008

DORA-IRM-009 reviewed defined

Wirksamkeitsprüfung von IKT-Kontrollen institutionalisieren

Die Wirksamkeit der IKT-Kontrollen wird regelmässig geprüft, dokumentiert und bei Feststellungen nachgesteuert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein standardisierter Prozess prüft die Wirksamkeit aller IKT-Kontrollen mindestens jährlich. Die Prüfung umfasst Design-Wirksamkeit und operative Wirksamkeit. Ergebnisse werden dokumentiert, mit Soll-Zustand abgeglichen und Maßnahmen bei Abweichungen eingeleitet.
DORA / MaRisk: DORA Art. 10 (Wirksamkeit und Überwachung) | MaRisk AT 4.4.2 Tz. 3 (Wirksamkeit), BT 2.2

Umsetzungsschritte

Prüfmethodik für Design-Wirksamkeit und operative Wirksamkeit festlegen.
Prüfplan mit Priorisierung (risikobasiert) und Frequenzen erstellen.
Wirksamkeitsprüfungen durchführen und Ergebnisse dokumentieren.
Maßnahmen bei nicht wirksamen Kontrollen ableiten und nachverfolgen.

Beispielnachweise

Prüfplan für Wirksamkeitsnachweise (jährlich)
Durchgeführte Wirksamkeitsprüfungen mit Ergebnissen
Maßnahmenplan bei nicht wirksamen Kontrollen
Management-Freigabe der Prüfergebnisse

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.8.8 A.9.1

ID: DORA-IRM-009

DORA-IRM-010 reviewed defined

Kritische IKT-Dienstleistungen identifizieren und Schutzbedarf bestimmen

Kritische IKT-Dienstleistungen und deren Schutzbedarf werden identifiziert und in das IKT-Risikomanagement einbezogen.

Themenbereich: IKT-Risikomanagement
Sollzustand: Eine institutsspezifische Definition und Identifikation kritischer IKT-Dienstleistungen ist etabliert. Der Schutzbedarf dieser Dienstleistungen hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit ist dokumentiert und wird bei Änderungen aktualisiert.
DORA / MaRisk: DORA Art. 7 Abs. 3 (Kritische Dienstleistungen), Art. 8 Abs. 2 | MaRisk AT 9 (Auslagerungen), BT 3 (Notfallmanagement)

Umsetzungsschritte

Kriterien für kritische IKT-Dienstleistungen definieren.
IKT-Dienstleistungen identifizieren und Kritikalität bewerten.
Schutzbedarf je kritischer Dienstleistung feststellen.
Ergebnisse mit IKT-Risikoinventar und Kontrollsystem verknüpfen.

Beispielnachweise

Kriterienkatalog für kritische IKT-Dienstleistungen
Bewertung der Kritikalität je Dienstleistung
Schutzbedarfsfeststellung für kritische Dienstleistungen
Verknüpfung mit Risikoinventar und Kontrollen

ISO/IEC 27001 Anker

A.5.9 A.5.10 A.5.19 A.8.1

ID: DORA-IRM-010

DORA-IRM-011 reviewed defined

IKT-Risikoüberwachung mit Frühwarnindikatoren betreiben

IKT-Risiken werden kontinuierlich überwacht und Frühwarnindikatoren zeigen Risikoveränderungen zeitnah an.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein Kennzahlensystem mit Frühwarnindikatoren (KRI) für IKT-Risiken ist definiert und in Betrieb. Die Kennzahlen werden regelmässig erhoben, überwacht und bei Schwellwertverletzungen wird eskaliert. Trends und Veränderungen werden analysiert und berichtet.
DORA / MaRisk: DORA Art. 10 (Überwachung), Art. 11 (Frühwarnung) | MaRisk AT 4.3.5 (Frühwarnung), BT 1.3

Umsetzungsschritte

Frühwarnindikatoren für IKT-Risiken identifizieren und definieren.
Schwellenwerte (Grün/Gelb/Rot) für jeden Indikator festlegen.
Automatisierte Datenerhebung und Berichterstattung aufbauen.
Regelmässige Überprüfung der Indikatoren auf Aussagekraft und Aktualität.

Beispielnachweise

Frühwarnindikatoren-Übersicht mit aktuellen Werten
Schwellwert-Definition und Eskalationsregeln
Monitoring-Bericht mit Trendanalyse
Eskalationsnachweise bei Schwellwertverletzung

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.5.35 A.8.16

ID: DORA-IRM-011

DORA-IRM-012 reviewed managed

Management-Reporting zu IKT-Risiken etablieren

Das Management erhält regelmässig entscheidungsrelevante Informationen über die IKT-Risikolage, Kontrollstatus, Vorfälle und Maßnahmenfortschritt.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein standardisiertes Reporting informiert das Management quartalsweise über die IKT-Risikolage: Risikoinventar-Entwicklung, Kontrollergebnisse, Frühwarnindikatoren, wesentliche Vorfälle, Maßnahmenstatus und Reifegradentwicklung.
DORA / MaRisk: DORA Art. 5 Abs. 3 (Berichtspflichten), Art. 11 (Risikoberichterstattung) | MaRisk AT 4.3.1 (Reporting), BT 1.4

Umsetzungsschritte

Reporting-Kennzahlen und Berichtsvorlage für IKT-Risiken definieren.
Berichtsrhythmus (quartalsweise) und Ad-hoc-Berichtsanlässe festlegen.
Reporting in das gesamtinstitutische Risikoberichtswesen integrieren.
Reporting regelmässig auf Aussagekraft und Entscheidungsrelevanz prüfen.

Beispielnachweise

Quartalsbericht IKT-Risikomanagement
Kennzahlen-Dashboard (Risiken, Kontrollen, Maßnahmen)
Ad-hoc-Bericht bei wesentlicher Veränderung
Review-Protokoll zur Reporting-Qualität

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.5.37

ID: DORA-IRM-012

DORA-IRM-013 reviewed defined

IKT-Risikobericht an das Leitungsorgan sicherstellen

Das Leitungsorgan erhält regelmässig einen umfassenden Bericht über die IKT-Risikolage und die Wirksamkeit des IKT-Risikomanagements.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein jährlicher IKT-Risikobericht informiert das Leitungsorgan über die Risikolage, wesentliche Risikoveränderungen, Kontrollergebnisse, Wirksamkeitsprüfungen, Reifegradentwicklung, Ressourcen- und Budgetbedarf sowie strategische Empfehlungen.
DORA / MaRisk: DORA Art. 5 Abs. 1 (Leitungsorgan), Art. 11 Abs. 2 | MaRisk AT 4.3.1 (Leitungsorgan), AT 4.4.1

Umsetzungsschritte

Berichtsanforderungen des Leitungsorgans für IKT-Risiken erheben.
Jährlichen IKT-Risikobericht mit Standardvorlage erstellen.
Berichtstermin mit Jahresplanung des Leitungsorgans abstimmen.
Berichtsergebnisse in strategische Planung und Budgetierung einsteuern.

Beispielnachweise

IKT-Risikobericht an Leitungsorgan (jährlich)
Sitzungsprotokoll mit Behandlung des Berichts
Beschlussvorlage mit Maßnahmen
Nachverfolgung der Beschlüsse

ISO/IEC 27001 Anker

A.5.1 A.5.4 A.5.36 A.5.37

ID: DORA-IRM-013

DORA-IRM-014 reviewed defined

Eskalationsprozess für IKT-Risiken definieren und betreiben

Wesentliche IKT-Risiken, Kontrollabweichungen und Vorfälle werden zeitnah und auf der richtigen Management-Ebene eskaliert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein dokumentierter Eskalationsprozess definiert Eskalationsauslöser, -stufen, -empfänger, -fristen und Kommunikationswege für IKT-Risiken. Eskalationen werden dokumentiert, nachverfolgt und auf Wirksamkeit geprüft.
DORA / MaRisk: DORA Art. 5 Abs. 2 (Eskalation), Art. 6 Abs. 2 | MaRisk AT 4.4.1 (Entscheidungswege), BT 3.2

Umsetzungsschritte

Eskalationsauslöser (Schwellenwerte, Fristen, Risikoklassen) definieren.
Eskalationsstufen und Entscheidungsbefugnisse je Stufe festlegen.
Kommunikationswege und -formate für Eskalationen standardisieren.
Eskalationsprozess regelmässig testen und schulen.

Beispielnachweise

Eskalationsmatrix mit Auslösern und Stufen
Dokumentierte Eskalationsfälle mit Verlauf
Eskalationstest-Protokoll
Schulungsnachweise für Eskalationsprozess

ISO/IEC 27001 Anker

A.5.2 A.5.3 A.5.24 A.5.35

ID: DORA-IRM-014

DORA-IRM-015 reviewed defined

Nachweis- und Evidenzmodell für IKT-Risikomanagement aufbauen

Alle IKT-Risikomanagement-Aktivitäten sind revisionssicher nachweisbar und mit dem Evidenzmodell der Plattform verknüpft.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein standardisiertes Evidenzmodell ordnet jeder IKT-Risikomanagement-Anforderung konkrete Nachweise zu. Nachweise sind mit Verantwortlichen, Review-Zyklen und Aufbewahrungsfristen versehen. Das Modell wird regelmässig auf Vollständigkeit und Aktualität geprüft.
DORA / MaRisk: DORA Art. 6 Abs. 4 (Dokumentation), Art. 10 Abs. 3 | MaRisk AT 4.4.2 (Dokumentation), BT 2.3

Umsetzungsschritte

Evidenzkategorien für IKT-Risikomanagement definieren.
Nachweiszuordnung zu jeder DORA-IRM-Anforderung herstellen.
Review-Zyklen und Verantwortliche je Nachweis festlegen.
Evidenzmodell mit Kontrollsystem und Maßnahmentracking verknüpfen.

Beispielnachweise

Evidenzmodell IKT-Risikomanagement (vollständig)
Nachweisverzeichnis mit Zuordnung zu Anforderungen
Review-Protokoll der Evidenzen
Verknüpfung mit Kontroll- und Maßnahmensystem

ISO/IEC 27001 Anker

A.5.33 A.5.34 A.5.35 A.5.36

ID: DORA-IRM-015

DORA-IRM-016 reviewed defined

Integration von DORA, MaRisk und ISO 27001 im IKT-Risikomanagement

Die Anforderungen aus DORA, MaRisk und ISO/IEC 27001:2022 werden im IKT-Risikomanagement konsistent und aufwandsminimierend integriert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein integriertes Anforderungsmapping zeigt die Korrespondenz zwischen DORA-IRM-Artikeln, MaRisk-AT/BT-Ziffern und ISO/IEC 27001:2022-Kontrollen. Gemeinsame Nachweise, Kontrollen und Berichtsformate werden genutzt, um Doppelarbeiten zu vermeiden.
DORA / MaRisk: DORA Art. 6 Abs. 1, Art. 15 (Konsistenz) | MaRisk AT 1 (Anwendungsbereich), AT 4.1 (Gesamtverantwortung)

Umsetzungsschritte

Anforderungsmapping zwischen DORA IRM, MaRisk und ISO 27001 durchführen.
Gemeinsame Kontrollziele und Nachweise identifizieren.
Integrierte Berichts- und Nachweisstruktur aufbauen.
Abweichungen und Zusatzanforderungen je Regulation dokumentieren.

Beispielnachweise

Anforderungsmapping DORA–MaRisk–ISO 27001
Gemeinsame Kontrollzielmatrix
Integrierte Nachweisstruktur
Abweichungsanalyse je Regulation

ISO/IEC 27001 Anker

A.5.1 A.5.36 A.5.37 A.6.1

ID: DORA-IRM-016

DORA-IRM-017 reviewed initial

Reifegradmodell für IKT-Risikomanagement etablieren

Der Reifegrad des IKT-Risikomanagements wird regelmässig gemessen, berichtet und als Grundlage für Verbesserungsmaßnahmen genutzt.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein institutsspezifisches Reifegradmodell bewertet alle Dimensionen des IKT-Risikomanagements (Governance, Risikoidentifikation, -analyse, -behandlung, Kontrollen, Überwachung, Reporting, Kultur) auf einer definierten Skala. Die Bewertung wird jährlich durchgeführt und mit Maßnahmenplänen verbunden.
DORA / MaRisk: DORA Art. 6 Abs. 5 (Kontinuierliche Verbesserung), Art. 15 | MaRisk AT 4.4.2 (Verbesserung), BT 2.4

Umsetzungsschritte

Reifegrad-Dimensionen und Bewertungsstufen für IKT-Risikomanagement definieren.
Bewertungskriterien je Dimension und Stufe festlegen.
Jährliche Reifegradbewertung durchführen und dokumentieren.
Ergebnisse mit Maßnahmen- und Verbesserungsplan verknüpfen.

Beispielnachweise

Reifegradmodell IKT-Risikomanagement
Jährliche Reifegradbewertung mit Ergebnissen
Maßnahmenplan aus Reifegradbewertung
Entwicklungsreport mit Vorjahresvergleich

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.10.1 A.10.2

ID: DORA-IRM-017

DORA-IRM-018 reviewed defined

Schulungs- und Sensibilisierungsprogramm für IKT-Risiken aufbauen

Mitarbeitende und Führungskräfte werden regelmässig zu IKT-Risiken geschult und für ihre Verantwortung im IKT-Risikomanagement sensibilisiert.

Themenbereich: IKT-Risikomanagement
Sollzustand: Ein rollenbasiertes Schulungsprogramm vermittelt IKT-Risikowissen an alle relevanten Mitarbeitenden. Führungskräfte erhalten vertiefende Schulungen zu IKT-Risikosteuerung, Eskalation und Reporting. Schulungsteilnahme und -erfolg werden dokumentiert.
DORA / MaRisk: DORA Art. 5 Abs. 2 (Personal), Art. 6 Abs. 3 (Sensibilisierung) | MaRisk AT 7.1 (Personal), AT 7.2 (Schulung)

Umsetzungsschritte

Schulungsbedarf für IKT-Risikomanagement rollenbasiert erheben.
Schulungsprogramm mit Basisschulung (alle) und Vertiefung (Rolleninhaber) entwickeln.
Jährlichen Schulungsplan erstellen und durchführen.
Schulungserfolg messen und Programm kontinuierlich verbessern.

Beispielnachweise

Schulungskonzept IKT-Risikomanagement
Rollenbasierte Schulungsmatrix
Teilnehmernachweise und Testergebnisse
Jährlicher Schulungsplan mit Durchführung

ISO/IEC 27001 Anker

A.5.2 A.5.3 A.6.3 A.7.2

ID: DORA-IRM-018

DORA-KWF-001 reviewed initial

Methodik zur Bestimmung kritischer oder wichtiger Funktionen etablieren

Das Institut verfügt über eine dokumentierte und freigegebene Methodik zur Bestimmung kritischer oder wichtiger Funktionen (kwF) nach DORA.

Themenbereich: Kritische oder wichtige Funktionen
Sollzustand: Eine institutsspezifische kwF-Methodik definiert Kriterien, Prozesse, Verantwortlichkeiten und Entscheidungsbefugnisse. Die Methodik berücksichtigt Ausfallperspektive, Pflichtverletzungsperspektive, Zeitkritikalität und regulatorische Bedeutung. Sie wird vom Leitungsorgan freigegeben und mindestens jährlich überprüft.
DORA / MaRisk: DORA Art. 3 Ziffer 23, Art. 28 Abs. 3 (Kritische oder wichtige Funktionen) | MaRisk AT 9 Tz. 3 (Wesentlichkeit von Auslagerungen)

Umsetzungsschritte

kwF-Kriterienkatalog mit Ausfall-, Pflichtverletzungs-, Zeit- und Regulatorik-Dimensionen entwickeln.
Methodik mit Prozesslandkarte, Bewertungsmatrix und Entscheidungslogik dokumentieren.
Methodik durch Leitungsorgan freigeben und kommunizieren.
Jährlichen Review der Methodik institutionalisieren.

Beispielnachweise

kwF-Methodik-Dokument (freigegeben)
Kriterienkatalog mit Bewertungsmatrix
Leitungsorgan-Beschluss zur Methodik
Review-Protokoll der Methodik

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.5.9 A.5.36

ID: DORA-KWF-001

DORA-KWF-002 reviewed initial

Prozesslandkarte für kwF-Bestimmung aufbauen

Eine vollständige Prozesslandkarte identifiziert alle institutsspezifischen Prozesse als Grundlage für die kwF-Bewertung.

Themenbereich: Kritische oder wichtige Funktionen
Sollzustand: Eine aktuelle Prozesslandkarte erfasst alle Prozesse mit Zuordnung zu regulierten Tätigkeiten, IKT-Abhängigkeiten, Kritikalität und Verantwortlichkeiten. Die Landkarte wird regelmässig aktualisiert und mit dem IKT-Risikoinventar abgeglichen.
DORA / MaRisk: DORA Art. 6 Abs. 1 (IKT-Risikomanagement), Art. 28 Abs. 3 | MaRisk AT 4.3.3 (Risikoinventar), AT 9 (Auslagerungen)

Umsetzungsschritte

Prozesse institutsweit inventarisieren und klassifizieren.
Regulierte Tätigkeiten den Prozessen zuordnen.
IKT-Abhängigkeiten je Prozess dokumentieren.
Prozesslandkarte in kwF-Bewertung integrieren.

Beispielnachweise

Prozesslandkarte (vollständig)
Prozess-Steckbriefe mit IKT-Abhängigkeiten
Zuordnung regulierte Tätigkeiten
Aktualisierungsprotokoll

ISO/IEC 27001 Anker

A.5.7 A.5.9 A.5.10 A.8.1

ID: DORA-KWF-002

DORA-KWF-003 reviewed initial

Ausfallszenarien für kwF bewerten

Die Auswirkung eines Ausfalls von Prozessen, IKT-Systemen oder Dienstleistern auf kwF wird systematisch bewertet.

Themenbereich: Kritische oder wichtige Funktionen
Sollzustand: Ein standardisierter Prozess bewertet Ausfallszenarien für alle potenziell kritischen Funktionen. Die Bewertung prüft zeitkritische Wiederherstellungsanforderungen, finanzielle Auswirkungen, Reputationsschäden und regulatorische Konsequenzen.
DORA / MaRisk: DORA Art. 7 (Risikoanalyse), Art. 11 (BCM) | MaRisk AT 4.3.3, BT 3 (Notfallmanagement)

Umsetzungsschritte

Ausfallszenarien für identifizierte kwF definieren.
Maximal tolerierbare Ausfallzeiten (MTPD) und Wiederherstellungsziele (RTO/RPO) festlegen.
Auswirkungen auf finanzielle Leistungsfähigkeit und Solidität bewerten.
Szenarioergebnisse dokumentieren und in kwF-Entscheidung einfliessen lassen.

Beispielnachweise

Ausfallszenario-Analyse je kwF
MTPD/RTO/RPO-Definitionen
Finanzielle Auswirkungsanalyse
kwF-Entscheidungsdokumentation

ISO/IEC 27001 Anker

A.5.7 A.5.29 A.5.30 A.8.34

ID: DORA-KWF-003

DORA-KWF-004 reviewed initial

Pflichtverletzungsszenarien für kwF bewerten

Die Auswirkung einer Pflichtverletzung durch Ausfall oder Beeinträchtigung von Prozessen oder IKT-Systemen wird systematisch bewertet.

Themenbereich: Kritische oder wichtige Funktionen
Sollzustand: Ein standardisierter Prozess bewertet Pflichtverletzungsszenarien für alle potenziell kritischen Funktionen. Die Bewertung prüft Verstösse gegen aufsichtsrechtliche Pflichten, Zulassungsanforderungen, Melde- und Dokumentationspflichten sowie sonstige regulatorische Anforderungen.
DORA / MaRisk: DORA Art. 7 (Risikoanalyse), Art. 3 Ziffer 23 | MaRisk AT 4.3.3, AT 9 Tz. 3

Umsetzungsschritte

Pflichtverletzungsszenarien für identifizierte kwF definieren.
Regulatorische Pflichten und Konsequenzen je Szenario dokumentieren.
Auswirkungen auf Zulassung und Aufsichtspflichten bewerten.
Szenarioergebnisse dokumentieren und in kwF-Entscheidung einfliessen lassen.

Beispielnachweise

Pflichtverletzungsszenario-Analyse je kwF
Regulatorische Pflichtenübersicht
Aufsichtsrechtliche Konsequenzenanalyse
kwF-Entscheidungsdokumentation

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.5.36 A.6.1

ID: DORA-KWF-004

DORA-KWF-005 reviewed initial

kwF-Managementfreigabe und Dokumentation sicherstellen

Die Einstufung als kritische oder wichtige Funktion wird managementseitig freigegeben und dokumentiert.

Themenbereich: Kritische oder wichtige Funktionen
Sollzustand: Jede kwF-Einstufung wird auf der dafür vorgesehenen Management-Ebene freigegeben. Die Entscheidung wird mit Begründung, Kriterienanwendung und Verantwortlichkeiten dokumentiert. Änderungen der Einstufung durchlaufen denselben Freigabeprozess.
DORA / MaRisk: DORA Art. 5 (Governance), Art. 28 Abs. 3 | MaRisk AT 4.3.1 (Gesamtverantwortung)

Umsetzungsschritte

Freigabestufen für kwF-Einstufungen definieren.
Entscheidungsvorlage mit Kriterienanwendung entwickeln.
kwF-Entscheidungen dokumentieren und managementseitig freigeben.
Änderungsmanagement für kwF-Einstufungen etablieren.

Beispielnachweise

kwF-Entscheidungsvorlage mit Kriterien
Managementfreigabe je kwF
Änderungsdokumentation bei Reklassifikation
Jährlicher Review der kwF-Entscheidungen

ISO/IEC 27001 Anker

A.5.1 A.5.2 A.5.3 A.5.36

ID: DORA-KWF-005

DORA-KWF-006 reviewed initial

kwF-Review-Zyklus institutionalisieren

Die kwF-Einstufungen werden regelmässig überprüft und bei wesentlichen Änderungen aktualisiert.

Themenbereich: Kritische oder wichtige Funktionen
Sollzustand: Ein dokumentierter Review-Prozess prüft kwF-Einstufungen mindestens jährlich sowie anlassbezogen bei wesentlichen Änderungen der Geschäftstätigkeit, Organisation, IKT-Landschaft oder regulatorischen Anforderungen.
DORA / MaRisk: DORA Art. 6 Abs. 5 (Review), Art. 28 Abs. 3 | MaRisk AT 4.4.2 (Review)

Umsetzungsschritte

Jährlichen Review-Termin für kwF-Einstufungen festlegen.
Anlassbezogene Review-Trigger definieren.
Review-Ergebnisse dokumentieren und bei Änderungen Managementfreigabe einholen.
Review-Historie je kwF führen.

Beispielnachweise

Jährlicher kwF-Review-Bericht
Anlassbezogene Reviews mit Begründung
Änderungshistorie je kwF
Managementfreigabe nach Review

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.9.1 A.10.1

ID: DORA-KWF-006

DORA-RTA-001 reviewed initial

Tätigkeiteninventar für regulierte Tätigkeiten aufbauen

Das Institut verfügt über ein vollständiges Inventar aller regulierten Tätigkeiten als Grundlage für kwF, Vorfallklassifikation und Informationsregister.

Themenbereich: Regulierte Tätigkeiten
Sollzustand: Ein zentrales Tätigkeiteninventar erfasst alle regulierten Tätigkeiten des Instituts mit Zuordnung zu nationalen und europäischen Begrifflichkeiten, EBA-Identifikatoren und betroffenen IKT-Dienstleistungen.
DORA / MaRisk: DORA Art. 3 Ziffer 23, Art. 19 (Vorfallklassifikation), Art. 28 Abs. 3 (Informationsregister) | MaRisk AT 4.3.3 (Risikoinventar)

Umsetzungsschritte

Regulierte Tätigkeiten aus Zulassung und Geschäftsmodell identifizieren.
Tätigkeiten mit europäischen Begrifflichkeiten und EBA-Identifikatoren abgleichen.
Zuordnung zu kwF, IKT-Dienstleistungen und Informationsregister herstellen.
Inventar regelmässig aktualisieren und mit Zulassungsänderungen abgleichen.

Beispielnachweise

Tätigkeiteninventar (aktuell)
Mapping nationale zu europäische Begrifflichkeiten
EBA-Identifier-Liste
Aktualisierungsprotokoll

ISO/IEC 27001 Anker

A.5.7 A.5.9 A.5.33

ID: DORA-RTA-001

DORA-RTA-002 reviewed initial

Mapping zwischen nationalen und europäischen Tätigkeitsbegrifflichkeiten etablieren

Nationale und europäische Begrifflichkeiten für regulierte Tätigkeiten werden konsistent gemappt und dokumentiert.

Themenbereich: Regulierte Tätigkeiten
Sollzustand: Ein dokumentiertes Mapping bildet nationale Tätigkeitsbezeichnungen auf europäische Begrifflichkeiten (EBA-Identifier, CRR/CRD, MiFID, AIFMD etc.) ab. Das Mapping wird bei regulatorischen Änderungen aktualisiert.
DORA / MaRisk: DORA Art. 28 Abs. 3 (Informationsregister), Art. 19 (Vorfallklassifikation) | MaRisk AT 4.3.3

Umsetzungsschritte

Nationale Tätigkeitsbezeichnungen aus Zulassungsbescheiden erfassen.
Europäische Begrifflichkeiten und EBA-Identifier recherchieren und zuordnen.
Mapping-Dokumentation mit Quellen und Gültigkeitsstand erstellen.
Aktualisierung bei regulatorischen oder geschäftlichen Änderungen sicherstellen.

Beispielnachweise

Mapping-Dokumentation national/europäisch
EBA-Identifier-Zuordnungstabelle
Quellenverzeichnis für Begrifflichkeiten
Aktualisierungsnachweise

ISO/IEC 27001 Anker

A.5.33 A.5.34 A.5.36

ID: DORA-RTA-002

DORA-RTA-003 reviewed initial

EBA-Identifier-Logik für das Informationsregister umsetzen

Die EBA-Identifier und deren Zuordnung zu IKT-Dienstleistungen sind für das Informationsregister korrekt und aktuell.

Themenbereich: Regulierte Tätigkeiten
Sollzustand: Die EBA-Identifier sind für jede regulierte Tätigkeit erfasst und den zugehörigen IKT-Dienstleistungen zugeordnet. Die Datenqualität wird regelmässig geprüft und Abweichungen werden korrigiert.
DORA / MaRisk: DORA Art. 28 Abs. 3 (Informationsregister) | MaRisk AT 9 Tz. 6

Umsetzungsschritte

EBA-Identifier aus EBA-Register und aufsichtlichen Vorgaben ableiten.
Identifier den regulierten Tätigkeiten zuordnen.
Verknüpfung mit IKT-Dienstleistungen im Informationsregister herstellen.
Datenqualität durch regelmässige Abgleiche sichern.

Beispielnachweise

EBA-Identifier-Tabelle mit Tätigkeitszuordnung
Verknüpfung im Informationsregister
Datenqualitätsbericht
Korrekturprotokoll bei Abweichungen

ISO/IEC 27001 Anker

A.5.33 A.5.34 A.5.36

ID: DORA-RTA-003

DORA-RTA-004 reviewed initial

Registerdatenqualität für regulierte Tätigkeiten sicherstellen

Die Datenqualität der regulierten Tätigkeiten im Informationsregister wird systematisch überprüft und verbessert.

Themenbereich: Regulierte Tätigkeiten
Sollzustand: Ein Prozess zur Sicherstellung der Registerdatenqualität definiert Vollständigkeits-, Korrektheits- und Aktualitätskriterien. Regelmässige Qualitätskontrollen identifizieren Fehler und leiten Korrekturmaßnahmen ein. Verantwortlichkeiten für Datenpflege und -prüfung sind festgelegt.
DORA / MaRisk: DORA Art. 28 Abs. 3 (Informationsregister), Art. 29 (Datenqualität) | MaRisk AT 9 Tz. 6

Umsetzungsschritte

Datenqualitätskriterien für regulierte Tätigkeiten definieren.
Regelmässige Qualitätskontrollen (mindestens quartalsweise) durchführen.
Fehlerprotokoll mit Korrekturmaßnahmen und Fristen führen.
Verantwortlichkeiten für Datenpflege und Qualitätssicherung zuweisen.

Beispielnachweise

Datenqualitätsbericht (aktuell)
Fehlerprotokoll mit Korrekturmaßnahmen
Kontrollplan für Registerdatenqualität
Review-Protokoll der Datenqualität

ISO/IEC 27001 Anker

A.5.33 A.5.34 A.5.35 A.5.36

ID: DORA-RTA-004

DORA-CON-001 reviewed initial

Vertragsklassifikation für IKT-Dienstleistungen etablieren

IKT-Dienstleistungsverträge werden nach Kritikalität und Komplexität klassifiziert, um angemessene Anforderungen je Kategorie zu definieren.

Themenbereich: IKT-Verträge
Sollzustand: Eine verbindliche Vertragsklassifikation unterscheidet Baseline IKT-Leistung, kontrollrelevante IKT-Leistung, kwF-relevante IKT-Leistung und strategisch kritische IKT-Leistung. Jede Kategorie hat definierte Mindestanforderungen an Vertragsinhalte, Kontrollrechte und Überwachung.
DORA / MaRisk: DORA Art. 28 (Vertragsanforderungen), Art. 29 (Überwachung) | MaRisk AT 9 (Auslagerungen), BT 4

Umsetzungsschritte

Klassifikationskriterien für IKT-Verträge entwickeln.
Kategorien (Baseline, kontrollrelevant, kwF-relevant, strategisch kritisch) definieren.
Bestandsverträge klassifizieren und nachkategorisieren.
Klassifikation bei Vertragsänderungen und jährlich überprüfen.

Beispielnachweise

Vertragsklassifikations-Richtlinie
Klassifizierte Vertragsliste
Überprüfungsprotokoll der Klassifikation
Abweichungsdokumentation

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.33

ID: DORA-CON-001

DORA-CON-002 reviewed initial

Mindestvertragsinhalte nach DORA sicherstellen

IKT-Dienstleistungsverträge enthalten alle nach DORA und institutsspezifisch erforderlichen Mindestinhalte.

Themenbereich: IKT-Verträge
Sollzustand: Eine standardisierte Vertragsprüfung stellt sicher, dass alle IKT-Verträge Leistungsbeschreibung, Rechte und Pflichten, Informationssicherheitsanforderungen, SLA-Vereinbarungen, Datenstandorte, Datenschutzklauseln, Kündigungsfristen, Haftungsregelungen und Änderungsmanagement enthalten.
DORA / MaRisk: DORA Art. 28 Abs. 2 (Vertragsanforderungen) | MaRisk AT 9 Tz. 7, BT 4 Tz. 3

Umsetzungsschritte

Mindestvertragsinhalte je Klassifikationskategorie definieren.
Vertragsprüfprozess mit Checkliste und Freigabestufen etablieren.
Bestandsverträge auf Lücken prüfen und nachbessern.
Abweichungen dokumentieren und managementseitig freigeben.

Beispielnachweise

Vertragsanforderungsmatrix je Kategorie
Prüf-Checkliste für IKT-Verträge
Lückenanalyse Bestandsverträge
Abweichungsregister mit Freigabe

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.31 A.5.33

ID: DORA-CON-002

DORA-CON-003 reviewed initial

Unterauftragnehmerregelungen vertraglich sichern

Verträge mit IKT-Dienstleistern enthalten Regelungen zur Offenlegung, Genehmigung und Steuerung von Unterauftragnehmern.

Themenbereich: IKT-Verträge
Sollzustand: Alle IKT-Verträge verpflichten Dienstleister zur Offenlegung wesentlicher Unterauftragnehmer und zur Einholung der Zustimmung bei Änderungen der Unterauftragnehmerkette. Ein aktuelles Unterauftragnehmerverzeichnis dokumentiert die vollständige Leistungskette.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. e (Unterauftragnehmer) | MaRisk AT 9 Tz. 5, BT 4 Tz. 2

Umsetzungsschritte

Vertragsklauseln zu Unterauftragnehmern (Offenlegung, Genehmigung, Änderung) definieren.
Unterauftnehmerverzeichnis je kritischer IKT-Dienstleistung aufbauen.
Regelmässige Aktualisierung und Prüfung der Unterauftragnehmerkette.
Konzentrationsrisiken durch gemeinsame Unterauftragnehmer identifizieren.

Beispielnachweise

Vertragsklauseln zu Unterauftragnehmern
Unterauftragnehmerverzeichnis (aktuell)
Genehmigungsdokumentation bei Änderungen
Konzentrationsrisikoanalyse Unterauftragnehmer

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.21 A.5.22

ID: DORA-CON-003

DORA-CON-004 reviewed initial

Exit-Regelungen vertraglich verankern

IKT-Verträge enthalten verbindliche Exit-Regelungen für eine geordnete Beendigung, Übertragung oder Ersetzung der Dienstleistung.

Themenbereich: IKT-Verträge
Sollzustand: Alle IKT-Verträge mit kwF-Relevanz enthalten Exit-Klauseln mit Kündigungsfristen, Datenrückgabe- und Löschverpflichtungen, Übergangsunterstützung, Migrationshilfen und Herausgabepflichten. Die Exit-Regelungen werden regelmässig auf Angemessenheit und Umsetzbarkeit geprüft.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. i (Exit), Art. 29 Abs. 5 | MaRisk AT 9 Tz. 9, BT 4 Tz. 6

Umsetzungsschritte

Exit-Mindestklauseln je Vertragskategorie definieren.
Datenrückgabe-, Lösch- und Migrationsverpflichtungen vertraglich regeln.
Übergangsfristen und Unterstützungsleistungen vereinbaren.
Exit-Regelungen regelmässig auf Aktualität und Umsetzbarkeit prüfen.

Beispielnachweise

Exit-Klauseln je IKT-Vertrag
Datenrückgabe- und Löschkonzept
Prüfprotokoll Exit-Regelungen
Abweichungsdokumentation

ISO/IEC 27001 Anker

A.5.19 A.5.29 A.5.30 A.5.36

ID: DORA-CON-004

DORA-CON-005 reviewed initial

Audit- und Kontrollrechte vertraglich sichern

IKT-Verträge enthalten umfassende Audit- und Kontrollrechte für das Institut und dessen Prüfungsinstanzen.

Themenbereich: IKT-Verträge
Sollzustand: Verträge mit kwF-relevanten IKT-Dienstleistern enthalten Rechte auf Vor-Ort-Prüfungen, Einsichtnahme in Unterlagen, Zugang zu Systemen und Informationen sowie das Recht auf Prüfungen durch externe Prüfer und Aufsichtsbehörden.
DORA / MaRisk: DORA Art. 28 Abs. 2 lit. f–h (Kontroll- und Zugangsrechte) | MaRisk AT 9 Tz. 7, BT 4 Tz. 4

Umsetzungsschritte

Audit- und Kontrollrechte als Pflichtklauseln definieren.
Ausübungskonzept für Kontrollrechte (Häufigkeit, Umfang, Eskalation) erstellen.
Kontrollrechte regelmässig ausüben und Ergebnisse dokumentieren.
Verweigerung von Kontrollrechten als Risikoindikator eskalieren.

Beispielnachweise

Audit-/Kontrollrechte-Klauseln je Vertrag
Kontrollplan für das laufende Jahr
Durchgeführte Audits und Prüfberichte
Eskalationsvermerk bei verweigerten Rechten

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.36 A.9.2

ID: DORA-CON-005

DORA-CON-006 reviewed initial

Berichtspflichten in IKT-Verträgen regeln

IKT-Verträge enthalten verbindliche Berichtspflichten über Leistungserbringung, Sicherheitslage und Risikoentwicklung.

Themenbereich: IKT-Verträge
Sollzustand: Verträge mit IKT-Dienstleistern definieren regelmässige Berichtspflichten zu SLA-Einhaltung, Sicherheitsvorfällen, Änderungen der Leistungserbringung, Personalveränderungen in Schlüsselfunktionen und Ergebnissen von Sicherheitsprüfungen.
DORA / MaRisk: DORA Art. 29 Abs. 1–2 (Überwachung und Berichtswesen) | MaRisk AT 9 Tz. 8, BT 4 Tz. 5

Umsetzungsschritte

Berichtsanforderungen je Vertragskategorie definieren.
Berichtsformate, -frequenzen und -empfänger festlegen.
Eingehende Berichte prüfen und bei Abweichungen eskalieren.
Berichtsqualität regelmässig bewerten und nachsteuern.

Beispielnachweise

Berichtsanforderungsmatrix je Vertrag
Eingegangene Dienstleisterberichte
Prüfprotokoll der Berichtsinhalte
Eskalationsnachweise bei Berichtsmängeln

ISO/IEC 27001 Anker

A.5.19 A.5.23 A.5.35 A.5.36

ID: DORA-CON-006

DORA-POL-001 reviewed initial

Richtlinieninventar für IKT-Sicherheits- und DORA-Richtlinien aufbauen

Das Institut verfügt über ein vollständiges und aktuelles Inventar aller IKT-Sicherheitsrichtlinien und DORA-relevanten Richtlinien.

Themenbereich: IKT-Richtlinien
Sollzustand: Ein zentrales Richtlinieninventar erfasst alle IKT-Richtlinien mit Zweck, Geltungsbereich, Version, Freigabedatum, verantwortlicher Rolle, Review-Zyklus und Verknüpfung zu DORA-, MaRisk- und ISO-Anforderungen.
DORA / MaRisk: DORA Art. 6 Abs. 4 (Dokumentation), Art. 8 (Schutzmaßnahmen) | MaRisk AT 4.4.2 (Dokumentation)

Umsetzungsschritte

Richtlinienkategorien (Sicherheit, IKT-Risiko, BCM, Auslagerungen etc.) definieren.
Bestehende Richtlinien inventarisieren und kategorisieren.
Richtlinienlücken gegen DORA- und MaRisk-Anforderungen identifizieren.
Inventar regelmässig aktualisieren und mit Richtlinien-Review synchronisieren.

Beispielnachweise

Richtlinieninventar (vollständig, aktuell)
Lückenanalyse Richtlinien vs. DORA/MaRisk
Kategorisierungsmatrix
Aktualisierungsprotokoll

ISO/IEC 27001 Anker

A.5.1 A.5.2 A.5.33 A.5.36

ID: DORA-POL-001

DORA-POL-002 reviewed initial

Dokumentenlenkung für IKT-Richtlinien etablieren

IKT-Richtlinien durchlaufen einen standardisierten Dokumentenlenkungsprozess von Erstellung über Freigabe bis zur Archivierung.

Themenbereich: IKT-Richtlinien
Sollzustand: Ein dokumentierter Dokumentenlenkungsprozess definiert Phasen (Entwurf, Abstimmung, Freigabe, Veröffentlichung, Review, Archivierung), Rollen (Autor, Prüfer, Freigeber) und Fristen. Jede Richtlinie hat eine eindeutige Version, Änderungshistorie und Gültigkeitsdauer.
DORA / MaRisk: DORA Art. 6 Abs. 4 (Dokumentation) | MaRisk AT 4.4.2

Umsetzungsschritte

Dokumentenlenkungsprozess mit Phasen und Rollen definieren.
Richtlinienvorlage mit Pflichtfeldern entwickeln.
Versionierung und Änderungshistorie sicherstellen.
Archivierungsregeln für abgelöste Richtlinien festlegen.

Beispielnachweise

Dokumentenlenkungsprozess (Dokument)
Richtlinienvorlage mit Metadaten
Änderungshistorie je Richtlinie
Archivierungsnachweis

ISO/IEC 27001 Anker

A.5.1 A.5.33 A.5.34 A.5.36

ID: DORA-POL-002

DORA-POL-003 reviewed initial

Leitungsorganfreigabe für IKT-Richtlinien sicherstellen

Wesentliche IKT-Richtlinien werden durch das Leitungsorgan oder die dafür bestimmte Management-Ebene freigegeben.

Themenbereich: IKT-Richtlinien
Sollzustand: Eine Freigabematrix definiert, welche Richtlinien durch das Leitungsorgan, welche durch die Geschäftsleitung und welche durch Fachbereichsleitungen freigegeben werden. Der Freigabeprozess ist dokumentiert und nachvollziehbar.
DORA / MaRisk: DORA Art. 5 Abs. 1 (Leitungsorgan) | MaRisk AT 4.3.1 (Gesamtverantwortung)

Umsetzungsschritte

Freigabematrix für IKT-Richtlinien definieren.
Freigabeprozess mit Vorlagen und Fristen standardisieren.
Freigaben dokumentieren und in der Richtlinie vermerken.
Freigabe bei Richtlinienänderungen erneut einholen.

Beispielnachweise

Freigabematrix IKT-Richtlinien
Freigabevermerk in jeder Richtlinie
Sitzungsprotokolle bei Leitungsorgan-Freigabe
Änderungsdokumentation mit erneuter Freigabe

ISO/IEC 27001 Anker

A.5.1 A.5.2 A.5.3 A.5.36

ID: DORA-POL-003

DORA-POL-004 reviewed initial

Review-Trigger für IKT-Richtlinien definieren

IKT-Richtlinien werden anlassbezogen und mindestens jährlich auf Aktualität und Angemessenheit überprüft.

Themenbereich: IKT-Richtlinien
Sollzustand: Ein dokumentierter Review-Prozess definiert verbindliche Trigger für die Überprüfung von IKT-Richtlinien: mindestens jährlich, nach wesentlichen IKT-Vorfällen, nach Resilienztests, nach Audits, nach behördlichen Hinweisen und bei wesentlichen Änderungen der Geschäftstätigkeit, Bedrohungslage oder rechtlichen Anforderungen.
DORA / MaRisk: DORA Art. 6 Abs. 5 (Review), Art. 12 (Tests) | MaRisk AT 4.4.2 (Review)

Umsetzungsschritte

Review-Trigger-Katalog für IKT-Richtlinien definieren.
Jährlichen Review-Plan für alle Richtlinien erstellen.
Anlassbezogene Reviews bei Trigger-Ereignissen auslösen.
Review-Ergebnisse dokumentieren und bei Bedarf Richtlinien anpassen.

Beispielnachweise

Review-Trigger-Katalog
Jährlicher Review-Plan
Durchgeführte Reviews mit Ergebnissen
Richtlinienänderungen aus Reviews

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.9.1 A.10.1

ID: DORA-POL-004

DORA-POL-005 reviewed initial

Kontroll- und Nachweislogik in IKT-Richtlinien integrieren

IKT-Richtlinien enthalten eine dokumentierte Kontroll- und Nachweislogik, die die Einhaltung der Richtlinienanforderungen belegbar macht.

Themenbereich: IKT-Richtlinien
Sollzustand: Jede IKT-Richtlinie enthält einen Abschnitt zur Kontroll- und Nachweislogik, der die zugehörigen Kontrollen, Nachweise, Verantwortlichkeiten und Prüffrequenzen beschreibt. Die Kontroll- und Nachweislogik ist mit dem IKT-Kontrollsystem der Plattform abgestimmt.
DORA / MaRisk: DORA Art. 8 (Schutzmaßnahmen), Art. 10 (Wirksamkeit) | MaRisk AT 4.4.2 (Kontrollsystem)

Umsetzungsschritte

Kontroll- und Nachweisanforderungen je Richtlinie definieren.
Nachweisartefakte und Aufbewahrungsfristen festlegen.
Verknüpfung mit dem plattformweiten Evidenzmodell herstellen.
Kontroll- und Nachweislogik regelmässig auf Vollständigkeit prüfen.

Beispielnachweise

Kontroll- und Nachweislogik je Richtlinie
Verknüpfungstabelle Richtlinien–Kontrollen–Nachweise
Prüfprotokoll der Kontroll- und Nachweislogik
Abweichungsbericht

ISO/IEC 27001 Anker

A.5.35 A.5.36 A.8.8 A.9.1

ID: DORA-POL-005

REG-NIS2-001 reviewed initial

NIS2-Anwendungsbereich für das Institut prüfen und dokumentieren

Das Institut prüft, ob und in welchem Umfang der NIS2-Anwendungsbereich für seine Tätigkeiten relevant ist.

Themenbereich: Regulatory Landscape
Sollzustand: Eine dokumentierte Prüfung bewertet den Einrichtungsstatus (besonders wichtig, wichtig, nicht betroffen) nach NIS2. Die Prüfung berücksichtigt die DORA-Ausnahmeregelung und dokumentiert die Begründung für die Einstufung.
DORA / MaRisk: DORA Art. 1 Abs. 3 (Ausnahme von NIS2) | –

Umsetzungsschritte

NIS2-Kriterien für besonders wichtige und wichtige Einrichtungen prüfen.
DORA-Ausnahmeregelung und deren Voraussetzungen dokumentieren.
Einrichtungsstatus institutsspezifisch bestimmen und begründen.
Prüfung jährlich und bei wesentlichen Änderungen wiederholen.

Beispielnachweise

NIS2-Anwendungsbereichsprüfung (dokumentiert)
Einrichtungsstatus-Begründung
DORA-Ausnahmeprüfung
Jährliches Review der Einstufung

ISO/IEC 27001 Anker

A.5.1 A.5.2 A.5.36

ID: REG-NIS2-001

REG-CRA-001 reviewed initial

CRA-Produktbezug für IKT-Produkte und -Dienstleistungen prüfen

Das Institut prüft, welche IKT-Produkte mit digitalen Elementen in den Anwendungsbereich des Cyber Resilience Act fallen.

Themenbereich: Regulatory Landscape
Sollzustand: Eine dokumentierte Prüfung identifiziert IKT-Produkte mit digitalen Elementen, die unter den CRA fallen könnten. Hersteller-, Händler- und Betreiberpflichten werden eingeordnet und in die Beschaffungs- und Vertragsprozesse integriert.
DORA / MaRisk: DORA Art. 28 Abs. 2 (Vertragsanforderungen), Art. 29 (Überwachung) | MaRisk AT 9 (Auslagerungen)

Umsetzungsschritte

IKT-Produkte mit digitalen Elementen inventarisieren.
CRA-Anwendungsbereich je Produkt prüfen.
Hersteller-/Lieferantenpflichten in Beschaffungsanforderungen übersetzen.
Schwachstellenmanagement und Security-Updates in Verträgen adressieren.

Beispielnachweise

CRA-Produktinventar
Anwendungsbereichsprüfung je Produkt
Beschaffungsanforderungen mit CRA-Bezug
Vertragsklauseln zu Updates und Schwachstellen

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.21 A.8.34

ID: REG-CRA-001

REG-AIA-001 reviewed initial

KI-Inventar nach AI Act aufbauen

Das Institut verfügt über ein vollständiges Inventar aller eingesetzten KI-Systeme als Grundlage für die AI-Act-Governance.

Themenbereich: Regulatory Landscape
Sollzustand: Ein KI-Inventar erfasst alle KI-Systeme mit Klassifikation (verboten, Hochrisiko, geringes Risiko, minimales Risiko), Zweck, Einsatzbereich, Datenquellen, Verantwortlichen und Risikobewertung.
DORA / MaRisk: DORA Art. 6 (IKT-Risikomanagement) | MaRisk AT 4.3.3

Umsetzungsschritte

KI-Systeme institutsweit identifizieren und erfassen.
Klassifikation nach AI-Act-Risikokategorien durchführen.
Verantwortlichkeiten für KI-Governance zuweisen.
Inventar regelmässig aktualisieren und mit Änderungsmanagement verbinden.

Beispielnachweise

KI-Inventar (vollständig, aktuell)
Klassifikationsmatrix nach AI-Act-Kategorien
Verantwortungsmatrix KI-Governance
Aktualisierungsprotokoll

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.5.9 A.5.33

ID: REG-AIA-001

REG-AIA-002 reviewed initial

KI-Kompetenz nach AI Act institutsweit sicherstellen

Mitarbeitende und Führungskräfte verfügen über ausreichende KI-Kompetenz entsprechend ihrer Rolle und Verantwortung.

Themenbereich: Regulatory Landscape
Sollzustand: Ein rollenbasiertes KI-Kompetenzprogramm vermittelt Grundlagenwissen zu KI-Funktionsweise, -Risiken, -Chancen und regulatorischen Anforderungen. Das Programm wird mindestens jährlich durchgeführt und aktualisiert.
DORA / MaRisk: DORA Art. 5 Abs. 2 (Personal), Art. 6 Abs. 3 (Schulung) | MaRisk AT 7.1, AT 7.2

Umsetzungsschritte

KI-Kompetenzbedarf rollenbasiert erheben.
Schulungsprogramm mit Basis- und Vertiefungsmodulen entwickeln.
Schulungen durchführen und Teilnahme dokumentieren.
KI-Kompetenz regelmässig auf Aktualität prüfen und Programm anpassen.

Beispielnachweise

KI-Kompetenzrahmen mit Rollenzuordnung
Schulungsprogramm und -materialien
Teilnehmernachweise
Kompetenzbewertung und -entwicklung

ISO/IEC 27001 Anker

A.5.2 A.5.3 A.6.3 A.7.2

ID: REG-AIA-002

OSS-001 reviewed defined

Open-Source-Richtlinie etablieren

Die Nutzung von Open Source Software ist durch eine freigegebene Richtlinie geregelt.

Themenbereich: Open Source & Software Supply Chain
Sollzustand: Eine vom Management freigegebene Richtlinie definiert den Geltungsbereich, zulässige Lizenzen, Genehmigungsprozess, Verantwortlichkeiten und Eskalationswege. Die Richtlinie wird jährlich überprüft und bei wesentlichen Änderungen aktualisiert.
DORA / MaRisk: Art. 5, Art. 8, Art. 9, Art. 24, Art. 28 | AT 4.3.1, AT 7.2

Umsetzungsschritte

IST-Stand zur OSS-Nutzung und Lizenzierung erheben.
Richtlinienentwurf mit Geltungsbereich, Lizenzmatrix, Genehmigungsprozess und Rollen erstellen.
Richtlinie durch Management freigeben und an alle relevanten Stellen kommunizieren.
Jährlichen Review-Prozess institutionalisieren.

Beispielnachweise

Freigegebene Open-Source-Richtlinie (aktuell)
Lizenz-Compliance-Matrix
Kommunikationsnachweis an Mitarbeitende und Lieferanten
Review-Protokoll mit Änderungshistorie

ISO/IEC 27001 Anker

A.5.1 A.5.2 A.5.3 A.5.36 A.8.1

ID: OSS-001

OSS-002 reviewed defined

SBOM-Erzeugung automatisieren

Für jede relevante Anwendung und jedes Release wird automatisiert eine SBOM erzeugt.

Themenbereich: Open Source & Software Supply Chain
Sollzustand: Die SBOM-Erzeugung ist in die CI/CD-Pipeline integriert. Jede SBOM dokumentiert direkte und transitive Abhängigkeiten mit Version, Lizenz und Herkunft. SBOMs werden versioniert, archiviert und mit dem Schwachstellenmanagement verknüpft.
DORA / MaRisk: Art. 6, Art. 7, Art. 8, Art. 24, Art. 28 | AT 4.3.2, AT 7.2, BT 1.1

Umsetzungsschritte

SBOM-Werkzeuge (SPDX/CycloneDX) in der Build-Pipeline evaluieren und integrieren.
SBOM-Format und Pflichtfelder institutsspezifisch definieren.
Automatisierte SBOM-Erzeugung für alle relevanten Anwendungen einrichten.
SBOM-Versionierung und Archivierung je Release konfigurieren.
SBOM-Daten mit Schwachstellendatenbanken koppeln.

Beispielnachweise

SBOM-Generator-Konfiguration in CI/CD
Ausgelieferte SBOM je Release (SPDX/CycloneDX)
Archivierungsnachweis (Versionshistorie)
Integrationstest Schwachstellenabgleich

ISO/IEC 27001 Anker

A.8.2 A.8.7 A.8.8 A.8.19 A.8.25

ID: OSS-002

OSS-003 reviewed initial

OSS-Komponenteninventar pflegen

Ein zentrales Inventar erfasst alle relevanten OSS-Komponenten mit Anwendung, Version, Kritikalität und Eigentümer.

Themenbereich: Open Source & Software Supply Chain
Sollzustand: Das OSS-Komponenteninventar ist mit dem Informationsregister und dem IKT-Assetmanagement verknüpft. Jede Komponente ist mit SBOM-ID, Anwendung, Kritikalität, Patch-Status und Risikobewertung erfasst. Das Inventar wird bei jeder Änderung aktualisiert.
DORA / MaRisk: Art. 6, Art. 7, Art. 10, Art. 28 | AT 4.3.3, BT 1, BT 1.1

Umsetzungsschritte

Komponenteninventar-Datenmodell mit Pflichtfeldern definieren.
Erstinventur aller OSS-Komponenten aus SBOMs und manueller Erfassung durchführen.
Inventar mit Informationsregister, IKT-Assets und Anwendungen verknüpfen.
Regelmäßige Aktualisierung bei neuen Releases oder Änderungen etablieren.

Beispielnachweise

OSS-Komponenteninventar (vollständig, aktuell)
Datenmodell-Dokumentation
Verknüpfungsnachweis mit Informationsregister
Änderungsprotokoll je Komponente

ISO/IEC 27001 Anker

A.5.9 A.5.10 A.8.1 A.8.19 A.8.25

ID: OSS-003

OSS-004 reviewed defined

OSS-Schwachstellenmanagement betreiben

Schwachstellen in OSS-Komponenten werden systematisch erkannt, bewertet und behandelt.

Themenbereich: Open Source & Software Supply Chain
Sollzustand: Ein siebenstufiger Workflow (Erkennung → Triage → Impact Assessment → Entscheidung → Umsetzung → Verifikation → Reporting) steuert alle OSS-Schwachstellen. Critical- und High-Findings unterliegen einem Human Gate. Behandlungsergebnisse fließen in das Management-Reporting.
DORA / MaRisk: Art. 8, Art. 10, Art. 11, Art. 24, Art. 28 | AT 4.3.3, AT 4.3.4, BT 1.2

Umsetzungsschritte

SBOM-Daten automatisiert gegen NVD, OSV und GitHub Advisory abgleichen.
CVSS-basierte Bewertung mit Geschäftsrelevanz und kwF-Bezug etablieren.
Human Gates für Risikoakzeptanz, Patch-Ausnahmen und Lieferanteneskalation definieren.
Reporting-Prozess für kritische Findings aufbauen.

Beispielnachweise

Schwachstellenbericht (monatlich)
CVSS-Bewertung mit Triage-Entscheidung
Human-Gate-Dokumentation für Akzeptanzen
Management-Reporting zu OSS-Schwachstellen

ISO/IEC 27001 Anker

A.5.7 A.5.8 A.8.8 A.8.19 A.8.25

ID: OSS-004

OSS-005 reviewed defined

Patch- und Ausnahmemanagement steuern

Sicherheitskritische Updates werden zeitnah bewertet, Abweichungen werden begründet und überwacht.

Themenbereich: Open Source & Software Supply Chain
Sollzustand: Ein standardisiertes Patch-Management definiert SLA-Zeiträume je Kritikalität. Abweichungen (compensating control, risk acceptance, supplier escalation) werden im Decision Log dokumentiert und unterliegen einer zeitlichen Befristung. Kompensierende Kontrollen werden auf Wirksamkeit überwacht.
DORA / MaRisk: Art. 8, Art. 10, Art. 11, Art. 24, Art. 28 | AT 4.3.4, BT 2, BT 2.1

Umsetzungsschritte

Patch-SLA nach Kritikalität (Critical: 30d, High: 90d, Medium: 180d) festlegen.
Entscheidungsmatrix mit fünf Optionen (Patch, Upgrade, Compensating Control, Risk Acceptance, Supplier Escalation) etablieren.
Ausnahmeentscheidungen im Decision Log mit Begründung und Befristung dokumentieren.
Kompensierende Kontrollen auf Wirksamkeit prüfen.

Beispielnachweise

Patch-Status-Übersicht (aktuell)
Decision-Log-Einträge für Ausnahmen
Wirksamkeitsnachweise kompensierender Kontrollen
SLA-Erfüllungsreport

ISO/IEC 27001 Anker

A.5.7 A.8.8 A.8.19 A.8.25 A.8.26

ID: OSS-005

OSS-006 reviewed initial

Lieferanten-SBOM-Anforderungen durchsetzen

IKT-Dienstleister sind vertraglich verpflichtet, SBOMs und OSS-Prozessinformationen bereitzustellen.

Themenbereich: Open Source & Software Supply Chain
Sollzustand: Eine Standard-Vertragsklausel verpflichtet IKT-Dienstleister zur Bereitstellung von SBOMs in SPDX- oder CycloneDX-Format. Schwachstellen-Meldung und Patch-SLA sind vertraglich fixiert. Auditrechte für OSS-Prozesse sind vereinbart. Die Einhaltung wird regelmäßig überprüft.
DORA / MaRisk: Art. 28, Art. 30, Art. 33 | AT 9, BT 2.3

Umsetzungsschritte

Standard-Vertragsklausel für Lieferanten-SBOM entwickeln und mit Legal abstimmen.
SBOM-Anforderungen in IKT-Verträge und Ausschreibungen integrieren.
Lieferanten-SBOMs bei Vertragsbeginn und je Release anfordern.
SBOM-Compliance der Lieferanten regelmäßig überprüfen und dokumentieren.

Beispielnachweise

Standard-Vertragsklausel (freigegeben)
Lieferanten-SBOM-Verzeichnis
SBOM-Compliance-Bericht
Auditnachweis für Lieferanten-OSS-Prozesse

ISO/IEC 27001 Anker

A.5.19 A.5.20 A.5.21 A.5.22 A.5.23

ID: OSS-006

OFS-001 reviewed defined

API-Inventar und API-Risikoklassifizierung führen

Alle internen, externen und Drittanbieter-APIs sind inventarisiert, klassifiziert und mit Owner dokumentiert.

Themenbereich: Open Finance Security
Sollzustand: Vollständiges API-Inventar mit Authentifizierungsmethode, Rate-Limits, Datenklasse und Kritikalität.
DORA / MaRisk: Art. 8, Art. 9, Art. 28 | AT 4.3.1, AT 7.2, AT 9

Umsetzungsschritte

API-Endpunkte über Discovery-Tools und manuelle Erfassung inventarisieren
Klassifizierung nach Datenart (PII, Zahlungsdaten, öffentlich) und Kritikalität durchführen
Owner (Product Owner + Security Engineer) je API dokumentieren
Inventar in API-Gateway/Service Catalog integrieren und quartalsweise aktualisieren

Beispielnachweise

API-Inventar (CSV/JSON-Export mit Timestamp)
Klassifikationsmatrix mit Kritikalitätsbewertung
RACI je API-Endpunkt

ISO/IEC 27001 Anker

A.8 A.9 A.12

ID: OFS-001

OFS-002 reviewed defined

FAPI-/OIDC-konforme OAuth-Profile für sensible Finanz-APIs nutzen

OAuth 2.0 wird mit Authorization Code + PKCE, restriktiven Scopes und Token-Rotation eingesetzt.

Themenbereich: Open Finance Security
Sollzustand: Alle Open-Finance-APIs nutzen FAPI-konforme OAuth-Profile mit dokumentierter Client-Registrierung.
DORA / MaRisk: Art. 8, Art. 9, Art. 28 | AT 4.3.1, AT 7.2

Umsetzungsschritte

Authorization Code Grant + PKCE (Proof Key for Code Exchange) einführen
FAPI 2.0 Security Profile (FAPI 2.0 Baseline + Advanced) evaluieren
Client-Registrierung mit dokumentierten Redirect-URIs und Scope-Requests etablieren

Beispielnachweise

OAuth-Client-Register (Audit-Log-fähig)
FAPI-Konformitäts-Assessment (FAPI OP/CIBA-Test-Suite)
Scope- und Token-Policy-Dokumentation

ISO/IEC 27001 Anker

A.8 A.9 A.12

ID: OFS-002

OFS-003 reviewed defined

mTLS-Zertifikats- und Schlüsselmanagement betreiben

mTLS-Verbindungen werden mit sicheren TLS-Konfigurationen, Zertifikatsüberwachung und Sperrprozessen betrieben.

Themenbereich: Open Finance Security
Sollzustand: Zertifikatsinventar, Key-Rotation, TLS-Audit und Revocation-Test dokumentiert.
DORA / MaRisk: Art. 8, Art. 9 | AT 4.3.1, AT 7.2

Umsetzungsschritte

Zertifikatsinventar mit Ablaufdaten, CA, Domains und Verantwortlichen führen
TLS-Konfiguration auf mindestens TLS 1.2 festlegen (TLS 1.3 anstreben)
Automatische Zertifikatsrotation (z. B. via cert-manager/ACME) implementieren
Revocation-Test für jedes Zertifikat nach Deployment durchführen

Beispielnachweise

mTLS-Zertifikatsinventar mit SHA-256-Fingerprint
TLS-Konfigurations-Audit (SSL Labs, testssl.sh)
Revocation-Test-Protokoll mit Datum + Ergebnis

ISO/IEC 27001 Anker

A.8 A.10 A.12

ID: OFS-003

ISO-Anchor Kontrollmatrix

Visualisierte Zuordnung der DORA-Maßnahmen zu ISO/IEC 27001:2022 Kontrollankern.

A.10

OFS-003 · Open Finance Security

A.10.1

DORA-INC-004 · IKT-Vorfälle
DORA-TST-004 · Digitale Resilienztests
DORA-EVD-003 · Nachweise & Auditfähigkeit
DORA-TPR-015 · IKT-Drittparteienrisiko

+3 weitere Maßnahmen

A.10.2

DORA-RISK-003 · IKT-Risikomanagement
DORA-INC-002 · IKT-Vorfälle
DORA-INC-004 · IKT-Vorfälle
DORA-TST-004 · Digitale Resilienztests

+2 weitere Maßnahmen

A.12

OFS-001 · Open Finance Security
OFS-002 · Open Finance Security
OFS-003 · Open Finance Security

A.5.1

DORA-GOV-001 · Governance & Verantwortung
DORA-EVD-004 · Nachweise & Auditfähigkeit
DORA-IRM-001 · IKT-Risikomanagement
DORA-IRM-003 · IKT-Risikomanagement

+8 weitere Maßnahmen

A.5.10

DORA-IRM-005 · IKT-Risikomanagement
DORA-IRM-010 · IKT-Risikomanagement
DORA-KWF-002 · Kritische oder wichtige Funktionen
OSS-003 · Open Source & Software Supply Chain

A.5.12

DORA-RISK-001 · IKT-Risikomanagement

A.5.19

DORA-TPR-001 · IKT-Drittparteienrisiko
DORA-TPR-003 · IKT-Drittparteienrisiko
DORA-TPR-005 · IKT-Drittparteienrisiko
DORA-EXT-001 · IKT-Drittparteienrisiko

+21 weitere Maßnahmen

A.5.2

DORA-GOV-002 · Governance & Verantwortung
DORA-IRM-001 · IKT-Risikomanagement
DORA-IRM-002 · IKT-Risikomanagement
DORA-IRM-014 · IKT-Risikomanagement

+7 weitere Maßnahmen

A.5.20

DORA-TPR-001 · IKT-Drittparteienrisiko
DORA-TPR-003 · IKT-Drittparteienrisiko
DORA-TPR-005 · IKT-Drittparteienrisiko
DORA-EXT-001 · IKT-Drittparteienrisiko

+12 weitere Maßnahmen

A.5.21

DORA-TPR-002 · IKT-Drittparteienrisiko
DORA-EXT-002 · IKT-Drittparteienrisiko
DORA-TPR-004 · IKT-Drittparteienrisiko
DORA-TPR-007 · IKT-Drittparteienrisiko

+4 weitere Maßnahmen

A.5.22

DORA-TPR-002 · IKT-Drittparteienrisiko
DORA-TPR-004 · IKT-Drittparteienrisiko
DORA-TPR-010 · IKT-Drittparteienrisiko
DORA-CON-003 · IKT-Verträge

+1 weitere Maßnahmen

A.5.23

DORA-TPR-001 · IKT-Drittparteienrisiko
DORA-TPR-004 · IKT-Drittparteienrisiko
DORA-TPR-001 · IKT-Drittparteienrisiko
DORA-TPR-003 · IKT-Drittparteienrisiko

+3 weitere Maßnahmen

A.5.24

DORA-PDR-003 · Schutz, Erkennung & Reaktion
DORA-INC-001 · IKT-Vorfälle
DORA-INC-003 · IKT-Vorfälle
DORA-TST-002 · Digitale Resilienztests

+3 weitere Maßnahmen

A.5.25

DORA-INC-001 · IKT-Vorfälle
DORA-TPR-013 · IKT-Drittparteienrisiko

A.5.26

DORA-PDR-003 · Schutz, Erkennung & Reaktion
DORA-INC-001 · IKT-Vorfälle
DORA-TPR-013 · IKT-Drittparteienrisiko

A.5.27

DORA-INC-004 · IKT-Vorfälle

A.5.28

DORA-INC-002 · IKT-Vorfälle

A.5.29

DORA-PDR-003 · Schutz, Erkennung & Reaktion
DORA-TST-002 · Digitale Resilienztests
DORA-TST-005 · Resilienztests
DORA-TPR-008 · IKT-Drittparteienrisiko

+4 weitere Maßnahmen

A.5.3

DORA-GOV-002 · Governance & Verantwortung
DORA-IRM-001 · IKT-Risikomanagement
DORA-IRM-002 · IKT-Risikomanagement
DORA-IRM-014 · IKT-Risikomanagement

+5 weitere Maßnahmen

A.5.30

DORA-RISK-002 · IKT-Risikomanagement
DORA-PDR-004 · Schutz, Erkennung & Reaktion
DORA-TST-001 · Digitale Resilienztests
DORA-TST-002 · Digitale Resilienztests

+9 weitere Maßnahmen

A.5.31

DORA-TPR-003 · IKT-Drittparteienrisiko
DORA-REG-004 · Informationsregister
DORA-EXT-002 · IKT-Drittparteienrisiko
DORA-TPR-005 · IKT-Drittparteienrisiko

+1 weitere Maßnahmen

A.5.33

DORA-REG-004 · Informationsregister
DORA-EVD-001 · Nachweise & Auditfähigkeit
DORA-TPR-001 · IKT-Drittparteienrisiko
DORA-TPR-002 · IKT-Drittparteienrisiko

+11 weitere Maßnahmen

A.5.34

DORA-REG-004 · Informationsregister
DORA-EVD-001 · Nachweise & Auditfähigkeit
DORA-TPR-012 · IKT-Drittparteienrisiko
DORA-IRM-015 · IKT-Risikomanagement

+4 weitere Maßnahmen

A.5.35

DORA-GOV-003 · Governance & Verantwortung
DORA-RISK-003 · IKT-Risikomanagement
DORA-INC-002 · IKT-Vorfälle
DORA-TST-004 · Digitale Resilienztests

+17 weitere Maßnahmen

A.5.36

DORA-GOV-001 · Governance & Verantwortung
DORA-GOV-004 · Governance & Verantwortung
DORA-TPR-002 · IKT-Drittparteienrisiko
DORA-REG-001 · Informationsregister

+32 weitere Maßnahmen

A.5.37

DORA-GOV-002 · Governance & Verantwortung
DORA-REG-002 · Informationsregister
DORA-EVD-002 · Nachweise & Auditfähigkeit
DORA-TPR-014 · IKT-Drittparteienrisiko

+4 weitere Maßnahmen

A.5.4

DORA-GOV-001 · Governance & Verantwortung
DORA-IRM-003 · IKT-Risikomanagement
DORA-IRM-013 · IKT-Risikomanagement

A.5.5

DORA-INC-003 · IKT-Vorfälle

A.5.6

DORA-INC-003 · IKT-Vorfälle

A.5.7

DORA-GOV-003 · Governance & Verantwortung
DORA-PDR-002 · Schutz, Erkennung & Reaktion
DORA-TST-003 · Digitale Resilienztests
DORA-IRM-004 · IKT-Risikomanagement

+12 weitere Maßnahmen

A.5.8

DORA-IRM-004 · IKT-Risikomanagement
DORA-IRM-006 · IKT-Risikomanagement
DORA-IRM-007 · IKT-Risikomanagement
DORA-IRM-008 · IKT-Risikomanagement

+5 weitere Maßnahmen

A.5.9

DORA-RISK-001 · IKT-Risikomanagement
DORA-REG-001 · Informationsregister
DORA-IRM-004 · IKT-Risikomanagement
DORA-IRM-005 · IKT-Risikomanagement

+6 weitere Maßnahmen

A.6.1

DORA-IRM-016 · IKT-Risikomanagement
DORA-KWF-004 · Kritische oder wichtige Funktionen

A.6.3

DORA-GOV-004 · Governance & Verantwortung
DORA-IRM-018 · IKT-Risikomanagement
REG-AIA-002 · Regulatory Landscape

A.6.4

DORA-GOV-004 · Governance & Verantwortung

A.7.2

DORA-IRM-018 · IKT-Risikomanagement
REG-AIA-002 · Regulatory Landscape

A.8

OFS-001 · Open Finance Security
OFS-002 · Open Finance Security
OFS-003 · Open Finance Security

A.8.1

DORA-IRM-005 · IKT-Risikomanagement
DORA-IRM-010 · IKT-Risikomanagement
DORA-KWF-002 · Kritische oder wichtige Funktionen
OSS-001 · Open Source & Software Supply Chain

+1 weitere Maßnahmen

A.8.12

DORA-REG-001 · Informationsregister

A.8.13

DORA-RISK-002 · IKT-Risikomanagement
DORA-PDR-004 · Schutz, Erkennung & Reaktion
DORA-TPR-005 · IKT-Drittparteienrisiko

A.8.14

DORA-PDR-004 · Schutz, Erkennung & Reaktion
DORA-TPR-004 · IKT-Drittparteienrisiko
DORA-EXT-001 · IKT-Drittparteienrisiko

A.8.15

DORA-REG-003 · Informationsregister
DORA-IRM-008 · IKT-Risikomanagement

A.8.16

DORA-GOV-003 · Governance & Verantwortung
DORA-RISK-003 · IKT-Risikomanagement
DORA-PDR-002 · Schutz, Erkennung & Reaktion
DORA-REG-003 · Informationsregister

+2 weitere Maßnahmen

A.8.19

OSS-002 · Open Source & Software Supply Chain
OSS-003 · Open Source & Software Supply Chain
OSS-004 · Open Source & Software Supply Chain
OSS-005 · Open Source & Software Supply Chain

A.8.2

DORA-RISK-001 · IKT-Risikomanagement
DORA-IRM-005 · IKT-Risikomanagement
OSS-002 · Open Source & Software Supply Chain

A.8.20

DORA-PDR-001 · Schutz, Erkennung & Reaktion
DORA-TST-003 · Digitale Resilienztests

A.8.21

DORA-PDR-001 · Schutz, Erkennung & Reaktion

A.8.25

OSS-002 · Open Source & Software Supply Chain
OSS-003 · Open Source & Software Supply Chain
OSS-004 · Open Source & Software Supply Chain
OSS-005 · Open Source & Software Supply Chain

A.8.26

OSS-005 · Open Source & Software Supply Chain

A.8.3

DORA-IRM-007 · IKT-Risikomanagement

A.8.31

DORA-TST-003 · Digitale Resilienztests

A.8.32

DORA-RISK-004 · IKT-Risikomanagement
DORA-REG-002 · Informationsregister

A.8.33

DORA-RISK-004 · IKT-Risikomanagement
DORA-REG-002 · Informationsregister

A.8.34

DORA-RISK-004 · IKT-Risikomanagement
DORA-TST-005 · Resilienztests
DORA-TPR-009 · IKT-Drittparteienrisiko
DORA-KWF-003 · Kritische oder wichtige Funktionen

+1 weitere Maßnahmen

A.8.7

DORA-PDR-002 · Schutz, Erkennung & Reaktion
OSS-002 · Open Source & Software Supply Chain

A.8.8

DORA-TST-001 · Digitale Resilienztests
DORA-IRM-004 · IKT-Risikomanagement
DORA-IRM-006 · IKT-Risikomanagement
DORA-IRM-008 · IKT-Risikomanagement

+5 weitere Maßnahmen

A.8.9

DORA-RISK-002 · IKT-Risikomanagement
DORA-PDR-001 · Schutz, Erkennung & Reaktion

A.9

OFS-001 · Open Finance Security
OFS-002 · Open Finance Security

A.9.1

DORA-TST-001 · Digitale Resilienztests
DORA-EVD-003 · Nachweise & Auditfähigkeit
DORA-IRM-009 · IKT-Risikomanagement
DORA-KWF-006 · Kritische oder wichtige Funktionen

+2 weitere Maßnahmen

A.9.2

DORA-EVD-002 · Nachweise & Auditfähigkeit
DORA-EVD-003 · Nachweise & Auditfähigkeit
DORA-TPR-006 · IKT-Drittparteienrisiko
DORA-CON-005 · IKT-Verträge

A.9.3

DORA-EVD-002 · Nachweise & Auditfähigkeit

Disclaimer

Hinweis: Diese Seite ist eine Umsetzungshilfe und ersetzt keine Rechtsberatung oder verbindliche aufsichtsrechtliche Auslegung.

Inhalte basieren auf öffentlich verfügbaren Regulierungsinformationen und werden für die operative Umsetzung in Finanzinstituten strukturiert aufbereitet.

Quellen und Stand

Review-Status: reviewed
Letzte Prüfung: 2026-05-07

BaFin: DORA Überblick Stand: Abruf 2026-05-07
EUR-Lex: DORA Verordnung (EU) 2022/2554 Stand: Abruf 2026-05-07

Diese Seite ist eine eigene Umsetzungshilfe auf Basis öffentlicher Quellen. Sie ersetzt keine Rechtsberatung und keine verbindliche Auslegung durch Aufsicht oder Rechtsberatung.