Der Digital Operational Resilience Act (DORA) ist seit dem 17. Januar 2025 in Kraft. Keine Übergangsfrist, keine Schonzeit, keine Bagatellgrenzen. Wer als IT-Dienstleister Banken, Versicherungen, Zahlungsinstitute oder Asset Manager in Hamburg betreut, ist mittelbar verpflichtet — und wird ab 2026 systematisch geprüft.
Die Hamburger Finanzbranche ist nach Frankfurt der zweitwichtigste Finanzplatz Deutschlands. Haspa, M.M.Warburg, Hamburg Commercial Bank, Otto Payments, Sutor Bank, Hapag-Lloyd-Versicherung — sie alle stehen jetzt vor der Frage: Sind unsere IT-Partner DORA-tauglich? Wer es nicht ist, fliegt raus. Und es ist still um die Häuser geworden, die einfach abgewartet haben.
Inhalt in Kürze
- DORA ist seit 17.01.2025 anwendbar — die BaFin prüft seit Sommer 2025, vertiefte Audits bei Drittanbietern starten 2026.
- Hamburg ist Finanzplatz Nr. 2 in Deutschland — Haspa, Warburg, HCOB, Sutor, Otto Payments und ca. 180 weitere Finanzakteure sind direkt betroffen.
- 15 Pflicht-Vertragsklauseln nach Art. 30 DORA — Standardverträge aus dem Mittelstand erfüllen das praktisch nie.
- Incident-Reporting-Fristen: 4 / 24 / 72 Stunden — wer als IT-Provider keinen 24/7-Notfallkanal anbietet, ist disqualifiziert.
- Strafen bis 10 Mio. € oder 5 % Jahresumsatz für Banken; CTPPs bis 1 % Tagesumsatz pro Tag — der Vertragsverlust trifft IT-Häuser aber härter.
- Vorbereitungskosten: 30.000 € bis 120.000 € einmalig — bezahlt sich mit einem einzigen Bankmandat über 5 Jahre.
Der Digital Operational Resilience Act ist eine EU-Verordnung, die seit 17. Januar 2025 für rund 22.000 europäische Finanzunternehmen und deren ICT-Drittanbieter gilt — sie zwingt Banken, Versicherer und Zahlungsdienstleister, ihre IT-Risiken systematisch zu managen, ihre Dienstleister vertraglich auf Audit-Pflichten, Incident-Reporting und Threat-Led Penetration Tests zu verpflichten und Resilienz-Tests jährlich nachzuweisen.
Was ist DORA und wer ist als IT-Dienstleister mittelbar betroffen?
DORA (Verordnung (EU) 2022/2554) gilt für alle regulierten Finanzunternehmen in der EU: Banken, Versicherungen, Wertpapierfirmen, Zahlungsinstitute, E-Geld-Institute, Kryptodienste, zentrale Gegenparteien, Handelsplätze, Ratingagenturen, Crowdfunding-Plattformen, Versicherungsvermittler. Indirekt aber auch jeden, der ihnen ICT-Dienstleistungen erbringt — und das ist ausdrücklich breit gefasst: Managed-IT-Provider, Cloud-Anbieter, Softwarehäuser, Pen-Tester, Hosting-Dienstleister, Telefonanlagen-Provider, Cybersecurity-Berater. Mehr Details zur Verordnung finden Sie auf der Seite der Europäischen Kommission zu DORA.
Konkret: Wir sehen in Hamburg gerade folgende Konstellationen unter Druck.
- Klassisches IT-Systemhaus betreut Haspa-Tochter oder Hapag-Lloyd-Versicherungstochter — bisher Standardvertrag, jetzt DORA-Annex Pflicht.
- Cloud-Anbieter (z.B. Microsoft 365 Reseller) für Wertpapierhandelshäuser — Sub-Auftragnehmer-Register und EU-Datenstandort werden plötzlich vertragsharte Anforderungen.
- Spezialisierte SaaS-Anbieter (Treasury-Software, Compliance-Tools) — werden zu potenziellen Critical ICT Third Party Service Providers (CTPPs) der ESAs.
- Penetrationstester und SOC-Provider — werden in TLPT-Übungen direkt eingebunden, müssen eigene Sicherheits-Standards offenlegen.
„Wir sehen seit Sommer 2025 fast wöchentlich Anfragen aus dem Hamburger Bankenumfeld: Bestehende IT-Verträge sollen DORA-konform nachgezogen werden. Wer im Bestand sitzt und vorbereitet ist, gewinnt — wer abwartet, verliert das Mandat an einen vorbereiteten Wettbewerber.”
„Banken haben jetzt keinen Spielraum mehr. Wenn ein IT-Dienstleister DORA nicht erfüllt, ist die Bank selbst sanktionsbedroht. Da hilft kein 'wir kennen uns seit 15 Jahren' — der Vertrag wird gekündigt. Bei unseren Hamburger Finanzkunden sehen wir genau diesen Mechanismus seit Monaten."
Jens HagelGeschäftsführer, hagel IT-Services GmbH
Hamburg als Finanzplatz: Wer in der Hansestadt von DORA besonders betroffen ist
Hamburg ist nach Frankfurt der zweitgrößte Bankenstandort Deutschlands. Rund 180 Finanzakteure haben hier ihren Hauptsitz oder eine relevante Niederlassung. Die Konzentration im Bereich rund um den Neuen Wall, Jungfernstieg, Adolphsplatz und HafenCity macht Hamburg zu einem natürlichen Cluster mit besonderer Dichte an Compliance-Aufgaben.
| Hamburger Finanzakteur | Branche | Relevanz für IT-Partner |
|---|---|---|
| Hamburger Sparkasse (Haspa) | Sparkasse, ca. 5.500 MA | Stärkste regionale Bank, klassische Outsourcing-Verträge |
| M.M.Warburg & CO | Privatbank | Vermögensverwaltung, hohe Cyber-Risiken |
| Hamburg Commercial Bank | Geschäftsbank | Schifffahrtsfinanzierung, internationale Datenflüsse |
| Sutor Bank | Fintech-Bank | Plattform-Outsourcing, viele SaaS-Drittanbieter |
| Otto Payments / Otto Group Digital Services | E-Geld-Institut, BaFin-lizenziert | Massiver IT-Outsourcing-Footprint |
| Hapag-Lloyd-Versicherung | Versicherer | DORA + VAG-Doppelregulierung |
| HanseMerkur | Versicherer, ca. 2.000 MA | Lebens-/Krankenvers., starke IT-Tiefe |
| Signal Iduna (Hamburger Niederlassung) | Versicherer | Outsourcing nach Hamburg-Mittelstand |
Wer einen dieser Akteure betreut — oder einen ihrer rund 200 lizenzierten Vermittler, Asset Manager oder Family Offices — muss DORA spätestens jetzt operativ umsetzen. Das gilt auch für unsere klassischen IT-Service Hamburg-Mandate: Sobald ein Hamburger Mittelständler einen Bank-Kunden in seinem Portfolio hat, schlägt die Welle durch.
Die fünf zentralen DORA-Pflichten für IT-Dienstleister
DORA strukturiert sich in fünf Säulen. Jede betrifft Sie als IT-Dienstleister direkt — auch wenn die Bank der formell Verpflichtete ist, weil die Bank die Anforderungen an Sie weiterreicht. Die wesentlichen Inhalte der Regulatory Technical Standards (RTS) finden Sie bei der European Banking Authority zentral dokumentiert.
1. ICT Risk Management (Kapitel II, Art. 5-15)
Banken müssen ein vollständiges ICT-Risikomanagement aufbauen — und ihre Dienstleister müssen reinpassen. Konkret: Asset-Inventar (welche Systeme bei wem?), Risiko-Klassifizierung, Schutzmaßnahmen, Detection, Incident Response, Recovery. Ihr Provider-Vertrag muss klar regeln, welche Risiken Sie tragen und wie Sie Risikoinformationen weiterreichen.
2. ICT-Related Incident Reporting (Kapitel III, Art. 17-23)
Die berühmten 4/24/72-Stunden-Fristen. Vorfälle werden anhand von sieben Kriterien als „major incident” klassifiziert: Anzahl betroffener Kunden, Datenverlust, Dienste-Ausfallzeit, geografische Verbreitung, Reputations-Auswirkung, wirtschaftlicher Schaden, kritische Dienste. Wer als IT-Dienstleister von einem Vorfall betroffen ist, muss seine Bank-Kunden so schnell informieren, dass diese die 4-Stunden-Erstmeldung an die BaFin halten können.
3. Digital Operational Resilience Testing (Kapitel IV, Art. 24-27)
Pflicht-Tests: jährliche Schwachstellenanalysen, Pen-Tests, Szenario-basierte Tests. Für signifikante Institute zusätzlich Threat-Led Penetration Testing (TLPT) alle drei Jahre — nach dem TIBER-EU-Framework. IT-Dienstleister werden in TLPT-Übungen einbezogen, müssen Red Teams in ihre Infrastruktur lassen und Befunde aufarbeiten. Mehr zu modernen Endpoint-Detection-Plattformen in unserem Leitfaden zu Bitdefender GravityZone für Compliance-Anforderungen.
4. Managing of ICT Third-Party Risk (Kapitel V, Art. 28-44)
Das Herzstück für Sie als IT-Partner. Banken müssen ein Drittanbieter-Register führen (RTS 2024/1773), ihre Anbieter klassifizieren (kritische vs. nicht-kritische Funktionen), Due-Diligence dokumentieren, Verträge nach Art. 30 strukturieren, Exit-Strategien vorhalten. Die BaFin-Auslegungsentscheidungen zu DORA konkretisieren die deutsche Anwendung.
5. Information Sharing (Kapitel VI, Art. 45)
Freiwillig, aber sinnvoll: Banken sollen Cyber-Threat-Intelligence austauschen. IT-Dienstleister können sich an Branchen-ISACs (Information Sharing and Analysis Centers) anschließen — z.B. dem Hamburger Bankenverband oder dem German Financial CERT.
Viele IT-Häuser denken: „Wir sind nicht direkt reguliert, also betrifft uns DORA nicht." Falsch. Die Bank ist verpflichtet, alle DORA-Anforderungen vertraglich an Sie weiterzureichen. Sie sind damit faktisch reguliert — nur ohne eigene Aufsichtsbehörde. Praktischer Effekt: Sie tragen alle Compliance-Kosten, ohne die Marktmacht eines BaFin-lizenzierten Instituts zu haben.
Die 15 Pflicht-Vertragsklauseln nach Art. 30 DORA
Hier liegt der mit Abstand größte Aufwand. Bestehende IT-Dienstleistungs-Verträge — selbst gute Standard-Service-Verträge — erfüllen praktisch nie alle Anforderungen. Eine vollständige Übersicht aus der EU-Quelle finden Sie im DORA-Verordnungstext (EUR-Lex).
- Vollständige Leistungsbeschreibung: Welche ICT-Funktion erbringen Sie? Pauschalformulierungen reichen nicht — exakte Scope-Definition pro Service.
- Standort der Leistungserbringung: Wo wird betrieben? Wo werden Daten verarbeitet/gespeichert? EU-Datenstandort bei sensiblen Funktionen meist Pflicht.
- Vollständiges Service Level Agreement: Verfügbarkeit, Reaktionszeit, Wiederherstellungszeit, jeweils mit Mess-Methode und Reporting.
- Schutz personenbezogener Daten: DSGVO-konform, Sub-Auftragsverarbeitungsverträge dokumentiert, Datenschutz-Folgenabschätzung wo nötig.
- Datenzugang, -wiederherstellung, -rückgabe: Bei Kündigung oder Insolvenz: Daten in maschinenlesbarem Standard-Format binnen definierter Frist zurück.
- Sub-Auftragnehmer-Regelung: Vollständiges Sub-Register, Kontroll-Rechte, Genehmigungsvorbehalt bei wesentlichen Sub-Auftragnehmern.
- Zugriffs- und Audit-Rechte: Der Kunde und die BaFin müssen jederzeit Audits durchführen können — vor Ort, in den Räumen, in den Systemen.
- Beteiligung an Aus- und Weiterbildung: Trainings für gemeinsame Notfall-Übungen, BCM-Tests, TLPT.
- Kündigungsrechte: Sofortkündigung bei wesentlichen Vertragsverletzungen, behördlichen Verstößen, Insolvenz.
- Beteiligung an TLPT: Vertragliche Verpflichtung, an Threat-Led Penetration Tests teilzunehmen.
- Incident-Reporting: Reporting-Pflichten innerhalb der DORA-Fristen, einschließlich Eskalations-Pfade.
- Vollständige Vertrags-Dokumentation: Alle Änderungen, Vertragsanlagen, Sub-Sub-Auftragnehmer schriftlich.
- Versicherungsnachweise: Cyber-Haftpflicht, Berufshaftpflicht — Deckungssumme passend zum Schutzgut der Bank.
- Exit-Strategie: Detaillierter, getesteter Ausstiegsplan — Daten, Knowhow, Übergabe-Prozess.
- Compliance mit anwendbarem Recht: Inkl. DSGVO, NIS2, nationale Aufsichtsregeln.
Praktisch lösen wir das mit einem DORA-Annex zum bestehenden Vertrag. Die Bank stellt ihre Vorlage, Sie prüfen, verhandeln Ausnahmen, gegenzeichnen. Realistischer Aufwand: 8 bis 20 Stunden pro Bestandskunden, abhängig von Vertragstiefe.
Threat-Led Penetration Testing (TLPT) — was Sie als Provider können müssen
TLPT ist die schärfste Klinge unter den DORA-Test-Anforderungen. Nicht jede Bank muss TLPT machen — nur „signifikante” Institute nach Art. 26 i.V.m. den Schwellenwerten der RTS 2024/1774. Aber sobald Ihre Bank-Kundin TLPT-pflichtig ist, sind Sie als IT-Dienstleister Teil der Übung.
Was passiert in einem TLPT?
- Threat Intelligence (TI) Phase: Ein externer TI-Provider erstellt ein Bedrohungsmodell für die Bank — basierend auf realen Angreifer-Gruppen wie z.B. APT-Banking-Gruppen, FIN-Akteure (siehe MITRE ATT&CK Groups).
- Red Team Phase: Ein zertifiziertes Red-Team-Provider (TIBER-EU-zertifiziert) führt verdeckte Angriffe gegen die Live-Produktionsumgebung durch — 12 bis 16 Wochen, ohne Vorwarnung des SOC.
- Closure Phase: Befunde werden aufgearbeitet, Maßnahmen geplant, Aufsicht informiert.
Als IT-Dienstleister werden Sie typischerweise in Phase 2 ins Spiel kommen — das Red Team versucht, Ihre Systeme als Einfallstor zu nutzen. Wer da unvorbereitet ist, sieht spektakulär schlecht aus. Vorbereitung heißt: Hardening dokumentiert, SOC-Alerts kalibriert, EDR aktiv (siehe unsere Praxisbeispiele zu Crowdstrike Falcon EDR und Bitdefender GravityZone), Lessons-Learned aus früheren Pen-Tests verarbeitet.
„Wir haben 2025 zwei TLPT-Übungen für Hamburger Bank-Kunden begleitet. In beiden Fällen waren die ersten Befunde nicht beim Kunden — sondern bei seinen IT-Dienstleistern. Veraltete RDP-Gateways, unverschlüsselte Backup-Snapshots, Account-Lockout-Bypass über Helpdesk-Tickets. Das sind die Themen, die im Mittelstand seit Jahren rumliegen — und im TLPT brutal sichtbar werden.”
Bevor Sie in einen echten TLPT geraten, fahren Sie einen internen Red-Team-Test gegen Ihre Verwaltung-Ihrer-Kunden-Infrastruktur — also gegen Ihre eigene PSA, Ihr RMM-System, Ihre Helpdesk-Tools. 80 % aller TLPT-Befunde gegen IT-Dienstleister liegen hier, nicht in den Endkunden-Umgebungen.
Incident Reporting in der Praxis: Die 4-Stunden-SLA
Die DORA-Incident-Reporting-Fristen sehen auf dem Papier machbar aus, sind operativ aber hart. Eine Bank muss bei einem „major incident” innerhalb von 4 Stunden nach Klassifikation (spätestens 24 Stunden nach Entdeckung) eine Erstmeldung an die BaFin abgeben. Das setzt voraus, dass die Bank den Vorfall schnell genug verstanden hat — und dazu braucht sie ihren IT-Dienstleister.
Praktischer Workflow, den wir in Hamburg etabliert haben:
| Zeitpunkt | Wer macht was |
|---|---|
| T+0 (Vorfall entdeckt) | EDR-Alert, SIEM-Alarm, oder Kunden-Meldung an Helpdesk — Ticket im 24/7-System des IT-Dienstleisters |
| T+30 min | Erste Triage durch Level-2-Engineer, vorläufige Klassifizierung (incident vs. major incident) |
| T+1 h | Lagebild an Bank-Compliance-Ansprechpartner per definiertem Kanal (Telefon-Hotline + E-Mail mit verschlüsseltem Anhang) |
| T+2 h | Bank klassifiziert nach DORA-Kriterien (sieben Faktoren), entscheidet major / non-major |
| T+3 h | IT-Dienstleister liefert technische Details für BaFin-Meldung (betroffene Systeme, Ursache wenn bekannt, Auswirkungen, Eingriffsmaßnahmen) |
| T+4 h | Bank reicht Erstmeldung an BaFin ein |
| T+72 h | Zwischenbericht — IT-Dienstleister liefert Lessons-Learned, Forensic-Status |
| T+1 Monat | Abschlussbericht — IT-Dienstleister liefert Root-Cause-Analyse |
Die BaFin DORA Meldewege-Dokumentation detailliert das offizielle Meldeformular.
Concentration Risk und der paradoxe Vorteil kleinerer IT-Häuser
Eines der unterschätzten Themen: Art. 29 DORA verlangt von Banken, ihre Drittanbieter-Konzentrationen zu analysieren. Wenn eine Bank mehrere kritische Funktionen bei einem einzigen IT-Dienstleister bündelt, gilt das als Konzentrationsrisiko. Die Bank muss dann entweder einen Backup-Provider aufbauen oder einen detaillierten Exit-Plan dokumentieren.
Für einen klassischen Hamburger Mittelständler im IT-Bereich heißt das paradoxerweise: Sie müssen Ihre eigene Substituierbarkeit nachweisen. Klingt absurd, ist aber Realität — die Bank will sehen, dass ein anderer Provider Ihre Aufgaben übernehmen könnte, wenn Sie ausfallen.
Was das praktisch heißt:
- Saubere Runbooks. Jeder Standard-Prozess dokumentiert, versioniert, getestet — nicht nur im Kopf der Senior-Engineers.
- Anerkannte Standards nutzen. ITIL, ISO 20000, ISO 27001, BSI IT-Grundschutz — je standardisierter, desto leichter substituierbar.
- Knowledge Transfer Plan. Schriftlich, getestet, vom Kunden gegengeprüft: Wie würde Provider X in 4 Wochen Ihre Rolle übernehmen?
- Datenrückgabe-Format definiert. Maschinenlesbar, dokumentiert, getestet — kein proprietäres Lock-in.
- Notfall-Backup-Provider. Optional, aber Marktargument: Eine zweite Firma als „Standby Provider" benennen, mit Eskalations-Vereinbarung.
Wer das hat, gewinnt Bank-Mandate gegen größere Wettbewerber — weil die Bank ihren Concentration-Risk-Nachweis leichter erbringt. Das ist ein echtes Verkaufsargument für einen Hamburger IT-Dienstleister mit klarer Prozess-Tiefe.
Strafen und Sanktionen: Was bei DORA-Verstößen droht
Die Bußgeld-Skala ist bewusst abschreckend gestaltet. Sie folgt der Logik von DSGVO und NIS2 — kein Spielraum für „wir haben nicht gewusst”.
| Sanktions-Empfänger | Höchstmaß |
|---|---|
| Finanzinstitut (Bank, Versicherer) | Bis 10 Mio. € oder 5 % des weltweiten Jahresumsatzes (höherer Wert) |
| Critical ICT Third-Party Provider (CTPP) | Bis 1 % des durchschnittlichen Tagesumsatzes pro Tag, max. 6 Monate |
| Natürliche Personen (Geschäftsleitung) | Bis 1 Mio. € persönliche Haftung |
| Verbot der Geschäftsausübung | Möglich bei wiederholten/schweren Verstößen |
Für einen Hamburger Mittelständler im IT-Bereich kommt der eigentliche wirtschaftliche Schaden aber nicht durch direkte Strafen — sondern durch Vertragsverluste. Eine Bank, die DORA-Compliance ihres Providers nicht nachweisen kann, ist selbst sanktionsbedroht. Im Zweifel wird der Vertrag schnell beendet, weil das BaFin-Risiko größer ist als der Kosten-Aufwand einer Provider-Migration.
Das haben wir auch in unserem Beitrag zu NIS2-Compliance vs. DORA-Doppelregulierung und beim Thema Cyber-Versicherung als Pflicht-Baustein ausführlich behandelt.
„Wir hatten 24 Jahre lang denselben IT-Dienstleister — bis er plötzlich Insolvenz angemeldet hat. Von einem Tag auf den anderen standen wir ohne Support da. Seitdem wissen wir: Man braucht einen Partner, der stabil aufgestellt ist."
Genau dieser Effekt — plötzlicher Wegfall des IT-Partners — ist unter DORA das Concentration-Risk-Szenario. Banken planen das systematisch ein. Wer als Provider seine eigene Stabilität nicht nachweisen kann, fliegt aus dem Pitch.
Roadmap für IT-Dienstleister: 8 bis 14 Wochen zur DORA-Tauglichkeit
Wenn Sie heute starten — und das ist nicht zu früh, sondern bereits sehr knapp für 2026er-Audits — sieht die typische Roadmap so aus:
- Wochen 1-2 — Bestandsaufnahme: Welche Finanzkunden haben Sie? Welche Verträge? Welche Services? Erste Klassifizierung kritisch vs. nicht-kritisch. Lückenanalyse gegen die 15 Art-30-Klauseln.
- Wochen 3-4 — Vertrags-Annexe: Erste Drafts für DORA-Annexe je Kunde. Bank-Vorlagen einholen wo vorhanden, sonst Eigen-Vorlage entwickeln (Anwaltskanzlei involvieren!).
- Wochen 5-7 — Prozess-Hardening: Incident-Reporting-Prozess auf 4-Stunden-SLA hochziehen. 24/7-Hotline einrichten oder externalisieren. Eskalations-Matrix dokumentieren.
- Wochen 6-10 — BIA und Risk Assessment: Business Impact Analysis je Finanzkunde. Welche Funktionen sind kritisch? Welche RTO/RPO? Welche Abhängigkeiten?
- Wochen 8-12 — TLPT-Readiness: Interner Red-Team-Test gegen eigene Infrastruktur. EDR/SOC-Reife prüfen. Pen-Test-Partner auswählen.
- Wochen 10-14 — Audit-Vorbereitung: Audit-Mappe je Kunden anlegen — alle DORA-relevanten Nachweise zentral. Mock-Audit durchführen lassen.
Wer mehrere große Mandate hat, kann das parallelisieren. Wer einen Sub-Auftragnehmer-Stack hat (Cloud-Provider, Telefonie, SaaS), muss zusätzlich dort die DORA-Konformität nachfragen — und manchmal Provider wechseln.
„Der größte Fehler, den wir gerade in Hamburg sehen: IT-Häuser starten DORA erst, wenn die Bank sich beschwert. Da ist der Vertrag schon halb verloren. Wer 6 Monate vor der Bank-Aufforderung proaktiv kommt — mit fertigem Annex und sauberer Roadmap — gewinnt das Mandat fürs nächste Jahrzehnt.”
DORA-konform werden, bevor die Bank Sie auffordert?
15 Minuten Erstgespräch. Wir prüfen Ihre Bank-/Versicherungs-Mandate auf DORA-Lücken, zeigen den realistischen Aufwand und die ersten konkreten Schritte. Kostenlos, ohne Vertriebsdruck.
Erstgespräch buchen →Die häufigsten Fehler — und wie Sie sie vermeiden
In unserer Beratung sehen wir immer wieder dieselben Muster. Wer diese Stolperfallen kennt, spart erhebliche Kosten und Zeit.
| Fehler | Folge | Besser |
|---|---|---|
| „Wir machen DORA erst, wenn die Bank fragt” | Verlorenes Mandat, weil Wettbewerber proaktiv anbietet | 6 Monate vor Audit-Termin proaktiv kommen |
| Annex 1:1 aus Bank-Vorlage übernehmen | Vertragliche Übersteuerung, Haftungs-Eskalation | Mit Fachanwalt prüfen, Ausnahmen verhandeln |
| Incident-Reporting per E-Mail | 4-Stunden-Frist nicht haltbar | Dedizierter Hotline-Kanal + Eskalations-SLA |
| Sub-Auftragnehmer nicht im Register | Vertragsbruch bei nächster Sub-Änderung | Sub-Register als zentrales Living Document |
| Pen-Tests einmalig vor Vertragsschluss | TLPT-Befunde im Mandat | Jährliche externe Tests, halbjährliche interne |
| EDR ohne 24/7-SOC | Detection-Lücke nachts/Wochenende | SOC-Service oder Managed SOC einkaufen |
| Keine Cyber-Versicherung | Bank fordert Versicherungsnachweis | Cyber-Haftpflicht mit Deckung passend zum Schutzgut |
| Datenrückgabe-Format nicht definiert | Streit beim Exit | Format + Frist im Vertrag definieren |
Wie hagel IT Hamburger Finanz-IT-Partner unterstützt
Wir betreuen seit 2008 Hamburger Mittelständler — und seit der ersten Welle (PSD2, MaRisk, BAIT, ZAIT) Finanzkunden in der zweiten Reihe: IT-Dienstleister, die selbst Banken, Versicherer und Zahlungsinstitute betreuen. DORA ist für uns nicht der erste Compliance-Sturm, sondern der konsequente nächste Schritt nach NIS2.
Was wir konkret anbieten:
- DORA Gap-Analyse für IT-Dienstleister: Wir nehmen Ihre bestehenden Bank-/Versicherungs-Verträge unter die Lupe und liefern eine Soll-Ist-Analyse gegen die 15 Art-30-Klauseln. Typische Projektzeit: 4 bis 6 Wochen.
- Vertragsannex-Entwicklung: Gemeinsam mit unserem Partner-Anwaltsnetzwerk in Hamburg. Wir liefern den DORA-Annex, Sie unterzeichnen.
- Incident-Reporting-Setup: 24/7-Notfall-Hotline auf Ihrer Telefonanlage (siehe unser Service Telefonie und Kommunikation), dokumentierter Eskalations-Prozess, Mock-Drills.
- TLPT-Readiness: Pre-Assessment, Hardening-Roadmap, ggf. externe Pen-Tests durch unser Partner-Netzwerk.
- Compliance-Monitoring: Kontinuierliches Tracking aller DORA-relevanten Kennzahlen — Verfügbarkeit, MTTR, Vorfall-Statistik, Audit-Bereitschaft.
Wer als IT-Dienstleister selbst nicht über die nötigen Cyber-Security-Tiefen verfügt, kann unsere Cybersecurity-Services + NIS2- und Compliance-Beratung als White-Label-Sub-Service einkaufen — wir liefern die Tiefe, Sie behalten den Kundenkontakt.
Fazit: DORA ist kein Sturm, der vorbeizieht
Anders als manche EU-Verordnung vorher ist DORA nicht „die nächste Sau, die durchs Dorf getrieben wird”. Die Verordnung ist gekommen, um zu bleiben — mit jährlichen RTS-Updates, kontinuierlicher Verschärfung und einer wachsenden Liste an Critical-ICT-Third-Party-Providern, die direkt ESA-reguliert sind.
Für Hamburger IT-Dienstleister mit Bank-, Versicherungs- oder Zahlungsdienst-Mandaten gilt: Wer 2026 nicht DORA-tauglich ist, ist 2027 raus aus diesen Mandaten. Wer es ist, gewinnt die Aufträge der weniger vorbereiteten Wettbewerber. Die Marktbereinigung läuft bereits.
