Penetrationstests und Compliance: wirksam und regelkonform

Nicht jeder Bericht aus einem Penetrationstest übersteht den Tisch eines Auditors. Diese Aussage klingt überraschend, doch in der Praxis ist es genau das Problem, das einen erheblichen Teil der Sicherheitsteams in Europa trifft. Unternehmen investieren in Pentests, erhalten Dokumente mit einer Liste von Schwachstellen - und dann zeigt sich, dass das nicht den Anforderungen von ISO 27001, GDPR oder einem anderen Standard genügt. Ein Pentest allein ist keine Compliance. Compliance ist ein Satz von Anforderungen an Umfang, Autorisierung, Methodik und Dokumentation - ohne sie hat kein Test Beweiskraft.

Inhaltsverzeichnis

• Was Penetration Testing Compliance ist und warum nicht jeder Pentest zählt

• Welche Vorschriften und Standards in Europa compliance-gerechte Pentests verlangen

• Pentest vs. Assessment: was die Anforderungen erfüllt und was nicht?

• Wirksame Umsetzung: wie man einen compliance-gerechten Pentest vorbereitet und abschließt

• Was den meisten Compliance-Pentests fehlt - unsere Beobachtungen

• Werkzeuge und Unterstützung für wirksame compliance-gerechte Penetrationstests

• Häufig gestellte Fragen

Wichtigste Erkenntnisse

Was Penetration Testing Compliance ist und warum nicht jeder Pentest zählt

Beginnen wir mit einer klaren Abgrenzung. Penetration Testing Compliance ist mehr als nur die Durchführung des Tests. Das SANS Glossary definiert den Pentest selbst als kontrollierte Simulation eines Angriffs zur Überprüfung der Systemresilienz - der Begriff "penetration testing compliance" geht über diese Definition hinaus und bezeichnet die Ausrichtung solcher Tests an konkreten Vorschriften und Richtlinien: mit einem rechtlich sauberen, autorisierten und kontrollierten Ablauf sowie mit Beweiswert für das Audit. Es geht nicht darum, ob jemand Nmap und Metasploit gestartet hat. Es geht darum, ob der gesamte Prozess die formalen und prozeduralen Vorgaben eines Regulators oder Standards erfüllt.

In der Praxis verlangt Compliance einige Elemente, die ein gewöhnlicher Penetrationstest nicht zwingend enthält:

• Schriftliche Autorisierung: jeder Test braucht die ausdrückliche Erlaubnis des Systemeigentümers. Ohne Autorisierungsdokument existiert der Test für den Auditor nicht.

• Definierter Umfang (Scope): was genau getestet wird, welche IP-Adressen, Systeme, Anwendungen und in welchem Zeitfenster.

• Rules of Engagement: Regeln, welche Techniken erlaubt sind, was verboten ist und wer im Krisenfall Ansprechpartner ist.

• Methodik: Verweis auf eine anerkannte Methodik. Für Webanwendungen - OWASP WSTG (Web Security Testing Guide); für Mobile - OWASP MASTG. Für Infrastruktur, Netzwerke und Active Directory - PTES (Penetration Testing Execution Standard), NIST SP 800-115 oder OSSTMM. Für den Finanzsektor unter DORA - TIBER-EU/TLPT.

• Ergebnisdokumentation: keine Schwachstellenliste, sondern dokumentierte Exploitation-Beweise, reale Angriffswege und Risikobewertung.

Der entscheidende Unterschied zwischen einem Compliance-Pentest und einem gewöhnlichen Assessment liegt darin, dass Compliance Beweise verlangt, nicht nur Ergebnisse. Der Auditor fragt nicht "gab es einen Test", sondern "was hat er bewiesen und wie wurde er durchgeführt".

Worin unterscheidet sich ein compliance-gerechter Pentest von einem Vulnerability Assessment? Ein Vulnerability Assessment ist kurz gesagt eine automatisierte oder teilweise manuelle Erkennung bekannter Schwachstellen auf Basis der CVE-Datenbank. Ein Pentest geht weiter. Der Pentester versucht aktiv, Schwachstellen auszunutzen, sie zu Angriffsketten zu verbinden und reales Risiko nachzuweisen. Für Compliance zählt genau dieses Element der Simulation eines realen Angreifers.

Erwähnenswert ist, dass das "Abhaken" eines Pentests auf der To-Do-Liste einer der häufigsten Fehler ist. Organisationen beauftragen einen Test, bekommen einen PDF-Bericht und legen ihn in den Compliance-Ordner. Der Auditor fragt nach Umfang, Autorisierung, Spielregeln und Exploitation-Beweisen. Fehlen diese Elemente, ist der Bericht aus Compliance-Sicht wertlos.

Welche Vorschriften und Standards in Europa compliance-gerechte Pentests verlangen

Die Definition kennen wir. Jetzt zu den konkreten Regelungen und Normen, die in diesem Bereich reale Anforderungen stellen.

GDPR (Datenschutz-Grundverordnung)

Artikel 32 GDPR verpflichtet Organisationen, die personenbezogene Daten verarbeiten, "ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen" zu implementieren. GDPR nennt das Wort "Pentest" nicht, aber europäische Regulatoren und Aufsichtsbehörden haben diese Vorgabe wiederholt als Anforderung an regelmäßige technische Sicherheitstests ausgelegt. Wie GDPR cybersecurity requirements anmerkt, fördert GDPR regelmäßige Tests der Wirksamkeit von Sicherheitsmaßnahmen, was oft als Pentest-Pflicht interpretiert wird.

Was bedeutet das für den Pentester? Wenn Sie einen Test für eine unter GDPR fallende Organisation durchführen, muss der Bericht klar zeigen, welche Datenschutzmaßnahmen getestet wurden und wie wirksam sie sind. Eine reine CVE-Liste beweist hier nichts.

ISO 27001

ISO/IEC 27001:2022 ist die aktuelle Version des Standards für Informationssicherheits-Management (die Übergangsfrist von der Version 2013 endete am 31. Oktober 2025 - Auditoren beziehen sich heute auf die neue Nummerierung). Kontrolle A.8.8 "Management of technical vulnerabilities" (vormals A.12.6.1 in der Version 2013) betrifft das Management technischer Schwachstellen, und Kontrolle A.5.36 "Compliance with policies, rules and standards for information security" (vormals A.18.2.3) verlangt ausdrücklich eine technische Überprüfung der Compliance. ISO 27001 schreibt Pentests nicht namentlich vor, aber Auditoren erwarten objektive Beweise für die Wirksamkeit der Kontrollen. In der Praxis heißt das: Wenn Ihr ISMS (Information Security Management System) feststellt, dass die Kontrollen wirksam sind, müssen Sie das nachweisen. Und ein gut dokumentierter Pentest ist genau dieser Nachweis.

NIST SP 800-115

NIST Special Publication 800-115 ist das technische Dokument zur Methodik von Sicherheitstests. Es definiert vier Phasen: Planung, Discovery, Angriff und Reporting. Für Compliance ist wichtig, dass NIST jeden Prozessschritt so genau dokumentiert haben will, dass die Ergebnisse reproduziert werden können.

Europäischer Kontext

DORA (Digital Operational Resilience Act), seit dem 17. Januar 2025 für den Finanzsektor verbindlich, verpflichtet kritische Institutionen zur Durchführung von Threat-Led Penetration Testing (TLPT). TLPT basiert auf dem Framework TIBER-EU der Europäischen Zentralbank - ein operatives Dokument, das Anforderungen an Scope, Threat Intelligence und Red Teaming unter Aufsicht des nationalen Regulators definiert.

NIS2 (EU-Richtlinie 2022/2555) ist heute der Hauptantrieb für Pentests in der EU für wesentliche und wichtige Einrichtungen: Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur, ICT-Dienstleister, öffentliche Verwaltung. In Polen umgesetzt durch das Gesetz über das nationale Cybersicherheitssystem (KSC). Artikel 21 verlangt das Management von Cybersicherheitsrisiken einschließlich der Bewertung der Wirksamkeit von Maßnahmen - Regulatoren legen das als Anforderung an regelmäßige technische Tests aus. Sanktionen: bis zu 10 Mio. EUR oder 2 % des globalen Umsatzes (wesentliche Einrichtungen), bis zu 7 Mio. EUR oder 1,4 % (wichtige Einrichtungen).

CRA (Cyber Resilience Act, Verordnung EU 2024/2847) trat im Dezember 2024 in Kraft (Hauptpflichten ab 11. Dezember 2027). Sie verpflichtet Hersteller von Produkten mit digitalen Elementen - IoT-Hardware, Software, vernetzte Geräte - zu Security-by-Design-Anforderungen und Sicherheitstests. Pentest wird Teil der Konformitätsbewertung vor dem Inverkehrbringen eines Produkts auf dem EU-Markt.

Pentest vs. Assessment: was die Anforderungen erfüllt und was nicht?

Sie wissen jetzt, welche Vorgaben wichtig sind. Zeit für die praktische Abgrenzung, welche Maßnahmen die Compliance-Anforderungen tatsächlich erfüllen.

Pentest und Vulnerability Assessment klingen ähnlich. In der Praxis sind es zwei unterschiedliche Leistungen mit völlig unterschiedlicher Beweiskraft. Wie SANS pentest vs. assessment festhält, ist ein Pentest eine Angriffssimulation, ein Assessment die Identifikation bekannter Schwachstellen - und Compliance verlangt eher Ersteres.

Was prüft ein Compliance-Auditor genau im Pentest-Bericht? Hier die Liste der zentralen Elemente, die in der Dokumentation auftauchen müssen:

1. Autorisierungsdokument, unterzeichnet vom Systemeigentümer oder Vorstand.

2. Umfang (Scope) mit präziser Liste der Systeme, Netzwerke und Anwendungen.

3. Rules of Engagement mit Beschreibung erlaubter und verbotener Techniken.

4. Methodik-Verweis (PTES, OWASP, NIST SP 800-115 oder andere anerkannte Norm).

5. Exploitation-Beweise: Screenshots, Logs, PoC (Proof of Concept) für jede kritische Schwachstelle.

6. Geschäftliche Risikobewertung im Kontext der getesteten Umgebung.

7. Remediation-Empfehlungen mit Priorisierung.

8. Datum und Berichtsversion mit dem Namen der verantwortlichen Person.

NIST und die Leitlinien der ENISA für EU-Vorschriften stimmen in diesem Punkt überein: Compliance verlangt den Nachweis eines Tests unter adversariellen Bedingungen. Das heißt: Ein reiner automatischer Scan, selbst mit Tausenden Befunden, ersetzt keinen dokumentierten Exploitation-Versuch.

Profi-Tipp: Bevor Sie den Test starten, bereiten Sie eine Dokumentationsvorlage vor, die dem zu erfüllenden Standard entspricht. Füllen Sie sie laufend aus, nicht nach Ende des Tests. Auditoren unterscheiden während des Tests erstellte Dokumentation von nachträglich angefertigten Unterlagen.

Ebenfalls lesenswert ist der Fuzzing-Leitfaden, der fortgeschrittene Techniken zur Entdeckung von Schwachstellen zeigt, die direkt für den Nachweis der Angriffsrealität nutzbar sind.

Wirksame Umsetzung: wie man einen compliance-gerechten Pentest vorbereitet und abschließt

Nach Abgrenzung und Standards lohnt es sich, praktisch zu zeigen, wie ein compliance-gerechter Pentest Schritt für Schritt abläuft.

Ein sauber organisierter Compliance-Pentest durchläuft sechs Phasen:

1. Planung und Autorisierung: Treffen mit dem Kunden, Definition geschäftlicher und technischer Ziele, Unterzeichnung des Autorisierungsdokuments. In dieser Phase wird der rechtliche Rahmen gesetzt. Ohne diesen Schritt hat keiner der folgenden Schritte einen Wert.

2. Scope und Rules of Engagement: präzise Systemliste, ausgeschlossene, ausfallkritische Produktionssysteme, Testfenster, Kontaktdaten. Der Umfang muss so detailliert sein, dass er nach Testende überprüfbar ist.

3. Aufklärung und Discovery: Informationssammlung zur Infrastruktur, Netzwerk-Mapping, Identifikation potenzieller Angriffsvektoren. Die Ergebnisse müssen dokumentiert werden, denn sie zeigen, was für einen hypothetischen Angreifer verfügbar war.

4. Exploitation und Beweisführung: aktive Versuche, Schwachstellen auszunutzen, sie zu Angriffsketten zu kombinieren und Privilegien zu eskalieren. Jede erfolgreiche Exploitation muss mit Screenshot oder Log dokumentiert werden, mit präzisem Zeitstempel und Tool-Version.

5. Post-Exploitation und Risikobewertung: was könnte ein Angreifer nach dem Durchbrechen der Sicherungen tatsächlich tun? Zugriff auf personenbezogene Daten, Zahlungssysteme, kritische Infrastruktur? Diese Phase ist für Compliance am wichtigsten, weil sie das reale Geschäftsrisiko zeigt.

6. Reporting und Review: Bericht in zwei Ebenen - technisch (für Pentester und Entwickler) und Executive Summary (für Vorstand und Auditoren). Der Bericht muss so belastbar sein, dass sich die Ergebnisse im Audit vertreten lassen.

Wie die Leitlinien der CREST zu "defensible penetration test" festhalten, ist die Qualität der Beweise entscheidend: Umfang, Spielregeln, präzise Dokumentation und die Verteidigbarkeit des Berichts im Audit.

Worauf achten Auditoren in der Dokumentation? Vor allem auf Konsistenz. Der zu Beginn definierte Scope muss zu den im Bericht behandelten Systemen passen. Exploitation-Beweise müssen mit konkreten Schwachstellen verknüpft sein. Empfehlungen müssen umsetzbar und an Risiken gebunden sein.

Die häufigsten Fehler in Compliance-Pentests sind:

• Fehlendes Autorisierungsdokument oder Autorisierung von einer Person ohne entsprechende Befugnisse.

• Zu vager Scope: "die gesamte IT-Infrastruktur" ohne Liste der IP-Adressen und Systemnamen.

• Fehlende Zeitstempel in den Exploitation-Beweisen.

• Rein technischer Bericht ohne geschäftliche Risikobewertung und Executive Summary.

• Fehlender Methodik-Verweis: der Auditor weiß nicht, nach welchen Kriterien der Pentester gearbeitet hat.

• Rein automatisierter Test: Scanner ersetzen keine manuelle Verifikation und Exploitation.

Profi-Tipp: Wenn Sie möchten, dass Ihr Bericht den Fragen des Auditors wirklich standhält, ergänzen Sie einen Abschnitt „Limitations“, der beschreibt, was der Test nicht abgedeckt hat und warum. Das zeigt methodische Reife und beugt Scope-Missverständnissen vor.

Fortgeschrittene Techniken wie Fuzzing haben direkten Nutzen beim Dokumentieren der Angriffsrealität. Eine detaillierte Vorgehensweise beschreibt der Artikel zur Anwendung von Fuzzing in Pentests, der als Methodik-Ergänzung lesenswert ist.

Was den meisten Compliance-Pentests fehlt - unsere Beobachtungen

Aus der Arbeit mit Sicherheitsspezialisten und dem Verfolgen der Berichte, die bei Auditoren landen, erkennen wir ein klares Muster. Die meisten Compliance-Probleme liegen nicht an mangelnder technischer Qualität des Tests. Sie entstehen durch mangelnde Dokumentationsdisziplin und einem Missverständnis dessen, wonach der Auditor wirklich sucht.

Das erste und häufigste Problem ist ein zu allgemein beschriebener Scope. "Wir haben die Netzwerkinfrastruktur des Kunden getestet" ist ein Satz, der nichts beweist. Der Auditor braucht eine Liste: welche Server, welche Anwendungen, welche IP-Bereiche, in welchem Zeitfenster. Ohne diese Genauigkeit kann selbst ein technisch hervorragender Test nicht als Compliance-Beweis akzeptiert werden.

Das zweite Problem ist die fehlende Verifikation der Ausnutzbarkeit. Viele Berichte enthalten lange Listen von Schwachstellen mit CVSS 9.0+, aber keinen einzigen Nachweis, dass irgendeine davon in der getesteten Umgebung tatsächlich ausnutzbar ist. Compliance verlangt eine Simulation eines echten Angriffs, keine Liste theoretischer Bedrohungen. Auditoren verstehen diesen Unterschied immer besser und lehnen immer häufiger Berichte ab, die ausschließlich auf automatisierten Scans beruhen.

Das dritte Problem sind Berichte, die ausschließlich für Techniker geschrieben sind. Compliance betrifft die gesamte Organisation, Entscheidungen trifft die Geschäftsleitung. Ein Bericht ohne Executive Summary und Geschäftsrisikobewertung ist für die Entscheider unbrauchbar und blockiert oft die Akzeptanz durch den Auditor.

Aus unserer Sicht ist der wichtigste Parameter eines Compliance-Pentests, wie realistisch der simulierte Angriff ist. Es zählt nicht, ob der Pentester die neueste Technik benutzt hat. Es zählt, ob der Test die realen Bedrohungen für die konkrete Umgebung abgebildet hat. Die Angreifer, die europäische Unternehmen tatsächlich bedrohen, sind keine akademischen Forscher. Sie nutzen einfache, bewährte Vektoren: Phishing, schwache Passwörter, nicht aktualisierte öffentliche Dienste. Ein Pentest, der sich ausschließlich auf exotische Exploits konzentriert und diese Vektoren übergeht, erzeugt ein falsches Sicherheitsgefühl.

Ein weiterer Punkt ist die Qualität der Vorabvereinbarungen. Rules of Engagement, Scope und das geschäftliche Testziel sollten vor dem Start schriftlich vereinbart werden. Wir sehen zu viele Fälle, in denen Pentester ohne klaren Rahmen beginnen und die Dokumentation später an den fertigen Bericht "anpassen" müssen. Das sieht man immer. Erfahrene Auditoren erkennen das.

Was die Tools angeht, hat gute Laborausrüstung erheblichen Einfluss auf die Qualität der Beweise. Geräte für Wi-Fi-Tests, RFID/NFC-Analyse oder spezielles Zubehör für Angriffssimulationen liefern reproduzierbare Nachweise, die sich verifizieren und wiederholen lassen. Genau das ist der Standard, den ein solider Compliance-Pentest verlangt. Mehr zu fortgeschrittenen Techniken der Beweissammlung finden Sie im praktischen Fuzzing-Leitfaden, der Methoden beschreibt, die direkt in die Beweiskraft des Berichts münden.

Werkzeuge und Unterstützung für wirksame compliance-gerechte Penetrationstests

Das erforderliche Wissen haben Sie nun. Im nächsten Schritt benötigen Sie Hardware, mit der Sie es praktisch anwenden und belastbare, vom Auditor akzeptierte Nachweise erzeugen können.

SAPSAN ist ein europäischer Distributor von Fachausrüstung für Pentester und IT-Security-Profis. Das Sortiment umfasst Werkzeuge für WLAN-Tests, Geräte zur RFID/NFC-Analyse, SDR-Equipment (Software Defined Radio), BadUSB-Zubehör und Flipper-Zero-Erweiterungen. Es ist Hardware für reale Tests in Labor- und Produktionsumgebungen, die Exploitation-Beweise in einer Form erzeugt, die Compliance-Auditoren akzeptieren. Jedes Gerät bei sapsan-sklep.pl ist mit Blick auf professionelle Einsätze ausgewählt: Pentests drahtloser Netzwerke, physische Zugangssicherheit, Analyse von Funkprotokollen und IoT-Angriffssimulation. Versand in ganz Europa.

Häufig gestellte Fragen

Reicht jedes regelmäßige Schwachstellen-Scanning für Compliance?

Nein, Compliance verlangt eher realistische Tests vom Typ Pentest als nur automatisches Scanning. Wie SANS pentest vs. assessment anmerkt, fordert Compliance die Simulation echter Angriffe, nicht nur die Detektion von Lücken.

Verlangt GDPR Pentests namentlich?

GDPR nennt Pentests nicht ausdrücklich, aber Artikel 32 verpflichtet zu regelmäßigen Tests der Wirksamkeit von Sicherheitsmaßnahmen. Wie die GDPR-Vorgaben zur Cybersicherheit betonen, wird die Pflicht zur regelmäßigen Überprüfung der Wirksamkeit der Kontrollen von Regulatoren als Pentest-Pflicht ausgelegt.

Welche Form des Pentest-Berichts akzeptieren Compliance-Auditoren?

Auditoren bevorzugen Berichte mit klarem Scope, schriftlichen Vereinbarungen, Beweisen aus realistischen Tests und konkreten Empfehlungen. Laut Penetration testing code compliance muss die Berichtsqualität eine Verteidigung der Ergebnisse im Audit erlauben.

Wie oft sollten compliance-gerechte Pentests durchgeführt werden?

Die Häufigkeit sollte aus einer Risikoanalyse folgen: Veränderlichkeit der Umgebung, Sensibilität der Daten und Tempo der Veränderungen in IT-Systemen. Der europäische Kontext verlangt einen risikobasierten Ansatz, keinen festen Testkalender.