Es gibt Regulierungswellen, die über Unternehmen hinweglaufen, ein paar neue Formulare hinterlassen und dann im Tagesgeschäft versanden. Und es gibt Regulierungen, die die Statik eines Hauses verändern: wie Entscheidungen fallen, wie Risiken gemessen werden, wie Verträge geschrieben sind, wie IT gebaut, betrieben und wiederhergestellt wird. MaRisk war für viele Institute der Start in dieses neue Denken; DORA zwingt es nun zu Ende. Dazwischen liegen Jahre, in denen BAIT/VAIT/KAIT, EBA-Leitlinien, Outsourcing-Regelwerke, Datenschutz und sektorübergreifende Cybersicherheitsvorgaben das Puzzle immer dichter gemacht haben. Das Ergebnis ist mehr als „mehr Pflichten“. Es ist ein neues Governance-Paradigma: weg von Richtlinien als Selbstzweck, hin zu wirksamer Steuerung mit Evidenz – im Normalbetrieb und unter Stress.

Von der Checkliste zur Steuerung: Was MaRisk wirklich ausgelöst hat

MaRisk hat die Grundmechanik moderner Governance im Finanzsektor etabliert: Risikobasierung, Proportionalität, Verantwortlichkeit der Geschäftsleitung. Viele Häuser begannen, Ziele und Risiken systematisch zu kaskadieren, Kontrollfunktionen unabhängiger zu stellen und mit drei Verteidigungslinien zu arbeiten. Doch der vielleicht wichtigste Schritt fand still statt: die Einsicht, dass ein reproduzierbarer Entscheidungspfad wertvoller ist als die perfekte Einzelmaßnahme. Ein Limit nützt nichts ohne Schwellen, Eskalationsrechte, Fristen und Re-Checks. Ein Risiko ist nur dann „behandelt“, wenn die Maßnahme nachweislich wirkt – nicht, wenn sie einmal beschlossen wurde. Diese Logik wirkt heute in allen Vorgaben fort.

Die Cloud ist längst kein Zukunftsthema mehr, sondern Alltag. Unternehmen aller Größenordnungen verlagern Daten, Anwendungen und ganze Infrastrukturen in die Cloud – aus guten Gründen: Flexibilität, Skalierbarkeit, schnellere Time-to-Market und planbarere Kosten. Doch wo Geschwindigkeit und Dynamik steigen, wachsen auch die Risiken. Viele Organisationen gehen Cloud Security noch immer zu intuitiv an – ohne eindeutige Ziele, ohne messbare Kontrollen, ohne gelebte Verantwortlichkeiten. Die Folge: Fehlkonfigurationen bleiben unentdeckt, Identitäten sind überprivilegiert, Protokolle fehlen, Nachweise für Compliance sind lückenhaft. Wer Cloud Security ernst nimmt, braucht mehr als Tools – er braucht einen Plan: klar, wiederholbar, auditierbar.

Ziele und Schutzbedarfe: Was wirklich geschützt werden muss

Der wirksamste erste Schritt ist eine Schutzbedarfsanalyse mit eindeutiger Priorisierung. Typische Klassen sind:

Wer 5G richtig verstanden hat, weiß: Der Sprung zur nächsten Mobilfunkgeneration wird nicht durch ein größeres Balkendiagramm im Speedtest definiert, sondern durch einen Architekturwechsel. 6G verspricht kein bloßes „Mehr“ an Bandbreite, sondern ein „Anders“: Netze, die sehen, hören, orten, interpretieren und entscheiden; Netze, die nicht nur Daten transportieren, sondern Bedeutung übertragen; Netze, die so eng mit Sensorik, KI und Edge-Rechenleistung verzahnt sind, dass sie zu einem operativen Sinnesorgan für Wirtschaft und Gesellschaft werden. Genau darin liegt der Kern der kommenden Welle – und die Frage, wie Unternehmen sich heute schon auf die Möglichkeiten und Pflichten von morgen vorbereiten.

Warum 6G mehr ist als „5G, aber schneller“

Die Versuchung ist groß, 6G unter die Überschrift „Gigabit mal zwei“ zu stellen. Doch dieser Blick greift zu kurz. Schon 5G hat den Paradigmenwechsel eingeleitet: weg vom „best effort“-Funk, hin zu planbaren Eigenschaften (Latenz, Jitter, Verfügbarkeit) per Network Slicing und Edge Computing. 6G setzt genau dort an – und verschiebt die Grenzwerte in vier Richtungen:

Policy-Sprawl ist eines dieser Probleme, die selten als „Problem“ gestartet sind. Es entsteht fast immer aus guten Gründen. Ein Audit bringt neue Anforderungen, ein Incident erzeugt Druck, ein neuer Dienstleister will klare Regeln, eine Revision fordert Nachweise, eine Aufsicht setzt Schwerpunkte, oder ein interner Standard soll harmonisiert werden. Also schreibt man eine Richtlinie. Und noch eine. Und irgendwann sind es nicht zehn, sondern vierzig, sechzig, achtzig. Das Ergebnis wirkt zunächst professionell – bis der Alltag zeigt, was sich heimlich aufgebaut hat: Niemand weiß mehr sicher, welche Regel in welchem Fall gilt, welche Version verbindlich ist, wo Ausnahmen stehen, welche Vorgaben sich widersprechen und welche davon wirklich gelebt werden. Im schlimmsten Fall entsteht eine Parallelrealität: Auf dem Papier ist alles geregelt, im Betrieb entscheidet Erfahrung, Gewohnheit und der schnellste Weg.

Das Gefährliche an Policy-Sprawl ist nicht die Anzahl der Dokumente. Das Gefährliche ist die verlorene Steuerbarkeit. Je mehr Richtlinien existieren, desto stärker steigt die Wahrscheinlichkeit, dass sie sich gegenseitig überlagern, dass Zuständigkeiten unklar werden und dass Teams anfangen, Richtlinien zu umgehen, weil sie zu schwer, zu unübersichtlich oder zu weit weg vom Betrieb sind. Dann kippt das Ganze in ein Muster, das man im Audit häufig sofort erkennt: Es gibt viele Dokumente, aber wenig belastbare Evidenz dafür, dass die Regeln im Alltag wirklich wirken. Und genau das ist der Punkt, an dem aus „guter Governance“ plötzlich „Dokumentationslast“ wird – ohne dass das Risiko sinkt.

Der „Wizard of GRC“ für eine Zeit, in der dein Kaffee noch warm ist

Es ist ein schwindelerregender Moment: Du öffnest den Editor, gibst zwei, drei Sätze in ein Prompt-Feld – und noch bevor dein Kaffee kalt wird, steht das Gerüst eines kompletten Dienstes vor dir. Routen, Controller, Datenmodell, API-Doku, Unit-Tests, Dockerfile, CI-Workflow: alles da. Was gestern noch ein Sprint war, passt heute in eine Session. Fantastisch für die Geschwindigkeit, beängstigend für die Sichtbarkeit. Denn jede generierte Codezeile erzählt nicht nur eine Geschichte von Produktivität, sondern auch eine über Compliance, Abhängigkeiten und Third-Party-Risiken.