Die 5 häufigsten Fehler im IT-Sicherheitsbericht – und wie Sie sie vermeiden

Der IT-Sicherheitsbericht ist in vielen Unternehmen eine Pflichtübung: einmal im Jahr zusammengetragen, in der Geschäftsleitung durchgewinkt, abgelegt. Seit NIS2 ist er ein Nachweisdokument – und die Fehler darin werden teuer. Diese fünf sehen wir am häufigsten.

Einleitung

Warum der IT-Sicherheitsbericht plötzlich wieder zählt

Lange war der IT-Sicherheitsbericht ein internes Dokument ohne Adressaten. Er wurde geschrieben, weil es im Qualitätshandbuch stand, und gelesen wurde er selten. Das hat sich in kurzer Zeit geändert – aus drei Richtungen gleichzeitig.

Erstens die Gesetzgebung: Das NIS2-Umsetzungsgesetz gilt in Deutschland seit dem 6. Dezember 2025, die Registrierungspflicht beim BSI seit dem 6. März 2026. Betroffene Unternehmen müssen nicht nur Maßnahmen ergreifen, sondern belegen können, dass sie es getan haben – und die Geschäftsleitung haftet dafür persönlich. Der Bußgeldrahmen liegt bei bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes.

Zweitens die Lieferkette. Wer als Zulieferer für ein betroffenes Unternehmen arbeitet, bekommt dessen Anforderungen vertraglich weitergereicht – auch unterhalb der eigenen Schwellenwerte von 50 Beschäftigten oder 10 Millionen Euro Umsatz. In Ausschreibungen wird der Sicherheitsbericht inzwischen routinemäßig mitverlangt.

Drittens die Cyber-Versicherer. Sie prüfen im Schadensfall, ob die im Antrag zugesagten Maßnahmen tatsächlich umgesetzt waren. Ein Bericht, der Maßnahmen behauptet, aber nicht belegt, ist dann kein Nachweis, sondern ein Problem.

Worum es in diesem Beitrag geht

Wir lesen und schreiben solche Berichte regelmäßig – als Ergebnis von Security Assessments, als Quartalsbericht im Managed Pentest und im Rahmen von NIS2- und ISO-27001-Projekten. Die Fehler wiederholen sich dabei so verlässlich, dass sich fünf Muster benennen lassen.

Es geht im Folgenden nicht um Formvorschriften. Es geht darum, dass ein Bericht drei Fragen beantworten muss, damit er seinen Zweck erfüllt: Wie steht es um unsere Sicherheit? Woher wissen wir das? Und wer tut jetzt was? Jeder der fünf Fehler verhindert die Antwort auf mindestens eine davon.

Fehler 1: Zahlen ohne Analyse

Warum die Auswertung wichtiger ist als die Erhebung

Der häufigste Bericht, der uns vorgelegt wird, besteht aus Exporten. 4.812 blockierte E-Mails, 217 offene Schwachstellen, 34 Endgeräte ohne aktuellen Patchstand, 12 Alarme im letzten Quartal. Alles korrekt erhoben – und trotzdem wertlos, weil keine dieser Zahlen für sich genommen eine Frage beantwortet.

Sind 217 offene Schwachstellen viel? Das hängt davon ab, wo sie liegen. Eine mit CVSS 9.8 bewertete Lücke auf einem isolierten Testserver ist harmloser als eine mit 6.5 auf dem Domänencontroller. Ein Bericht, der beide in derselben Zeile zählt, verschleiert genau die Information, wegen der er geschrieben wurde.

Aussagekräftig wird eine Zahl erst durch drei Zusätze: den Vergleich mit dem Vorzeitraum, die Einordnung in Ihre Umgebung und die Folgerung daraus. Aus „217 offene Schwachstellen" wird dann: „217 offene Schwachstellen, davon 9 kritisch auf von außen erreichbaren Systemen. Im Vorquartal waren es 14 kritische – der Rückstand wird kleiner, aber zwei der neun sind seit über 90 Tagen offen. Ursache ist ein Wartungsfenster, das nur zweimal im Jahr stattfindet."

Der zweite Satz ist entscheidungsfähig. Der erste ist eine Zahl.

Woher die Daten kommen sollten

Ein belastbarer Bericht speist sich nicht aus einer Quelle. Diese fünf sollten mindestens einfließen:

Schwachstellenmanagement: Fortlaufende Scans mit Verlauf, nicht der Einzelscan von letzter Woche. Erst die Entwicklung über die Zeit zeigt, ob der Prozess funktioniert.
Angriffserkennung: Alarme aus SIEM oder SOC, aufgeschlüsselt nach Schweregrad und Bearbeitungsdauer. Interessant ist nicht die Zahl der Alarme, sondern wie lange es bis zur Bewertung gedauert hat.
Offensive Prüfungen: Ergebnisse aus Penetrationstests und deren Retests. Sie beantworten als Einzige die Frage, ob die Maßnahmen einem echten Angreifer standhalten.
Vorfälle: Auch die kleinen, die glimpflich ausgingen. Ein abgewehrter Phishing-Versuch mit drei Klicks in der Belegschaft ist ein Befund, kein Erfolg.
Awareness: Schulungsquoten und Ergebnisse von Phishing-Simulationen. Für NIS2 muss auch die Geschäftsleitung nachweislich geschult sein.

Wer diese Quellen nicht zusammenführt, schreibt fünf Teilberichte und keinen Sicherheitsbericht.

Fehler 2: Ein Bericht von der Stange

Ein Standort, drei Standorte, drei Berichte

Vorlagen aus dem Netz gehen von einem Unternehmen aus, das es so nicht gibt: ein Standort, eine IT, ein Verantwortlicher. Sobald mehr als ein Gebäude im Spiel ist, stimmt das Bild nicht mehr – und die Abweichungen sind genau das, was in den Bericht gehört.

Ein typisches Beispiel aus unserer Praxis: ein Unternehmen mit Hauptsitz und Produktion in Nordrhein-Westfalen, einem Vertriebsbüro in München und einer kleinen Entwicklungsmannschaft in Berlin. Drei Standorte, drei völlig verschiedene Risikoprofile.

Produktion: Steuerungstechnik, die zwanzig Jahre läuft und sich nicht im laufenden Betrieb patchen lässt. Verfügbarkeit wiegt hier schwerer als Vertraulichkeit – die Maßnahmen sehen entsprechend anders aus als in der Büro-IT.
Vertriebsbüro: Viele mobile Geräte, viel Homeoffice, wenig lokale Infrastruktur. Das Risiko liegt bei Endgeräten und Identitäten, nicht im Netzwerk.
Entwicklung: Quelltext, Cloud-Zugänge, Build-Ketten. Hier entscheidet, wer wo welche Rechte hat – und ob ein kompromittiertes Entwicklerkonto bis in die Produktivumgebung durchreicht.

Ein Bericht, der über alle drei denselben Satz schreibt, ist für keinen der drei richtig. Und es geht nicht nur um Technik: Regionale Unterschiede in der Personalsituation gehören ebenfalls hinein. Wer in Köln oder Düsseldorf eine offene Stelle in der IT-Sicherheit ein Jahr lang nicht besetzt bekommt, hat ein Risiko – eines, das kein Werkzeug behebt und das die Geschäftsleitung kennen muss.

So schneiden Sie den Bericht auf Ihr Haus zu

Der Zuschnitt gelingt über vier Fragen, die vor dem Schreiben zu beantworten sind:

Wer liest das? Die Geschäftsleitung braucht zwei Seiten mit Entscheidungen, die IT braucht die Details. Beides in ein Dokument, aber getrennt – Management-Summary vorn, technischer Teil hinten.
Was ist bei uns wirklich schützenswert? Nicht „alle Daten", sondern konkret: die Konstruktionsdaten, das Warenwirtschaftssystem, die Personalakten. Der Rest folgt daraus.
Welche Standorte und Bereiche haben eigene Profile? Produktion, Verwaltung, Entwicklung, Außendienst – jeder bekommt einen eigenen Abschnitt, wenn sich Risiken oder Maßnahmen unterscheiden.
Wem müssen wir das vorlegen? Aufsicht, Kunde, Versicherer oder Auditor – der Adressat bestimmt, welche Nachweise beiliegen müssen.

Wer diese vier Fragen beantwortet hat, hat die Gliederung bereits geschrieben.

Fehler 3: Die Bedrohungslage fehlt

Was gerade tatsächlich passiert

Viele Berichte beschreiben ausführlich, was das Unternehmen tut – und mit keinem Wort, wogegen. Damit fehlt der Maßstab: Ohne Bedrohungslage lässt sich nicht beurteilen, ob die Maßnahmen angemessen sind.

Der Abschnitt muss dabei keine Abhandlung sein. Eine Seite genügt, wenn sie das aktuelle Bild auf Ihre Situation bezieht:

Ransomware mit Datenabfluss: Die Erpressung läuft heute zweigleisig: verschlüsseln und zusätzlich mit der Veröffentlichung der Daten drohen. Ein funktionierendes Backup schützt gegen die eine Hälfte, nicht gegen die andere.
Angriffe über die Lieferkette: Nicht Sie werden angegriffen, sondern Ihr Dienstleister mit Fernzugang. Wer wartungsbedingte Zugänge nicht inventarisiert hat, kennt seine eigene Angriffsfläche nicht.
Identitäten statt Schadsoftware: Ein gestohlener gültiger Zugang löst keinen Alarm aus. Deshalb verschiebt sich die Erkennung vom Schadprogramm zum auffälligen Verhalten – etwa einer Anmeldung, die technisch korrekt, aber zeitlich und örtlich unplausibel ist.
Generative KI auf Angreiferseite: Phishing-Mails ohne Rechtschreibfehler in jeder Sprache, geklonte Stimmen beim CEO-Betrug. Die Methoden sind alt, die Hürde ist gefallen – und mit ihr das Erkennungsmerkmal, auf das jahrelang geschult wurde.

Als belastbare Quelle für den allgemeinen Teil eignet sich der jährliche Lagebericht des BSI; verlinkt ist er am Ende dieses Beitrags. Den unternehmensspezifischen Teil liefert Ihre eigene Threat Intelligence – etwa die Frage, ob Zugangsdaten aus Ihrem Haus bereits in Leak-Sammlungen auftauchen.

Von der Bedrohung zur Maßnahme

Der Schritt, der am häufigsten fehlt: Jede genannte Bedrohung braucht im selben Dokument eine Zuordnung, welche Maßnahme ihr entgegensteht – und wo diese Zuordnung noch offen ist. Eine dreispaltige Tabelle reicht: Bedrohung, vorhandene Maßnahme, verbleibendes Risiko.

Das erzeugt zwei nützliche Nebenwirkungen. Erstens fallen die Lücken beim Schreiben auf, nicht erst im Audit. Zweitens ist die Tabelle genau der Nachweis, den NIS2 und ISO 27001 unter dem Stichwort Risikomanagement verlangen – Sie schreiben ihn also ohnehin, nur eben an einer Stelle statt an dreien.

Fehler 4: Niemand ist zuständig

Wer im Bericht benannt sein muss

Formulierungen wie „die IT wird prüfen", „es ist geplant" oder „soll künftig erfolgen" sind der zuverlässigste Hinweis darauf, dass eine Maßnahme nicht umgesetzt wird. Ohne Namen, Termin und Budget ist ein Vorhaben eine Absichtserklärung.

Vier Rollen sollten im Bericht namentlich auftauchen:

Die Geschäftsleitung: Sie trägt die Verantwortung, und zwar nach NIS2 persönlich und nicht delegierbar. Sie muss den Bericht nicht schreiben, aber nachweislich zur Kenntnis nehmen und die Maßnahmen freigeben.
Der Informationssicherheitsbeauftragte: Verantwortet Konzept, Bericht und Nachverfolgung. In kleineren Häusern eine Teilzeitrolle – aber eine benannte Person, keine Abteilung.
Der IT-Betrieb: Setzt um. Wichtig ist die klare Trennung: Wer betreibt, sollte nicht sich selbst prüfen und bewerten.
Die Fachbereiche: Nur sie können sagen, welche Daten und Prozesse wirklich kritisch sind. Ein Schutzbedarf, den die IT allein festlegt, geht regelmäßig an der Realität vorbei.

Praktischer Test: Nehmen Sie eine beliebige Maßnahme aus Ihrem letzten Bericht und fragen Sie, wer sie bis wann erledigt. Kommt darauf keine Antwort in einem Satz, gehört sie in dieser Form nicht ins Dokument.

Was ein externer Dienstleister übernehmen kann

Die verpflichtende Rolle der Geschäftsleitung lässt sich nicht auslagern – die fachliche Arbeit dahinter sehr wohl. Sinnvoll ausgelagert wird typischerweise dort, wo entweder Spezialwissen oder Unabhängigkeit gebraucht wird:

die unabhängige Bewertung, weil ein Betrieb, der sich selbst prüft, blinde Flecken behält
die technische Erhebung – Schwachstellenanalyse, Penetrationstest, Konfigurationsprüfung
die durchgehende Angriffserkennung, für die im Mittelstand die Schichtbesetzung fehlt
die Aufbereitung der Ergebnisse in eine Form, die Aufsicht, Auditor und Versicherer akzeptieren

Die Nica Systems GmbH übernimmt diese Teile für Unternehmen in Düsseldorf, Nordrhein-Westfalen und bundesweit. Wir sind kein IT-Generalist mit Sicherheitsabteilung, sondern ausschließlich in der Cybersecurity tätig – und als aktive Penetration Tester bewerten wir Maßnahmen danach, ob sie einem Angriff standhalten, nicht danach, ob sie in einer Checkliste abgehakt sind. Die Leistungserbringung erfolgt zu 100 Prozent in Deutschland.

Entscheidend bleibt die Rollentrennung: Wer Ihre Sicherheit bewertet, sollte nicht dieselbe Person sein, die den Betrieb verantwortet. Genau das macht den externen Blick im Bericht belastbar.

Fehler 5: Maßnahmen ohne Nachweis

Was in die Dokumentation gehört

Der fünfte Fehler ist der teuerste, weil er erst im Ernstfall auffällt. Im Bericht steht, dass eine Schwachstelle geschlossen wurde – aber nichts darüber, wer das wann festgestellt hat und woran. Im Audit, im Schadensfall oder gegenüber der Aufsicht ist eine solche Aussage nicht verwertbar.

Zu jeder umgesetzten Maßnahme gehören fünf Angaben:

Was: die Maßnahme in einem Satz, ohne Produktnamen als Selbstzweck
Warum: das Risiko, das sie adressiert – der Bezug zur Tabelle aus Fehler 3
Wann: Datum der Umsetzung, nicht das der Entscheidung
Wer: die verantwortliche Person, nicht die Abteilung
Womit belegt: der Nachweis: Retest-Bericht, Konfigurationsauszug, Schulungsnachweis, Protokoll einer Notfallübung

Der fünfte Punkt ist der, der am häufigsten fehlt – und der einzige, der die Aussage von einer Behauptung zu einem Nachweis macht.

Bewährtes Vorgehen

Nachweise beim Entstehen sammeln: Wer sie am Jahresende zusammensucht, findet die Hälfte nicht mehr. Ein Ablageort, der beim Abschließen einer Maßnahme befüllt wird, kostet Minuten statt Tage.
Behebung immer nachprüfen: Ein Retest bestätigt, dass die Lücke wirklich geschlossen ist. Erfahrungsgemäß ist ein Teil der als behoben gemeldeten Befunde es nicht – meist, weil nur ein System von mehreren angefasst wurde.
Quartalsweise statt jährlich berichten: Vier kurze Berichte sind weniger Arbeit als einer im Dezember und liefern nebenbei den Verlauf, der die Zahlen erst aussagekräftig macht. Beim Managed Pentest entsteht dieser Rhythmus ohnehin.
Offene Punkte offen benennen: Ein Bericht ohne Restrisiken wirkt nicht souverän, sondern unvollständig. Auditoren und Versicherer lesen genau dort zuerst.
Versionen führen: Freigabedatum, Stand und Verteiler auf Seite eins. Im Streitfall zählt, welche Fassung wann vorlag.

Fazit

Die fünf Fehler auf einen Blick

Zahlen ohne Analyse: Erhebung ersetzt keine Bewertung. Jede Zahl braucht Vergleich, Einordnung und Folgerung.
Bericht von der Stange: Standorte und Bereiche mit eigenem Risikoprofil brauchen eigene Abschnitte.
Fehlende Bedrohungslage: Ohne Maßstab lässt sich die Angemessenheit der Maßnahmen nicht beurteilen.
Unklare Verantwortlichkeiten: Ohne Name, Termin und Budget bleibt jede Maßnahme eine Absichtserklärung.
Maßnahmen ohne Nachweis: Was nicht belegt ist, zählt im Audit und im Schadensfall nicht.

Ihr nächster Schritt

Nehmen Sie Ihren letzten Bericht und prüfen Sie ihn gegen diese fünf Punkte. Erfahrungsgemäß treffen zwei bis drei zu – das ist normal und in einem Durchgang zu beheben, wenn die Datengrundlage stimmt.

Fehlt diese Grundlage, ist die Reihenfolge eine andere: erst erheben, dann berichten. Ein Security Assessment liefert die Bestandsaufnahme, ein Penetrationstest die Belastungsprobe. Ob Sie überhaupt unter die Berichtspflichten aus NIS2 fallen, klärt unser kostenloser NIS2-Readiness-Check in etwa drei Minuten.

Häufige Fragen

Was gehört in einen IT-Sicherheitsbericht?

Mindestens sechs Teile: eine Management-Summary mit den Entscheidungen, die aktuelle Bedrohungslage bezogen auf Ihr Unternehmen, den Stand der Maßnahmen mit Nachweisen, die offenen Risiken, die Kennzahlen im Verlauf und einen Maßnahmenplan mit Verantwortlichen und Terminen. Der Umfang richtet sich nach dem Adressaten – für die Geschäftsleitung zwei bis drei Seiten, der technische Teil dahinter.

Wie oft muss ein IT-Sicherheitsbericht erstellt werden?

Eine feste gesetzliche Frist gibt es nicht; NIS2 und ISO 27001 verlangen eine regelmäßige Bewertung, ohne den Takt vorzuschreiben. In der Praxis hat sich ein Quartalsbericht bewährt, ergänzt um eine ausführlichere Jahresfassung für das Management-Review. Vier kurze Berichte sind weniger Aufwand als einer im Dezember – und liefern den Verlauf, ohne den Zahlen kaum etwas aussagen.

Wer ist für den IT-Sicherheitsbericht verantwortlich?

Erstellt wird er in der Regel vom Informationssicherheitsbeauftragten, verantwortet wird er von der Geschäftsleitung. Nach dem NIS2-Umsetzungsgesetz ist diese Verantwortung persönlich und nicht an die IT-Abteilung delegierbar. Die fachliche Arbeit – Erhebung, unabhängige Bewertung, Aufbereitung – kann an einen externen Dienstleister vergeben werden.

Ist ein IT-Sicherheitsbericht für NIS2 verpflichtend?

Das Gesetz schreibt keinen „Sicherheitsbericht" unter diesem Namen vor. Es verlangt aber Risikomanagement, Wirksamkeitskontrolle der Maßnahmen und Nachweise gegenüber der Aufsicht – und ein regelmäßiger Bericht ist die praktikabelste Form, all das an einer Stelle zu erfüllen. Hinzu kommen die Meldepflichten bei Vorfällen: eine Erstmeldung an das BSI binnen 24 Stunden, unabhängig vom Berichtszyklus.

Was unterscheidet einen IT-Sicherheitsbericht von einem Pentest-Bericht?

Der Pentest-Bericht ist eine Momentaufnahme technischer Befunde: was gefunden wurde, wie es ausnutzbar war, wie es zu beheben ist. Der IT-Sicherheitsbericht ist die Ebene darüber und führt mehrere Quellen zusammen – Pentest, Schwachstellenmanagement, Angriffserkennung, Vorfälle, Schulungen – und bewertet daraus die Gesamtlage. Der eine ist eine Zutat, der andere das Gericht.

Quellen und weiterführende Informationen

Zuletzt aktualisiert am 31. August 2026 · Inhaltlich verantwortlich: Christian Renkes, Geschäftsführer der Nica Systems GmbH.

Kontakt

Nica Systems GmbH, Reisholzer Bahnstraße 41, 40599 Düsseldorf
Telefon: 0211 17520840
E-Mail: Kontaktformular
Erreichbarkeit: Mo–Fr 09:00–17:00 Uhr, Incident Response rund um die Uhr

Bitte aktivieren Sie JavaScript für die vollständige, interaktive Website.