DORA für IT-Systemhäuser — was Banken 2026 von Ihnen verlangen

Warum DORA Ihr IT-Systemhaus betrifft

DORA (Digital Operational Resilience Act, EU 2022/2554) adressiert primär Finanzunternehmen — Banken, Versicherer, Zahlungs- und E-Geld-Institute, Krypto-Dienstleister und viele mehr. Aber: Die operative Last der Umsetzung trifft zu einem erheblichen Teil deren IKT-Drittdienstleister. Genau hier sitzen mittelständische IT-Systemhäuser, MSPs und SaaS-Anbieter.

Konkret heißt das: Wenn auch nur einer Ihrer Kunden eine Bank, eine Versicherung, eine Kapitalverwaltungs­gesellschaft oder ein Zahlungsdienstleister ist, werden Sie 2026 mit folgenden Anforderungen konfrontiert:

• Anpassung Ihrer Verträge an Artikel 30 (DORA) — neue Klauseln in fast allen Bestandsverträgen.
• Aufnahme in das Informationsregister der Bank mit definierten Datenfeldern.
• Bereitstellung von Substituierbarkeits-Informationen und einer Exit-Unterstützung.
• Mitwirkung bei Threat-Led Penetration Testing (TLPT), falls Sie kritisch sind.
• Strengere Anforderungen an Vorfalls-Meldung, Sicherheits-Nachweise und Sub-Unternehmer-Transparenz.

Sind Sie IKT-Drittdienstleister?

DORA definiert in Art. 3 Nr. 19 „IKT-Drittdienstleister" sehr breit: Jeder, der „IKT-Dienstleistungen" für ein Finanzunternehmen erbringt. Das umfasst:

• Cloud-Anbieter (IaaS, PaaS, SaaS).
• Managed-Service-Provider (Network, Endpoint, Datacenter, Identity, Backup).
• Software-Anbieter, inkl. On-Prem-Lizenz mit Wartungsvertrag.
• Implementierungs- und Beratungs­dienstleister, sofern „IKT-Dienstleistung".
• Hosting-, Colocation-, CDN-, DNS-Anbieter.
• SOC- und MDR-Dienstleister.

Reine Beratungsleistungen ohne Bezug zu produktiven IKT-Systemen sind in der Regel nicht erfasst, der Grenzfall ist aber eng. Faustregel: Wenn Ihr Vertrag ein SLA, eine Verfügbarkeits-Zusage, einen administrativen Zugriff oder den Betrieb einer Komponente umfasst — Sie sind drin.

Kritische IKT-Drittdienstleister

Eine besondere Kategorie sind die kritischen IKT-Drittdienstleister (Critical Third-Party Providers, CTPPs). Die Europäische Aufsicht (EBA, ESMA, EIOPA) benennt diese explizit und führt eine direkte Aufsicht über sie ein. Für die meisten Mittelständler ist das nicht relevant — die Liste konzentriert sich auf Hyperscaler und große Spezialanbieter.

Aber: Auch nicht-kritische Anbieter werden indirekt voll mitreguliert, weil die Bank ihre Sorgfaltspflichten an die Vertragskette weitergibt. Der Unterschied: CTPP-Status bringt EU-direkte Aufsicht; alle anderen werden über die Banken kontrolliert.

Was Banken jetzt von Ihnen verlangen

Wenn Sie 2026 von einer Bank einen Fragenkatalog bekommen, deckt der typisch diese Themen ab. Bereiten Sie die Antworten einmal sauber vor und pflegen Sie sie in einem Anbieter-Datenpaket (Trust Center, Datenraum, NDA-Bundle):

• Sicherheitszertifizierungen — ISO 27001, SOC 2 Typ II, C5, TISAX. Wenn nichts davon vorliegt: dokumentierte Eigen-Erklärung mit Audit-Hinweis.
• Sub-Unternehmer-Verzeichnis — vollständige Liste der eingesetzten Sub-Auftragnehmer mit Funktion und Standort.
• Geografie — wo werden Daten verarbeitet, gespeichert, gesichert? Welche Rechenzentrums-Regionen?
• Vorfalls-Historie — gab es in den letzten 24 Monaten meldepflichtige Vorfälle? Wenn ja: Was wurde gelernt?
• BCM und DR — RTO/RPO pro Service, Test-Frequenz, letzter Test-Termin.
• Penetrationstests — Frequenz, letzter Test, Zusammenfassung der Erkenntnisse.
• Schwachstellen-Management — Patch-SLA, Severity-Verfahren.
• Logging und Monitoring — was wird geloggt, wie lange, wer hat Zugriff?
• Identity- und Access-Management — MFA-Pflicht? Joiner/Mover/Leaver?
• Personalsicherheit — Background-Checks? Vertraulichkeits­vereinbarungen?

Banken wollen die Antworten in einem strukturierten Format (häufig basierend auf SIG-Lite oder CAIQ). Die Vorbereitung lohnt sich, weil dieselben Fragen von praktisch jedem Finanzkunden kommen.

Verträge nach Artikel 30 — Pflichtinhalte

Art. 30 Abs. 2 und Abs. 3 DORA listet die Pflicht-Bestandteile, die in jedem Vertrag mit einem Finanzunternehmen stehen müssen. Diese Liste ist nicht verhandelbar — Sie können nur den Detail-Grad mitgestalten:

• klare und vollständige Leistungs- und Service-Level-Beschreibung;
• Orte der Leistungserbringung und Datenverarbeitung;
• Bestimmungen zur Verfügbarkeit, Authentizität, Integrität, Vertraulichkeit;
• Bestimmungen zum Schutz personenbezogener Daten (Bezug DSGVO);
• Unterstützungspflicht bei IKT-Vorfällen, mit oder ohne Zusatzkosten;
• uneingeschränkte Mitwirkung bei Aufsichts­maßnahmen der Bank;
• Kündigungsrechte mit Mindest-Kündigungsfrist und Sondergründen;
• für kritische/wichtige Funktionen zusätzlich:
  • Audit-Rechte der Bank, ihrer Beauftragten und der Aufsicht;
  • Sicherheits-Test-Pflicht für relevante Komponenten;
  • Schulungs- und Awareness-Verpflichtungen;
  • Mitwirkung bei TLPT falls die Bank in Scope ist;
  • Exit-Strategie und Übergabe-Unterstützung ohne unangemessene Kosten.

Praktischer Tipp: Bauen Sie einen DORA-Annex, der zu jedem Bestandsvertrag angeflanscht werden kann. Das spart Repapering-Verhandlungs­zeit pro Kunde von ~10 PT auf ~2 PT.

Das Informationsregister — Ihr Name in den Tabellen

Banken müssen ein Informationsregister aller IKT-Vertragsverhältnisse führen und jährlich an die Aufsicht melden. Die Datenfelder sind durch die technischen Regulierungsstandards der ESAs vorgegeben — über 80 Felder pro Vertrag, in mehreren verschachtelten Tabellen.

Für Sie als Anbieter relevant: Die Bank wird Sie nach diesen Daten fragen.

• Eindeutige Identifikation (LEI bevorzugt, sonst andere Identifier).
• Sitzland und Standorte der Leistungserbringung.
• Funktion in der Wertschöpfungskette der Bank (kritisch / nicht-kritisch).
• Verkettung der Sub-Unternehmer — Sie müssen Ihre Subs offenlegen, deren Subs idealerweise auch.
• Substituierbarkeits-Einschätzung — siehe nächster Abschnitt.

Wenn Sie keine LEI haben (Legal Entity Identifier, weltweit eindeutig), besorgen Sie sich eine. Kosten ~80–200 €/Jahr, Beantragung dauert wenige Tage. Banken fragen das mittlerweile reflexartig.

Exit-Strategie und Substituierbarkeit

Art. 28 Abs. 8 DORA verpflichtet Banken zu dokumentierten Exit-Strategien für jede kritische oder wichtige Funktion, die an einen IKT-Anbieter ausgelagert ist. Konkret bedeutet das für Sie als Anbieter:

• Sie müssen Datenformate offenlegen, die einen Wechsel ermöglichen.
• Sie müssen einen Migrationspfad zu mindestens einem alternativen Anbieter beschreiben können (oder zu In-House).
• Sie müssen Übergabe-Unterstützung für eine definierte Zeit nach Kündigung leisten.
• Sie dürfen für diese Unterstützung nur angemessene Kosten verlangen — keine Strafgebühren.

Threat-Led Penetration Testing — sind Sie dabei?

DORA verlangt von größeren Finanzunternehmen alle drei Jahre ein Threat-Led Penetration Test (TLPT, analog zu TIBER-EU). IKT-Drittdienstleister, die für die getestete kritische/wichtige Funktion relevant sind, müssen mitwirken.

Mitwirkung heißt: Eine kontrollierte Simulation eines fortgeschrittenen Angriffs gegen Ihre Systeme — koordiniert mit dem Test-Team der Bank, unter Geheimhaltung. Das ist anspruchsvoll und für kleinere Anbieter eine echte Herausforderung. Vorbereitung:

• Klare Kommunikations­wege zu Bank-CISO und Test-Lead etablieren.
• Eigene Blue-Team-Kapazität sicherstellen (eigenes SOC oder MDR-Partner).
• Detection-Logging so aufstellen, dass Sie eine TLPT-typische Lateral-Movement-Kette nachvollziehen können.
• Lessons-Learned-Prozess vorbereiten — der Test ist nutzlos ohne Nachbereitung.

Positionierung als DORA-ready Anbieter

DORA ist für ein gut aufgestelltes IT-Systemhaus mehr Chance als Risiko. Banken sortieren ihre Anbieter-Portfolios um — wer dokumentieren kann, dass er die Anforderungen erfüllt, verdrängt mittelfristig die Wettbewerber, die das nicht können.

Empfohlene Bausteine für die eigene Positionierung:

• Trust Center auf der eigenen Website mit den oben genannten Datenpunkten.
• DORA-Annex zum eigenen Standardvertrag als Verhandlungs-Grundlage.
• Public Cloud-Region-Statement für DE/EU-Hosting.
• Sub-Unternehmer-Register, das auf Anfrage geliefert werden kann.
• Pen-Test- und SOC-2-Status als wiederkehrendes Programm.
• Sales-Enablement — Account-Manager müssen die Bank-Sprache sprechen.

Wir unterstützen IT-Systemhäuser dabei mit einer DORA-Quick-Audit-Variante unseres Festpreis-Audits — Lieferung in 5–7 Werktagen, Maßnahmenkatalog inklusive Vertrags-Annex-Entwurf.

Häufige Fragen

Reicht unsere ISO 27001 als Nachweis?

Sie ist eine sehr gute Basis und beschleunigt die Bank-Onboarding-Phase deutlich, ersetzt aber nicht die DORA-spezifischen Vertrags-Pflichten (Art. 30) und die Bereitstellung der Datenfelder für das Informationsregister.

Was, wenn wir nur einen einzelnen Bank-Kunden haben?

Auch dann gilt DORA — über den Vertrag mit dieser Bank. Sie können den Aufwand kontrollieren, indem Sie ausschließlich den Annex zum bestehenden Vertrag anbieten und Ihr Trust-Center-Bundle einmal sauber aufsetzen.

Was ist mit Krypto-Dienstleistern und FinTechs?

DORA gilt für alle in Art. 2 Abs. 1 genannten Finanzunternehmen — darunter Krypto-Asset-Dienstleister nach MiCA und Zahlungs-/E-Geld-Institute nach PSD2/EMD. Die Anforderungen sind identisch zu Banken, die Reife der Umsetzung bei den Auftraggebern oft niedriger — Chance für Anbieter mit klarer Sprache.

Wir nutzen einen Hyperscaler — gilt DORA auch für unsere Subs?

Ja. Die Bank muss die gesamte Vertragskette nachvollziehen. AWS, Azure, Google Cloud haben DORA-Annexe für ihre Standardverträge — die müssen Sie in Ihr eigenes Vertragsgeflecht durchreichen.

Macht es Sinn, DORA und NIS2 gemeinsam zu adressieren?

Absolut. Die Überschneidungs­quote im Maßnahmen-Set ist hoch (Risiko-Mgmt, Vorfälle, Lieferkette, Schulung, Krypto). Wer ein integriertes Steuerungsmodell baut, vermeidet Doppel-Aufwand. Den NIS2-Teil dazu finden Sie im NIS2-Leitfaden und in der Maßnahmenkatalog-Vorlage.