DORA: IKT-Resilienz für den Finanzsektor ab Januar 2025

TL;DR

• Am 17. Januar 2025 tritt der Digital Operational Resilience Act (DORA) für Finanzinstitute und wesentliche IKT-Dienstleister in der EU zur Anwendung und etabliert einen verbindlichen Rahmen für IKT-Risikomanagement, Incident-Handling, Testing und Drittparteirisiko.
• DORA ergänzt den horizontalen Sicherheitsrahmen von NIS2 als spezialisierte, sektorspezifische Regulierung für den Finanzsektor – mit strengeren, detaillierteren Anforderungen an Governance, Testing (inkl. TLPT) und IKT-Drittanbietersteuerung.
• Threat-Led Penetration Testing (TLPT) nach TIBER-EU wird für große und systemrelevante Finanzakteure Pflicht und verlangt ein strukturiertes, nachrichtendienstlich gestütztes Red-Teaming gegen reale Bedrohungsszenarien.
• IKT-Drittparteirisiko rückt ins Zentrum: Ein vollständiges Register, systematische Due Diligence, klare Exit-Strategien und vertraglich gesicherte Audit- und Kontrollrechte werden zu Kernanforderungen der digitalen Resilienz.
• ayedo unterstützt Finanzinstitute mit einem DORA-Compliance-Workshop, ISO-27001-orientierten Betriebsmodellen, Cloud-Native-Plattform-Expertise und konkreter Vorbereitung auf TLPT, um technische und organisatorische Anforderungen pragmatisch umzusetzen.

---

DORA ab Januar 2025: Was auf Finanzinstitute zukommt

Mit der Verordnung (EU) 2022/2554 legt die EU erstmals einen einheitlichen, verbindlichen Rahmen für die digitale operationelle Resilienz von Finanzinstituten fest. DORA richtet sich an nahezu alle Akteure des Finanzsektors: Kreditinstitute, Zahlungsdienstleister, Versicherer, Investmentfirmen, Marktinfrastrukturen und – besonders wichtig – kritische IKT-Drittanbieter.

Formell ist DORA bereits seit dem 16. Januar 2023 in Kraft. Entscheidend für Sie ist jedoch: Am 17. Januar 2025 beginnt die Anwendungspflicht. Ab diesem Datum werden Aufsicht und Prüfer sehr konkret fragen, wie Sie IKT-Risiken steuern, Vorfälle melden, Ihre digitale Resilienz testen und Ihre IKT-Drittparteien managen.

DORA versteht digitale Resilienz nicht als rein technische Aufgabe. Sie verbindet:

• Governance und Board-Verantwortung
• IKT-Risikomanagement über den gesamten Lifecycle
• Harmonisierte Meldung bedeutender IKT-Vorfälle
• Systematische Tests bis hin zu Threat-Led Penetration Testing
• Strenge Anforderungen an IKT-Drittparteien und deren Aufsicht auf EU-Ebene

Damit schafft DORA genau das, was im europäischen Finanzsektor lange gefehlt hat: einen kohärenten Standard anstelle eines Flickenteppichs nationaler Vorgaben. Für technisch verantwortliche Führungskräfte ist das eine Chance, Sicherheit, Resilienz und regulatorische Compliance endlich auf ein einheitliches Fundament zu stellen.

---

DORA und NIS2: allgemeiner Rahmen vs. Finanz-Spezialnorm

Mit NIS2 hat die EU einen horizontalen Mindeststandard für Cybersicherheit in kritischen und wichtigen Sektoren geschaffen – vom Gesundheitswesen über Energie bis zu digitalen Infrastrukturen. DORA ist dazu die lex specialis für den Finanzsektor.

Wesentliche Punkte im Verhältnis von DORA zu NIS2:

• Geltungsbereich
  NIS2 adressiert eine breite Palette kritischer Sektoren. DORA fokussiert exklusiv auf Finanzentitäten und deren IKT-Drittanbieter.

• Detailtiefe
  NIS2 definiert allgemeine Vorgaben zu Risikomanagement, Incident-Meldung und Business Continuity. DORA geht deutlich tiefer: spezifische Vorgaben für Finanzaufsicht, Meldewege, Digital Resilience Testing (inkl. TLPT) und Drittparteirisiko.

• Anwendung im Konfliktfall
  Für Finanzinstitute gilt: Wo DORA spezielle Anforderungen definiert, hat DORA Vorrang vor NIS2. NIS2 bleibt aber als Hintergrundrahmen relevant – insbesondere dort, wo DORA bewusst offen bleibt oder auf andere Standards verweist.

Für Sie in der Praxis bedeutet das: Wenn Ihr Institut bereits NIS2-Vorbereitungen begonnen hat, sind viele Bausteine (z. B. Incident-Prozesse, BCP, grundlegende IKT-Sicherheitsmaßnahmen) wiederverwendbar. DORA ergänzt und schärft diese Bausteine für den Finanzkontext, insbesondere bei Testing und Drittparteien.

---

Die fünf Kernbausteine der IKT-Resilienz nach DORA

DORA strukturiert die Anforderungen in fünf zentrale Säulen. Für technisch Verantwortliche lohnt es sich, genau in diesen Säulen zu planen und zu berichten.

1. IKT-Risikomanagement als Chefsache

DORA macht klar: Die Verantwortung liegt beim Vorstand. Das IKT-Risikomanagement muss:

• eine dokumentierte Strategie und Risikotoleranz definieren,
• ein vollständiges Inventar von IKT-Assets, Geschäftsprozessen und Abhängigkeiten umfassen,
• Schutz-, Detektions-, Response- und Recovery-Maßnahmen abdecken,
• auf regelmäßigen Bewertungen, Tests und Audits basieren,
• über definierte KPIs/KRIs an das Management berichtet werden.

Aus technischer Sicht bedeutet das, dass Themen wie Asset-Transparenz, Netzsegmentierung, Zugriffsmanagement, Backup-Strategie und Monitoring nicht mehr nur „Best Practice“, sondern regulatorisch verankerte Pflicht sind – inklusive nachvollziehbarer Dokumentation.

2. Harmonisiertes Incident-Reporting

Bisher waren Meldepflichten für IKT-Vorfälle zersplittert: Datenschutz, Aufsicht, nationale CERTs – häufig mit unterschiedlichen Schwellenwerten und Formaten. DORA harmonisiert für den Finanzsektor:

• Definition „großer IKT-Vorfall“ anhand eines EU-weit einheitlichen Kriterienkatalogs,
• klare Meldewege zur zuständigen Behörde,
• abgestimmte Kommunikation mit CSIRTs, Datenschutz- und Strafverfolgungsbehörden,
• einheitliche Taxonomie und Mindestinhalte der Meldungen.

Für Ihre Organisation heißt das: Ein konsistenter Incident-Management-Prozess, der technische, operative und regulatorische Anforderungen zusammenführt, wird obligatorisch. Die Schnittstellen zwischen SOC, IT, Compliance und Legal müssen definiert und eingeübt sein.

3. Digital Resilience Testing – vom Scan bis TLPT

DORA verlangt ein abgestuftes Testprogramm, das zur Größe und Kritikalität Ihres Instituts passt. Dazu gehören:

• regelmäßige Vulnerability Assessments und Security-Tests,
• Tests von Business-Continuity- und Disaster-Recovery-Plänen,
• gezielte Szenariotests (z. B. Ransomware, Cloud-Ausfall, Lieferantenstörung),
• für große/systemrelevante Häuser: Threat-Led Penetration Testing (TLPT) nach TIBER-EU-Methodik.

Entscheidend ist der systematische Charakter: Tests müssen geplant, dokumentiert, ausgewertet und mit klaren Maßnahmen und Re-Tests verbunden werden. „Einmal im Jahr Penetrationstest“ wird die Anforderungen nicht mehr erfüllen.

4. IKT-Drittparteirisiko als Kernbestandteil

Outsourcing entschärft keine Verantwortung – DORA betont das ausdrücklich. Kernelemente sind:

• eine IKT-Drittparteistrategie mit klaren Prinzipien und Risikotoleranz,
• ein umfassendes Register aller IKT-Dienstleister, inkl. Subunternehmern,
• strukturierte Due-Diligence-Prozesse vor Vertragsabschluss,
• Mindestinhalte der Verträge (SLAs, Sicherheitsanforderungen, Audit- und Zugangsrechte, Exit-Klauseln),
• regelmäßige Bewertung von Konzentrationsrisiken (z. B. starke Abhängigkeit von wenigen Hyperscalern).

Damit wird IKT-Drittparteimanagement von einem Einkaufsthema zu einem zentralen Baustein der IKT-Governance.

5. EU-Oversight für kritische IKT-Provider

Ein Novum ist die direkte EU-Aufsicht über als „kritisch“ eingestufte IKT-Drittanbieter, etwa große Cloud- oder Infrastrukturdienstleister:

• Die europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA) übernehmen eine „Lead Overseer“-Rolle.
• Sie erhalten Untersuchungs-, Inspektions- und Anordnungsbefugnisse gegenüber diesen Dienstleistern.
• Drittland-Provider müssen eine ausreichend ausgestattete EU-Tochter bereitstellen, um Aufsicht und Durchsetzung zu sichern.

Für Finanzinstitute stärkt das die eigene Position: Anforderungen an Transparenz, Auditierbarkeit und Exit-Fähigkeit lassen sich nicht mehr als „nicht verhandelbar“ abtun.

---

Threat-Led Penetration Testing (TLPT) nach TIBER-EU

Für große Banken, Marktinfrastrukturen und andere systemrelevante Akteure ist Threat-Led Penetration Testing (TLPT) ein zentraler Baustein von DORA. Viele Häuser stehen hier vor einer neuen Qualität von Tests.

Konzept: Tests entlang realer Angreiferprofile

TLPT orientiert sich an der TIBER-EU-Methodik der EZB und zielt darauf, reale Angreifer so nah wie möglich zu simulieren. Kernelemente:

• Threat Intelligence: Relevante Angreifergruppen, Taktiken, Techniken und Prozeduren (TTPs) werden analysiert.
• Kritische Funktionen: Im Fokus stehen Geschäftsprozesse und Systeme, deren Ausfall die Finanzstabilität oder kritische Dienstleistungen gefährden würde.
• Red-Teaming: Ein spezialisiertes Team versucht, entlang der ermittelten TTPs in die definierten Ziele einzudringen, möglichst ohne Vorwissen der Verteidiger.

Damit verschiebt sich der Fokus von rein technischen Schwachstellen-Scans hin zu ganzheitlichen Resilienztests: Können Angreifer sich seitlich bewegen? Werden sie erkannt? Wie schnell wird reagiert? Funktionieren die Response-Prozesse?

Typischer Ablauf eines TLPT-Programms

Ein praxisnahes TLPT folgt in der Regel mehreren Phasen:

1. Scoping und Governance
   Festlegung des Umfangs, der kritischen Funktionen, der beteiligten Stakeholder und der Governance-Struktur. Hier wird auch die Aufsicht früh eingebunden.

2. Threat Intelligence
   Erhebung und Analyse aktueller Bedrohungsinformationen für Ihr spezifisches Profil: Geschäftsmodell, Technologie-Stack, geografische Präsenz.

3. Testplanung und Szenario-Design
   Ableitung konkreter Angriffswege und Szenarien, abgestimmt mit dem Risikoappetit und den regulatorischen Vorgaben.

4. Durchführung des Red-Team-Tests
   Durchführung der simulierten Angriffe über einen definierten Zeitraum, eng begleitet durch einen „White Team“-Kreis, der für Sicherheit und Abbruchkriterien sorgt.

5. Auswertung, Remediation und Re-Test
   Ausführliche Berichte, technische und prozessuale Maßnahmen, Priorisierung nach Risiko – und bei Bedarf Re-Tests, um Wirksamkeit zu verifizieren.

Für cloud-native Umgebungen bedeutet das: Container-Orchestrierung, Service-Meshes, Secrets-Management und CI/CD-Pipelines werden Teil des Testobjekts. Ohne ein sauberes Architektur- und Asset-Verständnis werden TLPTs hier unnötig aufwendig und riskant.

---

IKT-Drittparteirisiko: Register, Due Diligence, Exit-Strategien

Das Management von IKT-Drittparteien gehört zu den Bereichen, die sich mit DORA am stärksten verändern. Ein reines Vertrags- und Einkaufsdossier reicht nicht mehr aus.

Vollständiges IKT-Drittparteiregister

DORA verlangt ein zentrales Register aller IKT-Dienstleistungen, das mindestens umfasst:

• Dienstleister, inklusive Subunternehmer und Rechenzentrumsstandorte,
• die unterstützten Geschäftsprozesse und IKT-Systeme,
• Klassifikation der Kritikalität (z. B. „kritische oder wichtige Funktionen“),
• wesentliche Vertragsparameter, SLAs, Laufzeiten und Exit-Regelungen.

Dieses Register bildet die Grundlage für:

• Risikobewertungen auf Dienstleister- und Portfolio-Ebene,
• Konzentrationsrisikoanalysen (z. B. Abhängigkeit von einem Cloud-Anbieter),
• strukturierte Berichterstattung an Vorstand und Aufsicht.

Technisch verantwortliche Führungskräfte sollten darauf achten, dass dieses Register eng mit bestehenden CMDBs, Architekturübersichten und Cloud-Accounts verknüpft wird, statt eine isolierte Excel-Landschaft aufzubauen.

Due Diligence als laufender Prozess

Due Diligence endet nicht bei der Vertragsunterschrift. Gefordert ist ein kontinuierlicher Prozess:

• vor Vertragsabschluss: technische und organisatorische Sicherheitsbewertungen, Compliance-Status (z. B. ISO 27001, SOC-Reports), Resilienz- und Recovery-Fähigkeiten,
• während der Laufzeit: regelmäßige Reviews, Berichte, Audits, Penetrationstests, Nachweise zur Incident-Response-Fähigkeit,
• bei wesentlichen Änderungen: Neubewertung, etwa bei Plattform-Migrationen, Betreiberwechseln oder geänderten Betriebsmodellen.

Hier lohnt es sich, Standardisierungen zu etablieren: wiederverwendbare Fragebögen, Bewertungsmatrizen und Mindestanforderungen, die für alle kritischen IKT-Dienstleister gelten.

Exit-Strategien und Portabilität

Ein häufig unterschätzter, unter DORA aber zentraler Punkt ist die Exit-Fähigkeit:

• Können Sie kritische Services im Krisenfall in akzeptabler Zeit von einem Provider weg migrieren?
• Sind Datenformate, Schnittstellen und Infrastruktur so gestaltet, dass Portabilität realistisch ist?
• Sind Exit-Szenarien (inkl. „harter“ Exit) geplant, dokumentiert und getestet?

In Cloud-Native-Umgebungen sind Containerisierung, Infrastructure-as-Code und standardisierte Schnittstellen eine technische Grundlage, um reale Exit-Fähigkeit zu erreichen. Ohne eine entsprechende Architekturstrategie bleiben Exit-Klauseln ein theoretisches Versprechen.

---

Technische und organisatorische Umsetzung in der Praxis

DORA ist kein reines Rechts- oder Compliance-Projekt. Entscheidend ist die Verbindung von Governance, Prozessen und technischer Realität. Aus der Perspektive eines europäischen Cloud- und Plattformanbieters hat sich ein mehrstufiges Vorgehen bewährt.

1. Strukturierte Gap-Analyse entlang der fünf Säulen

Statt hunderte Seiten Regulierungstext zu interpretieren, ist ein pragmatischer Einstieg:

• Mapping bestehender Frameworks (z. B. ISO 27001, BAIT, MaRisk, EBA-Guidelines) auf die fünf DORA-Säulen,
• Bewertung der vorhandenen Artefakte: Policies, Prozesse, Reports, Testpläne, Lieferantenregister,
• Identifikation konkreter Lücken, priorisiert nach Risiko und Umsetzungsaufwand.

Gerade Institute mit etablierten Informationssicherheits-Managementsystemen (ISMS) werden feststellen: Vieles ist bereits vorhanden, muss aber DORA-konform konsolidiert und dokumentiert werden.

2. Operating Model für IKT-Resilienz

DORA fordert klare Zuständigkeiten und bewusste Entscheidungen. Dafür braucht es ein Operating Model, das Fragen beantwortet wie:

• Wer verantwortet das IKT-Risikomanagement auf C-Level?
• Wie sind IKT-Sicherheit, IT-Betrieb, Architektur, Compliance und Einkauf verzahnt?
• Welche Gremien treffen Entscheidungen zu IKT-Risiken, Drittparteien und Budgets?
• Wie wird über KPIs/KRIs, Incidents und Testergebnisse berichtet?

Technische Verantwortliche sollten darauf achten, dass dieses Operating Model realistisch zur Organisationsgröße passt. Überkomplexe Gremienstrukturen schaden der Resilienz; klare Verantwortlichkeiten und definierte Eskalationspfade stärken sie.

3. Technische Baseline nach ISO-27001-Logik

ISO 27001 liefert viele Elemente, die DORA verlangt: Risikobewertung, Kontrollen, kontinuierliche Verbesserung. In der Praxis bedeutet eine DORA-kompatible Baseline typischerweise:

• robuste Identity- und Access-Management-Prozesse,
• Netzwerk- und Workload-Segmentierung, inklusive klar definierter „Severing“-Möglichkeiten für Containment,
• Härtung kritischer Systeme und reguläre Patch-Prozesse,
• verlässliche Backup- und Recovery-Strategien mit definierten RTO/RPO-Zielen,
• zentrales Logging, Monitoring und (idealerweise) SIEM-/SOC-Anbindung.

In Cloud-Native-Umgebungen müssen diese Baseline-Kontrollen konsistent über Cluster, Plattformen und Regionen hinweg umgesetzt werden. Hier helfen standardisierte Plattform-Patterns, statt jedes Projekt individuell zu gestalten.

4. TLPT- und Audit-Reife als Zielbild

Selbst wenn Ihr Institut ab Januar 2025 noch nicht TLPT-pflichtig ist, lohnt es sich, die eigene Architektur und Prozesse TLPT-fähig zu denken:

• klare Dokumentation kritischer Geschäftsprozesse und ihrer technischen Abbildung,
• nachvollziehbare Zuordnung von Systemen, Schnittstellen und Datenflüssen,
• konsolidierte Sicht auf Privileged Access, Secrets und hochkritische Assets,
• etablierte Incident-Response- und Forensik-Prozesse.

Eine solche Vorbereitung reduziert nicht nur den Aufwand eines späteren TLPT, sondern verbessert auch klassische Audits und interne Red-Team-Übungen.

5. ayedo als Partner für Cloud-Native Resilienz unter DORA

Als Plattform- und Cloud-Spezialist mit Fokus auf regulierte Branchen unterstützt ayedo Institute in drei typischen Rollen:

• DORA-Compliance-Workshop
  Strukturierte Erarbeitung des spezifischen Impact-Profils Ihres Hauses, Mapping auf die fünf DORA-Säulen, Priorisierung von Handlungsfeldern und Ableitung eines realistischen Fahrplans.

• ISO-27001-orientierte Plattform- und Betriebsmodelle
  Gestaltung und Umsetzung von Cloud-Native-Plattformen, die zentrale Kontrollen (Identitäten, Segmentierung, Logging, Backup, Change-Management) standardisiert bereitstellen – als Basis für DORA-konformes IKT-Risikomanagement.

• Vorbereitung auf TLPT und Drittparteirisiko-Management
  Unterstützung bei der Definition kritischer Funktionen, der Architektur-Transparenz, der Dokumentation von Schnittstellen und Abhängigkeiten sowie der Ausgestaltung von Exit-Strategien für IKT-Drittanbieter.

Ziel ist ein Setup, in dem technische und regulatorische Anforderungen keine Gegensätze darstellen, sondern sich gegenseitig verstärken: eine robuste, gut dokumentierte Plattform, die Audits, TLPT und Aufsichtsanfragen souverän bestehen kann.

---

Häufige Fragen

Betrifft DORA nur große Banken, oder auch kleinere Institute und FinTechs?

DORA gilt grundsätzlich für einen sehr breiten Kreis von Finanzentitäten – inklusive kleinerer Banken, Zahlungsinstitute, E-Geld-Institute, Asset Manager und bestimmter Kryptodienstleister. Die Verordnung enthält zwar Proportionalitätsklauseln: Umfang und Tiefe der Maßnahmen sollen zur Größe, Natur und Komplexität des Instituts passen.

Das bedeutet aber nicht, dass kleine Institute „herausfallen“. Mindeststandards, insbesondere bei IKT-Risikomanagement, Incident-Handling und Drittparteirisiko, gelten für alle. Was sich unterscheidet, ist eher die Ausgestaltung: kleinere Gremien, weniger formale Strukturen, vereinfachte Dokumentation – aber kein Verzicht auf die Kernanforderungen.

Gerade für FinTechs und kleinere Häuser kann DORA eine Chance sein, frühzeitig robuste Strukturen aufzubauen, statt später unter Zeitdruck nachzubessern.

Wie oft müssen wir Digital Resilience Testing und TLPT durchführen?

DORA schreibt kein starres, für alle Institute identisches Testintervall vor, sondern fordert ein risikobasiertes, kontinuierliches Testprogramm. Einige Orientierungen:

• Standard-Tests (z. B. Schwachstellenscans, Penetrationstests, BCP-/DR-Tests) sollten in einer Frequenz durchgeführt werden, die zu Ihrem Risikoprofil und Änderungsvolumen passt – typischerweise mindestens jährlich, bei kritischen Änderungen häufiger.
• Für TLPT orientieren sich die Erwartungen an den TIBER-EU-Leitlinien und nationalen Umsetzungen. Für große, systemrelevante Häuser ist ein Zyklus von etwa drei Jahren üblich, ergänzt durch laufende, zielgerichtete Tests und Übungen.

Wichtiger als die exakte Frequenz ist die Integration in einen Verbesserungszyklus: Erkenntnisse aus Tests müssen in konkrete Maßnahmen, Priorisierungen und Re-Tests münden. DORA legt großen Wert auf diesen Lern- und Verbesserungsaspekt.

Wie unterstützt ayedo konkret bei der DORA-Umsetzung?

ayedo kombiniert technische Plattform-Expertise mit einem klaren Fokus auf regulatorische Anforderungen. Konkret unterstützen wir Sie typischerweise in drei Dimensionen:

1. Analyse und Zielbild
   Im DORA-Compliance-Workshop schaffen wir Transparenz darüber, wo Ihr Institut heute steht, welche bestehenden Frameworks (z. B. ISO 27001, BAIT/MaRisk) bereits genutzt werden und welche Lücken in Bezug auf DORA bestehen. Daraus entsteht ein pragmatischer Maßnahmenplan statt eines abstrakten „Compliance-Projekts“.

2. Technische Plattform- und Betriebsstrukturen
   Wir helfen Ihnen, Cloud-Native-Infrastrukturen so zu gestalten und zu betreiben, dass zentrale Kontrollen (IAM, Netzwerksegmentierung, Logging, Backup, Change-Management) standardisiert und auditierbar umgesetzt sind. Ziel ist eine Plattform, die DORA-Anforderungen nicht nur erfüllt, sondern die tägliche Arbeit Ihrer Engineering-Teams unterstützt.

3. TLPT- und Drittparteifähigkeit
   Gemeinsam mit Ihren Teams erarbeiten wir die technische Dokumentation und Transparenz, die für TLPT, Audits und Drittparteimanagement notwendig ist: von Architekturübersichten über Schnittstelleninventare bis hin zu Exit-Szenarien für kritische IKT-Dienstleister.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

DORA markiert einen Wendepunkt für die digitale Resilienz im europäischen Finanzsektor. Ab dem 17. Januar 2025 werden IKT-Risiken, Incident-Handling, Resilienzt-Tests und Drittparteimanagement nicht mehr primär als „IT-Themen“ betrachtet, sondern als integrale Bestandteile der Geschäftssteuerung.

Für technisch Verantwortliche bietet das eine klare Chance: Wer jetzt Strukturen schafft, die Technik, Governance und Regulierung zusammenführen, kann die kommenden Jahre nicht nur Compliance-konform, sondern auch technologisch souverän gestalten. Eine robuste, gut dokumentierte Cloud-Native-Plattform, klare Verantwortlichkeiten und realistische Exit-Strategien sind dabei keine Zusatzanforderungen, sondern Bausteine einer zukunftsfähigen Infrastruktur.

ayedo versteht sich in diesem Kontext nicht als klassischer Berater, der PowerPoint-Folien produziert und dann wieder verschwindet, sondern als technischer Partner: Wir helfen Ihnen, DORA-Anforderungen in konkrete Plattform-Architekturen, Betriebsmodelle und dokumentierte Prozesse zu übersetzen – orientiert an Standards wie ISO 27001 und TIBER-EU, aber immer mit Blick auf Ihre spezifische Situation.

Wenn Sie Ihre DORA-Umsetzung strukturiert angehen und gleichzeitig die technologische Basis für TLPT, Auditierbarkeit und Exit-Fähigkeit legen möchten, ist ein gemeinsamer Einstieg sinnvoll. Im DORA-Compliance-Workshop erarbeiten wir mit Ihren Fachbereichen, IT-Teams und Compliance-Verantwortlichen einen konkreten, priorisierten Fahrplan – vom IKT-Risikomanagement über Digital Resilience Testing bis hin zum IKT-Drittparteirisiko.

Der erste Schritt ist bewusst niedrigschwellig: Vereinbaren Sie einen gemeinsamen DORA-Compliance-Workshop.