DORA-Mapping: Anforderungen strukturiert nachweisen

Keine explizite Pflicht, trotzdem audit-entscheidend: So bringen Sie DORA-Mapping strukturiert in Prozesse, Verträge und Nachweise Ihres Unternehmens.

Inhalt

1. Was ist DORA-Mapping?
2. Warum brauchen Sie das?
3. Ist DORA-Mapping eine Pflicht?
4. Prozesse, Kontrolle & Verantwortlichkeiten
5. Drittanbieter-Risikomanagement
6. DORA-Mapping: ISO 27001 & NIS2

Überblick: DORA-Mapping

• DORA-Mapping: Zuordnung der EU-Verordnung 2022/2554 zu bestehenden Prozessen, Kontrollen und Verträgen
• Keine explizite gesetzliche Pflicht, aber faktisch unvermeidbar für Register, Verträge und Audits
• Third-Party Risk Management: zentrales Informationsregister plus CIF-Einstufung aller IKT-Dienstleister
• ISO 27001 und NIS2 decken große Teile ab, Lücken bei Meldefristen, Vertragsinhalten und Penetrationstests
• Human Risk Management Dashboard von SoSafe: rollenbasierte Awareness-Nachweise für Artikel 13 Abs. 6

DORA weiterdenken: Kennzahlen und Compliance im Blick

Vom Reifegrad-Check bis zur Audit-Vorbereitung: Diese DORA-Themen helfen IT- und Security-Teams, das Mapping in den größeren Compliance-Kontext einzuordnen und nächste Schritte zu planen.

Weiterlesen

Glossary

DORA-Compliance: Anforderungen, Checkliste und Human Risk

Weiterlesen

Glossary

DORA: Wer ist vom Digital Operational Resilience Act betroffen?

Was ist DORA-Mapping?

DORA-Mapping bezeichnet die strukturierte Zuordnung der Anforderungen aus der EU-Verordnung Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) zu den tatsächlichen Prozessen, Kontrollen, Verträgen und Verantwortlichkeiten eines Finanzunternehmens. Statt die Verordnungstexte einzeln abzuarbeiten, verknüpft ein gutes Mapping jede DORA-Anforderung mit der Stelle, an der sie im Unternehmen bereits gelebt wird oder eben noch nicht.

Ein Mapping bringt drei Ebenen zusammen: welche der fünf DORA-Säulen (IKT-Risikomanagement, Meldepflichten bei Vorfällen, Resilienztests, IKT-Drittparteienrisikomanagement, Informationsaustausch) einen Bereich betrifft, welcher bestehende Prozess oder welche Kontrolle die Anforderung bereits abdeckt, und mit welchem Nachweis sich das im Audit belegen lässt, etwa einem Dokument, Protokoll oder einer Vertragsklausel. Dieser letzte Punkt unterscheidet ein Mapping von einer reinen Checkliste: Eine Checkliste bestätigt „ja, das machen wir“, ein Mapping zeigt, womit sich das belegen lässt.

DORA gilt seit dem 17. Januar 2025 unmittelbar in allen EU-Mitgliedstaaten. Für die meisten betroffenen Häuser ist Mapping deshalb kein einmaliges Projekt, sondern eine laufende Aufgabe. Neue Dienstleister, geänderte Prozesse oder aktualisierte technische Regulierungsstandards (RTS) der europäischen Aufsichtsbehörden verändern die Zuordnung immer wieder.

Praxisnutzen: Warum brauchen Sie DORA-Mapping?

Ohne Mapping wirkt DORA-Compliance wie eine lose Sammlung einzelner Maßnahmen. Jede einzelne Maßnahme ist für sich genommen sinnvoll, im Audit fehlt dann aber oft der rote Faden. Ein strukturiertes Mapping zahlt sich handfest aus.

Prüferinnen und Prüfern geht es im Audit nicht allgemein darum, ob Sie DORA erfüllen. Stattdessen werden Sie konkreten Detailfragen wie „Wie weisen Sie Anforderung X in Prozess Y mit Kontrolle Z nach?“ gegenüberstehen. Ein Mapping liefert diese Kette von der Anforderung bis zum Beleg direkt mit, statt sie im Gespräch improvisieren zu müssen.

Auch Lücken lassen sich so zuverlässiger aufspüren: Erst die Gegenüberstellung von Anforderung und tatsächlichem Prozess zeigt, wo etwas fehlt, etwa eine Vertragsklausel, die Artikel 30 verlangt, aber im bestehenden Dienstleistervertrag nicht vorkommt, oder eine Meldekette, die die verschärften Fristen von DORA noch nicht abbildet.

Die meisten regulierten Unternehmen erfüllen große Teile von DORA schon über bestehende Rahmenwerke wie ISO 27001 oder NIS2. Ein Mapping macht diese Überschneidungen sichtbar und erspart doppelte Arbeit.

Für Sicherheitsteams mit begrenzter Kapazität liegt hier der praktische Nutzen. Der Aufwand für die eigentliche Anforderung bleibt gleich, aber der Aufwand, sie im Audit zu belegen, sinkt spürbar.

Rechtslage: Ist DORA-Mapping eine Pflicht?

Nein, zumindest nicht wörtlich. DORA schreibt an keiner Stelle explizit vor, ein „Mapping“ zu erstellen. Was die Verordnung stattdessen verbindlich verlangt:

• ein laufend aktuelles Informationsregister aller Verträge mit IKT-Drittdienstleistern (Art. 28 Abs. 3), das die Aufsichtsbehörden bei Bedarf einsehen können,
• eine Vorab-Sorgfaltsprüfung vor Vertragsschluss, die unter anderem Substituierbarkeit, Insolvenzrisiko, Datenschutz und Unterauftragsketten berücksichtigt (Art. 28 Abs. 4),
• Mindestvertragsinhalte nach Artikel 30 für Verträge, die „kritische oder wichtige Funktionen“ unterstützen,
• eine fortlaufende Überwachung der Dienstleisterbeziehungen (Art. 28 Abs. 6).

Diese Pflichten lassen sich in der Praxis kaum ohne eine strukturierte Zuordnung von Anforderung zu Prozess, Kontrolle und Nachweis erfüllen, schon weil Aufsichtsbehörden 2026 zunehmend diese Kette im Detail prüfen, von der Aktualität des Registers bis zu den Pflichtklauseln aus Artikel 30 in den Verträgen. Insofern ist Mapping de facto kaum vermeidbar, auch wenn es nirgends als eigenständige Pflicht benannt wird. Wer sich auf „wir erfüllen die Einzelanforderungen“ verlässt, ohne sie sauber zu dokumentieren und zuzuordnen, tut sich im Audit deutlich schwerer, das auch zu belegen.

Prozesse, Kontrollen & Verantwortlichkeiten

Der wirksamste Teil eines Mappings ist der interne: die Übersetzung der DORA-Anforderung in einen konkreten, bereits existierenden oder neu zu schaffenden Prozess mit klarer Verantwortlichkeit. Ohne diesen Schritt bleibt Mapping eine Excel-Liste ohne betrieblichen Nutzen.

In der Praxis bewährt sich eine einfache vierspaltige Struktur, die Anforderung, Funktion, Kontrolle und Nachweis miteinander verknüpft. Ein Beispiel anhand des Incident-Management-Prozesses:

Diese Tabelle lässt sich auf jeden der fünf DORA-Bereiche übertragen. Entscheidend ist, dass jede Zeile eine Person oder Rolle als Verantwortliche benennt, sonst bleibt die Zuordnung zwischen IT, Compliance und Risikomanagement diffus, und diese Governance-Lücken sind es, die Aufsichtsbehörden im Audit am häufigsten bemängeln.

Ein Bereich wird beim Mapping regelmäßig unterschätzt: der menschliche Faktor. Artikel 13 Absatz 6 verlangt rollenbasierte, dokumentierte Sensibilisierungs- und Schulungsmaßnahmen für Mitarbeitende und Management, nicht als freiwillige Zusatzmaßnahme, sondern als eigene, nachweispflichtige Zeile im DORA-Mapping. Wer diesen Punkt beim Auditor vorlegen muss, braucht mehr als eine Teilnahmequote: gefragt sind rollenspezifische Inhalte und ein Nachweis, dass Wissen auch nachhaltig wirkt. Das Human Risk Management Dashboard von SoSafe deckt genau diese Lücke: Es liefert rollenbasierte Lerninhalte und auditfeste Nachweise, sodass sich diese Zeile im DORA-Mapping mit belastbaren Daten statt mit einer bloßen Absichtserklärung füllen lässt.

Third-Party Risk Management beim DORA-Mapping

DORA macht das Prinzip klar: Digitale Resilienz und das damit verbundene Risiko lassen sich nicht an Dienstleister auslagern. Wer von DORA betroffen ist und für kritische Funktionen auf externe IKT-Anbieter setzt, bleibt selbst vollständig verantwortlich. Die Compliance des Dienstleisters ersetzt nicht die eigene.

Für das DORA-Mapping heißt das konkret:

1. Zentrales Register führen: Alle IKT-Drittdienstleister, von der Cloud-Infrastruktur bis zum spezialisierten SaaS-Tool, gehören in ein einziges, aktuelles Informationsregister (Art. 28 Abs. 3) mit Anbieteridentität, erbrachter Leistung, Vertragsdaten und Unterauftragsketten.
2. Kritikalität klassifizieren: Nicht jeder Dienstleister ist gleich relevant. Entscheidend ist die Einstufung, ob ein Anbieter eine „kritische oder wichtige Funktion“ (Critical or Important Function, CIF) unterstützt. Nur dafür gelten die vollständigen Pflichtklauseln aus Artikel 30, etwa Auditrechte, Exit-Strategien oder Regelungen zur Datenportabilität.
3. Verträge auf Pflichtklauseln prüfen: Bestehende Verträge müssen daraufhin durchgesehen werden, ob sie die nach Artikel 30 vorgeschriebenen Inhalte tatsächlich enthalten, häufig ein eigener Nachverhandlungsschritt bei älteren Rahmenverträgen.

Viele größere IKT-Anbieter stellen inzwischen eigene DORA-Dokumentation bereit, etwa GoTo, GitLab oder SAP. Wichtig für die Einordnung: Das ist die Zulieferung des jeweiligen Dienstleisters, nicht das eigene Mapping. Solche Dokumente helfen bei der Vertragsprüfung und der Sorgfaltspflicht gegenüber diesem einen Anbieter. Sie ersetzen aber weder das eigene, anbieterübergreifende Informationsregister noch die interne Kritikalitätsklassifizierung, die ausschließlich das Finanzunternehmen selbst vornehmen kann.

DORA-Mapping: ISO 27001 und NIS2

Die wenigsten Unternehmen starten beim DORA-Mapping bei null. Wer bereits nach ISO 27001 zertifiziert ist oder NIS2-Anforderungen umgesetzt hat, deckt einen erheblichen Teil von DORA bereits ab. Die Überschneidungen sichtbar zu machen, spart doppelte Arbeit und ist zugleich genau das, wonach Auditorinnen und Auditoren oft fragen.

Eine vereinfachte Orientierung, welche DORA-Bereiche sich an welchen Stellen mit ISO 27001 und NIS2 berühren:

DORA und ISO 27001

Der größte Deckungsgrad beim DORA-Mapping zu ISO 27001 liegt im IKT-Risikomanagement: ISO 27001 deckt mit seinen Annex-A-Controls große Teile der Artikel 5 bis 15 ab. Die Grenze liegt bei DORA-spezifischen Elementen, für die ISO 27001 kein Pendant kennt: allen voran die engen, gestaffelten Meldefristen bei Vorfällen und die Pflicht zu bedrohungsgeleiteten Penetrationstests (TLPT) für bedeutende Institute. Eine bestehende Zertifizierung ist damit ein starker Ausgangspunkt, aber kein Ersatz für die DORA-spezifischen Nachweise.

DORA und NIS2

Auch bei DORA und NIS2 liegt die größte Überschneidung im Bereich Lieferkettensicherheit und Risikomanagementmaßnahmen. Die Herausforderung hier ist eine andere als bei ISO 27001: NIS2 ist eine Richtlinie, die national unterschiedlich umgesetzt wird, während DORA als Verordnung unmittelbar und einheitlich gilt. Für Finanzunternehmen, die zugleich in den NIS2-Anwendungsbereich fallen, gilt zudem: DORA hat als sektorspezifisches Regelwerk im Zweifel Vorrang. Diesen Punkt sollte das Mapping explizit dokumentieren, um Doppelarbeit oder widersprüchliche Prozesse zu vermeiden.

Wie sich das über alle fünf DORA-Säulen hinweg im Detail darstellt, lässt sich am schnellsten in der Gesamtübersicht nachvollziehen:

Dieser Ratgeber dient der ersten Orientierung und ersetzt keine Rechtsberatung. Rechtsgrundlagen: Verordnung (EU) 2022/2554 (DORA), ISO/IEC 27001:2022, Richtlinie (EU) 2022/2555 (NIS2). Stand: September 2026