Der peinlichste Moment bei einem Audit ist fast immer derselbe. Wir fragen nach Nachweisen zum Management von Schwachstellen, und es kommt ein zweihundertseitiges PDF: der Scanner-Export mit seinen roten, gelben und grünen Zeilen. Dann fragen Sie: «Welche Auswirkungen hätten diese drei kritischen Punkte aus dem letzten Quartal auf das Unternehmen gehabt?», und es herrscht Schweigen. Das Dokument ist da. Die Antwort nicht.

Die Verwechslung zwischen automatischem Schwachstellenscan und Penetrationstest ist verständlich, da Ersterer oft eine der Techniken ist, die im Rahmen des Letzteren eingesetzt werden. Es handelt sich jedoch um zwei Dienstleistungen mit unterschiedlichen Zielen und Sicherungsniveaus, und bei einer Überprüfung wird der Unterschied deutlich sichtbar.

Was der Scanner leistet und was nicht

Der Scanner gleicht Ihre Assets mit einer Datenbank bekannter Probleme ab und liefert Ihnen bereits katalogisierte Schwachstellen, Fehlkonfigurationen und fehlende Updates. Er ist schnell, kostengünstig und deckt viel ab: Das sind echte Vorteile, und niemand hier sagt, dass man ihn nicht mehr nutzen sollte.

Was dem Scanner fehlt, ist der Kontext. Er weiß nicht, was Ihr Unternehmen tut, er kennt das von Ihnen implementierte Sicherheitskonzept nicht, er weiß nicht, welches das vorgesehene Verhalten dieser Anwendung ist. Er listet Schwachstellen auf, bewertet aber nicht deren Auswirkungen auf das Geschäft. Und vor allem betrachtet er sie einzeln, während ein Angreifer genau das Gegenteil tut.

Der manuelle Penetrationstest setzt dort an und geht weiter: Ein Fachmann validiert die Ergebnisse manuell, um Fehlalarme zu eliminieren, bewertet sie im spezifischen Umfeld und sucht nach Dingen, die ein automatisches Werkzeug bauartbedingt nicht erkennt. Zwei konkrete Beispiele, die ich einer Analyse entnehme, die sie gut erklärt und die ich regelmäßig in der Praxis wiederfinde.

Fehler in der Geschäftslogik. Eine IDOR (Insecure Direct Object Reference) in einer Webanwendung, also ein direkter Verweis auf ein unkontrolliertes Objekt, ermöglicht den Zugriff auf das Konto eines anderen Benutzers, indem einfach eine ID in der Adresse geändert wird. Für den Scanner antwortet diese Seite korrekt: keine nicht aktualisierte Software, keine fehlerhafte Konfiguration, kein Alarm. Für einen Angreifer ist es die Haupttür.

Kettenangriffe. In einem internen Netzwerk kann eine LLMNR-Vergiftung in Kombination mit einem SMB-Relay zur vollständigen Kompromittierung der Domäne und von dort aus zu Ransomware führen. Einzeln betrachtet, stehen diese beiden Schwachstellen in einem automatischen Bericht am Ende der Liste, möglicherweise als «mittel» eingestuft. Aneinandergereiht bedeuten sie für das Unternehmen das Aus für eine Woche.

Das ist der entscheidende Unterschied: Der Scanner zeigt, welche Türen offen sind, der Penetrationstest demonstriert, wohin sie führen.

Was die ISO 27001 wirklich verlangt

Hier muss etwas gesagt werden, das oft falsch vermittelt wird, und ich sage es deutlich, denn es ist der Kern der Sache: Die Norm verpflichtet Sie nicht zu einem Penetrationstest. Es gibt keine Kontrolle mit diesem Titel, und wer Ihnen dies als gesetzliche Verpflichtung darstellt, vereinfacht es, um zu verkaufen.

Was die ISO/IEC 27001 verlangt, ist anders und anspruchsvoller. Die Kontrolle A.8.8, Management technischer Schwachstellen, fordert von der Organisation, Informationen über Schwachstellen in den verwendeten Systemen zu erhalten, ihre eigene Exposition zu bewerten und angemessene Maßnahmen zu ergreifen. Das Schlüsselwort ist «bewerten»: nicht «auflisten». Ein Bericht, der eine Schwachstelle nach einem Standard-Score als kritisch einstuft, sagt nichts über Ihre Exposition aus, da dieser Score berechnet wird, ohne zu wissen, ob dieses System isoliert, im Internet exponiert oder mit dem Umsatz generierenden Verwaltungssystem verbunden ist.

Die Kontrolle A.8.29, Sicherheitstests in Entwicklung und Abnahme, verlangt hingegen die Definition und Umsetzung von Testprozessen entlang des Lebenszyklus, bevor etwas in Produktion geht. Auch hier liegt es bei Ihnen, wie dies geschieht. Doch wenn Sie Software entwickeln oder entwickeln lassen, wird ein Abnahmeprozess, der darin besteht, einen Scanner laufen zu lassen, der nächsten Frage des Auditors kaum standhalten: «Und wer hat die Anwendungslogik überprüft?».

Es geht also nicht um die Verpflichtung. Es geht darum, dass die Norm kein Werkzeug vorschreibt, sondern den Nachweis fordert, und für bestimmte Nachweise der Scanner allein nicht ausreicht. Dieser Unterschied wird bei einem Audit sofort spürbar.

Was NIS2 wirklich verlangt, und das entscheidende Datum

Dieselbe Logik, mit einem Temperaturunterschied: Hier gibt es keinen Auditor, der Ihnen eine Empfehlung gibt, sondern eine Behörde, die prüft.

Artikel 24 des Gesetzesdekrets 138/2024, welches die NIS2-Richtlinie umgesetzt hat, listet die Mindestmaßnahmen des Risikomanagements auf. Zwei Punkte dieser Liste betreffen dieses Thema direkt. Der erste ist die Sicherheit der Systementwicklung, einschließlich des Managements und der Offenlegung von Schwachstellen. Der zweite, der meiner Meinung nach am meisten im gesamten Dekret unterschätzt wird, sind die Richtlinien zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen.

Konzentrieren wir uns auf Letzteres. Die Wirksamkeit zu bewerten bedeutet, die Frage zu beantworten: «Funktionieren die von uns ergriffenen Maßnahmen wirklich?», und um dies zu beantworten, sind Beweise erforderlich. Ein internes Audit beweist, dass der Prozess existiert. Eine Managementbewertung beweist, dass jemand ihn überprüft. Der Nachweis, dass eine technische Maßnahme standhält, wird jedoch erbracht, indem man versucht, sie zu überwinden, und genau das leistet ein manueller Test.

Dann ist da noch das Datum, und es ist nah. Die ACN-Bestimmung Nr. 379907 vom 18. Dezember 2025, die die vorherige Nr. 164179/2025 ersetzt hat und ab dem 15. Januar 2026 gilt, legt die Basisspezifikationen fest. Die Frist für deren Implementierung und Inbetriebnahme ist der 31. Oktober 2026, also achtzehn Monate nach den Mitteilungen zur Aufnahme in die NIS-Liste, die zwischen April und Mai 2025 eingegangen sind.

Die wichtigen Einrichtungen müssen die 37 Maßnahmen und die 87 Anforderungen des Anhangs 1 umgesetzt haben.
Die wesentlichen Einrichtungen müssen die 43 Maßnahmen und die 116 Anforderungen des Anhangs 2 umgesetzt haben.

Ab diesem Datum tritt die Nationale Agentur für Cybersicherheit aus der Begleitphase in die Überprüfungsphase ein. Dabei ist eine Asymmetrie bei der Budgetplanung zu beachten: Bei wesentlichen Einrichtungen erfolgt die Überwachung ex ante, also proaktiv, während sie bei wichtigen Einrichtungen überwiegend ex post, nach einem Vorfall oder einer Meldung, stattfindet. Wenn Sie eine wesentliche Einrichtung sind, warten Sie nicht, bis etwas passiert, um festzustellen, ob Ihre Maßnahmen greifen.

Der Unterschied zeigt sich im Nachweis

In der Praxis besteht der Unterschied zwischen den beiden Ansätzen darin, was Sie vorlegen können, wenn jemand Rechenschaft fordert.

Mit dem Scanner allein legen Sie eine Liste bekannter Probleme vor und, wenn der Prozess gut durchgeführt wird, den Nachweis, dass Sie diese innerhalb der von Ihnen gesetzten Fristen behoben haben. Das ist bereits etwas und unerlässlich: Ohne diese Grundlage kommt man nirgendwohin.

Mit einem manuellen Test bringen Sie drei zusätzliche Dinge mit, und genau diese fordern die Normen. Eine Bewertung der tatsächlichen Exposition, da der Tester Ihre Umgebung gesehen hat und nicht nur eine Datenbank. Eine Wirkungsdemonstration, also einen Schritt für Schritt rekonstruierten Angriffspfad, der zeigt, wie weit er wirklich führt. Und eine Wirksamkeitsprüfung: Wenn der Test gestoppt wurde, haben Ihre Maßnahmen funktioniert, und dies ist der Nachweis, den Artikel 24 von Ihnen verlangt.

Es gibt auch die Kehrseite der Medaille, und das muss gesagt werden, weil es niemand je ausspricht. Ein schlecht durchgeführter manueller Test ist schlimmer als gar kein Test: Er erzeugt einen Bericht, der wie ein Nachweis aussieht, wird zu den Akten gelegt und schafft dieselbe trügerische Sicherheit wie der Scanner, zuzüglich der Kosten. Die Qualität hängt hier davon ab, wer ihn durchführt, nicht davon, was Sie gekauft haben.

Was Sie von einem Anbieter fordern sollten

Wenn Sie einen Anbieter bewerten, trennen diese fünf Fragen einen echten Test von einem Scanner mit der Rechnung für einen Test.

Sind die Ergebnisse manuell validiert? Wenn der Bericht der Export des Tools ist und noch Fehlalarme enthält, haben Sie einen Scan gekauft.
Überprüfen Sie die Anwendungslogik und die Berechtigungskontrollen? Das ist die Art von Problemen, wie IDOR, die kein automatisches Tool findet.
Werden Schwachstellen verkettet? Fragen Sie nach einem Beispiel eines rekonstruierten Angriffspfads bei einem früheren Kunden, auch anonymisiert. Wenn die Antwort vage ist, lautet die Antwort nein.
Zeigt der Bericht die Auswirkungen auf das Geschäft oder beschränkt er sich auf den Schweregrad? Der Score wird berechnet, ohne etwas über Sie zu wissen.
Was passiert danach? Ein Test, der keine im Managementsystem verfolgten Aktionen erzeugt, ist kein Wirksamkeitsnachweis: Es ist eine Momentaufnahme.

Wie wir vorgehen

Hier bin ich transparent, denn es ist unsere Arbeitsweise und ich glaube, es ist auch der richtige Weg. Den technischen Test führen wir nicht intern durch: Wir beauftragen damit spezialisierte, professionelle Partner, die von uns ausgewählt und koordiniert werden. Wer Penetrationstests ernsthaft durchführt, macht dies hauptberuflich, und ein Berater für Managementsysteme, der einen offensiven Test improvisiert, ist genau der Anbieter, von dem ich Ihnen gerade geraten habe, die Finger zu lassen.

Was wir einbringen, ist der Teil, der bei einem Audit oder einer Inspektion den Unterschied zwischen einem Bericht und einem Nachweis ausmacht:

Die Definition des Umfangs basierend auf der Risikoanalyse und den wirklich wichtigen Assets, anstatt einer IP-Adressliste.
Die Wahl des richtigen Partners für diesen Umfang, mit den oben genannten Qualitätskriterien, die im Lastenheft festgehalten sind.
Die Verknüpfung mit den Kontrollen: A.8.8 und A.8.29 für ISO 27001, Schwachstellenmanagement und Wirksamkeitsbewertung für Artikel 24, mit explizitem Verweis in der Systemdokumentation.
Die Integration der Ergebnisse in das Managementsystem: Aktionen, Verantwortlichkeiten, Fristen, Überprüfung. Dies ist das Element, das einen Test in einen nachweisbaren Wirksamkeitsmaßstab verwandelt.
Die Wiederholung im Laufe der Zeit, da ein Wirksamkeitsnachweis nur gültig ist, solange sich die Umgebung nicht ändert – und die Umgebung ändert sich immer.

Der Test ist ein Teil eines Prozesses, kein isolierter Kauf. Wer ihn allein kauft, ohne den Rest, steht am Ende mit einem PDF und dem gleichen Problem wie zuvor da: dem fehlenden Nachweis, wenn jemand ihn anfordert.

Wenn Sie wissen wollen, wo Sie stehen, ist der Ausgangspunkt immer derselbe: Nehmen Sie den letzten Sicherheitsbericht in die Hand und prüfen Sie, ob er die Frage beantwortet: «Was wäre wirklich passiert?» Wenn er nur antwortet: «Das ist nicht aktualisiert», wissen Sie bereits, was Ihnen fehlt. Wir sprechen gerne darüber: Den vollständigen Prozess finden Sie auf den Seiten zu ISO/IEC 27001 und NIS2, oder schreiben Sie uns, und wir beginnen mit Ihrem tatsächlichen Umfang. Wenn Sie sich zuerst selbst ein Bild machen möchten, finden Sie unter unseren kostenlosen Tools die Positionsüberprüfung zu NIS2.

Hinweis: Die Anwendbarkeit der Maßnahmen und deren Umfang hängen von der Klassifizierung der Einrichtung und dem konkreten Geltungsbereich ab. Dieser Artikel dient allgemeinen Informationszwecken und ersetzt keine spezifische Fallbeurteilung. Artikel aktualisiert im August 2026, unter Bezugnahme auf die ACN-Bestimmung Nr. 379907/2025 und die Frist vom 31. Oktober 2026.

Hintergrund

Der automatische Schwachstellenscan nutzt spezialisierte Tools, um bekannte Schwachstellen, Fehlkonfigurationen und fehlende Sicherheitsupdates durch den Abgleich von Assets mit einer Datenbank bekannter Probleme zu identifizieren. Er ermöglicht eine schnelle Erkennung, geringere Kosten und eine breite Abdeckung, erfasst jedoch nicht den Geschäftskontext, das Sicherheitsdesign oder die vorgesehene Funktionalität von Anwendungen oder Systemen. Er beschränkt sich darauf, Schwachstellen zu identifizieren, ohne deren tatsächliche Auswirkungen auf das Geschäft zu bewerten.
Der Penetrationstest ist eine manuelle Sicherheitsbewertung, die von einem Fachmann durchgeführt wird. Er umfasst oft den Schwachstellenscan, geht aber darüber hinaus, indem er analysiert, wie Schwachstellen ausgenutzt werden können und welche Auswirkungen sie auf die Organisation haben könnten. Seine besonderen Merkmale sind die manuelle Validierung zur Reduzierung von Fehlalarmen, die Bewertung von Schwachstellen im spezifischen Kontext der Zielumgebung, die Identifizierung von Mängeln in der Geschäftslogik und in den Zugriffskontrollen (wie IDOR bei Webanwendungen), die automatische Tools nicht erkennen können, sowie die Fähigkeit, mehrere Schwachstellen zu verketten, um realistische Angriffspfade aufzuzeigen. Der Artikel nennt Beispiele wie den IDOR-Angriff in Webanwendungen, der unbefugten Zugriff auf Benutzerkonten ermöglicht, oder die Kombination von LLMNR-Vergiftung und SMB-Relay in internen Infrastrukturen, die zu einer vollständigen Kompromittierung der Domänenumgebung und der Implementierung von Ransomware führen kann.

Warum es wichtig ist

Ohne einen manuellen Penetrationstest riskiert Ihre Organisation, komplexe und verkettete Schwachstellen offenzulassen, die automatische Scanner nicht erkennen können, wodurch Sie realen Angriffen wie Ransomware und Datenverlust ausgesetzt sind. Angreifer nutzen nicht nur einzelne Schwachstellen aus, sondern kombinieren diese, um ihre Ziele zu erreichen, was zu finanziellen Verlusten und Reputationsschäden führt. Stellen Sie sicher, dass Ihr Sicherheitsprogramm nicht nur Schwachstellen identifiziert, sondern auch deren tatsächliche Auswirkungen durch realistische Angriffssimulationen bewertet. Ist Ihre Organisation bereit, sich gegen Angriffe zu verteidigen, die unentdeckte Schwachstellenketten ausnutzen?

Was zu tun ist

Manuellen Penetrationstest in das Sicherheitsprogramm integrieren, um detaillierte Bewertungen zu erhalten.
Automatisches Schwachstellen-Scanning zur schnellen Identifizierung bekannter Schwachstellen und Fehlkonfigurationen nutzen.
Sicherheits-Testanbieter auffordern, die Ergebnisse manuell zu validieren, um Fehlalarme zu reduzieren.
Sicherstellen, dass Tests die Analyse der Geschäftslogik und der Zugriffskontrollen von Anwendungen umfassen.
Tests priorisieren, die das Verketten mehrerer Schwachstellen demonstrieren, um realistische Angriffspfade zu simulieren.

Was zu vermeiden ist

Sich ausschließlich auf automatische Scanner für eine vollständige und genaue Sicherheitsbewertung zu verlassen.
Die tatsächlichen Auswirkungen einzelner Schwachstellen zu unterschätzen, ohne zu berücksichtigen, wie sie von Angreifern kombiniert werden könnten.
Die Fähigkeit, Schwachstellen zu identifizieren, mit dem Verständnis ihres Kontexts und ihrer Auswirkungen auf das Geschäft zu verwechseln.

Praktische Auswirkungen

Eine Organisation, die sich ausschließlich auf automatische Scans für ihre Sicherheitslage verlässt, riskiert eine falsche Wahrnehmung von Schutz. Dieser Ansatz lässt entscheidende Schwachstellen unentdeckt, wie Fehler in der Geschäftslogik oder Angriffsketten, die ein echter Angreifer ausnutzen würde. Das mangelnde Verständnis der wahren Auswirkungen und der Verkettung von Schwachstellen kann zu einer vollständigen Kompromittierung von Systemen führen, mit verheerenden Folgen wie sensiblen Datenlecks, Betriebsunterbrechungen durch Ransomware und erheblichen Reputationsschäden.

Empfohlene Maßnahmen

Eine Sicherheitsstrategie definieren, die sowohl automatische Scans für Effizienz als auch manuelle Penetrationstests für Tiefe und Kontext umfasst.
Die Wirksamkeit von Zugriffskontrollen und Geschäftslogik in kritischen Anwendungen regelmäßig durch manuelle Tests bewerten.
In die Schulung des Sicherheitspersonals investieren, um fortgeschrittene Testmethoden und realistische Angriffstechniken zu verstehen.
Einen Prozess für das Schwachstellenmanagement etablieren, der nicht nur die individuelle Schwere, sondern auch das Kettenpotenzial priorisiert.

Zu vermeidende Fehler

Nicht ausreichende Ressourcen für Penetrationstests bereitstellen, diese als Kosten statt als präventive Investition betrachten.
Ergebnisse manueller Tests ignorieren, die komplexe Risiken aufzeigen, und stattdessen einfache und schnelle Lösungen bevorzugen.
Sicherheitsrichtlinien und Testanforderungen nicht regelmäßig an die Entwicklung von Bedrohungen und Technologien anpassen.

Fragen zur Selbsteinschätzung

Versteht unsere Organisation den Unterschied zwischen Schwachstellenscan und Penetrationstest klar?
Haben wir Sicherheitstestprogramme, die über die Identifizierung einzelner Schwachstellen hinausgehen und auch den Geschäftskontext und die Verkettung bewerten?
Zeigen unsere Anbieter von Sicherheitstests die tatsächlichen Auswirkungen von Schwachstellen, anstatt nur eine Liste von Problemen zu liefern?
Haben wir Schwachstellen getestet, die unsere Benutzerkonten oder internen Systeme durch kombinierte Angriffe gefährden könnten?
Berücksichtigt unser Risikomanagement Schwachstellen, die automatische Tools möglicherweise nicht erkennen?

Zum Originalartikel auf IT Governance ↗

Vulnerability-Scan oder Penetrationstest: Was ISO 27001 und NIS2 wirklich verlangen