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 digitale operationale Resilienz (DORA) hat die EU einen Rahmen geschaffen, der ICT-Risiken systematisch adressiert – inklusive Risiken aus Cloud-Nutzung. Die entscheidende Klarstellung findet sich in Art. 28 Abs. 1 lit. a DORA:

Finanzunternehmen bleiben jederzeit vollständig verantwortlich für die Erfüllung ihrer Pflichten – auch wenn ICT-Dienstleistungen ausgelagert sind.

Cloud entbindet also nicht von Verantwortung. Sie verschiebt sie nicht. Sie macht sie komplexer.

Was DORA tatsächlich verlangt – und was nicht

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

Was DORA jedoch fordert, ist:

• ein wirksames ICT-Risikomanagement

• eine strukturierte Steuerung von ICT-Drittparteirisiken

• Transparenz über ausgelagerte Leistungen

• ein aktuelles Register of Information über alle vertraglichen ICT-Arrangements (Art. 28 Abs. 3 DORA)

Dieses Register ist verpflichtend – proportional in der Ausgestaltung, aber ohne generelle Ausnahme.

Was daraus folgt: Ein Unternehmen muss erklären können, welche Cloud-Leistungen es nutzt, in welchem Umfang, mit welcher Kritikalität und mit welcher vertraglichen Grundlage. DORA spricht also von Steuerbarkeit und Nachvollziehbarkeit, nicht von Kostensenkung.

Wo FinOps ins Spiel kommt

FinOps ist kein regulatorischer Begriff. Es ist ein Betriebs- und Steuerungsmodell für Cloud-Umgebungen. In regulierten Umfeldern wird es relevant, weil es eine Lücke schließt:

Zwischen regulatorischer Dokumentationspflicht und operativer Cloud-Realität.

Praxisbeispiel: Fehlende Transparenz ist kein Compliance-Verstoß – aber ein Governance-Risiko

Ein mittelständisches Finanzunternehmen betreibt mehrere Azure-Subscriptions. Historisch gewachsen, unterschiedliche Teams und damit unterschiedliche Kostenstellen.

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

Was jedoch fehlt: 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 keine juristische Pflicht, sondern eine strukturierte Datengrundlage, damit Steuerbarkeit belastbar wird:

• Nutzung pro Geschäftsprozess

• Zuordnung zu Verantwortlichen

• Entwicklung im Zeitverlauf

• Budgetabweichungen mit Begründung

Konzentrationsrisiken: Architektur ist nicht genug

DORA adressiert Konzentrationsrisiken ausdrücklich, insbesondere im Kontext kritischer ICT-Drittparteien. Dabei geht es nicht um starre Schwellenwerte, sondern um eine fundierte Bewertung von Abhängigkeiten.

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?

Spend- und Nutzungsdaten sind kein regulatorisches Muss – aber ein wirksames Instrument, um Konzentrationsrisiken nachvollziehbar zu quantifizieren. FinOps wird hier zum Analysewerkzeug. Nicht zur Compliance-Pflicht.

Drittparteienverantwortung endet nicht beim Vertrag

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

Das bedeutet praktisch:

• Kritische ICT-Leistungen 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. 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.

DORA verlangt kein explizites Kostenlimit. Aber es verlangt ein kontrolliertes ICT-Risikomanagement. In solchen Konstellationen kann fehlende Kostentransparenz als Indiz mangelnder Steuerungsmechanismen gewertet werden.

FinOps-Mechanismen wie Budget-Alerts, definierte Cost-Guardrails oder dokumentierte Architekturentscheidungen sind hier keine regulatorische Pflicht – aber ein belastbares Governance-Element.

Reporting: Zwischen Risiko und Wirtschaftlichkeit

DORA verpflichtet Unternehmen zu strukturiertem ICT-Incident-Reporting und zu einem angemessenen Steuerungs- und Kontrollsystem. Was DORA nicht verlangt: Monatliche Cloud-Kostenberichte an die Aufsicht. Was jedoch implizit erwartet wird: Management und Kontrollorgane müssen Risiken verstehen und bewerten können.

Hier entsteht die Schnittstelle zwischen:

• technischer Verfügbarkeit

• Drittparteirisiko

• 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 nicht nur finanziell, sondern regulatorisch relevant ist.

Was FinOps nicht leisten kann

Wichtig ist eine klare Abgrenzung:

FinOps ersetzt kein:

• ICT-Risikomanagement

• Auslagerungsregister

• Drittparteien-Due-Diligence

• Resilienztest

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.“

DORA adressiert keine dieser Aussagen direkt. Aber es fordert Steuerbarkeit, Verantwortung und Transparenz – und genau hier entstehen die Lücken.

Fazit: FinOps als Enabler, nicht als Pflicht

DORA fordert keine Kostensenkung. DORA fordert Verantwortung.

Diese Verantwortung umfasst:

• ICT-Drittparteirisiken

• Konzentrationsrisiken

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

• verbleibende Gesamtverantwortung (Art. 28 Abs. 1)

FinOps ist kein regulatorisches Muss. Aber es ist ein wirkungsvolles Mittel, um die geforderte Steuerbarkeit operativ umzusetzen. Insbesondere im Mittelstand, wo Cloud-Umgebungen schnell wachsen und Governance-Strukturen oft schlank sind, wird diese Transparenz zum entscheidenden Faktor.

Nicht, weil die Aufsicht Kosten sehen will. Sondern weil sie sehen will, dass Risiken beherrscht werden.