In fast jeder Security-Organisation, die ich gesehen habe, gibt es irgendwann „das Dashboard“. Es ist gut gemeint: Transparenz schaffen, Fortschritt zeigen, Sicherheit messbar machen. In der Praxis passiert aber oft etwas anderes: Man misst, was leicht zu messen ist — und nicht das, was wirklich steuert.
Das Ergebnis sind grüne Ampeln, steigende Prozentwerte und trotzdem dieses ungute Bauchgefühl: Werden wir wirklich besser — oder berichten wir nur schöner?
Über die Zeit habe ich mir eine KPI-Shortlist angewöhnt, die manchmal unbequem ist. Genau deshalb ist sie nützlich: Diese Kennzahlen „lügen“ deutlich seltener, weil sie direkt an Wirksamkeit hängen — nicht an Aktivität.
Was „ehrliche“ Security-KPIs ausmacht
Tier-0/1 statt „Gesamtunternehmen“
Viele KPIs sehen gut aus, weil sie über alles gemittelt werden. 95% Patch-Compliance sagt wenig, wenn die fehlenden 5% genau dort liegen, wo es kritisch ist. Darum messe ich bevorzugt auf:
Tier 0: Identität, Schlüssel, Admin-Systeme, zentrale Management-Planes (IdP, PKI, PAM, AD)
Tier 1: Crown-Jewel-Workloads, sensitive Datenflüsse, Kernprozesse (ERP, Produktionssteuerung, Payment, Patientendaten)
Steuerungs-KPIs statt Reporting-KPIs
Ein KPI ist für mich nur dann gut, wenn er eine klare Aktion auslösen kann: Wer ist Owner? Welche Schwelle ist „nicht akzeptabel“? Was ist der konkrete Fix/Plan?
Wenn die Antwort auf Abweichungen „Wir nehmen es in die Roadmap“ ist, ist es meistens ein Reporting-KPI — kein Steuerungsinstrument.
Die CISO-Shortlist: 7 KPIs, die wirklich steuern
1) Patch-Tempo auf Tier-0/1
Was ich messe: Anteil kritischer Tier-0/1 Assets mit kritischen Patches innerhalb von X Tagen — optional getrennt nach Plattform und Exposition.
Warum das nicht lügt: „Patch-Compliance“ als Gesamtwert ist leicht zu gamen: Man patcht viel „einfaches“ Zeug und bleibt bei den harten Fällen liegen.
Praktisch: Setze klare SLOs — Tier 0: Kritisch ≤ 7 Tage, Tier 1: Kritisch ≤ 14 Tage. Tracke nicht nur „gepatcht“, sondern auch „geblockt“.
2) Phishing-resistente MFA für privilegierte Identitäten
Was ich messe: Anteil Admin-/PAM-Identitäten mit phishing-resistenter MFA (FIDO2/Passkeys, Smartcard, Zertifikatsbasiert) und Anteil privilegierter Zugriffe durch Conditional Access.
Warum das nicht lügt: Identity ist die Abkürzung in fast jeden Security-Vorfall. Wenn privilegierte Identitäten sauber abgesichert sind, sinkt dein Risiko spürbar.
Stolperfalle: „MFA ist ausgerollt“ — ja, aber auf allen privilegierten Pfaden? Inklusive Legacy-Protokollen, API-Access, Notfall-Accounts?
3) EDR „healthy“ + Tamper Protection
Was ich messe: Anteil Tier-0/1 Systeme mit EDR-Agent aktiv, aktuell, nicht ausgenommen. Tamper Protection eingeschaltet.
Warum das nicht lügt: Installationszahlen sind ein Klassiker: 99% Coverage — und die 1% sind Domain Controller, Jump Hosts oder kritische Server, weil „da macht der Agent Probleme“.
Praktisch: „Healthy“ klar definieren: Agent alive, policy applied, telemetry received, no broad exclusions.
4) Logging, das wirklich ankommt
Was ich messe: Anteil kritischer Logquellen, die im SIEM/Log-Backend ankommen. Drop Rate, Parsing Errors, Schema-Fehler. Latenz.
Warum das nicht lügt: „Wir haben ein SIEM“ ist kein Sicherheitszustand. Ein SIEM ohne verlässliche Daten ist nur teurer Storage.
Praktisch: Definiere eine „Minimum Viable Logging List“ (Tier 0/1): IdP, PAM, AD, EDR, VPN/ZTNA, DNS, Proxy, E-Mail, Cloud Control Plane.
5) MTTC: Mean Time To Contain
Was ich messe: Zeit von erster Detection bis Containment — idealerweise getrennt nach Incident-Typ.
Warum das nicht lügt: Viele Teams optimieren Tickets (MTTR), aber nicht den Schaden. In echten Incidents ist Containment der Punkt, an dem du die Ausbreitung stoppst — und Kosten explodieren oder eben nicht.
Stolperfalle: Containment scheitert oft an Zuständigkeiten („Wer darf isolieren?“). Das ist kein Technikproblem, sondern Operating Model.
6) Restore-Fähigkeit
Was ich messe: Anteil Tier-0/1 Systeme mit erfolgreichem Restore-Test in den letzten 90 Tagen. Median Restore-Zeit. Erfolgsquote „Restore + Applikation funktionsfähig“.
Warum das nicht lügt: Backups zu haben ist leicht. Restores zuverlässig durchführen zu können — unter Stress, mit Prioritäten, mit Abhängigkeiten — ist etwas anderes.
Praktisch: Restore-Tests als Routine, nicht als Projekt. Abhängigkeiten dokumentieren (Identity, DNS, PKI, Secrets, Config).
7) Exceptions mit Ablaufdatum
Was ich messe: Anzahl Security-Exceptions ohne Enddatum. Anteil Exceptions mit Owner, Risikoakzeptanz, Mitigation, Review-Termin.
Warum das nicht lügt: In jeder Organisation gibt es Ausnahmen. Der Unterschied zwischen „kontrolliert“ und „gefährlich“ ist, ob sie gesteuert werden oder verwahrlosen.
Praktisch: Standardisiertes Exception-Template. Reviews in klarer Kadenz. Alles ohne Enddatum ist automatisch rot.
Wie du daraus ein steuerndes KPI-Set machst
Begrenze dich radikal: 8–10 KPIs max. Mehr führt zu Reporting-Show statt Steuerung.
Gib jedem KPI einen Owner und einen Trigger: Schwellenwerte mit Bedeutung, Trigger-Aktion bei Rot.
Zeige Trends, nicht nur Punktwerte: Wird es besser? Wie schnell? Wo sind Rückschritte?
Verknüpfe KPIs mit Entscheidungen: Was stoppen wir? Was priorisieren wir? Welche Ausnahme wird beendet?
Was ich bewusst NICHT als Top-KPI nutze
Anzahl geschlossener Findings — kann reine Fleißarbeit abbilden
Awareness-Completion-Rate — sagt wenig über Verhalten
„Anzahl abgewehrter Angriffe“ — abhängig vom Messsystem, oft Marketing
Vulnerability Count ohne Kontext — führt zu Lärm, nicht zu Risiko-Reduktion
Das heißt nicht, dass diese Daten nutzlos sind — aber als CISO-Steuerungsgröße sind sie oft zu indirekt.
Fazit
Wenn du nur eine Sache mitnimmst:
Miss zuerst dort, wo es richtig weh tut (Tier 0/1) und miss Wirksamkeit, nicht Aktivität. Diese 7 KPIs haben mir in der Praxis geholfen, Diskussionen von „wir fühlen“ zu „wir entscheiden“ zu drehen.
Im Executive Briefing behandle ich Security-KPIs und Board-Reporting in Modul 4. In der Executive Masterclass entwickeln Sie Ihr eigenes KPI-Dashboard als Teil des 90-Tage-Workshops.