Penetrationstests 2026: Umfang, Methodik, TLPT und die Abgrenzung zum Schwachstellenscan

Penetrationstest, Schwachstellenscan, Red Team, Purple Team und TLPT

Diese Begriffe bezeichnen unterschiedliche Prüfungsformen.

Schwachstellenscanning ist weitgehend automatisierte Erkennung bekannter Schwachstellen und Konfigurationsfehler. Es ist wiederholbar und kann häufig durchgeführt werden, ersetzt aber weder die manuelle Analyse der Geschäftslogik noch das Verketten mehrerer Schwächen oder die Bewertung geschäftlicher Auswirkungen.

Ein Penetrationstest hat ein definiertes Ziel und einen festgelegten Umfang, etwa eine Webanwendung, die externe Infrastruktur, Active Directory, ein internes Netz oder eine mobile Anwendung. Automatisierte Werkzeuge werden eingesetzt, die wesentlichen Entscheidungen zu Angriffshypothesen, Validierung, Ausnutzung und weiterer Bewegung trifft jedoch der Tester. Der OWASP WSTG beschreibt Web-Sicherheitstests als aktive Analyse von Schwächen, technischen Fehlern und Sicherheitslücken; festgestellte Probleme sollen dem Systemverantwortlichen zusammen mit einer Bewertung der Auswirkungen und Hinweisen zur Risikominderung dargestellt werden.^[8]

Ein Red-Team-Test untersucht die weiter gefasste Fähigkeit einer Organisation, einen Gegner zu erkennen und auf ihn zu reagieren. Er kann Techniken umfassen, die über einen klassischen Penetrationstest hinausgehen, etwa Social Engineering, Missbrauch von Cloud-Funktionen, Vertrauensbeziehungen oder physischen Zutritt, jedoch nur, wenn diese Aktivitäten ausdrücklich autorisiert wurden. Das Verteidigungsteam kann über Einzelheiten der Übung im Unklaren bleiben, weil unter anderem Erkennung und Reaktion gemessen werden sollen.

Purple Teaming ist nicht einfach ein "weniger strenger Red-Team-Test". Es ist ein Kooperationsmodell, bei dem offensive und defensive Teams Techniken durchführen und deren Wirkung unmittelbar mit Telemetrie, Detektionslogik und Reaktion vergleichen. Der aktuelle TIBER-EU-Rahmen sieht Replay und Purple Teaming in der Abschlussphase vor.^[5]

TLPT, also threat-led penetration testing beziehungsweise bedrohungsorientierter Penetrationstest, ist eine regulierte Prüfung, die auf Bedrohungsinformationen zur konkreten Institution aufbaut. Im Finanzsektor bildet DORA die Rechtsgrundlage; die Delegierte Verordnung (EU) 2025/1190 konkretisiert Auswahlkriterien, Prüfungsphasen, Anforderungen an Tester, Umfang, Berichterstattung und Zusammenarbeit mit Behörden.^[3][4] Die EZB hat TIBER-EU 2025 an DORA und diese Delegierte Verordnung angepasst. Wer 2026 ausschließlich mit der TIBER-EU-Fassung von 2018 arbeitet, verwendet daher einen überholten Stand.^[5]

Eine allgemeingültige Reihenfolge wie "jährlich Penetrationstest, alle drei Jahre Red Team" gibt es nicht. Häufigkeit und Tiefe müssen sich aus Risiko, Änderungsgeschwindigkeit, Kritikalität der Dienste, rechtlichen Anforderungen und Reife des Monitorings ergeben. Ein Red-Team-Test hat nur begrenzten Wert, wenn keine Telemetrie und keine Reaktionsprozesse vorhanden sind, deren Wirksamkeit geprüft werden könnte.

Zuerst Umfang und Rules of Engagement

Ein professioneller Test beginnt vor dem ersten Paket, das an das Zielsystem gesendet wird. Die Parteien sollten mindestens Folgendes vereinbaren:

• Ziel der Prüfung und die Entscheidungen, die sie unterstützen soll;
• den exakten technischen Umfang einschließlich Domains, Adressen, Anwendungen, Netzsegmente, Cloud-Tenants und Testkonten;
• ausgeschlossene Elemente;
• das Zugriffsmodell: Black Box, Gray Box oder White Box;
• erlaubte und verbotene Handlungen, insbesondere Phishing, Persistenz, laterale Bewegung, kontrollierte Exfiltration, DoS-Tests und physischer Zutritt;
• zulässige Zeiten und Lastgrenzen;
• Notfallkontakte und Bedingungen für einen sofortigen Abbruch;
• Umgang mit Daten, Geheimnissen, Tokens, kopierten Dateien und Beweismaterial;
• Entfernung der Testartefakte;
• Eskalation kritischer Feststellungen bereits während der Prüfung;
• Umfang des Retests und Kriterien für den Abschluss von Feststellungen.

NIST SP 800-115 und CREST behandeln Planung und Vereinbarung als Bestandteil des Prüfprozesses und nicht als administrative Nebensache.^[6][7] Bei regulierten Tests ist der Formalisierungsgrad noch höher. Der aktuelle TIBER-EU-Rahmen verlangt unter anderem die Identifikation kritischer oder wichtiger Funktionen, die Festlegung der einbezogenen Systeme und Dienste sowie die Freigabe des Umfangs durch das Leitungsorgan der Einrichtung.^[5]

Black Box, Gray Box und White Box

Beim Black-Box-Test erhält der Tester nur minimale Vorinformationen. Das Modell eignet sich zur Beurteilung der externen Angriffsfläche und öffentlich erreichbarer Systeme, ein Teil der bezahlten Prüfzeit wird jedoch dafür verwendet, Informationen erneut zu ermitteln, die der Auftraggeber bereits besitzt. Es führt auch nicht automatisch zu einem vollständigeren Sicherheitsbild.

Beim Gray-Box-Test erhält der Tester begrenzte Informationen und kontrollierte Benutzerkonten, beispielsweise Konten mit mehreren Rollen. Bei Geschäftsanwendungen können damit Autorisierung, Mandantentrennung und Prozesslogik meist deutlich effizienter geprüft werden. Häufig ist dies der sinnvollste Kompromiss zwischen Realitätsnähe und Abdeckung.

Ein White-Box-Test kann Architekturdokumentation, Konfiguration, Quellcode und privilegierte Konten einbeziehen. Ziel ist nicht die Nachbildung der Ausgangsposition eines Angreifers, sondern eine möglichst hohe Wahrscheinlichkeit, innerhalb begrenzter Zeit Schwachstellen zu finden. Bei Individualsoftware oder einer vertieften Prüfung der Autorisierung kann er wertvoller sein als ein reiner Black-Box-Test.

Es gibt keine belastbare Grundlage für die Aussage, ein Modell sei immer "realistischer" oder "besser". Das Zugriffsmodell muss zur Fragestellung passen. Die Prüfung der Widerstandsfähigkeit gegen einen unbekannten externen Angreifer und eine tiefgehende Sicherheitsprüfung einer Individualanwendung verfolgen unterschiedliche Ziele.

Methodiken und Referenzdokumente im Jahr 2026

Es gibt keinen einzelnen weltweiten Standard, der sämtliche Arten von Penetrationstests vollständig beschreibt. In der Praxis werden mehrere Dokumente mit unterschiedlichem Status kombiniert.

NIST SP 800-115 stammt aus dem Jahr 2008, wird von NIST jedoch weiterhin als aktuelle Final-Publikation geführt. Das Dokument strukturiert die Planung technischer Sicherheitstests, die Auswahl von Verfahren, die Auswertung und die Behandlung von Feststellungen.^[6] Es ist kein polnisches Recht.

Der OWASP Web Security Testing Guide v4.2 ist am 29. August 2026 weiterhin die stabile WSTG-Fassung. Parallel arbeitet OWASP an Version 5.0, doch die Inhalte unter "latest" können sich laufend ändern. Verträge und Berichte sollten deshalb eine konkrete Version nennen und nicht nur "nach dem neuesten OWASP" formulieren.^[8]

Bei mobilen Anwendungen gab es am 4. Juli 2026 eine wesentliche Änderung: OWASP veröffentlichte MASTG v2.0.0 als stabile Version. MASTG sollte zusammen mit MASVS verwendet werden, weil das eine Dokument Testverfahren beschreibt und das andere erwartete Sicherheitseigenschaften definiert.^[9]

MITRE ATT&CK ist keine Penetrationstest-Methodik. Es handelt sich um eine Wissensbasis zu Verhaltensweisen von Angreifern, die sich zur Beschreibung von Techniken, zur Entwicklung von Red-Team-Szenarien und zum Vergleich mit Detektionen eignet. Am 29. August 2026 ist ATT&CK v19.2 die aktuelle Version.^[10] Nicht jede technische Feststellung sollte ATT&CK zugeordnet werden, wenn sie kein Angreiferverhalten beschreibt.

PTES kann weiterhin als gemeinschaftlich entwickeltes Prozessmodell nützlich sein, insbesondere in der Pre-Engagement-Phase. Es ist jedoch weder eine formale Norm noch eine Regulierung und darf nicht als Quelle rechtlicher Pflichten dargestellt werden.^[20]

CREST Defensible Penetration Test und die CREST-Beschaffungsleitfäden sind beim Einkauf einer Dienstleistung hilfreich, weil sie drei Punkte hervorheben: die Reife der anbietenden Organisation, die Kompetenz der konkreten Tester und eine vereinbarte Testspezifikation.^[7] Eine Akkreditierung kann ein nützliches Qualitätssignal sein, beweist aber nicht automatisch die Qualität eines konkreten Projekts.

Ablauf eines belastbaren Tests

Ein guter Test beginnt nicht damit, sämtliche verfügbaren Scanner zu starten. Zunächst erstellt der Tester ein Modell der Zielumgebung und Angriffshypothesen.

Die Aufklärung klärt, was erreichbar ist, welche Abhängigkeiten bestehen und welche Komponenten zum Prüfziel führen können. Bei einer Anwendung kann dies die Erfassung von Funktionen, Rollen, APIs und Datenflüssen bedeuten. In einem internen Netz können Vertrauensbeziehungen, Authentifizierungsdienste, administrative Pfade und Segmentierung im Mittelpunkt stehen.

Die Validierung von Schwachstellen trennt das Signal eines Werkzeugs von einer tatsächlich vorhandenen Schwäche. Eine erkannte Softwareversion reicht nicht aus, wenn eine Distribution einen Patch zurückportiert hat, ohne die sichtbare Versionsnummer zu ändern, der Dienst über den geprüften Vektor nicht erreichbar ist oder die verwundbare Komponente gar nicht verwendet wird.

Die Ausnutzung muss zum Prüfziel passen. Manchmal genügt ein minimaler Nachweis, dass eine Kontrolle umgangen werden kann. In anderen Projekten soll eine vollständige Kette vom Erstzugriff über Privilegienausweitung bis zum vereinbarten Zielsystem nachgewiesen werden. Je größer die potenzielle operative Auswirkung, desto genauer müssen Grenzen und Abbruchbedingungen festgelegt sein.

Post-Exploitation darf den Penetrationstest nicht in einen unkontrollierten Sicherheitsvorfall verwandeln. Persistenz, Gewinnung weiterer Konten, laterale Bewegung, kontrollierte Exfiltration und C2-Aktivität sind nur zulässig, wenn der vereinbarte Umfang dies vorsieht. Jedes Artefakt sollte identifizierbar und entfernbar sein.

Cleanup ist Bestandteil des Tests. Der Tester sollte angelegte Konten, Dateien, geplante Aufgaben, Schlüssel, Regeln, Tunnel, Tokens und andere Artefakte entfernen; der Auftraggeber sollte diesen Zustand verifizieren können. Fehlende Cleanup-Verfahren sind insbesondere bei Red-Team- und TLPT-Projekten problematisch.

Ein Retest sollte nicht nur prüfen, ob der ursprüngliche Exploit nicht mehr funktioniert, sondern auch, ob die Korrektur auf allen betroffenen Komponenten umgesetzt wurde und keinen neuen Angriffspfad geschaffen hat. Ein Ticket mit dem Status "geschlossen" ist kein Nachweis der Behebung.

Der Bericht: Nachweis statt Alarmliste

Ein Penetrationstestbericht sollte einem fachkundigen Empfänger ermöglichen, die wichtigsten Feststellungen nachzuvollziehen und zu reproduzieren. Das bedeutet nicht, Geheimnisse in einem weit verteilten Dokument offenzulegen. Detaillierte technische Nachweise können in einem geschützten Anhang abgelegt werden.

Eine gute Feststellung enthält:

• das Kriterium oder die erwartete Sicherheitseigenschaft;
• den beobachteten Zustand und die Bedingungen, unter denen er festgestellt wurde;
• den Nachweis;
• den Ausnutzungsweg;
• technische und geschäftliche Auswirkungen;
• Grenzen der Schlussfolgerung;
• Hinweise zur Behebung;
• das Verfahren für den Retest.

CVSS kann die technische Schwere einer Schwachstelle beschreiben, darf aber den Kontext der Organisation nicht ersetzen. Gerade bei Penetrationstests sind Angriffsketten wichtig, weil mehrere einzeln moderate Schwächen gemeinsam zu einer kritischen Auswirkung führen können.

Die Management-Zusammenfassung muss andere Fragen beantworten als der technische Anhang. Sie sollte zeigen, welche Ziele des Angreifers erreichbar waren, welche Verteidigungsschichten versagt haben, welche Entscheidungen erforderlich sind und welche Feststellungen voneinander abhängen. Sie darf nicht den Eindruck erwecken, dass das Nichtfinden eines Angriffspfads dessen Nichtexistenz beweist.

Penetrationstest, SOC und Detektion

Ein offensiver Test gewinnt zusätzlichen Wert, wenn seine Zeitleiste mit der Telemetrie des SOC verglichen werden kann. Die Organisation erhält dann nicht nur eine Antwort auf "Konnte der Angreifer eindringen?", sondern auch auf "Wann hätten wir es erkennen müssen?"

ATT&CK v19.2 kann helfen, ausgeführte Verhaltensweisen zu beschreiben und sie mit vorhandenen Detektionen zu vergleichen.^[10] Daraus sollte jedoch kein isolierter Prozentwert für "ATT&CK-Abdeckung" werden. Eine einer Technik zugeordnete Regel ohne erforderliche Telemetrie oder ohne Test liefert keine reale Detektionsfähigkeit.

Nach einem Red-Team-Test ist eine gemeinsame Rekonstruktion des Angriffspfads durch das offensive und defensive Team besonders wertvoll. Der aktuelle TIBER-EU-Rahmen formalisiert Replay und Purple Teaming, um die Aktionen des Red Teams mit der Reaktion des Blue Teams und dem Maßnahmenplan zu verbinden.^[5]

Bei 4crypto wird der Penetrationstest als eigenständige Prüfmethodik behandelt, die kontinuierliches Schwachstellenscanning, SOC-Monitoring, Hardening und Sicherheitsaudits ergänzt. Die Kombination dieser Arbeiten ist nur sinnvoll, wenn Ziele, Nachweise und Verantwortlichkeit für die Schlussfolgerungen getrennt bleiben.

OT und ICS: Aktives Testen kann selbst zum Risiko werden

Operational Technology erfordert mehr Vorsicht als ein typisches Büronetz. NIST SP 800-82 Rev. 3 weist darauf hin, dass Penetrationstests in OT-Netzen so durchgeführt werden müssen, dass die OT-Funktionen nicht nachteilig beeinflusst werden; als mögliche Ausgleichsmaßnahmen nennt NIST unter anderem Tests auf replizierten, virtualisierten oder simulierten Systemen sowie Tests in geplanten Stillstandsfenstern.^[11]

Daraus folgt keine allgemeingültige Regel "in Produktion ausschließlich passiv testen". Aktive Tests in Produktionsumgebungen können in bestimmten Fällen möglich sein, setzen aber Prozesskenntnis, Einbindung des Betreibers, begrenzte Techniken und eine bewusste Risikoentscheidung voraus. Tests an PLCs, RTUs oder Geräten der funktionalen Sicherheit ohne Verständnis des Prozesses können ein größeres Risiko verursachen als die gesuchte Schwachstelle.

Die IEC-62443-Familie ist eine wichtige Referenz für die Sicherheit industrieller Automatisierungs- und Steuerungssysteme. Soll sie jedoch als formales Kriterium dienen, müssen der konkrete Teil und die Ausgabe genannt werden. Der allgemeine Verweis auf "IEC 62443" definiert keine einheitliche Penetrationstest-Methodik.

Tests von AI- und LLM-Systemen

Sicherheitstests von Systemen mit großen Sprachmodellen erweitern klassische Anwendungstests um Fehlerklassen des Modells und seiner Integration. Typische Prüfbereiche sind direkte und indirekte Prompt Injection, Abfluss von Kontextdaten, Missbrauch von Werkzeugen eines Agenten, Fehler bei der Mandantentrennung, Umgehung von Richtlinien und die Nutzung nicht vertrauenswürdiger Inhalte zur Steuerung des Modellverhaltens.

Es wäre jedoch falsch zu behaupten, seit dem 2. August 2026 müssten alle Hochrisiko-KI-Systeme bereits nach dem ursprünglich geplanten Zeitplan die Anforderungen des Art. 15 AI Act erfüllen. Die Verordnung (EU) 2026/1744 verschob die Anwendung der Abschnitte 1-3 des Kapitels III für Hochrisiko-Systeme: auf den 2. Dezember 2027 für Systeme nach Art. 6 Abs. 2 und Anhang III und auf den 2. August 2028 für Systeme nach Art. 6 Abs. 1 und Anhang I.^[14][15]

Anders ist die Lage bei KI-Modellen mit allgemeinem Verwendungszweck und systemischem Risiko. Art. 55 AI Act verpflichtet deren Anbieter unter anderem zur Modellevaluierung mit geeigneten dem Stand der Technik entsprechenden Protokollen und Werkzeugen, einschließlich Durchführung und Dokumentation adversarialer Tests zur Identifikation und Minderung systemischer Risiken.^[14] Der Anwendungsbereich dieser Pflicht ist wesentlich enger als die verkürzte Aussage "Der AI Act verlangt AI-Pentests".

Rechtliche Anforderungen in Polen und der EU

KSC und NIS2. NIS2 verlangt von den erfassten Einrichtungen verhältnismäßige Maßnahmen zum Management von Cybersicherheitsrisiken sowie Strategien oder Verfahren zur Bewertung ihrer Wirksamkeit.^[2] In Polen ergeben sich die konkreten Pflichten in erster Linie aus dem geltenden Gesetz über das nationale Cybersicherheitssystem. Nach der Novelle von 2026 verlangt Art. 8 von wesentlichen und wichtigen Einrichtungen unter anderem Sicherheit beim Erwerb, bei Entwicklung, Wartung und Betrieb des Informationssystems einschließlich seiner Tests sowie Strategien und Verfahren zur Bewertung der Wirksamkeit der Maßnahmen.^[1] Das Gesetz führt jedoch keine universelle Pflicht zu einem jährlichen Penetrationstest für jede Organisation ein.

DSGVO. Art. 32 Abs. 1 Buchst. d verlangt risikoadäquat ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit technischer und organisatorischer Maßnahmen.^[12] Die Vorschrift bestimmt weder den Penetrationstest als einzige zulässige Methode noch eine einheitliche Häufigkeit für alle Verantwortlichen.

DORA. Art. 24 verlangt ein risikoorientiertes Programm zur Prüfung der digitalen operationalen Resilienz. TLPT ist dessen fortgeschrittener Bestandteil. Nach Art. 26 führen ausgewählte Finanzunternehmen unter Berücksichtigung der dort vorgesehenen Ausnahmen mindestens alle drei Jahre einen TLPT durch; die zuständige Behörde kann die Häufigkeit nach Risikoprofil und operativen Umständen anpassen.^[3] Auswahlkriterien und detaillierter Ablauf ergeben sich aus der Delegierten Verordnung (EU) 2025/1190.^[4] Nicht jede Bank, Versicherung oder sonstige DORA-pflichtige Einrichtung muss allein wegen der Anwendbarkeit von DORA automatisch einen TLPT durchführen.

PCI DSS. Für Einrichtungen, auf die PCI DSS anwendbar ist, ist v4.0.1 die aktuelle Fassung. Requirement 11.4 betrifft regelmäßige interne und externe Penetrationstests; 11.4.2 und 11.4.3 verlangen sie mindestens alle zwölf Monate und nach wesentlichen Änderungen der Infrastruktur oder Anwendung.^[13] PCI DSS ist ein Branchenstandard und kein allgemein geltendes polnisches Gesetz.

ISO/IEC 27001. Die Norm kann als Kriterium für ein Managementsystem für Informationssicherheit und als Referenz für ein Programm zur Wirksamkeitsbewertung von Kontrollen dienen. Eine Zertifizierung beweist jedoch nicht, dass eine bestimmte Anwendung einem konkreten Penetrationstest unterzogen wurde. Am 29. August 2026 ist ISO/IEC 27001:2022 einschließlich Amd 1:2024 weiterhin aktuell.^[16]

Auswahl des Dienstleisters

Es gibt kein einzelnes Zertifikat, dessen Besitz automatisch einen guten Penetrationstest garantiert. Bei der Auswahl eines Dienstleisters sollten insbesondere geprüft werden:

• Erfahrung der tatsächlich eingesetzten Tester mit der geprüften Technologie;
• vorgesehene Berichtsstruktur und Umgang mit Nachweisen;
• Verfahren zur Qualitätsprüfung;
• Umgang mit Kundendaten und Geheimnissen;
• Versicherung und vertragliche Haftung, soweit für das Projekt relevant;
• Eskalation kritischer Feststellungen während der Prüfung;
• Behandlung von Interessenkonflikten;
• Bedingungen des Retests und Löschung der Daten nach Projektende.

Unabhängigkeit muss im Kontext des Prüfungsziels bewertet werden. Es gibt kein allgemeines Verbot, wonach ein IT-Dienstleister niemals einen Penetrationstest durchführen dürfte. Soll seine eigene Implementierung unabhängig bewertet werden, spricht der Interessenkonflikt klar für einen anderen Prüfer. Bei TLPT gelten zusätzliche Anforderungen an externe und interne Tester aus DORA und der Delegierten Verordnung 2025/1190.^[3][4]

Häufige Fehler bei der Beschaffung

1. Schwachstellenscanning unter der Bezeichnung Penetrationstest einkaufen. Ein automatisch erzeugter Bericht kann im Vulnerability Management wertvoll sein, belegt aber keine manuelle Validierung, Prüfung der Geschäftslogik, Verkettung von Schwächen oder Verifikation der Auswirkung.
2. Ein zu großes Leistungsversprechen bei unklar definiertem Budget. "Penetrationstest der gesamten Infrastruktur" ohne Anzahl von Anwendungen, Segmenten, Hosts, Rollen, Schnittstellen und Ausschlüssen ist ein Slogan und kein Prüfungsumfang.
3. Die Erwartung einer bestimmten Anzahl von Feststellungen. Null kritische Schwachstellen beweisen weder hohe Sicherheit noch einen schlechten Tester. Entscheidend sind Abdeckung des Umfangs, geprüfte Hypothesen, Qualität der Nachweise, Einschränkungen und Reproduzierbarkeit.
4. Das Fehlen eines Retests. Ein Bericht beschreibt den Zustand während der Prüfung. Wurde die Behebung nicht verifiziert, weiß die Organisation nur, dass ihre Umsetzung erklärt wurde.
5. Die fehlende Verbindung zur Detektion. Betreibt die Organisation ein SOC oder SIEM, sind bekannte Aktionen des Testers besonders wertvolle Daten, um die tatsächliche Funktionsfähigkeit von Telemetrie und Detektionsregeln zu prüfen.

Was reale Daten zu Sicherheitsverletzungen zeigen

Der Verizon DBIR 2026 weist für seinen Datensatz die Ausnutzung von Schwachstellen bei 31% der bekannten initialen Zugriffsvektoren und den Missbrauch von Zugangsdaten bei 13% aus.^[19] Daraus folgt nicht, dass jeder Penetrationstest in erster Linie öffentliche CVEs prüfen sollte. Die Daten sprechen jedoch dagegen, ein Prüfprogramm ausschließlich auf Phishing oder Identitätskonfiguration zu beschränken.

Der ENISA Threat Landscape 2025 und der Jahresbericht von CERT Polska für 2025 zeigen ebenfalls, dass die Bedrohungslage von Sektor, Region und Art der Dienste abhängt.^[17][18] Bei bedrohungsorientierten Tests sind diese Quellen Ausgangsmaterial für Szenarien und keine fertige Angriffsliste, die ohne Kontext abgearbeitet werden sollte.

Fazit

Ein guter Penetrationstest ist weder ein Wettbewerb um die Zahl der CVEs noch eine Werkzeugdemonstration. Sein Wert entsteht durch eine präzise Fragestellung, einen sinnvoll begrenzten Umfang, die Kompetenz des Testers, hochwertige manuelle Validierung, reproduzierbare Nachweise und die Fähigkeit der Organisation, aus dem Ergebnis konkrete Maßnahmen abzuleiten.

Ein reifes Programm fragt nicht nur: "Haben wir dieses Jahr einen Penetrationstest durchgeführt?" Es fragt, welche Szenarien tatsächlich geprüft wurden, was außerhalb des Umfangs lag, welche Verteidigungsschichten funktioniert haben, welche versagt haben und ob Retests nachweisen, dass die wichtigsten Angriffspfade geschlossen wurden.