GRC-Automation klingt nach einer naheliegenden Lösung: Anforderungen wachsen, Nachweise steigen, Audits werden häufiger – also automatisieren wir eben. Workflows, Tickets, Freigaben, automatische Erinnerungen, Dashboards. Viele Organisationen starten genau so. Und viele stellen nach ein paar Monaten fest, dass zwar „mehr System“ da ist, aber nicht unbedingt mehr Steuerung. Manchmal sogar weniger. Das liegt nicht daran, dass Automation grundsätzlich schlecht wäre. Es liegt daran, dass Workflows nur dann helfen, wenn sie eine saubere Betriebslogik unterstützen. Wenn sie dagegen unklare Prozesse, diffuse Verantwortlichkeiten oder schlechte Evidenzlogik einfach nur digitalisieren, entsteht Tool-Chaos: mehr Klicks, mehr Status, mehr Listen – und trotzdem Unsicherheit, wenn es wirklich zählt.

Der Unterschied zwischen „hilfreicher Automation“ und „Tool-Chaos“ ist selten eine Toolfrage. Er ist eine Designfrage. Automatisierung ist wie Beton: Sie macht das, was schon da ist, stabiler – in gut wie in schlecht. Wenn Ihr GRC-Betrieb klare Decision Points hat, klare Owners, klare Nachweisartefakte und einen sinnvollen Takt, dann kann Automation diese Logik verstärken. Wenn Ihr Betrieb aber auf Zuruf funktioniert, wenn Entscheidungen informell getroffen werden oder wenn Evidenz nachträglich zusammengesucht wird, dann verstärkt Automation genau diese Schwächen. Dann wird aus „Wir automatisieren“ schnell „Wir pflegen ein System, das niemandem hilft“.

Kontrollwirksamkeit klingt nach etwas, das man „einfach messen“ müsste: Kontrolle definiert, Kontrolle durchgeführt, fertig. Viele Dashboards funktionieren genau nach dieser Logik. Sie zeigen Quoten: wie viele Kontrollen wurden ausgeführt, wie viele waren „ok“, wie viele Maßnahmen sind offen. Und trotzdem bleibt bei Führung und Prüfern oft ein ungutes Gefühl: Das sieht nach Aktivität aus, aber es sagt nicht zuverlässig, ob das Unternehmen tatsächlich stabiler und sicherer geworden ist. Genau hier biegen viele GRC-Dashboards falsch ab. Sie messen vor allem, dass etwas passiert – nicht, dass es wirkt.

Das ist kein akademischer Einwand. Es ist ein praktisches Problem, weil falsche Messlogik zu falscher Steuerung führt. Wenn Sie „Erfüllung“ reporten, optimieren Teams auf Erfüllung. Wenn Sie „Wirksamkeit“ reporten, optimieren Teams auf Wirksamkeit. Das klingt trivial, ist aber einer der größten Hebel in GRC. Denn Kennzahlen verändern Verhalten. Und wenn Kennzahlen das falsche Verhalten fördern, wird GRC mit jeder Ausbaustufe schwerer – ohne dass die Risikolage spürbar sinkt.

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.

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-KPIs sind in vielen Unternehmen ein Dauerbrenner – und trotzdem bleibt ein unangenehmes Gefühl: Wir messen viel, aber es verändert zu wenig. Es gibt Dashboards, Ampeln, Kontrollquoten, Reifegradwerte, Audit-Feststellungen, Maßnahmenlisten. Und dennoch fragen Führungskräfte irgendwann (zu Recht): „Was soll ich damit konkret entscheiden?“ Spätestens an diesem Punkt wird sichtbar, ob KPI-Reporting eine reine „Pflichtlage“ ist oder ein echtes Steuerungsinstrument.

Der Kern des Problems liegt selten in fehlenden Daten. Er liegt in der Logik dahinter. Viele GRC-KPIs sind so gebaut, dass sie zeigen, ob etwas existiert oder ob etwas erledigt wurde. Das ist nicht wertlos – aber es ist nur die erste Stufe. Führung braucht nicht primär ein Bild davon, dass Kontrollen „irgendwie laufen“. Führung braucht ein Bild davon, wo das Unternehmen gerade verwundbar ist, was die wahrscheinlichsten Ausfall- oder Schadensszenarien sind und welche Entscheidungen die Situation spürbar verbessern. Genau an dieser Stelle kippt das Reporting häufig: Es ist entweder zu technisch, zu detailliert oder zu sehr auf „Kontroll-Abarbeitung“ fokussiert. Dann wird es zwar geliefert, aber nicht genutzt.