KPI‑basierte Risiko‑Governance: Welche Kennzahlen Manager für IT‑Risiken festlegen sollten

Viele Organisationen haben ein formal korrektes Risikoregister, aber kaum eine belastbare Steuerung im Alltag. In der Praxis entscheidet nicht die Anzahl dokumentierter Risiken, sondern ob Verantwortliche früh erkennen, wo sich Risiko tatsächlich aufbaut, und ob Maßnahmen wirksam sind. Genau hier setzt KPI‑basierte Risiko‑Governance an: Sie übersetzt abstrakte Risiken in wenige, konsistent gemessene Kennzahlen, die sich über Teams, Systeme und Lieferanten hinweg vergleichen lassen – und die in Entscheidungen zu Budget, Prioritäten, Ausnahmen und Eskalationen münden.

Der kritische Punkt: KPIs (Key Performance Indicators) messen Leistung und Umsetzung, KRIs (Key Risk Indicators) messen Risikoexposition. In vielen Reports werden beide vermischt. Das führt zu scheinbar „grünen“ Dashboards, obwohl das Unternehmen faktisch verletzlich bleibt (zum Beispiel gute Patch‑Quote insgesamt, aber hohe Verwundbarkeit in internetexponierten Systemen). Dieser Beitrag zeigt, welche Kennzahlen sich für IT‑Risiken bewährt haben, wie Sie sie definieren, welche Datenquellen typischerweise nötig sind und wie Sie Governance so aufsetzen, dass Audits und Betriebsrealität zusammenpassen.

Warum Kennzahlen in der Risiko‑Governance oft scheitern

Typische Fehlerbilder sind erstaunlich konstant – unabhängig von Branche oder Tooling:

• Zu viele Kennzahlen: Teams reporten 30–60 Werte, aber niemand kann daraus Entscheidungen ableiten. Konsequenz: Reporting als Pflichtübung, nicht als Steuerung.
• Uneinheitliche Definitionen: „kritische Systeme“, „Patch‑Stand“ oder „Incident“ bedeuten in Betrieb, Security und Audit jeweils etwas anderes. Das macht Trends wertlos.
• Keine Verknüpfung zu Verantwortlichkeiten: Ohne klare RACI‑Logik (Responsible, Accountable, Consulted, Informed) bleibt unklar, wer handeln muss – und wer das Risiko trägt.
• Metriken ohne Datenhygiene: Wenn Asset‑Inventar und Identitäten nicht stimmen, werden Kennzahlen zu Scheinpräzision. Audit‑Fragen lassen sich dann nicht beantworten.
• Keine Schwellenwerte und Eskalationspfade: Ein „roter“ Wert ohne definierte Folgeentscheidung erzeugt nur Diskussion, keine Risikoreduktion.

Eine belastbare KPI‑Logik ist weniger ein Dashboard‑Thema als ein Governance‑Thema: Definitionen, Datenquellen, Grenzwerte, Maßnahmenkatalog, Ausnahmeverfahren und Audit‑Evidenz müssen zusammenpassen.

KPI‑basierte Risiko‑Governance: Grundmodell, Rollen und Entscheidungslogik

Für IT‑Risiken hat sich ein dreistufiges Modell bewährt, das auch in Audits gut nachvollziehbar ist:

1) Risikoexposition (KRIs): „Wie groß ist das Risiko gerade?“

KRIs zeigen die aktuelle Angriffs- oder Ausfallfläche, z. B. ungepatchte kritische Schwachstellen in produktiven, internetexponierten Systemen. Sie sind führende Indikatoren, weil sie vor Incidents steigen.

2) Kontrollwirksamkeit (Control KPIs): „Funktionieren unsere Kontrollen?“

Beispiele sind MFA‑Abdeckung, erfolgreiche Restore‑Tests oder Change‑Erfolgsquote. Diese KPIs zeigen, ob die Governance‑Kontrollen im Betrieb wirklich greifen.

3) Ergebniskennzahlen (Outcome KPIs): „Welche Schäden/Unterbrechungen treten ein?“

Beispiele sind ungeplante Ausfallzeit, Sicherheitsvorfälle mit Datenabfluss oder Kosten aus Notfallmaßnahmen. Diese Kennzahlen sind wichtig, kommen aber oft zu spät, um zu steuern.

Wichtig ist die Rollenzuordnung: Accountable ist typischerweise ein Service‑Owner oder System‑Owner (für Risiko im jeweiligen Scope), Responsible sind Betrieb/Security‑Funktionen, und Consulted/Informed sind Compliance, Datenschutz, Einkauf und Management. Ohne diese Zuordnung werden KPIs zu „Security‑Zahlen“, die fachlich zwar stimmen, aber organisatorisch wirkungslos bleiben.

Auswahlprinzipien: Welche Kennzahlen Manager wirklich brauchen

Wenn Sie nur wenige Kennzahlen auswählen dürfen, sollten diese vier Kriterien erfüllen:

• Entscheidungsfähigkeit: Der Wert muss eine konkrete Aktion auslösen können (priorisieren, freigeben, stoppen, ausnehmen, eskalieren).
• Vergleichbarkeit: Der Wert muss über Zeit und über Einheiten (Teams/Services/Standorte) konsistent sein.
• Manipulationsresistenz: Die Kennzahl sollte nicht „grünreportbar“ sein, indem man Definitionen verschiebt oder Tickets schließt, ohne Risiko zu senken.
• Audit‑Evidenz: Datenquelle, Ermittlung, Verantwortlichkeit und Nachweis müssen reproduzierbar sein.

Praktisch heißt das: Lieber 10–15 Kernkennzahlen mit klaren Grenzwerten und Maßnahmenlogik als ein unüberschaubares KPI‑Set. Ergänzende Detailkennzahlen können operativ existieren, gehören aber nicht in das Management‑Gremium.

Kern‑Kennzahlen für IT‑Risiken (mit Definitionen, Schwellen und typischen Datenquellen)

Im Folgenden ein praxistauglicher Satz von Kennzahlen. Sie können ihn als Vorlage nutzen und pro Unternehmen auf Kritikalität, Regulatorik und Architektur (On‑Prem, Cloud, Hybrid) anpassen.

1) Asset‑Abdeckung: Wie vollständig ist unsere Sicht?

Warum relevant: Ohne verlässliches Asset‑Inventar (Endgeräte, Server, Cloud‑Ressourcen, Anwendungen, Schnittstellen) sind alle nachgelagerten KPIs unsicher. In Audits ist das oft der erste Angriffspunkt.

• KPI: Abdeckungsgrad verwalteter Assets = (Assets in Inventar/CMDB mit Owner + Kritikalität + Lifecycle‑Status) / (gesamte entdeckte Assets)
• Schwellen: Management‑Zielwerte je Scope (z. B. Produktiv/Internet) strenger als für Lab‑Netze
• Datenquellen: CMDB, Discovery‑Scanner, Cloud‑Asset‑Inventar, MDM/EDR, Netzwerk‑Inventarisierung

Governance‑Hinweis: Definieren Sie „Asset“ und „Owner“ eindeutig. Für Business‑Software und prozessnahe Softwarelösungen ist der Service‑Owner (fachlich/operativ) meist sinnvoller als ein rein technischer Host‑Owner.

2) Kritikalitätsabdeckung: Wo fehlt Business‑Kontext?

KPI: Anteil Assets/Services mit klassifizierter Kritikalität (z. B. nach Verfügbarkeit, Vertraulichkeit, Integrität) und Datenkategorie (personenbezogen, vertraulich, öffentlich)

Warum relevant: Patch‑Fristen, Monitoring‑Dichte und Change‑Hürden müssen an Kritikalität hängen, sonst entsteht entweder Overhead oder Blindflug.

3) Patch‑Compliance als KRI: Risiko durch Rückstände in kritischen Zonen

Wichtig: „Patch‑Compliance“ ist nur dann risikorelevant, wenn sie segmentiert wird (z. B. internetexponiert, privilegierte Systeme, OT/Produktion, Kronjuwelen‑Datenbanken).

• KRI: Anteil Systeme mit überfälligen Sicherheitsupdates in definierten Kritikalitätsklassen (z. B. > 14/30/60 Tage über SLA)
• KPI ergänzend: Median‑Zeit bis Patch (MTTP: Mean Time To Patch) für kritische Updates
• Datenquellen: Patch‑Management, Configuration Management, Vulnerability‑Scanner, Cloud‑Image‑Pipelines

Schwellenlogik: Definieren Sie je Zone harte Grenzwerte und ein formales Ausnahmeverfahren. „Kann aktuell nicht gepatcht werden“ ist eine Entscheidung mit Risikoakzeptanz – kein Status.

4) Verwundbarkeiten: Exponierte kritische Schwachstellen (Exploit‑Risk)

Vulnerability‑Counts ohne Kontext sind unbrauchbar. Entscheidend ist die Kombination aus Schweregrad, Ausnutzbarkeit und Exposition.

• KRI: Anzahl/Anteil „kritischer, ausnutzbarer Schwachstellen“ in produktiven, extern erreichbaren Systemen
• Optional: Anteil Findings mit definiertem Remediation‑Plan und Owner
• Datenquellen: Vulnerability‑Scanner, EDR, WAF/Ingress‑Inventar, Cloud‑Security‑Scanner

Audit‑Perspektive: Dokumentieren Sie, wie „ausnutzbar“ operationalisiert wird (z. B. Known Exploited Vulnerabilities, Exploit‑Hinweise, Threat‑Intel‑Flags). Ohne Definition wird es im Audit zur Meinungsfrage.

5) Identitäts- und Zugriffssicherheit: MFA‑Abdeckung und Privileged Access

Viele erfolgreiche Angriffe sind Identity‑getrieben. Daher gehören IAM‑Kennzahlen (Identity and Access Management) in die Risiko‑Governance.

• KPI: MFA‑Abdeckung für privilegierte Konten und Remote‑Zugänge (Admin‑Konten, VPN, Cloud‑Konsole, O365/Workspace)
• KRI: Anzahl privilegierter Konten ohne nachvollziehbaren Owner oder ohne regelmäßige Rezertifizierung
• KPI: Zeit bis Deprovisioning (Offboarding) für kritische Rollen
• Datenquellen: IAM/IdP, PAM (Privileged Access Management), HR‑System, Ticketing

Governance‑Entscheidung: Legen Sie fest, welche Rollen „privilegiert“ sind (lokale Admins, DB‑Admins, Cloud‑Owner, CI/CD‑Admin, Backup‑Admin). Diese Liste ist ein Audit‑Artefakt und muss versioniert werden.

6) Logging und Detection: Abdeckung, Qualität, Reaktionsfähigkeit

„Wir haben ein SIEM“ ist keine Kennzahl. Messbar ist, ob relevante Quellen angebunden sind und ob Alarme zu Entscheidungen führen.

• KPI: Log‑Quellen‑Abdeckung in kritischen Services (Authentifizierung, Admin‑Aktionen, Datenzugriffe, Netzwerk‑Egress)
• KPI: MTTD/MTTA (Mean Time To Detect/Acknowledge) für Sicherheitsalarme definierter Schwere
• KRI: Anteil Alarme ohne Triage innerhalb SLA oder mit wiederkehrender Ursache ohne Maßnahme
• Datenquellen: SIEM, EDR, IdP‑Logs, Cloud‑Audit‑Logs, Ticketing/IR‑Plattform

Betriebsfolgen: Eine hohe Alarmzahl ist nicht automatisch schlecht; schlecht ist, wenn Alarme nicht bearbeitet werden oder keine nachhaltige Ursachenbehebung erfolgt.

7) Backup‑ und Recovery‑Risiko: Testquote, RPO/RTO‑Einhaltung

Backup‑Erfolg allein ist kein Sicherheitsnetz. Entscheidend ist, ob Wiederherstellung unter realen Bedingungen funktioniert.

• KPI: Anteil kritischer Systeme mit regelmäßigem Restore‑Test (nach Plan, mit Protokoll)
• KPI: Erfüllung von RPO/RTO (Recovery Point/Time Objective) in Tests und echten Ereignissen
• KRI: Anzahl Backup‑Jobs mit wiederkehrenden Fehlern oder ohne überprüfte Verschlüsselung/Unveränderlichkeit (Immutable Backup)
• Datenquellen: Backup‑System, Test‑Runbooks, Notfallprotokolle, Monitoring

Audit‑Evidenz: Restore‑Testprotokolle sind ein starkes Nachweisobjekt. Wichtig: Scope, Datenstand, Dauer, Abweichungen, Freigabe durch Owner.

8) Change‑Risk: Änderungen als Haupttreiber für Ausfälle

Change‑Management ist ein Risiko‑Hebel, nicht nur ITIL‑Prozess. Für digitale Unternehmenslösungen mit vielen Schnittstellen ist das besonders relevant.

• KPI: Change‑Failure‑Rate (Anteil Changes mit Rollback/Incident innerhalb definiertem Zeitraum)
• KPI: Anteil Changes mit vollständigem Risiko‑Check (Impact, Backout‑Plan, Testnachweis, Security‑Review bei relevanten Klassen)
• KRI: Anteil „Emergency Changes“ ohne nachgelagerte Bewertung und Ursachenanalyse
• Datenquellen: ITSM, Deployment‑Logs, Monitoring, Post‑Incident‑Reviews

Governance‑Praxis: Definieren Sie Change‑Klassen (standard/normal/emergency) und knüpfen Sie Mindestanforderungen und Nachweispflichten daran. Das reduziert Diskussionen im Einzelfall.

9) Incident‑Response‑Reife: Geschwindigkeit, Qualität, Lerneffekt

Outcome‑KPIs (Anzahl Incidents) sind stark von Erkennungsfähigkeit abhängig. Reife zeigt sich in Reaktionszeiten und im Lernen aus Vorfällen.

• KPI: MTTR (Mean Time To Restore) für definierte Service‑Ausfälle
• KPI: Anteil Security‑Incidents mit vollständiger Root‑Cause‑Analyse und Maßnahmenverfolgung
• KRI: Wiederholungsrate gleicher Incident‑Klassen (zeigt fehlende Prävention)
• Datenquellen: ITSM/IR‑Tool, Postmortems, Problem‑Management

10) Drittanbieter‑ und Lieferkettenrisiko: Steuerbarkeit statt Bauchgefühl

Third‑Party‑Risk ist häufig der Bereich, in dem Governance formal existiert, aber operativ nicht nachgehalten wird.

• KRI: Anteil kritischer Dienstleister ohne aktuelle Sicherheitsbewertung, ohne Vertragspunkte zu Incident‑Meldung/SLAs oder ohne Exit‑Plan
• KPI: Zeit bis Schließen identifizierter Lieferanten‑Findings
• Datenquellen: Vendor‑Management, Vertragsdaten, Auditberichte, Ticketing

Audit‑Perspektive: Wichtig ist weniger ein „Score“ als die Nachvollziehbarkeit: Klassifikation, Mindestanforderungen, Abweichungen, Risikoakzeptanz, Nachverfolgung.

Vorlage: KPI‑Steckbrief (Definition, Owner, Grenzwerte, Evidenz)

Damit Kennzahlen nicht zu Interpretationsspielraum werden, braucht jede Management‑Kennzahl einen Steckbrief. Folgende Struktur ist in Audits gut verwendbar:

• Name und Zweck (welche Entscheidung wird unterstützt?)
• Scope (welche Systeme/Services, welche Zonen, welche Zeitfenster)
• Definition/Formel (inkl. Datenfilter, Ausnahmen, Rundung)
• Owner (Accountable) und Datenverantwortliche (Responsible)
• Grenzwerte (grün/gelb/rot) und Eskalationspfad
• Maßnahmenkatalog (was ist bei gelb/rot verpflichtend?)
• Evidenz (welche Logs/Reports sind Nachweis, wo werden sie gespeichert, wie lange)
• Review‑Zyklus (monatlich/quarterly, plus Anlassreview nach Major Incident)

KPI-Steckbrief (Kurzvorlage)

KPI-Name:
Ziel/Entscheidung:
Scope (Services/Zonen):
Definition/Formel:
Datenquellen (Systeme, Reports):
Datenqualität/Validierung:
Owner (Accountable):
Bearbeitung (Responsible):
Grenzwerte (G/Y/R):
Eskalation (Gremium, Frist):
Pflichtmaßnahmen bei Gelb:
Pflichtmaßnahmen bei Rot:
Evidence (Ablage, Retention):
Review-Zyklus:
Letzte Anpassung/Version:

Von Kennzahlen zu Entscheidungen: Schwellenwerte, Ausnahmen, Risikoakzeptanz

Kennzahlen werden erst dann Governance‑fähig, wenn klar ist, welche Entscheidung bei welchem Wert getroffen wird. Das lässt sich mit drei Bausteinen operationalisieren:

Schwellenwerte müssen an Kritikalität gekoppelt sein

Ein Patch‑SLA von 30 Tagen kann in internen Backoffice‑Systemen angemessen sein, ist aber für internetexponierte Admin‑Interfaces oft zu lang. Definieren Sie Grenzwerte je Kritikalitätsklasse, nicht als One‑Size‑Fits‑All.

Ausnahmen brauchen ein Ablaufdatum und Kompensation

Wenn ein System nicht patchbar ist (Legacy, Herstellerbindung, Produktionsfenster), braucht die Ausnahme:

• Risiko‑Begründung und Business‑Owner‑Freigabe (Accountable)
• Enddatum (z. B. 60/90 Tage) oder Migrationsplan
• Kompensierende Kontrollen (z. B. Netzwerksegmentierung, zusätzliche Detection, Zugriff nur über Jump‑Host)
• Nachweispflicht (Evidenz, wer genehmigt hat)

Risikoakzeptanz ist eine Entscheidung, kein Zustand

In der Praxis verschwinden Risiken in „Akzeptiert“-Spalten, ohne dass klar ist, wer welches Restrisiko trägt. Etablieren Sie ein Format, in dem Risikoakzeptanz explizit dokumentiert wird (Scope, Zeitraum, Restrisiko, Verantwortlicher). Das reduziert „stille“ Risiken, die später im Incident eskalieren.

Audit‑Readiness: Was Prüfer an KPI‑Governance typischerweise hinterfragen

Unabhängig davon, ob Sie sich an ISO‑27001, BSI‑Grundschutz, NIS2‑nahe Anforderungen oder interne Kontrollsysteme anlehnen: Prüfer stellen oft dieselben Fragen. Eine KPI‑basierte Risiko‑Governance kann hier sehr stark sein – wenn sie sauber dokumentiert ist.

1) Nachvollziehbarkeit der Datenkette

Woher kommt der Wert, wie wird er erzeugt, und ist er reproduzierbar? Wenn Sie Daten aus mehreren Tools konsolidieren, dokumentieren Sie die Transformationslogik (auch wenn es nur ein Reporting‑Job ist).

2) Vollständigkeit und Scope

Welche Systeme sind enthalten, welche nicht – und warum? Ein bewusst definierter Scope ist auditierbar; ein zufälliger Scope wirkt wie Kontrolllücke.

3) Evidenz für Maßnahmen

„Wir haben priorisiert“ reicht nicht. Prüfer wollen sehen, dass bei Grenzwertverletzungen Entscheidungen getroffen wurden (Tickets, Change‑Freigaben, Ausnahmegenehmigungen, Protokolle aus Gremien).

4) Regelmäßige Wirksamkeitsprüfung

KPIs müssen reviewed und bei Änderungen der Architektur angepasst werden (Cloud‑Migration, neue IAM‑Plattform, neue Business‑Software). Ohne Review‑Protokoll wirkt das KPI‑Set schnell veraltet.

Kosten- und Kapazitätsperspektive: Kennzahlen als Budget- und Priorisierungswerkzeug

Risiko‑Governance scheitert häufig nicht am Willen, sondern an Ressourcen. Gute Kennzahlen helfen, Kapazität dort einzusetzen, wo sie den größten Risikohebel hat. Drei praktische Muster:

• Risikobasiertes Backlog: Maßnahmen werden nicht nach Lautstärke, sondern nach KRI‑Beitrag priorisiert (z. B. Reduktion „kritisch ausnutzbarer Schwachstellen in Exposed Systems“).
• Finanzierbare Mindestkontrollen: Für jede Kritikalitätsklasse definieren Sie Minimalstandards (MFA, Logging, Backup‑Tests). Alles darüber hinaus wird als Projekt mit Business‑Case geführt.
• Transparente Tech‑Debt: Wenn Legacy‑Systeme dauerhaft Ausnahmen erzeugen, wird daraus eine Management‑Entscheidung: Modernisierung, Ablösung oder bewusstes Restrisiko. Kennzahlen liefern die Begründung.

Wichtig ist, dass KPIs nicht als „Bestrafungsinstrument“ eingeführt werden. Sonst optimieren Teams auf Zahlen statt auf Risiko (zum Beispiel durch Scope‑Verkleinerung). Governance muss daher immer die Datenintegrität und die richtige Incentivierung im Blick behalten.

Implementierungsfahrplan in 6 Wochen: Von Null zu belastbarer KPI‑Governance

Wenn Sie heute ein fragmentiertes Reporting haben, ist ein schlanker, realistischer Einstieg entscheidend. Ein typischer Fahrplan:

Woche 1: Scope und Risikoentscheidungen festlegen

• Kritikalitätsklassen definieren (Services/Anwendungen, nicht nur Server)
• Management‑Gremium bestimmen (z. B. Security‑/Risk‑Board) und Entscheidungstypen festlegen
• Top‑10 Risiken auswählen, die über Kennzahlen steuerbar sind

Woche 2: KPI‑Set auswählen und Steckbriefe schreiben

• 10–15 Kennzahlen (KRIs + Control KPIs + wenige Outcomes)
• Für jede Kennzahl Steckbrief, Owner, Grenzwerte, Maßnahmenlogik

Woche 3: Datenquellen anbinden und Datenqualität prüfen

• Asset‑Inventar/CMDB gegen Discovery/Cloud‑Inventar abgleichen
• Definitionen testen (z. B. „exponiert“, „kritisch“, „überfällig“)

Woche 4: Reporting und Evidence‑Ablage standardisieren

• Einheitliches Reporting‑Format (monatlich) inkl. Trend und Maßnahmenstatus
• Ablageort für Evidenz (Protokolle, Ausnahmen, Testberichte) mit Retention

Woche 5: Pilot‑Gremium durchführen und Eskalationspfade üben

• 2–3 reale Fälle anhand Grenzwerte durchspielen
• Ausnahmeprozess und Freigaben testen

Woche 6: Stabilisieren und in Regelbetrieb überführen

• Definitionen anpassen, „Gaming“-Risiken eliminieren
• RACI sauber dokumentieren, Verantwortliche briefen
• Review‑Zyklus und Change‑Trigger für KPI‑Anpassungen festlegen

Checkliste für Manager: KPI‑Governance, die im Betrieb funktioniert

• Sind KRIs und KPIs klar getrennt (Risiko vs. Leistung)?
• Gibt es pro Kennzahl einen Owner (Accountable) mit Entscheidungsmandat?
• Sind Grenzwerte an Kritikalität und Exposition gekoppelt?
• Existiert ein formales Ausnahmeverfahren mit Enddatum und Kompensation?
• Ist die Datenkette dokumentiert und auditierbar (Quelle, Ermittlung, Evidenz)?
• Gibt es eine feste Governance‑Routine (Agenda, Protokoll, Maßnahmenverfolgung)?
• Werden Lessons Learned aus Incidents in Grenzwerte/Kontrollen zurückgeführt?

Fazit: Wenige Kennzahlen, klare Entscheidungen, saubere Nachweise

KPI‑basierte Risiko‑Governance ist kein Reporting‑Projekt, sondern ein Steuerungsmechanismus: Sie verbindet technische Realität (Assets, Schwachstellen, Identitäten, Changes) mit Management‑Entscheidungen (Prioritäten, Budgets, Ausnahmen, Risikoakzeptanz). Der größte Nutzen entsteht, wenn Sie nicht „alles messen“, sondern wenige, harte Kennzahlen definieren, die an Kritikalität gekoppelt sind und bei Grenzwertverletzung verbindliche Konsequenzen auslösen. Dann wird Risiko nicht nur dokumentiert, sondern tatsächlich geführt – im Betrieb, in Projekten und im Audit.

Für dieses Thema sind auch It‑Risikomanagement und It‑Governance wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.