FinOps trifft Regulierung: Cloud-Transparenz unter DORA

Cloud-Kosten werden häufig als reines Effizienzthema behandelt. Monatliche Rechnungen steigen, Einsparpotenziale werden gesucht, Reserved Instances diskutiert. In DORA-pflichtigen Finanzunternehmen greift diese Sicht aber zu kurz.

Mit der Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA) hat die EU einen Rahmen geschaffen, der IKT-Risiken einschließlich der Risiken aus der Cloud-Nutzung systematisch regelt. Die entscheidende Klarstellung steht in Art. 28 Abs. 1 lit. a DORA:

Finanzunternehmen, die vertragliche Vereinbarungen über die Nutzung von IKT-Dienstleistungen für die Ausübung ihrer Geschäftstätigkeit getroffen haben, bleiben jederzeit in vollem Umfang für die Einhaltung und Erfüllung aller Verpflichtungen nach dieser Verordnung und nach dem anwendbaren Finanzdienstleistungsrecht verantwortlich.

Mit der Cloud wird diese Verantwortung komplexer.

Anforderungen von DORA an Cloud-Leistungen

Gefordert sind:

• ein wirksames IKT-Risikomanagement

• ein strukturiertes Management des IKT-Drittparteienrisikos

• Transparenz über die IKT-Dienstleistungen, die das Unternehmen von IKT-Drittdienstleistern bezieht

• ein aktuelles Informationsregister über alle vertraglichen Vereinbarungen über die Nutzung von IKT-Dienstleistungen (Art. 28 Abs. 3 DORA)

Dieses Register ist für jedes Finanzunternehmen im Anwendungsbereich von DORA Pflicht, auch für Kleinstunternehmen. Aufbau und Felder sind in Standardvorlagen festgelegt (Durchführungsverordnung (EU) 2024/2956).

Ein Unternehmen muss also erklären können, welche Cloud-Leistungen es nutzt, in welchem Umfang, mit welcher Kritikalität und mit welcher vertraglichen Grundlage.

DORA fordert kein „FinOps-Programm“. Es gibt keinen Artikel, der Kostentransparenz als Selbstzweck vorschreibt.

FinOps als Betriebsmodell

FinOps ist ein Betriebs- und Steuerungsmodell für Cloud-Umgebungen. In regulierten Umfeldern wird es relevant, weil es die Lücke zwischen regulatorischer Dokumentationspflicht und operativer Cloud-Realität schließt.

Praxisbeispiel: Azure-Subscriptions ohne Zuordnung zu Geschäftsprozessen

Ein mittelständisches Finanzunternehmen betreibt mehrere historisch gewachsene Azure-Subscriptions, die zu unterschiedlichen Teams und damit zu unterschiedlichen Kostenstellen gehören.

Im Informationsregister ist der Hyperscaler sauber dokumentiert. Vertragsdaten sind vorhanden.

Es fehlt aber eine konsistente Übersicht darüber, welche Services für welche kritischen Geschäftsprozesse genutzt werden und wie sich die Nutzung entwickelt.

Formell liegt wohl kein Regelverstoß vor. Faktisch fehlt jedoch die Grundlage, um Konzentrations- oder Skalierungsrisiken realistisch zu bewerten.

FinOps liefert hier eine strukturierte Datengrundlage, mit der sich die Cloud-Nutzung belastbar steuern lässt:

• Nutzung pro Geschäftsprozess

• Zuordnung zu Verantwortlichen

• Entwicklung im Zeitverlauf

• Budgetabweichungen mit Begründung

Konzentrationsrisiken: Architektur ist nicht genug

DORA verlangt ausdrücklich, das IKT-Konzentrationsrisiko zu bewerten: vor jedem Vertrag über IKT-Dienstleistungen (Art. 28 Abs. 4 lit. c) und vertieft bei Verträgen über IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen (Art. 29). Feste Obergrenzen setzt DORA bewusst nicht (Erwägungsgrund 67).

In der Praxis wird Konzentrationsrisiko oft rein architektonisch diskutiert: „Wir nutzen hauptsächlich Azure.“

Was dabei fehlt, ist die quantitative Perspektive:

• Welche Workloads sind kritisch?

• Wie hoch ist die wirtschaftliche Abhängigkeit?

• Wie stark wächst die Nutzung?

Die jährlichen Ausgaben je Vertrag und je direktem IKT-Drittdienstleister gehören ohnehin ins Informationsregister (Durchführungsverordnung (EU) 2024/2956). Mit genaueren Kosten- und Nutzungsdaten lassen sich Konzentrationsrisiken nachvollziehbar beziffern. FinOps dient hier als Analysewerkzeug.

Drittparteienverantwortung endet nicht beim Vertrag

Art. 28 Abs. 1 DORA stellt klar: Die Verantwortung verbleibt beim Finanzunternehmen.

Das bedeutet praktisch:

• IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, müssen identifizierbar sein.

• Risiken müssen bewertet werden.

• Steuerungsmaßnahmen müssen dokumentiert sein.

Praxisbeispiel: Skalierung ohne Schwellenwerte

Ein DevOps-Team implementiert automatisches Autoscaling für produktive Systeme, technisch sauber und wirtschaftlich vertretbar.

Bei einer internen Prüfung stellt sich jedoch heraus:

• Es gibt keine definierten Schwellenwerte.

• Keine formale Dokumentation der Kostenlogik.

• Keine abgestimmten Budgetgrenzen für kritische Systeme.

Ein Kostenlimit schreibt DORA nicht vor. Fehlende Kostentransparenz kann in solchen Konstellationen trotzdem als Indiz mangelnder Steuerungsmechanismen im IKT-Risikomanagement gewertet werden.

FinOps-Mechanismen wie Budget-Alerts, definierte Cost-Guardrails oder dokumentierte Architekturentscheidungen sind hier belastbare Governance-Elemente.

Reporting: Zwischen Risiko und Wirtschaftlichkeit

DORA verpflichtet Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle der Aufsicht zu melden (Art. 19), und verlangt einen internen Governance- und Kontrollrahmen für IKT-Risiken (Art. 5 Abs. 1). Monatliche Cloud-Kostenberichte an die Aufsicht sieht die Verordnung nicht vor. Die Mitglieder des Leitungsorgans müssen IKT-Risiken und ihre Auswirkungen verstehen und bewerten können (Art. 5 Abs. 4).

Hier entsteht die Schnittstelle zwischen:

• technischer Verfügbarkeit

• IKT-Drittparteienrisiko

• wirtschaftlicher Exposition

Ein reifes FinOps-Modell verbindet diese Ebenen:

• Kosten pro kritischem Geschäftsprozess

• Entwicklung der Provider-Abhängigkeit

• Forecast im Kontext regulatorischer Anforderungen

• Dokumentierte Entscheidungsgrundlagen

Damit entsteht Transparenz, die finanziell und regulatorisch relevant ist.

Grenzen von FinOps

FinOps ersetzt nicht:

• das IKT-Risikomanagement

• das Informationsregister

• die Sorgfaltspflicht bei potenziellen IKT-Drittdienstleistern

• das Testen der digitalen operationalen Resilienz

Es ist ein Organisationsinstrument. Sein regulatorischer Mehrwert entsteht erst durch Einbettung in bestehende Governance-Strukturen.

Typische Fehlannahmen im regulierten Mittelstand

Aus der Praxis zeigen sich wiederkehrende Missverständnisse:

1. „Wir haben einen Vertrag mit dem Hyperscaler, damit ist das Thema geregelt.“

2. „Kosten sind ein Controlling-Thema, nicht regulatorisch relevant.“

3. „Konzentrationsrisiken sind rein technisch.“

4. „FinOps ist nur Optimierung von Reserved Instances.“

Aus diesen Annahmen entstehen Lücken bei der Steuerbarkeit, der Verantwortung und der Transparenz, die DORA verlangt.

Fazit

Die Verantwortung bleibt beim Finanzunternehmen.

Diese Verantwortung umfasst:

• IKT-Drittparteienrisiken

• Konzentrationsrisiken

• Dokumentation und Registerführung (Art. 28 Abs. 3 DORA)

• verbleibende Gesamtverantwortung (Art. 28 Abs. 1)

FinOps ist ein wirkungsvolles Mittel, um die geforderte Steuerbarkeit im Betrieb umzusetzen und der Aufsicht zu zeigen, dass das Unternehmen seine Risiken beherrscht. Das gilt besonders im Mittelstand, wo Cloud-Umgebungen schnell wachsen und Governance-Strukturen oft schlank sind.