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.

KRITIS, NIS2, DORA – drei Kürzel, die in vielen Unternehmen gerade gleichzeitig aufschlagen. Und fast immer passiert dabei dasselbe: Es wird erst mal gesammelt. Anforderungen, Pflichten, Leitfäden, Listen, Zuständigkeiten. Dann entstehen Workstreams. Dann entstehen Überschneidungen. Und irgendwann stellt jemand die richtige Frage: „Moment – was davon betrifft uns wirklich, und wie vermeiden wir Doppelarbeit?“

Dieser Beitrag ist eine Landkarte. Nicht im Sinne eines juristischen Kommentars, sondern als Orientierung für Praktiker: Welche Themen liegen wo, was ist ähnlich, was ist wirklich anders – und welche Entscheidungen sollten Sie früh treffen, damit Sie nicht ein Jahr lang parallel aneinander vorbeiarbeiten. Ich vermeide bewusst Nebelbegriffe. Stattdessen arbeite ich mit einem einfachen Prinzip: Pflichten sind nur dann hilfreich, wenn sie sich in einen betrieblichen Ablauf übersetzen lassen.

Auf dem Papier wirkt die Risikologik des EU AI Act zunächst wie eine saubere Sortierung: Einordnen, Pflichten ableiten, fertig. In der Praxis ist genau dieser Schritt einer der größten Stolpersteine. Nicht, weil Teams das Thema „nicht verstehen“, sondern weil Klassifizierung im Alltag selten an einem klaren, stabilen Entscheidungsprozess hängt. Stattdessen passiert sie oft nebenbei: im Projekt, im Einkauf, in der IT, manchmal in der Fachabteilung – je nachdem, wer gerade am schnellsten ist. Das Ergebnis ist dann eine Mischung aus gut gemeinten Annahmen und unvollständigen Informationen. Und genau dort entstehen Fehlklassifizierungen.

Warum ist das so kritisch? Weil die Risikoklasse im EU AI Act nicht nur ein Label ist. Sie steuert, wie streng Sie Anforderungen erfüllen müssen, welche Nachweise Sie brauchen, wie viel Governance-Takt sinnvoll ist – und welche Risiken Sie eingehen, wenn Sie zu locker oder zu streng einsortieren. Eine Fehlklassifizierung ist daher selten nur ein „Formfehler“. Sie führt typischerweise zu einem von zwei Problemen: Entweder Sie unterschätzen Pflichten und stehen später mit Lücken da. Oder Sie überziehen unnötig und bauen eine Governance, die Projekte bremst und dann umgangen wird. Beides ist gefährlich – nur auf unterschiedliche Weise.

NIS2 und ISO 27001 begegnen sich in vielen Unternehmen gerade auf eine Weise, die erst einmal „logisch“ wirkt – und dann erstaunlich schnell anstrengend wird: Man hat ein etabliertes ISMS, dazu ein Set an Kontrollen, Richtlinien und Nachweisen. Dann kommt NIS2, und plötzlich entstehen neue Listen, neue Workstreams, neue Maßnahmenpläne, neue Reportings. Alles mit gutem Grund. Und trotzdem bleibt bei vielen Teams am Ende ein Gefühl: Wir machen vieles doppelt, und trotzdem sind wir nicht sicher, ob es wirklich besser geworden ist.

Genau hier lohnt sich ein Perspektivwechsel. Denn NIS2 ist kein Ersatz für ISO 27001, aber es zwingt dazu, den Blick zu erweitern: weg von „Sicherheitsmanagement als System“ hin zu „Sicherheits- und Resilienzfähigkeit als Betriebsrealität“. ISO 27001 liefert Ihnen die Struktur, um Informationssicherheit systematisch zu managen. NIS2 setzt stärker auf die Frage, ob diese Struktur in der Praxis spürbar wirkt – besonders dort, wo es unangenehm wird: bei Incidents, bei Lieferkettenabhängigkeiten, bei Managementverantwortung, bei operativer Steuerung. Das ist keine Kritik an ISO 27001. Es ist eine Erinnerung daran, dass ein Managementsystem erst dann seine Stärke zeigt, wenn es den Betrieb stabilisiert, nicht nur Dokumente erzeugt.

Wenn in der Praxis über DORA gesprochen wird, geht es oft zuerst um interne Themen: Prozesse, Rollen, Tests, Meldungen, Nachweise. Das ist nachvollziehbar, weil man dort „direkt“ gestalten kann. Der größte Hebel für die operative Stabilität liegt aber in vielen Unternehmen an einer anderen Stelle: bei externen Dienstleistern. Nicht, weil Dienstleister per se schlecht wären – im Gegenteil. Sondern weil moderne IT-Landschaften ohne Provider, SaaS, Plattformen, Rechenzentren, Integrationspartner und spezialisierte Services kaum noch sinnvoll betrieben werden können. Genau dadurch entsteht jedoch ein Risiko, das in Audits und im Ernstfall besonders sichtbar wird: Ihr Dienstleister kann Ihr größtes Ausfallrisiko sein – und zwar selbst dann, wenn Ihre interne Organisation sauber aufgestellt ist.

Third-Party Risk klingt als Begriff schnell nach „Vendor Management“. In der Realität ist es viel konkreter: Es geht um Abhängigkeiten, um Reaktionsfähigkeit, um Eskalationswege, um das Zusammenspiel im Incident – und um die Frage, ob Sie als Kunde die Steuerung wirklich in der Hand haben. DORA verschärft diese Perspektive, weil es nicht reicht, einen Vertrag zu haben oder einmal im Jahr eine Bewertung auszufüllen. DORA zielt auf laufende Beherrschung: wiederholbar, nachvollziehbar und im Betrieb sichtbar.