Cloud ist längst nicht mehr nur Technologieentscheidung, sondern Strategiethema. Institute wollen schneller liefern, Lastspitzen elastisch abfedern, Innovationen aus der Plattform-Ökonomie nutzen – und zugleich die Kontrolle behalten: über Daten, Risiken, Lieferketten, Kosten und Nachweise. Genau an dieser Nahtstelle zwischen Geschwindigkeit und Beherrschbarkeit setzt die BAIT an. Sie schreibt nicht vor, welche Cloud zu wählen ist oder wie viele Availability Zones „genug“ sind. Aber sie macht unmissverständlich klar, dass Verantwortung im Haus bleibt, dass Auslagerung nicht Entsorgung ist und dass Prüfanforderungen nicht am Rechenzentrumsrand enden. Wer die Cloud souverän nutzen will, liest BAIT daher nicht als Bremse, sondern als Geländer: Sie definiert Leitplanken, innerhalb derer sich Institute sicher bewegen können – mit Tempo, aber ohne Kontrollverlust.

Cloud ist kein Ziel, sondern ein Betriebsmodell

Die meisten Transformationsprogramme starten mit einer langen Tool-Liste und enden in Diskussionen über Providerfunktionen. Das verfehlt den Kern. Cloud ist ein anderes Betriebsmodell: Infrastruktur, Plattform und teils komplette Anwendungen werden als Service bezogen, Verantwortlichkeiten verschieben sich entlang des „Shared-Responsibility“-Modells, Änderungen wandern vom Change-Board in Automationspipelines, und Beobachtbarkeit ersetzt Bauchgefühl. BAIT verdeutlicht, was das heißt: Governance, Risikosteuerung, Informationssicherheit, Berechtigungen, Entwicklung/Change, Betrieb/Notfall sowie Auslagerungen müssen als durchgehende Kette funktionieren – nicht als sieben Silos. Cloud wird dort beherrschbar, wo diese Kette geschlossen ist und an jeder Stelle prüfbare Spuren entstehen.

Es gibt Momente, in denen ein Regelwerk seinen wahren Charakter zeigt. Nicht, wenn alles ruhig ist und Pläne akkurat funktionieren, sondern wenn mehrere Dinge gleichzeitig schiefgehen: Märkte zucken, Systeme stolpern, ein Dienstleister meldet Störung, das Callcenter läuft am Limit, und im Vorstand klingeln die Telefone. Genau in diesen Augenblicken beweist sich MaRisk – als Stresstest für Steuerung, Daten, Prozesse und Verhalten. Entweder entsteht Kontrolle: klare Prioritäten, kurze Schleifen, nachvollziehbare Entscheidungen, verlässliche Eskalationen. Oder es herrscht Chaos: Meeting-Marathons ohne Beschluss, Reports, die mehr Fragen als Antworten erzeugen, widersprüchliche Mails, Verantwortungen im Nebel. Dieser Artikel zeigt, warum MaRisk im Kern kein Papierprojekt ist, sondern ein System, das einen ganzen Kosmos aus Kredit, Markt, Liquidität, IT, Auslagerungen und operationellen Risiken in handhabbare Praxis übersetzt – und warum gerade IT-Organisationen davon genauso betroffen sind wie die klassischen Risikoeinheiten.

Worum es im Kern geht: Steuerungsfähigkeit unter Druck

MaRisk ist weder Checklistenromantik noch Selbstzweck. Es ist der Versuch, in einem hochkomplexen Umfeld eine gemeinsame Denkschiene für Entscheidungen zu etablieren: Welche Risiken nehmen wir bewusst? Woran erkennen wir Abweichungen früh? Welche Schwellen lösen Maßnahmen aus? Wer darf was entscheiden? Und wie kommen Erkenntnisse aus Fachbereichen, IT und Auslagerungen zur rechten Zeit an den Ort, an dem gehandelt wird?

Vorstände lieben klare Ampeln. Grün heißt: weiter so. Rot heißt: sofort handeln. Gelb bedeutet: beobachten, vielleicht ein Projekt starten. Eine Business Impact Analyse (BIA) liefert solche Ampelfarben scheinbar auf Knopfdruck. Sie verrät, welche Prozesse kritisch sind, welche Ausfälle schmerzen, welche RTOs und RPOs gelten sollen. Das Dokument ist sauber, die Prioritäten sind sichtbar, man nickt, unterschreibt – und geht zum Tagesgeschäft über. Wochen später kommt die Frage nach dem Budget für neue Kontrollen, redundant ausgelegte Systeme, Pen-Tests oder Backup-Modernisierung. Und plötzlich wirkt die BIA erstaunlich leise. Sie beantwortet nämlich nicht die Fragen, die jetzt wirklich zählen: Wie groß ist das Risiko? Wie wahrscheinlich ist welches Szenario? Welcher Euro investiert reduziert welchen Verlust um wie viel? Was bleibt als Rest­risiko – und ist das mit unserer Risikobereitschaft vereinbar?

Genau an dieser Stelle fehlt in vielen Organisationen der nächste, entscheidende Schritt: die Risk Impact Analysis – kurz RIA. Unter RIA verstehen wir hier die systematische Übersetzung der BIA-Erkenntnisse in quantifizierte Risiken, konkrete Steuerungsoptionen und belastbare Investitionsentscheidungen. BIA beschreibt, was passiert, wenn etwas ausfällt. RIA zeigt, wie oft das realistischerweise passieren kann, wie teuer das im Erwartungswert und in Extremszenarien wird, welche Maßnahmen welchen Risikoeffekt haben und welches Rest­risiko bewusst zu akzeptieren ist. Wer diesen Schritt auslässt, produziert schöne Folien – aber keine Steuerung.

Mit dem Entwurf IDW EPS 528 (08.2025) legt das Institut der Wirtschaftsprüfer erstmals einen branchenübergreifenden Prüfungsstandard für die aufsichtliche Prüfung nach DORA vor. Der Standard adressiert Institute, Versicherungsunternehmen, externe Kapitalverwaltungsgesellschaften sowie bestimmte Investmentvermögen und schafft damit einen konsistenten, methodisch klar strukturierten Rahmen für Planung, Durchführung und Berichterstattung von DORA-Prüfungen. Er ist bis zum 31.10.2025 zur Stellungnahme geöffnet.
Zum Entwurf: https://lnkd.in/dyWzguDM

Einordnung: Warum dieser Standard jetzt wichtig ist

DORA ist seit dem 17. Januar 2025 anzuwenden und markiert den Übergang von isolierten IT-Sicherheitsanforderungen hin zu einem einheitlichen europäischen Rahmen für digitale operationale Resilienz. Das Finanzmarktdigitalisierungsgesetz (FinmadiG) verankert zugleich die Prüfung ausgewählter DORA-Pflichten im Rahmen der Jahresabschlussprüfung – erstmals für Geschäftsjahre, die nach dem 31.12.2024 beginnen. In dieser Lage fehlte bislang ein sektorübergreifender Prüfungsmaßstab, der die Vielzahl an Einzelanforderungen in ein nachvollziehbares Prüfungsprogramm übersetzt. IDW EPS 528 schließt diese Lücke: Er formuliert eine prinzipienorientierte, risikobasierte Prüfarchitektur, die die Proportionalität in den Mittelpunkt stellt und gleichzeitig die Anschlussfähigkeit an die Aufsichtspraxis sicherstellt.

Eine tragfähige IT-Strategie beginnt nicht mit einem Toolkauf, nicht mit einer Cloud-Migration und auch nicht mit einer neuen Architekturfolie. Sie beginnt mit einer gedanklichen Klarheit über Richtung und Sinn: Welche langfristigen Ziele verfolgen wir als Unternehmen – und welche Rolle spielt die IT dabei? Diese Frage klingt simpel, ist in der Praxis aber der Dreh- und Angelpunkt. Wer sie überzeugend beantwortet, formt eine robuste Vision, aus der sich Entscheidungen ableiten lassen – täglich, in Projekten, in Budgets, in Personalfragen, in der Zusammenarbeit mit Partnern und nicht zuletzt in der Art, wie über Technologie gesprochen wird.

Eine IT-Vision ist kein Slogan, der auf einer Folie glänzt; sie ist eine Zielvorstellung, die Orientierung stiftet und Grenzen zieht. Gerade in der IT, wo Produktzyklen kurz, Technologien flüchtig und Hypes omnipräsent sind, braucht es diesen Fixstern. „Langfristig“ ist hier kein 20-Jahres-Horizont, sondern meist drei bis fünf Jahre – ein Zeitraum, in dem sich Strategien realisieren lassen und in dem gleichwohl genügend Ungewissheit liegt, um Demut vor der Zukunft zu bewahren. Eine gute IT-Vision formuliert deshalb Ambition ohne Allwissenheit: Sie benennt, was erreicht werden soll, ohne vorzugeben, über welche konkreten Releases, Tools oder Lieferanten man dort ankommt.