DORA-Compliance 2026: Warum 70 % der Finanzinstitute einen neuen Softwareentwicklungs-Partner benötigen

17. Januar 2027. Dieses Datum müssen über 22.000 Finanzinstitute in der Europäischen Union rot in ihren Compliance-Kalendern markieren. Bis zu diesem Tag muss jede Bank, jedes Versicherungsunternehmen, jede Investmentgesellschaft und jedes Zahlungsinstitut die volle Einhaltung des Digital Operational Resilience Act nachweisen — oder Sanktionen von bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes für maximal sechs Monate hinnehmen.

Die jüngste Bewertung der Europäischen Bankenaufsichtsbehörde zeichnet ein düsteres Bild: Etwa 70 % der Finanzinstitute sind noch nicht bereit, die Anforderungen der DORA an das ICT-Risikomanagement und die Aufsicht über Dritte zu erfüllen. Die Lücke liegt nicht im regulatorischen Verständnis — sie liegt in der technischen Umsetzung. Und diese Lücke kann nur mit dem richtigen Softwareentwicklungs-Partner geschlossen werden.

Was die DORA tatsächlich von Ihrem Technologie-Stack verlangt

Die DORA ist keine weitere Berichtspflicht. Sie ist eine grundlegende Neuarchitektur der Art und Weise, wie Finanzinstitute ICT-bezogene Störungen verwalten, überwachen und davon recovern. Die Verordnung schreibt fünf Säulen vor, die jeweils direkte Auswirkungen auf die Softwareentwicklung haben:

Säule 1: ICT-Risikomanagement-Rahmen

Artikel 6 verlangt von Finanzinstituten die Implementierung eines umfassenden ICT-Risikomanagement-Rahmens, der Identifizierung, Schutz, Erkennung, Reaktion und Wiederherstellung abdeckt. Dies ist keine Policy-Übung — sie erfordert:

• Automatisierte Risiko-Identifizierung — kontinuierliches Scanning und Klassifizierung von ICT-Assets, Abhängigkeiten und Schwachstellen über den gesamten Technologiebestand hinweg
• Echtzeit-Bedrohungserkennung — Sicherheitsüberwachungssysteme, die anomale Verhaltensmuster erkennen können, die auf Cyberangriffe oder Systemausfälle hindeuten
• Dokumentierte Wiederherstellungsverfahren — technisch validierte Disaster-Recovery- und Business-Continuity-Pläne mit definierten RTO- und RPO-Zielen, mindestens jährlich getestet

Für die meisten Institute bedeutet die Erfüllung dieser Anforderungen den Aufbau oder Erwerb neuer Überwachungs-, Erkennungs- und Reaktionsfähigkeiten, die ihre aktuellen Technologie-Stacks nicht unterstützen.

Säule 2: ICT-bezogenes Vorfallsmanagement

Die Artikel 17–23 etablieren einen verbindlichen Rahmen für Vorfallklassifizierung, -meldung und -reaktion. Finanzinstitute müssen:

• Vorfälle anhand einer standardisierten Schweregradskala klassifizieren, die mit den Vorlagen der Europäischen Aufsichtsbehörden übereinstimmt
• Schwerwiegende Vorfälle innerhalb strenger Fristen ihrer zuständigen Behörde melden — Erstbenachrichtigung innerhalb von 4 Stunden nach Klassifizierung
• Ein zentrales Vorfallsregister mit Ursachenanalyse und Verfolgung von Behebungsmaßnahmen pflegen

Das 4-Stunden-Meldefenster ist besonders anspruchsvoll. Es erfordert automatisierte Vorfallserkennungs-, Klassifizierungs- und Benachrichtigungssysteme, die in Echtzeit operieren — eine Fähigkeit, die den meisten Instituten derzeit fehlt.

Säule 3: Testen der digitalen operativen Resilienz

Die Artikel 24–27 schreiben regelmäßige Resilienztests vor, proportional zur Größe des Instituts, seinem Risikoprofil und seiner systemischen Bedeutung. Systemisch bedeutende Institute müssen bedrohungsorientierte Penetrationstests (TLPT) durchführen — fortgeschrittene Red-Team-Übungen unter Aufsicht des Lead Overseer.

TLPT-Anforderungen umfassen:

• Bedrohungsintelligenz-basierte Szenarien — Tests, die auf aktueller, glaubhafter Bedrohungsintelligenz basieren, statt auf generischem Schwachstellen-Scanning
• Tests in Live-Umgebungen — Tests gegen Produktionssysteme, nicht Staging-Umgebungen, um die Resilienz in der realen Welt zu validieren
• Ursachenbehebung — Erkenntnisse müssen mit verifizierten Fixes adressiert werden, nicht nur dokumentiert

Die Vorbereitung auf TLPT erfordert erhebliche Security-Engineering-Kapazitäten, die die meisten Institute innerhalb der verbleibenden Frist nicht intern aufbauen können.

Säule 4: ICT-Drittpartei-Risikomanagement

Die Artikel 28–44 etablieren die kommerziell folgenreichste Anforderung: Finanzinstitute müssen ICT-Konzentrationsrisiken und Drittparteien-Vereinbarungen verwalten und überwachen. Diese Säule allein ist der Grund, warum die meisten Institute einen neuen Softwareentwicklungs-Partner benötigen.

Zentrale Anforderungen:

• Ein Register aller ICT-Drittparteien-Vereinbarungen mit Vertragsdetails, erbrachten Leistungen und Risikobewertungen pflegen
• Vorvertragliche Due Diligence bei ICT-Dienstleistern durchführen, die Sicherheitspraktiken, Vorfallsreaktion und Business Continuity abdeckt
• Sicherstellen, dass Verträge obligatorische Bestimmungen enthalten: Audit-Rechte, Vorfall-Meldepflichten, Datenlokalisationsanforderungen und Exit-Strategien
• Konzentrationsrisiken überwachen — übermäßige Abhängigkeit von einer kleinen Anzahl von ICT-Anbietern erzeugt systemische Verwundbarkeit

Säule 5: Informations- und Intelligence-Austausch

Die Artikel 45–46 fördern den freiwilligen Austausch von Informationen über Cyberbedrohungen und Vorfälle zwischen Finanzinstituten über anerkannte Informationsaustausch-Vereinbarungen. Die Umsetzung erfordert sichere, standardisierte Austauschplattformen und -protokolle.

Warum Ihr aktueller Softwareentwicklungs-Partner die DORA-Compliance wahrscheinlich nicht liefern kann

Die Drittpartei-Risikomanagement-Anforderungen erzeugen ein Paradox: Die Partner, die Ihre aktuellen Systeme gebaut haben, entsprechen möglicherweise nicht den Standards, die die DORA nun an sie stellt. Hier ist der Grund.

Die SBOM-Lücke

Die Konzentrationsrisiko-Bestimmungen der DORA in Kombination mit dem EU Cyber Resilience Act fordern de facto Software Bills of Materials (SBOMs) für alle ICT-Lieferungen. Die meisten Softwareentwicklungsunternehmen generieren derzeit keine SBOMs als Teil ihres Standardlieferprozesses. Wenn Ihr Entwicklungspartner kein vollständiges, aktuelles und kontinuierlich aktualisiertes SBOM für jede Komponente liefern kann, wird er zum Compliance-Risiko statt zum Compliance-Vorteil.

Die Vorfallsreaktions-Lücke

Die DORA verlangt, dass ICT-Drittparteien-Anbieter ihre Finanzinstitut-Kunden innerhalb von Stunden — nicht Tagen — über Vorfälle informieren. Die meisten Softwareentwicklungsunternehmen operieren mit Support-Ticket-SLAs, die in Arbeitstagen gemessen werden. Die kulturelle und operative Lücke zwischen „wir werden Ihr Ticket innerhalb von 48 Arbeitsstunden beantworten" und „wir werden Sie über jeden Sicherheitsvorfall, der Ihre Systeme betrifft, innerhalb von 4 Stunden informieren" ist enorm.

Die Audit-Rechte-Lücke

Artikel 30 verlangt, dass Verträge mit ICT-Drittparteien-Anbieter Bestimmungen enthalten, die dem Finanzinstitut, seinen Prüfern und den zuständigen Behörden Audit- und Inspektionsrechte gewähren. Viele Softwareentwicklungsunternehmen — insbesondere solche mit Offshore-Betrieb oder unter restriktiven Datenregimen — können diese Anforderungen nicht ohne Restrukturierung ihres Betriebs erfüllen.

Die Konzentrationsrisiko-Lücke

Wenn Ihr Institut für kritische ICT-Funktionen auf einen einzigen Softwareentwicklungs-Partner angewiesen ist, können die Konzentrationsrisiko-Bestimmungen der DORA eine Diversifizierung erfordern. Die Verordnung schreibt keine Multi-Vendor-Strategien explizit vor, aber Aufsichtsbehörden werden Vereinbarungen prüfen, bei denen ein einzelner Anbieter einen unverhältnismäßigen Anteil an kritischen ICT-Dienstleistungen hat.

Wie DORA-ready Softwareentwicklung aussieht

Ein Softwareentwicklungs-Partner, der die DORA-Compliance unterstützen kann, muss Fähigkeiten in fünf Domänen nachweisen, die weit über Standard-Entwicklungspraktiken hinausgehen.

1. Integriertes Resilience Engineering

DORA-konforme Software muss von Anfang an für operative Resilienz entwickelt werden. Das bedeutet:

• Circuit-Breaker-Muster — automatischer Abbau unter Fehlerbedingungen statt kaskadierendem Kollaps
• Chaos Engineering — proaktives Testen von Fehlerszenarien unter kontrollierten Bedingungen
• Observability-First-Architektur — umfassendes Logging, Tracing und Metriken, die Echtzeit-Erkennung und Diagnose von ICT-Vorfällen ermöglichen
• Graceful Degradation — Systeme, die mit reduzierter Kapazität weiterbetrieben werden, statt vollständig auszufallen

Dies sind keine optionalen Qualitätsattribute. Es sind regulatorische Anforderungen, die Aufsichtsbehörden gegenüber nachweisbar sein müssen.

2. Automatisierte Compliance-Infrastruktur

Die Melde- und Überwachungsanforderungen der DORA verlangen Automatisierung, die manuelle Prozesse nicht leisten können:

• Kontinuierliches ICT-Asset-Inventar — automatisch gepflegtes Register aller Hardware-, Software- und Dienstleistungen
• Echtzeit-Schwachstellenmanagement — automatisiertes Scanning, Klassifizierung und Verfolgung von Behebungsmaßnahmen
• Vorfallklassifizierungs-Engines — automatisierte Erstklassifizierung im Einklang mit ESA-Vorlagen zur Einhaltung der 4-Stunden-Meldezeiten
• SBOM-Generierung — automatisierte Erstellung von Software Bills of Materials im SPDX- oder CycloneDX-Format mit jedem Release

3. Security-First-Entwicklungspraktiken

Über die Supply-Chain-Sicherheitspraktiken, die wir andernorts analysiert haben, erfordert DORA-ready Entwicklung:

• Threat Modeling für jedes Feature vor der Implementierung
• Statische und dynamische Analyse in CI/CD integriert mit Sperr-Policies für kritische Befunde
• Penetration Testing als Standard-Liefermeilenstein, nicht als Nachgedanke
• Sicherheitsarchitektur-Reviews durch unabhängige Security-Engineers

4. Drittparteien-Aufsichtsfähigkeiten

Wenn Ihr Entwicklungspartner Systeme baut, die mit anderen ICT-Anbietern integriert werden, muss er verstehen, wie die Aufsichtsanforderungen der DORA umzusetzen sind:

• Vertragliche Compliance — Sicherstellung, dass Subunternehmer-Vereinbarungen die obligatorischen Vertragsbestimmungen der DORA erfüllen
• Kontinuierliche Überwachung — technische Mechanismen zur Überwachung der Sicherheitslage von Sub-Anbietern
• Konzentrationsrisiko-Bewertung — analytische Rahmen zur Bewertung, ob ICT-Vereinbarungen übermäßige Konzentration erzeugen

5. Europäische Regulatorische Fluenz

Die DORA wird in den EU-Mitgliedstaaten unterschiedlich durchgesetzt. Ein Entwicklungspartner, der nur den Text der Verordnung versteht, aber nicht, wie FCA, BaFin, Banca d'Italia, ACPR und andere nationale Behörden ihn interpretieren und anwenden, wird technisch konforme, aber operativ unzulängliche Lösungen produzieren.

Die Build-vs-Partner-Entscheidung für DORA-Compliance

Finanzinstitute stehen vor einer strategischen Wahl: DORA-Compliance-Fähigkeiten intern aufbauen oder mit einem Softwareentwicklungsunternehmen partnerschaften, das diese bereits besitzt.

Der Build-Weg

Der interne Aufbau erfordert die Einstellung von Spezialisten für ICT-Risikomanagement, Security Engineering und regulatorische Compliance — ein Talentpool, der bereits knapp ist und mit Annäherung an die Januar-2027-Frist noch knapper wird. Aktuelle Schätzungen legen nahe, dass europäische Finanzinstitute über 30.000 Cybersecurity- und ICT-Resilienz-Stellen besetzen müssen, um die DORA-Anforderungen zu erfüllen. Der Talentmangel ist strukturell, nicht zyklisch.

Der Partner-Weg

Die Partnerschaft mit einem etablierten Softwareentwicklungsunternehmen bietet schnellere Time-to-Compliance, Zugang zu spezialisiertem Fachwissen und die Fähigkeit, Compliance-Kapazitäten bei Bedarf zu skalieren. Der Partnerauswahlprozess muss jedoch selbst DORA-konform sein — was die Durchführung der vorvertraglichen Due Diligence, die Sicherstellung vertraglicher Bestimmungen gemäß Artikel 30 und die Etablierung kontinuierlicher Überwachungsmechanismen bedeutet.

Der effektivste Ansatz für die meisten Institute ist ein hybrides Modell: Interne Teams besitzen das Risikomanagement-Framework und die Governance, während externe Partner die spezialisierte Engineering-Kapazität für die Umsetzung der technischen Kontrollen bereitstellen.

So bewerten Sie einen Softwareentwicklungs-Partner für DORA-Compliance

Bei der Bewertung potenzieller Entwicklungspartner sollten Finanzinstitute den folgenden Bewertungsrahmen anwenden:

DORA-Anforderung	Partner-Bewertungskriterien
ICT-Risikomanagement	Nachweisbare Erfahrung beim Aufbau von Echtzeit-Überwachungs- und Erkennungssystemen für Finanzinstitute
Vorfallsmanagement	24/7-Vorfallsreaktionsfähigkeit mit dokumentierten SLAs, die DORA-Meldezeiten erfüllen
Resilienztests	TLPT-Erfahrung und Security-Engineering-Kapazität für bedrohungsorientierte Testprogramme
Drittpartei-Risiko	Fähigkeit, SBOMs zu liefern, Audit-Rechte zu gewähren und Konzentrationsrisiko-Überwachung zu unterstützen
Informationsaustausch	Erfahrung bei der Implementierung sicherer, standardisierter Informationsaustauschplattformen und -protokolle

Die besten Fintech-Softwareentwicklungs-Unternehmen in Europa differenzieren sich zunehmend durch nachweisbare DORA-Bereitschaft — nicht nur Marketing-Behauptungen, sondern dokumentierte Prozesse, technische Fähigkeiten und Referenzen von Finanzinstituten, die bereits ihre Compliance-Reisen begonnen haben.

Die Uhr tickt

Mit dem Januar-2027-Durchsetzungsdatum weniger als ein Jahr entfernt, wird das Fenster für die Compliance-Vorbereitung enger. Finanzinstitute, die noch nicht damit begonnen haben, ihre ICT-Resilienz-Lücken zu bewerten und Entwicklungspartner zu evaluieren, stehen vor einer zunehmend begrenzten Zeitleiste, in der Talentknappheit und Partnerverfügbarkeit akut werden.

DORA-Compliance ist keine Checkbox-Übung. Sie ist eine grundlegende Transformation der Art und Weise, wie Finanzinstitute Technologie-Risiken managen — und die Partner, die sie für die Ausführung dieser Transformation wählen, werden bestimmen, ob sie die Frist zuversichtlich einhalten oder unter Aufsichtsdruck Ergebnisse nachbessern müssen.

Die 70 %-Unvorbereitheitsstatistik ist keine Vorhersage — sie ist eine aktuelle Messung. Die Frage für jedes Finanzinstitut ist einfach: Sind Sie in den 30 %, die bereit sind, oder in den 70 %, die jetzt handeln müssen?

Veröffentlicht am 15. April 2026 · SectorPunk Research