DORA-Gap-Analysen haben einen schlechten Ruf, und das nicht ganz zu Unrecht. Viele Organisationen starten mit guter Absicht und landen trotzdem in einem Zustand, der sich anfühlt wie „Workshop-Dauerbetrieb“: Anforderungen werden diskutiert, Interpretationen werden verglichen, Listen wachsen, offene Punkte werden in Maßnahmenpläne geschrieben – und nach einigen Wochen fragt jemand zu Recht: „Was haben wir jetzt eigentlich konkret gewonnen? Können wir irgendetwas belastbar zeigen, oder sind wir nur klüger geworden?“

Das Problem ist selten Fachwissen. Das Problem ist die Form. Eine Gap-Analyse, die nur auf Papier existiert, produziert zwar Erkenntnisse, aber keine Betriebsfähigkeit. DORA bewertet jedoch am Ende nicht Ihre Fähigkeit, Anforderungen zu erklären, sondern Ihre Fähigkeit, sie im Betrieb wiederholbar zu erfüllen – inklusive Nachweisen. Genau deshalb bleibt eine Gap-Analyse oft stecken, wenn sie als „Interpretationsprojekt“ geführt wird. Sie wird erst wirksam, wenn sie als Aufbau von prüfbaren Pfaden gestaltet wird: kritische Services, Entscheidungen, Prozesse, Evidenz. Das ist weniger diskutieren, mehr bauen.

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.

Als über den EU AI Act gesprochen wird, landen die Gespräche oft sehr schnell bei Governance-Strukturen, Risikoklassen, Registern und internen Prüfprozessen. Das ist wichtig – aber es blendet eine Realität aus, die in vielen Unternehmen darüber entscheidet, ob AI-Compliance überhaupt kontrollierbar wird: Der größte Teil der KI, die heute genutzt wird, wird nicht „gebaut“, sondern eingekauft. Und genau deshalb ist Einkauf und Vendor Management die unterschätzte Frontlinie.

Das klingt zunächst nach Zuständigkeitsdebatte, ist aber in Wahrheit eine Steuerungsfrage. Denn wenn KI-Funktionen in Standardsoftware, Cloud-Services, Plattformen oder Dienstleisterleistungen stecken, dann entstehen Pflichten und Risiken dort, wo Sie als Kunde Einfluss nehmen können: in Beschaffung, Vertragsgestaltung, laufender Steuerung und Exit-/Fallback-Logik. Wenn diese Hebel nicht sauber gesetzt sind, kann die beste interne Governance im Alltag kaum greifen. Dann haben Sie vielleicht ein KI-Register – aber die wesentlichen Informationen fehlen. Oder Sie haben eine Klassifizierung – aber kein vertragliches Fundament, um Nachweise einzufordern. Oder Sie haben Regeln – aber keine Routine, um Änderungen des Anbieters rechtzeitig zu erkennen.

NIS2 wird in vielen Unternehmen zunächst als „Security-Thema“ einsortiert: IT und Informationssicherheit klären Maßnahmen, Compliance koordiniert, und irgendwann bekommt die Geschäftsleitung ein Update mit Ampeln. Das wirkt vertraut, weil viele Regulierungs- und Auditwellen so gelaufen sind. Der Unterschied bei NIS2 ist jedoch, dass sich die Erwartung an die Geschäftsleitung deutlich verändert – nicht nur als Empfänger von Berichten, sondern als sichtbarer Teil der Verantwortungskette. In der Praxis ist das weniger dramatisch, als es manchmal klingt, aber es ist konkreter: Es geht um Organisationsentscheidungen, um Priorisierung, um nachvollziehbare Steuerung – und darum, dass diese Steuerung im Ernstfall und in der Prüfung belegbar ist.

Genau hier entstehen typische Reibungen. Auf der einen Seite will die Geschäftsleitung keine zusätzlichen „Programme“, die den Betrieb lähmen. Auf der anderen Seite will sie nicht in einer Situation stehen, in der ein Vorfall eskaliert, die Aufsicht Fragen stellt oder ein Kunde Nachweise fordert – und man dann feststellt, dass vieles zwar „gemacht“ wurde, aber nicht sauber als Verantwortung, Entscheidung und Evidenz zusammenläuft. Das ist der eigentliche Kern: NIS2 verlangt nicht, dass Vorstände plötzlich technische Spezialisten werden. NIS2 verlangt, dass Verantwortung so organisiert ist, dass sie im Betrieb funktioniert und im Zweifel auch nachweisbar ist.

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.