DORA-Anforderungen an IKT-Drittdienstleister: Was Banken bei Entwicklungspartnern prüfen sollten

Zwei Personen entwickeln an einem Computer eine Banking-App, eine zeigt mit dem Finger auf den Bildschirm, im Hintergrund steht eine EU-Flagge

Ein Entwicklungspartner für eine Banking-App muss mehr können, als gute Software zu entwickeln. Banken müssen unter dem Digital Operational Resilience Act (DORA) auch die Risiken beurteilen und steuern, die durch externe Anbieter von Informations- und Kommunikationstechnologie entstehen.

Das verändert die Auswahl von Softwarepartnern. Informationssicherheit, nachvollziehbare Verantwortlichkeiten, Auditrechte und die Transparenz der Lieferkette werden ebenso relevant wie technische Kompetenz, Projekterfahrung und Kosten.

Für Banken in Österreich und Deutschland stellt sich deshalb eine konkrete Frage: Kann der Entwicklungspartner nicht nur liefern, sondern auch die Nachweise und Prozesse bereitstellen, die das eigene IKT-Drittparteienrisikomanagement erfordert?

Zusammenfassung für Eilige

DORA verpflichtet Finanzunternehmen dazu, Risiken aus der Nutzung externer IKT-Dienstleistungen über den gesamten Lebenszyklus zu steuern. Dazu gehört eine Due-Diligence-Prüfung bereits vor Vertragsabschluss. Sowohl die österreichische Finanzmarktaufsicht (FMA) als auch die deutsche BaFin heben diese Anforderungen hervor. Ein Entwicklungspartner fällt typischerweise darunter, wenn seine Leistung auf Dauer angelegt ist, etwa durch Wartung, Support oder Weiterentwicklung.

ISO-27001-Zertifizierungen können ein wichtiger Nachweis für Informationssicherheit sein. Sie ersetzen die Prüfung eines Dienstleisters jedoch nicht. Ebenso wichtig sind Auditierbarkeit, klare Entwicklungsprozesse, transparente Standorte und der Umgang mit Unterauftragnehmern. Für Banken bedeutet das: Die Qualität eines Entwicklungspartners zeigt sich zunehmend auch darin, wie einfach sich dessen Organisation und Software-Lieferkette prüfen und kontrollieren lassen.

Was verlangt DORA bei IKT-Drittdienstleistern?

DORA gilt seit dem 17. Januar 2025 und schafft einen einheitlichen europäischen Rahmen für die digitale operationale Resilienz des Finanzsektors. Beim Einsatz externer IKT-Dienstleister bleibt die Verantwortung bei der Bank. Laut FMA müssen Finanzunternehmen ihr IKT-Drittparteienrisiko über den gesamten Lebenszyklus steuern. Dazu zählen unter anderem eine Strategie für das Drittparteienrisiko, ein Informationsregister, Due-Diligence-Prüfungen vor Vertragsabschluss, festgelegte Vertragsinhalte und Ausstiegsstrategien. Letztere sind insbesondere für Dienstleistungen relevant, die kritische oder wichtige Funktionen unterstützen.

Auch die BaFin betont für den deutschen Markt die Risikobewertung und Due Diligence vor Vertragsabschluss sowie die laufende Überwachung der IKT-Drittparteienrisiken.

Das bedeutet nicht, dass jeder Softwaredienstleister ein bestimmtes Zertifikat besitzen muss. DORA verlangt vielmehr, dass die Bank beurteilen kann, ob der jeweilige Anbieter geeignet ist und angemessene Standards für Informationssicherheit einhält. Art. 28 DORA sieht ausdrücklich eine Due Diligence potenzieller IKT-Drittdienstleister vor.

Wann ist ein Entwicklungspartner ein IKT-Drittdienstleister?

Nach Einschätzung der FMA setzt eine IKT-Dienstleistung unter anderem voraus, dass sie auf Basis einer vertraglichen Vereinbarung und mit dauerhaftem beziehungsweise längerfristigem Charakter erbracht wird. Ein reines Einmalprojekt ist deshalb nicht in jedem Fall erfasst. Sobald Wartung, Support, Betrieb oder Weiterentwicklung hinzukommen, ist das bei Banking-Apps häufig der Fall, und Banken sollten den Entwicklungspartner als IKT-Drittdienstleister behandeln. Die Einstufung nimmt die Bank im Einzelfall selbst vor.

Reicht eine ISO-27001-Zertifizierung für DORA?

Nein. Aber sie ist ein relevanter Baustein. ISO/IEC 27001 definiert Anforderungen an ein Informationssicherheits-Managementsystem. Eine entsprechende Zertifizierung liefert damit einen unabhängigen Nachweis dafür, dass Informationssicherheit strukturiert organisiert und regelmäßig überprüft wird.

Auch die FMA sieht Branchenzertifizierungen wie ISO 27001 als mögliche Informationsquelle bei der Beurteilung eines Dienstleisters. Gleichzeitig hält sie fest: Eine Zertifizierung ersetzt weder die ursprüngliche Dienstleisterprüfung noch die laufende Überprüfung. Für Banken ist diese Unterscheidung wesentlich: Ein Zertifikat kann die Due Diligence unterstützen und Nachweise vereinfachen, beantwortet aber nicht automatisch alle Fragen zu Entwicklungsprozessen, Unterauftragnehmern, Zugriffsrechten, Datenstandorten oder zur konkreten Leistung für das Institut.

Warum die Software-Lieferkette für Banken relevant ist

Ein weiterer Punkt gewinnt dadurch an Bedeutung: Wer entwickelt die Software tatsächlich?

DORA schreibt für IKT-Verträge Mindestinhalte vor. Dazu gehört, dass die Länder beziehungsweise Regionen, in denen Dienstleistungen erbracht und Daten verarbeitet werden, vertraglich festgehalten werden. Bei Leistungen, die kritische oder wichtige Funktionen unterstützen, ist zusätzlich zu regeln, ob und unter welchen Bedingungen Unterauftragnehmer eingesetzt werden dürfen. Wie tief die Bank Sub-Dienstleister prüft, richtet sich laut FMA nach Risiko und Verhältnismäßigkeit.

Nearshoring, Offshoring oder der Einsatz von Subunternehmen sind dadurch nicht grundsätzlich verboten. Jede zusätzliche Stufe kann aber weitere Parteien, Standorte, Zugriffsrechte und Abhängigkeiten in die Lieferkette bringen, die eine Bank beurteilen und gegebenenfalls überwachen muss.
Eine kurze und transparente Entwicklungslieferkette kann deshalb einen praktischen Vorteil bieten: Verantwortlichkeiten sind einfacher nachvollziehbar und der Prüfaufwand kann geringer ausfallen.

Für Entscheider:innen ergibt sich daraus eine einfache Prüffrage: Kann der Dienstleister transparent darstellen, wer an der Software arbeitet, wo die Entwicklung stattfindet und welche weiteren Unternehmen Zugriff auf Systeme, Code oder Informationen haben?

Welche Nachweise sollten Banken bei einem Entwicklungspartner prüfen?

Das Gesamtbild eines potenziellen Softwarepartners samt nachvollziehbarer Informationssicherheitsprozesse, eines klar geregelten Berechtigungsmanagements sowie definierter Entwicklungs- und Freigabeprozesse nebst Möglichkeit, entsprechende Kontrollen und Nachweise zu prüfen, sind für Banken relevant.

Auch Verträge werden unter DORA wichtiger. Für IKT-Dienstleistungen sieht die Verordnung Mindestanforderungen vor - bei Leistungen, die kritische oder wichtige Funktionen unterstützen, kommen zusätzliche Anforderungen wie umfangreichere Überwachungs-, Zugangs-, Inspektions- und Auditrechte hinzu. Damit wird bereits bei der Auswahl eines Entwicklungspartners relevant, ob dieser mit solchen Anforderungen umgehen kann.

NIS2 und NISG 2026: Lieferkettensicherheit wird breiter relevant

Seit 1. Oktober 2026 gilt in Österreich das Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026), mit dem die europäische NIS2-Richtlinie national umgesetzt wird. Das ist auch für die Diskussion über Software-Lieferketten relevant, denn das Gesetz verlangt von betroffenen wesentlichen und wichtigen Einrichtungen angemessene technische, operative und organisatorische Cybersicherheitsmaßnahmen. Die zugrunde liegende NIS2-Richtlinie nennt die Sicherheit der Lieferkette dabei ausdrücklich als Teil dieser Risikomanagementmaßnahmen.

Für Banken bleibt DORA jedoch die zentrale sektorspezifische Regulierung und geht den entsprechenden NIS2-Vorgaben vor.

Der größere Zusammenhang ist dennoch relevant: Die Fähigkeit, digitale Lieferketten und externe Technologiepartner nachvollziehbar zu steuern, entwickelt sich weit über den Finanzsektor hinaus zu einer zentralen Anforderung.

Was bedeutet das für die Auswahl eines Banking-App-Entwicklungspartners?

Banken sollten einen potenziellen Entwicklungspartner deshalb nicht nur nach Technologien, Referenzen und Projektkosten beurteilen.

Mindestens ebenso wichtig ist die Frage, wie gut sich der Anbieter in die regulatorischen und organisatorischen Anforderungen der Bank integrieren lässt. bluesource – mobile solutions arbeitet seit vielen Jahren für Banken und Finanzunternehmen und ist mit den Due-Diligence-, Security- und Audit-Anforderungen der Bankkundschaft vertraut. Entsprechende Vendor Assessments und Audits werden regelmäßig durchgeführt.
Das Unternehmen ist nach ISO/IEC 27001:2022 zertifiziert. In der Entwicklung kommen unter anderem striktes Berechtigungsmanagement, Code-Review-Prozesse und definierte Quality Gates zum Einsatz.

Ein weiterer Unterschied liegt in der Lieferkette: Die Softwareentwicklung erfolgt mit dem eigenen Team im oberösterreichischen Hagenberg im Mühlkreis anstelle von Near- oder Offshoring. Entwicklungsverantwortung und zentrale Kompetenzen bleiben innerhalb des eigenen Teams.

Für Banken steht die Frage im Fokus, ob ein Entwicklungspartner Sicherheit, Prozesse, Verantwortlichkeiten und seine Lieferkette nachvollziehbar darstellen kann.

Banking-App-Projekt mit regulatorischen Anforderungen besprechen

Sie planen eine neue Banking-App oder entwickeln ein bestehendes mobiles Frontend weiter - wofür Sie einen Entwicklungspartner benötigen, der die Anforderungen eines regulierten Bankenumfelds kennt?
bluesource verbindet mobile Softwareentwicklung mit ISO-zertifiziertem Informationssicherheitsmanagement, einem eigenen Entwicklungsteam in Österreich und Erfahrung aus der Zusammenarbeit mit Finanzinstituten.

Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung.

Portrait von Martin Sprengseis
Managing Partner, Banken & Versicherungen
Martin Sprengseis-Kogler

Lassen Sie uns drüber reden!

Quellenhinweis

Die regulatorische Einordnung basiert auf der Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA), insbesondere den Bestimmungen zum Management des IKT-Drittparteienrisikos und zu vertraglichen Vereinbarungen mit IKT-Drittdienstleistern.
Für die österreichische Perspektive wurden die Informationen der Finanzmarktaufsicht Österreich (FMA) zum Management von IKT-Drittparteienrisiken sowie zum Verhältnis zwischen DORA und NIS2 beziehungsweise NISG 2026 herangezogen. Die Angaben zum NISG 2026 basieren auf dem Rechtsinformationssystem des Bundes (RIS).
Für Deutschland dienen die Informationen der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) zu DORA, IKT-Drittparteienrisiken und den regulatorischen Anforderungen an entsprechende Vertragsbeziehungen als Grundlage.
Angaben zur ISO/IEC-27001:2022-Zertifizierung und zu bluesource – mobile solutions basieren auf Unternehmensinformationen von bluesource.

Quellen:

FAQ

Häufig ja, nämlich dann, wenn die Leistung auf Dauer angelegt ist. Nach Einschätzung der FMA setzt eine IKT-Dienstleistung unter anderem eine vertragliche Grundlage und einen dauerhaften beziehungsweise längerfristigen Charakter der Leistung voraus. Ein reines Einmalprojekt ist deshalb nicht automatisch erfasst. Kommen Wartung, Support, Betrieb oder Weiterentwicklung hinzu, was bei Banking-Apps oft der Fall ist, sollte die Bank den Partner als IKT-Drittdienstleister behandeln. Die Einstufung nimmt die Bank im Einzelfall selbst vor.

Nein. DORA verlangt kein bestimmtes Zertifikat, ISO 27001 ist also nicht verpflichtend. Die Bank muss aber beurteilen können, ob der Dienstleister geeignet ist und angemessene Standards für Informationssicherheit einhält. Eine ISO-27001-Zertifizierung ist dafür ein relevanter, unabhängiger Nachweis. Laut FMA kann sie als Informationsquelle dienen, ersetzt aber weder die Prüfung vor Vertragsabschluss noch die laufende Überprüfung.

DORA sieht eine Due-Diligence-Prüfung vor Vertragsabschluss vor (Art. 28 DORA). Banken sollten auf das Gesamtbild achten: nachvollziehbare Informationssicherheitsprozesse, klar geregeltes Berechtigungsmanagement, definierte Entwicklungs- und Freigabeprozesse sowie die Möglichkeit, Kontrollen und Nachweise zu prüfen.

Dazu kommen Standorte und Unterauftragnehmer. Nearshoring und Subunternehmer sind nicht verboten, müssen aber transparent und beurteilbar sein. Die Länder oder Regionen, in denen Leistungen erbracht und Daten verarbeitet werden, sind vertraglich festzuhalten. Bei Leistungen für kritische oder wichtige Funktionen ist zusätzlich zu regeln, ob und unter welchen Bedingungen Unterauftragnehmer eingesetzt werden dürfen. Hier kommen außerdem umfangreichere Überwachungs-, Zugangs-, Inspektions- und Auditrechte hinzu. Wie tief die Bank Sub-Dienstleister prüft, richtet sich laut FMA nach Risiko und Verhältnismäßigkeit. Eine kurze, transparente Entwicklungslieferkette kann den Prüfaufwand verringern.

Ja, bluesource ist nach ISO/IEC 27001:2022 zertifiziert. Die Softwareentwicklung erfolgt mit dem eigenen Team im oberösterreichischen Hagenberg im Mühlkreis, anstelle von Near- oder Offshoring. Entwicklungsverantwortung und zentrale Kompetenzen bleiben im eigenen Team. In der Entwicklung kommen unter anderem striktes Berechtigungsmanagement, Code-Review-Prozesse und definierte Quality Gates zum Einsatz. Zudem ist bluesource mit den Vendor Assessments und Audits der Bankkundschaft vertraut.

Anmeldung zum Newsletter
Bleiben Sie auf dem Laufenden.