Viele Unternehmen haben ein Risikoregister. Manche haben sogar ein sehr gutes: sauber strukturiert, regelmäßig aktualisiert, mit Kategorien, Bewertungen, Maßnahmen, Verantwortlichen und hübschen Heatmaps. Und trotzdem bleibt im Alltag oft ein irritierender Eindruck: Das Register ist da – aber Entscheidungen passieren woanders. Projekte laufen, Provider werden gewechselt, Releases gehen live, Incidents eskalieren, Budgets werden gekürzt oder umgeschichtet. Und das Risikoregister? Es wird gepflegt, berichtet, zur Kenntnis genommen. Aber es steuert nicht.

Das ist keine Seltenheit, sondern eher der Normalfall. Nicht, weil Risk Management unwichtig wäre, sondern weil es häufig als Dokumentationsdisziplin betrieben wird. Dann entsteht ein Artefakt, das „vollständig“ wirken soll, aber im entscheidenden Moment zu wenig liefert: eine klare Priorisierung, eine begründete Entscheidung, eine spürbare Veränderung im Betrieb. Genau an dieser Stelle lohnt sich ein Perspektivwechsel. Ein Risikoregister ist nicht das Ziel. Es ist nur ein Rohstoff. Das Ziel ist, aus Risiko eine Entscheidungsfähigkeit zu machen – und zwar so, dass man im Alltag schneller, klarer und nachvollziehbarer steuern kann.

GRC wird in vielen Organisationen immer noch wie ein Sammelbegriff behandelt: ein bisschen Risiko hier, ein paar Kontrollen dort, dazu Richtlinien, Audits und eine Handvoll Reports. Und dann – ganz am Ende – eine Excel, die alles „zusammenführt“. Das Problem daran ist nicht Excel. Das Problem ist die Erwartung, dass man Führung, Steuerung und Nachweisführung über Listen „nachrüsten“ kann, während der Betrieb längst mit eigener Logik läuft.

Wenn Sie GRC wirklich wirksam machen wollen, hilft ein anderes Bild: GRC als Betriebssystem. Nicht als Tool, nicht als Abteilung und nicht als Papierlage – sondern als die Logik, nach der Entscheidungen vorbereitet, umgesetzt und überprüfbar gemacht werden. Ein Betriebssystem ist unsichtbar, solange es funktioniert. Es macht Abläufe zuverlässig, reduziert Reibung und sorgt dafür, dass ein System unter Last stabil bleibt. Genau das ist auch die Aufgabe eines guten GRC-Ansatzes: Er muss das Unternehmen im Alltag stabiler machen – und nebenbei auditfest.

GRC – Governance, Risk & Compliance – galt jahrelang als vernünftiger Dreiklang, in der Praxis aber oft als Dreifaltigkeit der Silos. Governance schrieb Richtlinien, Risk malte Heatmaps, Compliance pflegte Ordner – jede Disziplin korrekt im eigenen Kosmos, selten im Gleichklang. Das Ergebnis: viele Aktivitäten, wenig Wirkung. Heute, mit überlappenden Aufsichten (DORA, NIS2, AI Act, CRA, CSRD), komplexen Lieferketten und softwaregetriebener Wertschöpfung, bricht dieses Modell sichtbar. Was fehlt, ist kein weiterer Standard, sondern eine Arbeitsweise, die GRC zu einem System macht: aus einem Guss geplant, aus Daten gespeist, im Betrieb verankert, mit Nachweisen, die aus dem Tun entstehen – nicht aus dem Nachzeichnen. Dieser Beitrag zeigt, wie die Integration gelingt: organisatorisch, technisch, kulturell. Und warum „integriert“ nicht bedeutet, alles zu zentralisieren, sondern Schnittstellen so zu gestalten, dass Arbeit fließt.

1) Warum die alte GRC-Logik scheitert – und zwar zuverlässig

Silos sind bequem. Jedes Team setzt seine Tools, seine Taxonomie, seine KPIs. Doch drei strukturelle Brüche machen das alte Modell unhaltbar:

„GRC“ war über Jahre ein Sammelbegriff, hinter dem sich vieles und damit oft zu wenig verbarg: Richtlinienbibliotheken, Risikomatrizen, Kontrollen-Kataloge, Auditkalender. Das war nützlich, aber selten spürbar wertschöpfend. Heute kippt die Perspektive. Märkte reagieren in Stunden, Lieferketten sind digital verschaltet, Vorfälle verbreiten sich viral, Regulierungen greifen tiefer in Produkte und Prozesse ein. In dieser Welt kann Governance, Risk & Compliance nicht mehr die Disziplin der Nachreichungen sein. Sie muss führen – durch Echtzeitfähigkeit, Anschluss an den operativen Takt und Investitionssteuerung. Genau das meint GRC Next: Governance als Betriebsleistung, die Risiken nicht nur inventarisiert, sondern Zeit gewinnt, Renditen schützt und Wachstum ermöglicht. Es ist der Schritt vom „ordnet“ hin zu „entscheidet“.

Warum das alte GRC an Grenzen stößt

Das klassische GRC versprach Kontrolle durch Vollständigkeit: jede Policy erfasst, jedes Risiko bewertet, jedes Kontrollziel beschrieben, jedes Audit geplant. In stabilen Umfeldern reichte das. Doch drei Entwicklungen haben dieses Modell überholt.

Digitale Resilienz ist in den letzten Jahren zu einem festen Begriff in der Finanzwelt geworden. Unternehmen sprechen darüber in Strategiepapieren, Beratungsfirmen verwenden ihn in Hochglanzpräsentationen, und auch Regulierungsbehörden betonen immer wieder seine Bedeutung. Doch während Resilienz lange Zeit vor allem als gutes Ziel galt – als eine Art Leitlinie, an der man sich orientieren konnte – hat sich die Situation mit dem Digital Operational Resilience Act, kurz DORA, grundlegend verändert. Aus der Theorie ist eine gesetzliche Pflicht geworden, und die EU hat dafür fünf zentrale Säulen definiert, die jedes betroffene Unternehmen umsetzen muss. Diese Säulen sind nicht nur Überschriften in einem Gesetzestext, sondern bilden ein verbindliches Gerüst, das alle relevanten Aspekte abdeckt, um den Betrieb auch unter digitalen Extrembedingungen aufrechtzuerhalten. Wer sie versteht, erkennt schnell: Es geht nicht nur um Technik, sondern um ein Zusammenspiel aus Prozessen, Organisation und Kultur.

Der Gesamtzusammenhang: Warum DORA digitale Resilienz neu definiert

DORA ist keine weitere „IT-Compliance-Checkliste“, sondern ein Rahmenwerk, das das Zusammenspiel von Risikomanagement, operativem Betrieb, Lieferkette, Testkultur und sektorweitem Lernen in den Mittelpunkt stellt. Der Kernunterschied zu älteren Regelwerken: DORA verlangt Wirksamkeit. Es genügt nicht, Policies zu schreiben oder Tools zu beschaffen. Entscheidend ist, ob ein Institut seine kritischen Dienstleistungen auch dann liefern kann, wenn Teile der IT gestört, angegriffen oder extern beeinträchtigt werden. Messbar wird das an Reaktionszeiten, Wiederanlauf, Qualität der Kommunikation, Stabilität der Lieferkette und geübten Notfallabläufen. Die fünf Säulen bilden dafür die Struktur – die Umsetzung wird am Ergebnis gemessen.