Die meisten Security-Reports beantworten Fragen, die niemand im Verwaltungsrat gestellt hat. Patch-Stände, blockierte Angriffe, Klickraten aus der Phishing-Simulation: alles sauber dokumentiert, und am Ende der Präsentation kommt trotzdem nur eine Frage zurück: "Sind wir jetzt sicher?" Wenn darauf keine belastbare Antwort folgt, war das Security-KPI-Reporting Beschäftigung, keine Führung. Das ist kein Vorwurf an die IT. Es zeigt nur, dass Berichten an GL und VR eine andere Aufgabe ist als das Überwachen von Systemen. Die eine misst Technik, die andere trägt Entscheidungen.
Security-KPI-Reporting für GL und VR funktioniert, wenn jede Kennzahl an ein Top-Risiko oder eine anstehende Entscheidung gekoppelt ist. Vier bis sechs Kennzahlen mit Trend und Zielwert reichen, dazu die wichtigsten Risiken mit Massnahmenstand und eine Entscheidungsvorlage pro Sitzung. Tool-Dashboards bleiben im Maschinenraum: Sie messen Aktivität, nicht Risiko.
Warum kommt dein Security-Reporting bei GL und VR nicht an?
Weil es Aktivität misst statt Risiko. Patch-Quoten, gescannte Mails, blockierte Angriffe: Diese Zahlen belegen, dass gearbeitet wird. Sie beantworten aber keine der Fragen, über die GL und VR entscheiden müssen: Welche Risiken tragen wir gerade? Passen sie zu dem, was das Geschäft vorhat? Und wo braucht es Geld oder einen Entscheid?
Dazu kommt ein Massstabsproblem. Ob eine Patch-Quote gut oder schlecht ist, kann im Gremium niemand beurteilen, weil der Vergleichswert fehlt. Also nickt das Gremium. Der Verwaltungsrat trägt die Oberleitung und muss zeigen können, dass er die wesentlichen Risiken kennt und behandelt, auch die aus der IT. Ein Bericht, der ihm das nicht ermöglicht, wird höflich zur Kenntnis genommen und entfaltet keine Wirkung.
In unserer Erfahrung scheitert das Reporting selten am technischen Verständnis des Gremiums. Es scheitert daran, dass der Bericht keine Entscheidung anbietet. Ein Gremium, das nichts entscheiden kann, geht zum nächsten Traktandum. Und ein Security-Budget, das jahrelang nur abgenickt wurde, ist beim nächsten Sparprogramm das erste, das zur Diskussion steht, weil nie jemand verstanden hat, was es eigentlich kauft.
Welche Security-KPIs gehören in den Bericht an GL und VR?
Vier bis sechs Kennzahlen, jede an ein Top-Risiko oder eine anstehende Entscheidung gekoppelt, jede mit Trend und Zielwert. Dazu die fünf wichtigsten Risiken mit Massnahmenstand und pro Sitzung eine konkrete Entscheidungsvorlage. Alles andere bleibt im Maschinenraum: Die Detailmetriken braucht der Betrieb, nicht das Gremium.
Welche Kennzahl konkret sinnvoll ist, hängt vom Unternehmen ab. Die Kategorien dahinter bleiben über Branchen hinweg stabil:
- Widerstandsfähigkeit: Wie lange dauert es, bis eine kritische Schwachstelle auf den wichtigsten Systemen geschlossen ist? Wann wurde die Wiederherstellung aus dem Backup zuletzt getestet, und hat sie funktioniert? Die zweite Frage ist unbequemer als die erste, und deshalb gehört sie in den Bericht.
- Vorfallsbereitschaft: Wie schnell erreicht ein Vorfall die Geschäftsleitung? Wer kritische Infrastrukturen betreibt oder beliefert, hat hier seit dem 1. April 2025 eine harte Referenz: Das ISG verlangt die Meldung von Cyberangriffen ans BACS innert 24 Stunden nach Entdeckung. Eine Organisation, in der ein Vorfall intern drei Tage bis zur GL braucht, kann diese Frist nicht halten.
- Verpflichtungen: Stand der Auditfindings, offene Punkte aus Kundenfragebögen, Status von Zertifikaten und Kundenzusagen. Für viele KMU ist das die Kategorie mit dem direktesten Umsatzbezug.
- Menschen: Nicht die Klickrate aus der Phishing-Simulation, sondern die Meldequote: Wie viele verdächtige Mails melden die Mitarbeitenden? Eine steigende Meldequote sagt mehr über die Sicherheitskultur als eine sinkende Klickrate, denn sie zeigt, dass Leute mitdenken statt sich zu schämen.
Die Gegenüberstellung zeigt den Unterschied zur üblichen Praxis:
| Werkzeugmetrik (bleibt im Betrieb) | Führungskennzahl (gehört in den Bericht) |
|---|---|
| Anzahl blockierter Angriffe | Zeit bis zur Schliessung kritischer Schwachstellen auf Kernsystemen |
| Phishing-Klickrate | Meldequote verdächtiger Mails |
| Anzahl eingesetzter Security-Tools | Abdeckung der Top-Risiken durch wirksame Massnahmen |
| Verfügbarkeit der Backup-Infrastruktur | Datum und Ergebnis des letzten Wiederherstellungstests |
Der VR will nicht sehen, dass ihr unverwundbar seid. Das kann niemand liefern, und ein erfahrenes Gremium glaubt es auch nicht. Er will sehen, dass jemand die Risiken kennt, priorisiert und Entscheidungen sauber dokumentiert. Gutes Reporting weist Sorgfalt nach. An diesem Massstab misst der VR auch die eigene Verantwortung.
Wie oft und in welcher Form berichtet ein CISO an GL und VR?
Bewährt hat sich ein Rhythmus auf zwei Ebenen: monatlich ein kurzer Steuerkreis mit der Geschäftsleitung, vier Seiten, keine Foliendekoration. Quartalsweise ein Bericht an den Verwaltungsrat mit Risikolage, Trends und den Entscheidungen, die anstehen. Dazu ein definierter Weg für Vorfälle, der nicht auf die nächste Sitzung wartet.
Die vier Seiten des Steuerkreises folgen immer derselben Logik: Was hat sich an der Lage verändert? Wo stehen die Kennzahlen im Trend? Wo stehen die Massnahmen zu den Top-Risiken? Und was ist zu entscheiden? Wenn nichts zu entscheiden ist, steht das da. Auch das ist eine Information, und sie kostet niemanden eine Stunde Sitzungszeit.
Der Quartalsbericht an den VR ist kein aufgeblasener Steuerkreis, sondern eine Verdichtung: Risikolage im Trend über drei Monate, Stand der grossen Vorhaben wie ISMS-Aufbau oder Auditfindings, Abgleich mit dem Risikoappetit, Entscheidungsbedarf. Und er hält fest, was der VR entschieden hat. Diese Protokollspur wirkt unscheinbar, aber sie ist es, die im Ernstfall dokumentierte Sorgfalt belegt, gegenüber Kunden, Versicherern und Behörden.
Der dritte Kanal ist der Ernstfall selbst. Wer informiert wann die Geschäftsleitung, ab welcher Schwelle den Verwaltungsrat, wer spricht mit Kunden? Diese Eskalationswege gehören definiert, bevor sie gebraucht werden. Ein Vorfall ist der falsche Moment, um Zuständigkeiten auszuhandeln, und ein Gremium, das aus der Zeitung von einem Vorfall erfährt, verzeiht das dem Reporting nicht.
Beim Aufwand gilt dieselbe Regel wie bei der Toollandschaft: richtig dimensionieren. Ein Reporting, das jeden Monat zwei Tage Handarbeit kostet, wird nach drei Monaten still beerdigt. Die Kennzahlen müssen aus Systemen kommen, die ihr ohnehin betreibt. Wenn für das Reporting scheinbar ein neues Tool nötig ist, ist meist das Reporting falsch geschnitten, nicht die Toollandschaft zu klein. Wie sich aus einer gewachsenen Toollandschaft überhaupt belastbare Aussagen gewinnen lassen, haben wir im Artikel über das Konsolidieren von Security-Tools beschrieben.
Wie das in einem KMU konkret aussieht
Ein typisches Bild aus unserer Erfahrung, anonymisiert: Industrieunternehmen, rund 150 Mitarbeitende, solide IT, kein CISO. Der IT-Leiter berichtet quartalsweise an die GL, rund dreissig Folien, exportiert aus drei Dashboards. Die GL hört zu, dankt, entscheidet nichts. Als ein Grosskunde im Lieferantenaudit nach der Risikobeurteilung durch die Geschäftsleitung fragt, kann niemand ein Dokument zeigen, das diesen Namen verdient. Peinlich ist das nicht wegen der Technik, die war in Ordnung. Es fehlte der Nachweis, dass die Führung die Risiken kennt.
Der Umbau war unspektakulär. Ein Risikoregister mit den fünf grössten Risiken, formuliert in Geschäftssprache: Produktionsunterbruch, Verlust von Konstruktionsdaten, Lieferfähigkeit nach einem Ransomware-Fall. Fünf Kennzahlen, jede einem Risiko zugeordnet. Vier Seiten statt dreissig Folien. Und in jeder Sitzung eine Entscheidungsvorlage nach dem Muster: Risiko X tragen wir bewusst, oder wir behandeln es für den Betrag Y. Die GL diskutierte zum ersten Mal über Risiken statt über Tools. Die GL verlängerte zwei Tool-Verträge nicht und steckte das frei gewordene Geld in die Absicherung der Fernzugänge. Das Lieferantenaudit im Jahr darauf war ein Termin, kein Projekt.
Zuerst wurde also die Führung besser, nicht die Sicherheit. Die bessere Sicherheit folgte, weil zum ersten Mal jemand priorisieren konnte.
Häufige Fragen
Was ist der Unterschied zwischen KPI und KRI im Security-Reporting?
Ein KPI misst, wie gut die Sicherheitsarbeit funktioniert, etwa die Zeit bis zur Schliessung kritischer Schwachstellen. Ein KRI, ein Key Risk Indicator, zeigt an, wie sich die Risikolage verändert, etwa die Zahl der aus dem Internet erreichbaren Systeme. Für GL und VR ist die Unterscheidung zweitrangig. Wichtig ist, dass jede Zahl an ein Risiko oder eine Entscheidung gekoppelt ist, egal wie sie heisst.
Reichen die Dashboards aus unseren Security-Tools nicht als Bericht?
Nein. Dashboards zeigen, was das jeweilige Tool sieht und tut, in der Logik des Herstellers. Sie kennen weder eure Top-Risiken noch eure Geschäftsziele. Als Rohmaterial für den Bericht sind sie nützlich, als Bericht an ein Führungsgremium sind sie eine Zumutung: viel Fläche, keine Aussage.
Wer erstellt das Reporting, wenn wir keinen CISO haben?
Meist der IT-Leiter, und genau dort liegt die Grenze: Er bewertet dann die eigene Arbeit. Das ist keine Frage der Integrität, sondern der Rollen. Eine Zweitmeinung von aussen macht das Reporting glaubwürdiger, gerade gegenüber dem VR. Das kann ein Fractional CISO im Mandat sein oder ein Sparring, das die GL- und VR-Termine gemeinsam mit dem IT-Leiter vorbereitet.
Falls du das für euer Unternehmen einordnen willst: Im CISO Retainer sind der monatliche Steuerkreis und der Quartalsbericht an den VR fester Bestandteil des Mandats, im CISO Sparring bereiten wir deine GL- und VR-Termine gemeinsam vor. Was beides kostet, steht transparent bei den Paketen auf der Startseite. Und falls du erst einmal wissen willst, wie euer heutiges Reporting im Vergleich dasteht: Die unbequemste Frage aus diesem Artikel, wann der letzte Wiederherstellungstest war, kannst du morgen stellen. Die Antwort sagt mehr über eure Sicherheitslage als jedes Dashboard.