Penetrationstest: Der komplette Guide für Unternehmen [2026]

Ein Penetrationstest zeigt einem Unternehmen seine Systeme aus der Perspektive eines Angreifers, bevor ein echter Angreifer sie findet. Was ein Test leisten muss, wie Ablauf, Vertrag und Bericht aussehen und woran ein geeigneter Anbieter zu erkennen ist, war lange Auslegungssache.

Seit 2026 gibt es dafür eine gemeinsame Referenz der Branche: die Handreichung Penetrationstests des TeleTrusT (Bundesverband IT-Sicherheit e.V.). AWARE7 hat im TeleTrusT-Arbeitskreis PenTests an dieser Handreichung mitgearbeitet. Ihre Empfehlungen zu Vertrag, Bericht, Anbieterauswahl und Modulen sind in diesem Guide an den jeweiligen Stellen eingearbeitet und mit Seitenangabe als Quelle markiert.

Was ist ein Pentest?

Ein Penetrationstest (kurz: Pentest) ist ein organisierter, gezielter und genehmigter Angriffsversuch auf IT-Systeme mit dem Ziel, das IT-Sicherheitsniveau langfristig zu erhöhen. Dabei dringen ausgebildete Sicherheitsexperten, sogenannte White-Hat-Hacker oder ethische Hacker, kontrolliert in Netzwerke, Anwendungen oder Infrastrukturen ein, um Schwachstellen zu finden, bevor echte Angreifer sie ausnutzen können.

Das Ergebnis ist der Nachweis tatsächlicher Ausnutzbarkeit: Ein guter Pentest demonstriert, was ein Angreifer mit einer Schwachstelle anrichten könnte, etwa eine vollständige Systemübernahme oder den Zugriff auf Kundendaten.

Schwachstellenanalyse: Was ein Pentest leistet

Mit einem Penetrationstest lassen sich Schwachstellen in vernetzten Informationssystemen finden, analysieren und schließen: Konfigurationsfehler, fehlende Patches, unbekannte Sicherheitslücken. Die Ergebnisse werden in einem Report dokumentiert, der Findings nach Kritikalität priorisiert und konkrete Handlungsempfehlungen enthält.

Ein Pentest ist immer eine Momentaufnahme. Auch ein Test ohne Findings bedeutet nicht, dass ein System frei von Schwachstellen ist. Regelmäßige Untersuchungen helfen jedoch, das Sicherheitsniveau kontinuierlich zu steigern.

Wann sollten Unternehmen einen IT-Penetrationstest beauftragen?

• Regelmäßig, mindestens jährlich, Pflicht für ISO 27001 und NIS2
• Vor dem Launch neuer Anwendungen oder nach größeren Codeänderungen
• Nach Sicherheitsvorfällen (Post-Breach Assessment)
• Für Compliance-Anforderungen: PCI-DSS, BSI IT-Grundschutz, KRITIS, DORA
• Zur Kontrolle externer IT-Dienstleister
• Vor oder nach einer Zertifizierung

Rechtliche Grundlagen: Hackerparagraph § 202a StGB

Ein Penetrationstest ist juristisch ein beauftragter Angriff auf eigene Systeme. Der sogenannte „Hackerparagraph" (§§ 202a-202c StGB) stellt unbefugtes Eindringen in Computersysteme unter Strafe, auch für Pentester, wenn keine Genehmigung vorliegt. Nach § 202c StGB ist bereits das Vorbereiten des Ausspähens strafbar. Das Bundesverfassungsgericht hat klargestellt, dass dies nicht für Dienstleistungen gilt, die der Eigentümer oder Betreiber der Systeme selbst beauftragt (TeleTrusT-Handreichung 2026, S. 27).

Die Lösung ist eine schriftliche Genehmigungsvereinbarung (nach Unterzeichnung eines NDA), die explizit die Erlaubnis erteilt, die vereinbarten Systeme anzugreifen. Bei Cloud-Systemen müssen zusätzlich die Pentest-Richtlinien des Cloud-Anbieters beachtet werden: AWS erlaubt Tests auf EC2, RDS, CloudFront und anderen Diensten, verbietet aber DoS-Tests und Port-Flooding. Microsoft verlangt die Einhaltung seiner Rules of Engagement.

Was steht in der TeleTrusT-Handreichung Penetrationstests 2026?

Die Handreichung Penetrationstests 2026 ist ein Leitfaden des TeleTrusT (Bundesverband IT-Sicherheit e.V.) für Firmen, Behörden und Dienstleister, die Penetrationstests planen oder beauftragen. Erarbeitet hat sie der TeleTrusT-Arbeitskreis PenTests unter Leitung von Jan-Tilo Kirchhoff. Sie definiert, was einen Penetrationstest ausmacht, und liefert Vorlagen für Vertrag, Bericht, Anbieterauswahl und Ausschreibung.

Der Anlass ist ein Marktproblem: Penetrationstest ist kein geschützter Begriff. Entsprechend unterschiedlich fällt aus, was Anbieter unter diesem Namen liefern (Handreichung, S. 5). Die Handreichung soll ein gemeinsames Verständnis schaffen, ersetzt aber keine individuelle technische oder rechtliche Beratung. Zu den Autoren zählen Fachleute von secuvera, TÜV Informationstechnik, Deutsche Telekom MMS, itWatch und AWARE7 (Handreichung, S. 2).

Nach der Handreichung sind für jeden Penetrationstest acht Punkte festzulegen (S. 6):

1. ein definiertes Ziel
2. eine sinnvolle Informationsbasis
3. eine definierte Berechtigung
4. ein festgelegter Ausgangspunkt
5. ein definierter Zeitraum und Aufwand
6. ein bestimmter Zeitpunkt
7. dieselben technischen Methoden, die reale Angreifer nutzen
8. erwartbare Ergebnisse

Ein Penetrationstest ist eine Momentaufnahme und läuft zeitlich begrenzt („Time Boxed"). Das Auffinden bisher unbekannter Schwachstellen, sogenannter Zero-Days, gehört meist nicht zum Umfang (Handreichung, S. 7).

Die Handreichung ist als PDF bei TeleTrusT abrufbar: Handreichung Penetrationstests 2026.

Pentest vs. Vulnerability Scan vs. Red Teaming

Die drei Begriffe unterscheiden sich in Aufwand, Ergebnis und Aussagewert. Die TeleTrusT-Handreichung grenzt zusätzlich Vulnerability Assessment, Attack Surface Management, Audit und Threat-Led Penetration Testing ab (S. 8-9).

Schwachstellenscan

Ein Schwachstellenscan ist ein automatisierter Prozess. Werkzeuge wie Nessus, OpenVAS, Qualys oder Rapid7 InsightVM verbinden sich mit Systemen, prüfen Versionen und Konfigurationen gegen eine Datenbank bekannter Schwachstellen und liefern eine priorisierte Liste mit CVEs und CVSS-Scores.

Stärken: Schnell, kosteneffizient, gut skalierbar, ideal für kontinuierliche Baseline-Messung und wöchentliche Scans.

Schwächen: Viele False Positives (gemeldete Schwachstellen sind oft nicht ausnutzbar), viele False Negatives (Logikfehler und Authentifizierungsschwächen werden nicht erkannt), kein Angriffspfad, kein Business-Kontext.

Das Ergebnis ist eine Liste ohne Angriffspfad. Die TeleTrusT-Handreichung formuliert es deutlich: Eine rein automatisierte Schwachstellenanalyse mit generierten Berichten ist kein echter Penetrationstest (S. 8).

Penetration Testing: manuelle Expertenarbeit

Ein Penetrationstest ist manuelle Arbeit qualifizierter Experten, unterstützt durch Werkzeuge, aber gelenkt durch menschliches Urteilsvermögen. Was einen Pentest ausmacht:

• Exploitation statt nur Detektion: Der Pentester nutzt gefundene Schwachstellen wirklich aus und beweist damit ihre Ausnutzbarkeit.
• Kreative Kombination: Ein erfahrener Pentester kombiniert eine mittelschwere Schwachstelle mit einer schwachen Passwortkonfiguration und einer übermäßigen Berechtigung und gelangt so zu einer kritischen Ressource, die ein Scanner nie als gefährdet markiert hätte.
• Laterale Bewegung: Nach initialem Zugang versucht der Pentester, sich ins Netzwerk auszubreiten, genau wie ein echter Angreifer.
• Business-Kontext: Ein guter Pentest bewertet Risiken danach, was wirklich schützenswert ist.

Red Teaming

Red Teaming geht über den klassischen Pentest hinaus. Beim Red Teaming simuliert ein Team reale Angreifer, die möglichst unerkannt bleiben und gezielt nur eine einzige kritische Schwachstelle suchen, um ein definiertes Ziel zu erreichen. Der Unterschied: Red Teaming testet die Erkennungs- und Reaktionsfähigkeit des Sicherheitsteams, nicht die Vollständigkeit gefundener Lücken.

Mit einer Dauer von rund einem Monat (versus zwei Wochen beim Pentest) eignet sich Red Teaming vorrangig für Unternehmen, die Pentests bereits regelmäßig durchführen. Die TeleTrusT-Handreichung zieht die Grenze schärfer: „Wenn kein Blue Team vorhanden ist, braucht es kein Red Teaming." Regelmäßige Penetrationstests sollten vorher ein etablierter Prozess sein (S. 9). Details zum Vergleich: Red Team vs. Penetrationstest.

Vergleichsübersicht: Pentest vs. Vulnerability Scan

Arten von Penetrationstests: Black-Box-Test, White-Box-Test und Module

Penetrationstests unterscheiden sich nach Testziel und zusätzlich nach dem Informationsstand des Testers.

White-Box-Test, Gray Box oder Black Box?

Die drei Begriffe beschreiben, mit welchem Vorwissen ein Tester startet, und damit das Angreifermodell:

Black Box: Der Tester startet ohne Informationen und simuliert einen externen Angreifer ohne Vorwissen. Viel Zeit fließt in Reconnaissance, die Tiefe bleibt begrenzt. Sinnvoll, wenn die Frage lautet, wie wahrscheinlich ein unabhängiger Angreifer ohne Vorwissen erfolgreich ist.

Gray Box: Der Tester erhält Basisinformationen wie API-Dokumentation und einen Benutzeraccount, also das Modell eines Kunden oder Partners mit legitimem Zugang. Diese Balance aus Realismus und Effizienz führt in kürzerer Zeit zu mehr Findings, weshalb die meisten Tests mit einer solchen Informationsbasis laufen.

White Box: Der Tester erhält vollständige Informationen inklusive Quellcode und Architektur, das Modell eines Innentäters oder eines sehr gut vorbereiteten Angreifers. Größte Tiefe bei geringstem Aufwand, findet Schwachstellen, die Tests ohne Vorwissen übersehen. Ideal für Code Reviews und die Integration in einen sicheren SDLC.

Die TeleTrusT-Handreichung hält diese Einteilung für die Beschreibung von Angreifermodellen für sinnvoll, verzichtet für die Durchführung aber bewusst auf eine pauschale Einordnung. Es zählt, welche Informationsbasis für das jeweilige Testziel sinnvoll und effizient ist, und die kann je Modul unterschiedlich ausfallen (S. 6-7). Statt pauschal einen Gray-Box-Test zu bestellen, legt der Auftraggeber deshalb pro Modul fest, welche Zugänge, Testkonten und Unterlagen der Tester bekommt. Die Modultabelle unten nennt genau diese Angaben.

Pentest-Scope nach Modulen: Grundlage für die Ausschreibung

Die Handreichung definiert sieben Module, die sich direkt als Grundlage für eine Ausschreibung verwenden lassen (S. 35 und S. 37-47). Für jedes Modul nennt sie Ziel, Umfang, Abgrenzung und die Angaben, die ein Anbieter für ein belastbares Angebot braucht.

Zwei Hinweise aus den Modulen widersprechen verbreiteten Ausschreibungen. Erstens sind die OWASP Top 10 ein Sensibilisierungsdokument und kein Testkatalog. Als verbindliche Testvorgabe eignet sich der OWASP Web Security Testing Guide (WSTG) deutlich besser (S. 45-46). Zweitens sollten IDS, IPS und WAF für die Quelladressen der Tester deaktiviert werden, weil Penetrationstests effizient ablaufen sollen und damit „laut" sind (S. 37). Ob die Angriffserkennung anschlägt, ist eine eigene Frage: für interne Tests als optionale zweite Testphase mit aktivem IDS/IPS (S. 39), sonst als Red Teaming.

Testziele: Web Application Pentest, Netzwerk, Mobile, Cloud, OT

Web-Applikationen: Prüfung auf OWASP-Top-10-Schwachstellen wie SQL-Injection, Cross-Site-Scripting (XSS), IDOR, Server-Side Template Injection. Sowohl authentifizierte als auch unauthentifizierte Tests möglich. Produktionssystem bietet höchsten Realitätsbezug, Staging-System reduziert das Risiko von Ausfällen. Was ein solcher Test umfasst, steht auf der Seite Penetrationstest für Web-Applikationen.

Netzwerk und Infrastruktur: Interne Netzwerke (erfordert VPN-Zugang), DMZ mit öffentlich erreichbaren Servern, WLAN-Sicherheitstests, VoIP. Angreifer versuchen, sich lateral zu bewegen und auf sensitive Ressourcen wie Active Directory zuzugreifen. Umfang und Vorgehen beschreibt die Seite Penetrationstest der Netzwerk-Infrastruktur. Typische Angriffe auf das Verzeichnis beschreibt der Beitrag Active Directory Red Team.

Mobile Apps: iOS und Android, Prüfung auf unsichere Datenspeicherung, Kommunikation und Authentifizierung.

APIs: REST-APIs, GraphQL, SOAP sowie Mobile App Backends.

Cloud: AWS-, Azure- und GCP-Konfigurationen, Container-Umgebungen wie Kubernetes. Kein Infrastruktur-Test des Cloud-Anbieters selbst. Vertiefung: Cloud Penetrationstest.

OT/IoT: Industrielle Steueranlagen, vernetzte Geräte, von Gesundheitsanwendungen bis zu Küchengeräten. Erfordert spezialisiertes Know-how und erhöhte Tagessätze.

Authentifizierungsebenen: Ein unauthentifizierter Test zeigt, was ein externer Angreifer ohne Login sieht. Ein authentifizierter Test mit einem Benutzeraccount deckt Post-Login-Schwachstellen auf. Ein privilegierter Test mit Admin-Account zeigt, was ein Insider anrichten kann.

Der PTES-Standard und Ablauf eines Pentests

Der Penetration Testing Execution Standard (PTES) ist ein etabliertes Rahmenwerk für die Durchführung professioneller Penetrationstests. Er gliedert jeden Test in 7 Phasen und schafft damit Vergleichbarkeit zwischen Anbietern.

Phase 1: Pre-Engagement und Scoping

Scope-Definition, Vertragsabschluss, NDA, Genehmigungsvereinbarung. In dieser Phase wird festgelegt, welche Systeme getestet werden, welche ausgeschlossen sind, welcher Zeitraum gilt und wer die Notfallkontakte sind. Das Whitelisting der statischen IP-Adresse des Pentest-Anbieters erfolgt ebenfalls hier. Die TeleTrusT-Handreichung empfiehlt zusätzlich einen Verbindungstest (Dry Run) ein bis zwei Wochen vor dem eigentlichen Test (S. 35).

Phase 2: Intelligence Gathering (Informationsbeschaffung / OSINT)

Die OSINT-Phase sammelt öffentlich verfügbare Informationen über das Zielunternehmen. Automatisierte Tools beschleunigen die Recherche, die Ergebnisse werden von Experten bewertet. Auf Basis der gewonnenen Informationen lassen sich Passwortangriffe auf Mitarbeiter-Accounts vorbereiten.

Phase 3: Threat Modeling (Gefahrenanalyse)

Simulation eines Hackers: Welche Angriffswege sind realistisch? Welche Ziele sind für einen Angreifer besonders attraktiv? Die Ergebnisse werden organisiert und systematisch erfasst.

Phase 4: Vulnerability Analysis (Schwachstellenanalyse)

Kombination aus automatisierten Scans und manueller Prüfung. Nicht nur bekannte CVEs, sondern auch Logikfehler, Konfigurationsprobleme und anwendungsspezifische Schwachstellen. Ausgewählte Schwachstellen werden für die nächste Phase priorisiert.

Phase 5: Exploitation (Ausnutzung)

In dieser Phase wird der Proof-of-Concept erbracht: Der Pentester nutzt Schwachstellen tatsächlich aus und beweist ihre Wirksamkeit. „Mögliche RCE-Schwachstelle" wird zu „Wir haben Shell auf dem Server, hier ist der Screenshot."

Phase 6: Post-Exploitation und Lateral Movement

Nach erfolgreicher Kompromittierung: Ausweitung von Rechten, laterale Bewegung, Datenextraktion (ohne echten Schaden anzurichten). Diese Phase zeigt, welche Möglichkeiten ein Angreifer im internen Netz hätte, zum Beispiel Zugriff auf alle Kundendaten vom kompromittierten Workstation aus. Zum Abschluss gehört das Clean-up: Remote-Shells, Test-Accounts und andere Spuren werden entfernt, damit der Test kein Einfallstor zurücklässt (Handreichung, S. 36).

Phase 7: Reporting (Pentest-Bericht)

Alle Findings werden dokumentiert. Ein professioneller Pentest-Bericht enthält:

1. Management Summary: Risikoeinschätzung auf einer Seite, ohne Technikjargon. Für die Geschäftsleitung verständlich, ohne technisches Vorwissen zu erfordern.
2. Technische Findings: Jede Schwachstelle mit CVSS-Score, Nachweis (Screenshot, PoC), Risikobewertung und konkreter Handlungsempfehlung. Der Nachweis verwandelt „mögliche RCE-Schwachstelle" in „Wir haben Shell auf dem Server, hier ist der Screenshot."
3. Angriffspfade: Visualisierung: Wie wäre ein Angreifer vorgegangen? Nicht "System X hat Schwachstelle Y", sondern "Von Workstation A konnten wir in zwei Stunden auf Active Directory und alle Kundendaten zugreifen."
4. Priorisierung: Kritisch/Hoch/Mittel/Niedrig mit Empfehlung nach Aufwand/Wirkung.
5. Compliance-Mapping: Welche Findings adressieren welche regulatorischen Anforderungen (NIS2, PCI DSS, ISO 27001, DSGVO)
6. Retest-Angebot: Verifizierung der Behebung

Mindestanforderungen an den Pentest-Report nach TeleTrusT

Ein Scanner-Output mit Logo ist kein Pentest-Bericht. Ein professioneller Bericht enthält ausschließlich manuell verifizierte Findings, keine automatisch generierten False-Positive-Listen. Jedes Finding hat einen klaren Beweis (Screenshot, HTTP-Request/Response, PoC-Code) und eine Handlungsempfehlung, die ein Entwickler direkt umsetzen kann.

Die TeleTrusT-Handreichung nennt den Bericht das wichtigste Element des gesamten Auftrags und legt Mindestanforderungen fest (S. 30-32):

• Format: PDF, weil unveränderbar. Optional eine Präsentation für die Abschlussbesprechung. Soll ein Ticketsystem befüllt werden, wird das maschinenlesbare Format vorab festgelegt.
• Management Summary: Wer hat was, wann und wo getestet, die kritischsten Schwachstellen, eine qualitative Bewertung und priorisierte Maßnahmen. Technische Details auf ein Minimum reduziert.
• Übersicht der Schwachstellen: Tabelle nach Kritikalität mit ID, Risikoeinstufung, Kapitel, Seite und Bezeichnung, ergänzt um eine grafische Verteilung.
• Testplan und Methodik: Zeitplan, Umfang, Testbedingungen und die angewandte Methodik, orientiert an anerkannten Standards wie den OWASP Testing Guides.
• Je Schwachstelle: Beschreibung mit betroffenen Komponenten, Auswirkung, reproduzierbarer Proof-of-Concept mit Screenshots, Logs und Tool-Version, Bewertung nach CVSS, EPSS oder eigenen Kategorien, Empfehlung.
• Rohdaten: Logs, Scan-Ergebnisse und Debug-Ausgaben gehören nicht in den Bericht, sondern in einen separaten, zeitlich begrenzt vorgehaltenen Anhang.

Zwei Punkte werden in der Praxis oft übersehen. Der Bericht ist eine Mängelbeschreibung: Testfälle ohne Auffälligkeiten tauchen nicht auf. Wer eine vollständige Dokumentation aller Prüfungen braucht, etwa für ein Audit, muss das beim Scoping vereinbaren (S. 14). Und die Schweregrad-Einstufung des Anbieters entbindet den Auftraggeber nicht von einer eigenen Bewertung nach seinem Schutzbedarf (S. 30).

Ein anonymisierter Beispielbericht vor der Beauftragung zeigt Qualität und Tiefe der Dokumentation besser als jede Referenzliste.

Scope und Rules of Engagement: Entscheidungen vor dem Pentest

Der Scope bestimmt, was getestet wird und was nicht. Zu breit bedeutet hohe Kosten bei geringer Tiefe. Zu eng bedeutet, dass reale Angriffspfade außerhalb des Scopes liegen und unentdeckt bleiben.

Was in den Scope gehört. Ein Scope-Dokument muss folgende Punkte festhalten:

• Alle IP-Ranges und Domains im Scope
• Explizit ausgeschlossene Bereiche (z.B. Produktionsdatenbank, bestimmte Drittsysteme)
• Testzeitraum mit Datum und Uhrzeit
• Notfallkontakte auf beiden Seiten

Fehler vermeiden: Viele Unternehmen testen aus Kostengründen nur das Frontend, nicht die zugehörige API. Angreifer nutzen genau die nicht getestete API. Wenn das Frontend auf eine REST-API angewiesen ist, gehört die API zwingend in den Scope.

Produktionssystem oder Staging-Umgebung?

Diese Entscheidung hat keine universell richtige Antwort.

Produktionssystem: Höchster Realitätsbezug. Fehlkonfigurationen, die nur in Produktion existieren, werden gefunden. Reaktionsschwächen des IT-Teams werden sichtbar. Risiko: Ausfall oder Datenbeschädigung möglich, umso wichtiger sind vollständige Backups vor Testbeginn und der Verzicht auf DoS-Angriffe bei laufendem Betrieb.

Staging-Umgebung: Kein Risiko für den Betrieb. Risiko: Nur sinnvoll, wenn die Staging-Umgebung wirklich produktionsgleich ist: gleicher Code, gleiche Konfiguration, gleiche Datenbankstruktur. Eine abgespeckte Staging-Umgebung liefert kein realistisches Bild. Die TeleTrusT-Handreichung verlangt dafür ausdrücklich, dass die Konfiguration der Prüfobjekte mit dem Produktivsystem übereinstimmt, und empfiehlt anonymisierte oder pseudonymisierte Testdaten in den Datenbanken (S. 14).

Empfehlung für den ersten Test: Staging, wenn wirklich produktionsgleich konfiguriert. Sonst Produktion mit engem Scope und ausgeschlossenen kritischen Operationen (kein Löschen von Daten, kein DoS).

AWS-Pentest und Azure: Cloud-spezifische Scope-Regeln

Cloud-Provider haben eigene Pentest-Richtlinien, die vor Testbeginn bekannt sein müssen:

AWS: Tests auf EC2, RDS, Aurora, API Gateway, CloudFront und anderen Diensten sind ohne Vorab-Genehmigung erlaubt. Verboten sind DNS-Zone-Walking über Route 53, DoS- und DDoS-Tests und Port-Flooding. Tests mit Command-and-Control-Infrastruktur brauchen eine Genehmigung (AWS Penetration Testing Policy).

Azure: Seit dem 15.06.2017 verlangt Microsoft keine Vorab-Genehmigung mehr. Verbindlich sind die Microsoft Cloud Unified Penetration Testing Rules of Engagement (Microsoft Learn).

Bei Multi-Cloud-Setups gelten die Richtlinien aller beteiligten Provider, das Scope-Dokument muss dies explizit berücksichtigen.

Ethical Hacking: Regeln für den Tester

Ethisches Hacking beschreibt eine Grundhaltung, ein Penetrationstest eine Tätigkeit. Ein Pentest braucht beides. In der Praxis heißt das: ausschließlich mit schriftlicher Erlaubnis arbeiten, jeden Schritt gegenüber dem Auftraggeber dokumentieren, die Risiken der eingesetzten Werkzeuge kennen und kritische Findings wie einen Zugriff auf Produktionsdaten sofort eskalieren. Fehler beim Test können neue Schwachstellen erzeugen statt bestehende zu schließen.

Das BSI hat mit dem Praxis-Leitfaden IS-Penetrationstest und dem Durchführungskonzept für Penetrationstests zwei Dokumente veröffentlicht, an denen sich professionelle Anbieter orientieren. Die TeleTrusT-Handreichung 2026 baut auf beiden auf (S. 5 und S. 35).

Rechtliche Absicherung: Der Pentest-Vertrag

Ein Penetrationstest ist juristisch ein beauftragter Angriff. Wesentlicher Bestandteil des Vertrags ist laut TeleTrusT-Handreichung der Scope sowie die Klärung, welche Rechte der Auftraggeber und etwaige Dritte an den zu prüfenden Systemen und Daten haben (S. 27). Ein professioneller Pentest-Vertrag regelt mindestens acht Punkte:

1. Scope-Definition mit allen IP-Ranges und Domains, keine mündliche Absprache, alles schriftlich
2. Testzeitraum mit genauem Datum und Uhrzeit, kein Überraschungsmoment für das IT-Team
3. Emergency-Stop-Verfahren: wie wird der Test sofort gestoppt, wenn etwas schiefläuft? Wer ruft wen an?
4. Haftungsausschluss: was passiert, wenn ein System während des Tests ausfällt? Die Grenzen der Haftung des Testers müssen klar definiert sein
5. Vertraulichkeit / NDA: der Pentest-Bericht enthält eine vollständige Anleitung zum Eindringen in die getesteten Systeme. Er ist hochsensibel und muss entsprechend behandelt werden
6. Datenverarbeitung: verarbeitet der Dienstleister personenbezogene Daten (z.B. aus einem Datenbankdump als Exploit-Nachweis)? Dann greifen DSGVO-Pflichten: Auftragsverarbeitungsvertrag (AVV) nötig
7. Bericht-Eigentumsrechte: die Rechte an Ergebnissen und Bericht gehen auf den Auftraggeber über, allerdings nur für den vereinbarten Verwendungszweck. Eine weitergehende Verwertung, etwa das Einreichen gefundener Schwachstellen bei Bug-Bounty-Programmen, muss gesondert geregelt werden (Handreichung, S. 27)
8. Aufbewahrungspflichten des Dienstleisters: wie lange darf der Anbieter Informationen über die gefundenen Schwachstellen aufbewahren?

Die Handreichung ergänzt diese Liste um den Zeitplan, einen Prozess für Vertragsänderungen, die Testtiefe (werden Schwachstellen nur dokumentiert oder auch ausgenutzt), die Meldung von Sicherheitslücken an Dritte und das Kommerzielle: pauschal oder nach Zeit, Nebenkosten, Reisekosten (S. 27-28).

Werkvertrag oder Dienstvertrag?

Beide Vertragstypen kommen vor. Die Handreichung beschreibt den Unterschied so (S. 28):

Welche Variante gilt, gehört ausdrücklich in den Vertrag. Ein Time-Boxed-Test mit explorativem Ansatz passt eher zum Dienstvertrag, ein klar umrissenes Modul mit definiertem Berichtsumfang eher zum Werkvertrag.

NDA, AVV und Haftungsfreistellung

Geheimhaltung: Die Handreichung empfiehlt ein mNDA (mutual Non-Disclosure Agreement), das die Vertraulichkeit für beide Seiten wechselseitig regelt. Je nach Sensibilität wird es bereits bei der ersten Kontaktaufnahme geschlossen (S. 28). Ein Responsible-Disclosure-Verfahren für gefundene Herstellerschwachstellen ersetzt diese Verschwiegenheitsregelung nicht (S. 49).

Auftragsverarbeitung: Ein Penetrationstest ist nicht automatisch eine Auftragsverarbeitung. Ein AVV nach Art. 28 DSGVO wird nötig, wenn produktive Systeme mit Echtdaten im Scope sind, besondere Kategorien nach Art. 9 DSGVO wie Gesundheitsdaten betroffen sind oder der Anbieter angewiesen ist, Daten zu dokumentieren (S. 28-29).

Haftungsfreistellung: Der Auftraggeber sollte den Anbieter von Schäden freistellen, die durch die Durchführung des Tests entstehen, außer bei Vorsatz oder grober Fahrlässigkeit. Das gilt auch, wenn im Scope Systeme liegen, die einem Dritten gehören. Diese Klärung kann nur der Auftraggeber verbindlich vornehmen. Aus der Schweregrad-Einstufung des Anbieters lassen sich keine Haftungsansprüche ableiten (S. 29-30).

Eskalationsmanagement bei kritischen Findings

Ein guter Anbieter informiert den Auftraggeber nicht erst im Schlussbericht über kritische Findings. Folgende Situationen erfordern sofortige Eskalation noch während des Tests:

• Zugriff auf Produktionsdaten oder personenbezogene Daten (DSGVO-Relevanz)
• Vollständige Übernahme eines kritischen Systems
• Möglichkeit zur Datenexfiltration großer Mengen von Kundendaten
• Entdeckung von Anzeichen eines laufenden echten Angriffs im System

Diese Eskalationspfade (wer informiert wen, auf welchem Kanal, wie schnell) müssen vor Testbeginn schriftlich vereinbart sein.

Was kostet ein Pentest?

Der Preis hängt von Scope, Testtiefe, Qualifikation der Tester und dem notwendigen Know-how ab.

Pentest-Kosten in Deutschland (2026)

Typische Projekte liegen zwischen 3.000 € (kleine Web-Applikation, externer Netzwerk-Pentest) und 50.000 € (komplexe Anwendungen mit vielen Schnittstellen); Red-Team-Assessments beginnen bei 25.000 €. Detaillierte Preisspannen nach Testgegenstand und einen Festpreis-Rechner bietet die Seite Penetrationstest-Kosten.

Von einem Penetrationstest kann ab dem Einsatz von mindestens zwei Testtagen ausgegangen werden. Bei branchenüblichen Tagessätzen ab 1.000 EUR sind Kosten von mindestens 2.000 EUR netto einzuplanen. Spezialisierte Pentester für seltene Programmiersprachen, kritische Steuer- und Industrieanlagen oder Tests auf Live-Systemen können Tagessätze von bis zu 1.800 EUR erreichen.

Preisfaktoren: Penetration Testing Kosten im Detail

• Scope: Größe und Komplexität der zu testenden Systeme
• Kritikalität der Daten: Systeme, deren Ausfall oder Kompromittierung existenzbedrohend wäre, erfordern ein höheres Testbudget
• Testtiefe: automatisiert unterstützt vs. vollständig manuell
• Qualifikation der Tester: zertifizierte Experten mit nachweisbarer Erfahrung
• Retest: Verifizierung behobener Findings inklusive oder separat berechnet
• Zeitrahmen: Expresslieferung kostet mehr

Ein Angebot sollte laut TeleTrusT-Handreichung mindestens vier Dinge enthalten: die projektspezifische Zielsetzung, die Leistungsbestandteile mit Vorgehensweise, die Qualifikation des eingesetzten Personals und den Einsatzort (S. 24). Diese vier Punkte gehören in jedes Angebot, bevor ein Unternehmen einen Penetrationstest beauftragt. Die Vertragsbedingungen sollten zusätzlich über Haftung, Versicherungssummen, Verantwortungsbereiche und Unterauftragnehmer aufklären.

Pentest as a Service vs. einmaliger Pentest

Einmaliger Pentest. Der klassische Pentest ist ein zeitlich begrenztes Projekt: Scope-Definition, Durchführung, Bericht, Retest. Mindestens einmal jährlich ist für ISO 27001 und NIS2 der Standard.

PTaaS: Pentest im Abonnement

Pentest as a Service löst den klassischen Einmal-Jahres-Pentest durch monatliche oder quartalsweise Sicherheitstests ab. Das Modell passt zu Unternehmen, die Software oder digitale Produkte entwickeln und laufend testen müssen.

Wann was wählen: Penetration Testing as a Service oder Einzeltest

Einmaliger Pentest wenn: Budget begrenzt ist, erstmalig getestet wird, ein konkreter Anlass besteht (Launch, Compliance-Audit), die Infrastruktur sich selten ändert.

Pentest as a Service wenn: Continuous Development stattfindet, regulatorische Anforderungen häufige Tests fordern, Software-Sicherheit ein permanentes Qualitätskriterium ist, das interne Know-how für kontinuierliches Security-Testing fehlt.

Automatisierter Pentest: Möglichkeiten und Grenzen

Was Pentest-Tools leisten

Pentest-Tools sind eine willkommene Arbeitserleichterung. Bei der Informationsbeschaffung (OSINT), beim Portscanning (nmap), beim Schwachstellenscan (Nessus, OpenVAS) und bei der Verwaltung von Exploits (Metasploit Framework) beschleunigen automatisierte Werkzeuge die Arbeit erheblich.

Grenzen von Automated Penetration Testing und KI

Die vollautomatisierte Durchführung eines Penetrationstests ist keinem Anbieter zuverlässig gelungen. Die hohe Anzahl an False Positives macht es schwierig, korrekte Erkenntnisse abzuleiten. Entscheidender: Automatisierte Tools können nicht auf unerwartete Ereignisse oder individuelle Konfigurationen reagieren, keine kreativen Angriffspfade durch Kombination mehrerer Schwachstellen entwickeln und keine Bewertung im Business-Kontext vornehmen.

Für Compliance-relevante Anforderungen durch externe Stellen sind automatisierte Tools per Definition nicht ausreichend.

Das gilt auch für KI. Die TeleTrusT-Handreichung sieht den Nutzen von KI in der Analyse von Scan-Ergebnissen, Logs und Konfigurationsdaten und in der Automatisierung wiederkehrender Prüfungen, also als Assistenz für erfahrene Tester. Als Risiken nennt sie fehlende Erklärbarkeit, False Positives und False Negatives, unbeabsichtigte Auswirkungen auf das Testobjekt und den Abfluss vertraulicher Daten an Cloud-KI-Anbieter. Ihr Fazit: Ein rein KI-gestützter Ansatz widerspricht dem Charakter eines Penetrationstests (S. 22-24).

Den richtigen Pentest-Anbieter finden

Eine Marktübersicht mit Anbieter-Typen, Auswahlkriterien und dem Verweis auf die BSI-Liste zertifizierter IT-Sicherheitsdienstleister: Penetrationstest-Anbieter in Deutschland.

Pentest-Zertifizierung: Unternehmens- und Personenzertifikate

Die TeleTrusT-Handreichung unterscheidet Unternehmens- und Personenzertifikate (S. 15-16). Auf Unternehmensebene nennt sie drei dienstleistungsbezogene Nachweise:

• BSI IT-Sicherheitsdienstleister: Das Zertifikat bescheinigt Risikomanagement, Qualitätssicherung, Personalqualifikation und Vorfallsbehandlung. Jeder zertifizierte Anbieter muss mindestens zwei Penetrationstester mit Kompetenzfeststellung durch das BSI beschäftigen.
• CREST: International anerkannte Akkreditierung für Unternehmen, im deutschsprachigen Raum aber nicht weit verbreitet.
• ISO/IEC 17025: Akkreditierung für Prüflaboratorien. Auf Penetrationstests angewandt bestätigt sie qualifiziertes Personal, validierte Verfahren und reproduzierbare Ergebnisse.

Ob der Anbieter selbst ein ISMS nach ISO/IEC 27001 oder BSI IT-Grundschutz betreibt, ist ein eigenes Kriterium und wird je nach Compliance-Anforderung des Auftraggebers relevant. Personenzertifikate sind laut Handreichung Indikatoren, deren Qualität, Tiefe und Praxisrelevanz schwanken. Das BSI führt eine Liste anerkannter Personenzertifikate für Penetrationstester. Nicht alle Pentest-Zertifizierungen sind gleichwertig:

OSCP (OffSec Certified Professional): Eine 24-Stunden-Prüfung ohne Multiple Choice (OffSec PEN-200). Jeder OSCP hat aktiv Systeme gehackt, diese Zertifizierung ist die anerkannte Grundqualifikation im Markt.

OSCE3 (OffSec Experienced Penetration Tester): Ein fortgeschrittenes Bundle aus OSEP, OSED und OSWE. Sehr selten, sehr hohes Niveau.

CREST (Council of Registered Ethical Security Testers): UK-zentriert, sowohl als Personen- als auch als Unternehmensakkreditierung, in Deutschland selten nachgefragt.

CEH (Certified Ethical Hacker): Multiple-Choice-basiert, weniger angesehen. Kein Nachweis praktischer Fähigkeiten.

GPEN (GIAC Penetration Tester): Multiple Choice mit praktischer Prüfung, anerkannt besonders in den USA.

Fragen an den Pentest-Dienstleister

• „Welche Zertifizierungen haben Ihre Tester?"
• „Wer führt den Test durch, nicht wer verkauft ihn?"
• „Wie viele Pentests hat dieser Tester in den letzten 12 Monaten gemacht?"
• „Haben Sie Erfahrung mit unserer spezifischen Technologie (Java/Rails/Azure)?"
• „Können Sie einen anonymisierten Beispielbericht zeigen?"

Statische IP-Adresse als Qualitätsmerkmal

Wer professionelle Penetrationstests anbietet, sollte über eine oder mehrere offizielle, statische IP-Adressen verfügen. Eine dynamische IP-Adresse wechselt und lässt sich im Monitoring nicht zuverlässig unterscheiden, weder von echten Angreifern noch für das Whitelisting.

Statische IP-Adressen sind in der RIPE-Datenbank eingetragen. Mit der RIPE Database Text Search lässt sich verifizieren, ob eine angegebene IP-Adresse einem Unternehmen gehört. Diese Überprüfung kostet nichts und zeigt, ob ein Anbieter professionelle Infrastruktur betreibt.

Entscheidungsmatrix und Ausschlusskriterien nach TeleTrusT

Für die Bewertung mehrerer Angebote schlägt die Handreichung eine gewichtete Matrix vor (S. 25-26). Sie taugt direkt als Bewertungsbogen, wenn ein Unternehmen einen Penetrationstest beauftragen will:

Vor der Bewertung stehen Ausschlusskriterien. Fehlt eines davon, fällt das Angebot raus: Datenschutzerklärung und technisch-organisatorische Maßnahmen liegen vor, ein NDA ist unterschrieben, der Datenaustausch läuft verschlüsselt, die Erreichbarkeit im Testzeitraum ist zugesichert, es arbeitet ausschließlich festangestelltes Personal und je Modul stehen mindestens zwei Tester zur Verfügung (S. 26).

Drei weitere Einschätzungen der Handreichung helfen bei der Auswahl. Branchenkenntnis spielt nach Ansicht der Autoren eine nachgeordnete Rolle, weil sich Netzwerke, Systeme und Anwendungen zwischen Branchen kaum unterscheiden (S. 17). Ein Interessenkonflikt droht, wenn derselbe Anbieter Schwachstellen findet, behebt und anschließend die Wirksamkeit prüft (S. 18). Und nach einem Sicherheitsvorfall sollte im Idealfall ein anderer Dienstleister testen als der, der den Vorfall bearbeitet hat, damit sich kein Dienstleister selbst überprüft (S. 35). Eine Checkliste für kleinere Unternehmen liefert der Beitrag Pentest-Anbieter auswählen.

Warnsignale beim Penetration Testing Service

• „Wir nutzen nur automatische Tools": kein manueller Test
• Keine anonymisierten Beispielberichte verfügbar
• Tester haben keine nachweisbaren Zertifizierungen
• Preis unter 3.000 € für einen Web-App-Pentest
• Kein NDA und keine Vertraulichkeitsvereinbarung
• Ergebnisse innerhalb von 24 Stunden, zu schnell für Qualitätsarbeit
• Anbieter macht Versprechen wie „100% sicher nach Test"

Weitere Prüfpunkte vor der Beauftragung:

• Welche Rechtsform hat das Unternehmen? (Impressum prüfen)
• Besitzt der Anbieter eine gültige Haftpflichtversicherung?
• Gibt es anonymisierte oder öffentliche Referenzen?
• Ist der Anbieter als Vollunternehmen tätig oder im Neben-/Kleingewerbe?
• Läuft die Kommunikation verschlüsselt (PGP oder S/MIME, verschlüsselter Datenraum für den Bericht)?
• Gibt es einen vordefinierten Eskalationsweg und eine Regelung für Responsible Disclosure (Handreichung, S. 18-19)?

Pentest-Pflicht: NIS2, DORA, Cyber Resilience Act, ISO 27001, DSGVO

Für eine Reihe von Unternehmen sind Penetrationstests regulatorisch vorgeschrieben oder werden für Zertifizierungen benötigt. Die TeleTrusT-Handreichung fasst die Lage so zusammen: Penetrationstests „gelten dabei häufig als Best Practice, um Sicherheitsanforderungen nachvollziehbar umzusetzen und zu dokumentieren". Wer nach branchenspezifischen oder internationalen Standards arbeitet, kommt um regelmäßige Tests kaum herum (S. 11-12).

ISO 27001 Pentest: Anhang A 8.8, 5.35 und 5.36

Die ISO/IEC 27001:2022 listet in Anhang A Maßnahmen auf, die die Informationssicherheit einer Organisation steigern sollen. Drei davon sind besonders relevant für Penetrationstests:

• A.8.8: Handhabung technischer Schwachstellen
• A.5.35: Unabhängige Überprüfung der Informationssicherheit
• A.5.36: Einhaltung von Richtlinien, Vorschriften und Normen für die Informationssicherheit

Ein professioneller Pentest unterstützt die Umsetzung aller drei Anforderungen. Neue Systeme sollten stets vor dem Produktiveinsatz getestet werden. Die TeleTrusT-Handreichung stuft Penetrationstests als zwingend ein, wenn ein Unternehmen nach ISO 27001 zertifiziert ist oder sich zertifizieren will (S. 12). Wie ein ISMS aufgebaut wird, beschreibt die Seite ISO 27001 Beratung und Zertifizierungsbegleitung.

NIS2 Pentest: Art. 21 und Erwägungsgrund 86

NIS2 (Art. 21 Abs. 2 lit. f) fordert Konzepte und Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen. Penetrationstests gelten als anerkannte Methode, diese Anforderung zu erfüllen. Erwägungsgrund 86 der Richtlinie verlangt von wesentlichen und wichtigen Einrichtungen zudem erhöhte Sorgfalt bei der Auswahl von Dienstleistern für Penetrationstests, weil diese tief in die Systeme eingebunden sind.

PCI DSS Pentest: Requirement 11.4

PCI DSS v4.0 (Req. 11.4) stellt eine explizite Anforderung an jährliche Penetrationstests für alle Unternehmen, die Kreditkartendaten verarbeiten.

DORA TLPT: Threat-Led Penetration Testing alle drei Jahre

DORA (Digital Operational Resilience Act) verlangt von regulierten Finanzunternehmen Schwachstellen- und Penetrationstests (Art. 25) und von den dafür bestimmten Instituten Threat-Led Penetration Testing (TLPT) mindestens alle drei Jahre auf Live-Produktionssystemen (Art. 26). Art. 27 legt die Anforderungen an die Tester fest. Nach Lesart der TeleTrusT-Handreichung muss jeder dritte Test durch einen externen Tester erfolgen, bedeutende Kreditinstitute müssen immer externe Tester einsetzen. In der Praxis verlangt die BaFin regelmäßig einen Nachweis über durchgeführte Penetrationstests (S. 12).

DSGVO Pentest: Art. 32 als technische Maßnahme

Die DSGVO verpflichtet Verarbeiter personenbezogener Daten in Art. 32 zu angemessenen technischen und organisatorischen Maßnahmen. Erwägungsgrund 83 nennt die regelmäßige Prüfung der Systeme auf Schwachstellen. Ein Penetrationstest kann eine solche Maßnahme sein. Die Handreichung ordnet ein: kein Pflicht-Penetrationstest, aber sinnvoll bei Datenpannen oder Prüfungen (S. 11).

TISAX und Cyber Resilience Act

Der Cyber Resilience Act (CRA) verpflichtet Hersteller von Produkten mit digitalen Elementen zu Cybersicherheitsmaßnahmen über den gesamten Lebenszyklus. Für Produkte der Risikoklassen I und II nennt die Handreichung Penetrationstests und Code-Analysen als unerlässliche Sicherheitsprüfungen. Einen ausdrücklichen Testzwang enthält der CRA nicht, faktisch sind Tests aber notwendig, um die Anforderungen revisionssicher nachzuweisen (S. 12). Bei TISAX in der Automobilindustrie müssen Teilnehmer die Angemessenheit ihrer Sicherheitsmaßnahmen nachweisen. Penetrationstests sind hier laut Handreichung „Best Practice, wenn nicht sogar Voraussetzung" (S. 12).

Cyberversicherung: Pentest als Bedingung

Cyber-Versicherer können regelmäßige Penetrationstests zur Voraussetzung für Deckung oder günstigere Prämien machen. Die genauen Anforderungen gehören vor Vertragsabschluss mit dem Versicherer geklärt.

Pentest-Checkliste: Penetrationstest beauftragen

Vor dem Test

• Scope präzise definiert (IP-Ranges, Domains, ausgeschlossene Bereiche)
• Testzeitraum mit Datum und Uhrzeit festgelegt
• Angreifermodell benannt: extern ohne Vorwissen, Kunde oder Partner mit Zugang, Innentäter
• Informationsbasis pro Modul festgelegt (Zugänge, Testkonten, Unterlagen) statt pauschal Black, Gray oder White Box (Handreichung S. 6-7)
• Testaccounts pro Rolle und Berechtigung sowie API- und Architekturdokumentation bereitgestellt, soweit das Modul sie braucht
• Staging vs. Produktion entschieden und begründet
• Backups aller Systeme erstellt
• IT-Team informiert (kein Phishing-Simulationstest), überraschte Admins können den Test blockieren
• Whitelisting der Tester-Adressen in IDS, IPS und WAF geklärt
• Verbindungstest (Dry Run) ein bis zwei Wochen vor Testbeginn terminiert
• Zentraler Ansprechpartner und Notfallplan benannt

Anbieterauswahl

• Tester haben nachweisbare Zertifizierungen (OSCP als Minimum)
• Anonymisierter Beispielbericht auf Anfrage verfügbar
• Anbieter verfügt über statische IP-Adresse (in RIPE-Datenbank verifizierbar)
• Gültige Haftpflichtversicherung bestätigt
• Wechselseitiges NDA (mNDA) unterschrieben, AVV-Bedarf geprüft, Haftungsfreistellung geregelt
• Werkvertrag oder Dienstvertrag im Vertrag benannt
• Nur festangestelltes Personal, mindestens zwei Tester je Modul
• Schriftliche Beauftragung mit Emergency-Stop-Verfahren und Haftungsausschluss
• Retest bei kritischen und hohen Findings inklusive oder Preis bekannt
• Dedizierter Ansprechpartner während des Tests, kein Callcenter
• Bericht auf Deutsch lieferbar falls nötig
• CVSS-Bewertung aller Findings im Bericht zugesagt
• Priorisierter Maßnahmenplan im Bericht enthalten

Während des Tests

• Ansprechpartner rund um die Uhr erreichbar, bei kritischem Fund ist sofortiges Handeln gefragt
• Monitoring läuft weiter (nicht pausieren)
• IT-Team lässt Tester arbeiten ohne echte Security Response auszulösen

Nach dem Test

• Mindestens eine Stunde für Bericht-Durchsprache eingeplant
• Maßnahmenplan erstellt mit klaren Verantwortlichkeiten und Fristen
• Retest terminiert zur Verifizierung der Behebungen
• Bericht sicher archiviert (enthält hochsensible Informationen)

Häufige Fehler beim Pentest beauftragen

Fehler 1: Pentest nur für Compliance. Findings werden nicht ernst genommen, beim nächsten Test tauchen dieselben Schwachstellen wieder auf.

Fehler 2: Scope zu klein aus Kostengründen. Nur das Frontend wird getestet, nicht die API. Angreifer nutzen genau die nicht getestete API.

Fehler 3: Den billigsten Anbieter wählen. Das Ergebnis ist oft ein automatischer Scanner-Output mit Logo, kein echter Pentest.

Fehler 4: Kein Retest. „Wir haben es behoben", aber wurde es verifiziert? Häufig ist der Fix falsch implementiert.

Fehler 5: Das IT-Team nicht informiert. IDS oder Firewall sperrt die IP des Testers. Das Unternehmen hält sich für sicher, weil „kein Angriff" erkannt wurde. Das Ergebnis ist nicht repräsentativ.

Fehler 6: Zu selten testen. Ein jährlicher Pentest ist gut. Ein Major Release ohne Test ist riskant.

Nach dem Pentest: Remediation und Retest

Mit dem Bericht beginnt die Behebung. Drei Schritte gehören dazu: auswerten, priorisieren, nachprüfen.

Berichtsauswertung am Beispiel: Im Webinar zur Pentest-Report-Analyse mit Vincent Heinen geht es darum, Findings einzuordnen und daraus einen Maßnahmenplan abzuleiten. Auf der Webinarseite finden Sie den Termin und weitere Informationen.

CVSS-Bewertung und Angriffspfade: den Bericht auswerten

Für die Durchsprache des Berichts mit dem Pentest-Team gehört mindestens eine Stunde eingeplant. Ziel ist das Verstehen der Angriffspfade und der Prioritäten:

• Welche Findings sind kritisch für den eigenen Business-Kontext?
• Welche Behebungen blockieren andere (Abhängigkeiten)?
• Welche Findings lassen sich kurzfristig mit einem Workaround mitigieren, während die eigentliche Behebung mehr Zeit braucht?

Maßnahmenplan erstellen

Jedes Finding braucht: einen verantwortlichen Eigentümer, eine Frist und einen definierten Done-Status. Ohne klare Verantwortlichkeiten passiert nichts, „das IT-Team kümmert sich" ist keine Zuweisung.

Priorisierung nach Risiko und Aufwand:

• Kritisch und schnell behebbar: sofort, innerhalb weniger Tage
• Kritisch, hoher Aufwand: Interim-Workaround sofort, vollständige Behebung mit Frist
• Mittel/Niedrig: in regulären Sprint oder Release-Zyklus eintakten

Den Bericht sicher aufbewahren. Ein Pentest-Bericht enthält eine vollständige Anleitung zum Einbruch in die eigenen Systeme, mit Beweisscreenshots und funktionierendem PoC-Code. Er gehört zu den sensibelsten Dokumenten im Unternehmen:

• Verschlüsselt speichern, Zugriff auf Need-to-know beschränken
• Nicht per unverschlüsselter E-Mail versenden
• Aufbewahrung nach Behebung aller Findings überdenken: wer Berichte als Compliance-Nachweis archiviert, sollte den Zugriff protokollieren

Retest: Verifizierung ist Pflicht

"Wir haben es behoben" ist keine ausreichende Aussage. Häufig ist ein Fix zwar implementiert, aber falsch: der ursprüngliche Angriffspfad funktioniert weiterhin über einen leicht veränderten Eingabepfad.

Ein professioneller Retest prüft:

1. Ist die ursprüngliche Schwachstelle tatsächlich geschlossen?
2. Hat die Behebung keine neuen Schwachstellen eingeführt (Regression)?
3. Funktioniert der Bypass-Versuch nicht mehr?

Ein Retest kostet einen Bruchteil des initialen Tests, ist aber genauso wichtig. Ob der Retest für kritische und hohe Findings im Preis enthalten ist, gehört vor der Beauftragung geklärt.

Einordnung

Der Markt für Penetrationstests hatte bis 2026 kein gemeinsames Vokabular. Der Begriff ist nicht geschützt, die BSI-Studie zum Durchführungskonzept stammt aus dem Jahr 2003, und Ausschreibungen verlangen bis heute „OWASP Top 10" als Testkatalog. Die TeleTrusT-Handreichung schließt diese Lücke mit Definitionen, Modulen, Vertrags- und Berichtsvorgaben, die Auftraggeber und Anbieter gleichermaßen binden.

Für Unternehmen ändert sich damit vor allem die Beauftragung. Wer die sieben Module als Ausschreibungsgrundlage nutzt, die Ausschlusskriterien prüft und den Bericht an den Mindestanforderungen misst, kann Angebote strukturiert vergleichen. Die technische Qualität des Tests entscheidet sich weiterhin am Tester, der Rahmen dafür ist jetzt beschrieben.

Quellen

1. TeleTrusT - Bundesverband IT-Sicherheit e.V.: Handreichung Penetrationstests 2026, Arbeitskreis PenTests, Berlin 2026 (PDF, 51 Seiten). Seitenangaben im Text beziehen sich auf dieses Dokument.
2. BSI: IS-Penetrationstest und IS-Webcheck mit dem Praxis-Leitfaden „IS-Penetrationstest - Aus der Praxis für die Praxis" und der Liste zertifizierter IT-Sicherheitsdienstleister.
3. Verordnung (EU) 2022/2554 (DORA): EUR-Lex, Art. 3 Nr. 17, Art. 25 bis 27.
4. Richtlinie (EU) 2022/2555 (NIS2): EUR-Lex, Art. 21 Abs. 2 lit. f, Erwägungsgrund 86.
5. ISO/IEC 27001:2022, Anhang A, Maßnahmen 5.35, 5.36 und 8.8.
6. AWS: Penetration Testing Policy; Microsoft: Penetration testing in Azure.
7. Rapid7: Under the Hoodie 2019, durchschnittlich rund 80 vertraglich vereinbarte Stunden je Test.