Was macht ein Penetration Test Engineer? Aufgaben, Alltag und Einstieg

Warum Penetration Test Engineers jetzt besonders gefragt sind

Unternehmen digitalisieren schneller denn je – und damit wächst die Angriffsfläche. Parallel verschärfen Regulierungen die Erwartungen an Testtiefe und Nachweisführung. Im Finanzsektor wird Threat‑Led Penetration Testing (TLPT) im Rahmen von DORA für bestimmte Institute vorgesehen und kann verpflichtend werden; Leitfäden beschreiben hierfür u. a. produktionsnahe Testszenarien, den Einsatz externer Red‑Team‑/TI‑Provider und formale Bestätigungen durch die Aufsicht. Für Bewerber:innen heißt das: Die Rolle verbindet offensive Technik mit sauberer rechtlicher Absicherung, methodischer Strenge und guter Beratung.

Zur fachlichen Einordnung: Ein Penetrationstest ist eine systematische, autorisierte Angriffssimulation, die deutlich über automatisierte Schwachstellenscans hinausgeht. Er verlangt menschliche Kreativität, Kontextanalyse und das Zusammenspiel mehrerer Schwachstellenketten. Rechtlich zulässig ist er nur mit schriftlicher Autorisierung und klaren „Rules of Engagement“ – in Deutschland die Grundlage, um Straftatbestände nach StGB (z. B. 202a, 303b) auszuschließen. Eine prägnante Prozess‑ und Rechtsübersicht liefert der Fachbeitrag von AWARE7 (Überblick).

Rolle und Abgrenzung: Was macht ein Penetration Test Engineer?

Penetration Test Engineers planen und führen Penetrationstests durch, dokumentieren reproduzierbare Nachweise und beraten Teams bei der Behebung. Sie arbeiten zielgerichtet entlang etablierter Standards (z. B. PTES, OWASP Testing Guide) und übersetzen technische Befunde in priorisierte Maßnahmen.

Abgrenzungen, die im Berufsalltag wichtig sind:

Vulnerability Scanning vs. Penetration Test: Scans sind automatisiert und erkennen bekannte Schwachstellen. Penetrationstests kombinieren automatisierte Voranalyse mit manuellen Angriffsschritten, demonstrieren Exploitierbarkeit und reale Auswirkungen – inklusive Post‑Exploitation und Ketteneffekten. Gute Quellen dazu: AWARE7 und der praxisnahe Überblick von ADVISORI (Methoden & Ablauf).
Red Teaming: Länger laufende, realitätsnahe Simulationen mit ausgeprägter OPSEC, oft ohne Vorwarnung des Blue Teams. Pentests sind fokussierter, kürzer und stärker auf definierte Scopes ausgerichtet. In regulierten Finanzumgebungen wird Red Teaming als TLPT formalisiert – siehe DORA‑Kontext unten.
Security Consulting: Breiter Beratungsfokus (Policies, Prozesse, Risk Management). Penetration Test Engineers sitzen näher an der Technik, liefern aber ebenso verwertbare Empfehlungen und begleiten Nachtests.

Typische Einsatzszenarien sind Web‑Anwendungen und APIs, interne und externe Netzwerke, mobile/Cloud‑Umgebungen oder spezifische Infrastruktursegmente. Je nach Zielsetzung erfolgen Black‑, Grey‑ oder White‑Box‑Tests (keine, partielle oder volle Vorabinformationen) – alle drei sind in Fachquellen klar beschrieben.

Kernaufgaben entlang anerkannter Phasen

Die Arbeit folgt bewährten Phasen (PTES) – mit klaren Übergaben und Artefakten:

Vorbereitungsphase: Scope und Zeitfenster festlegen, Systeme/IP‑Ranges definieren, Notfallkontakte klären, Testtabus (z. B. DoS) festhalten, rechtlich absichern (Auftrag, Autorisierung, Rules of Engagement). Das ist unverzichtbar, um Rechtssicherheit und Teststabilität zu gewährleisten.
Informationsbeschaffung und Analyse: OSINT, passive und aktive Aufklärung, Technologie‑Fingerprinting. Automatisierte Scanner (z. B. Nessus, OpenVAS) liefern Breite; die Tiefe entsteht in der manuellen Verifikation und Modellierung realistischer Angriffswege.
Exploitation und Post‑Exploitation: Kontrolliertes Ausnutzen bestätigter Schwachstellen, Privilegien‑Eskalation und laterale Bewegung. Ziel ist der Nachweis realer Risiken – nicht maximaler Schaden.
Reporting und Nachbereitung: Management‑Summary, reproduzierbare Schritte, Belege (z. B. Screenshots/PoCs), Einstufung nach CVSS und priorisierte Maßnahmen. Gute Anbieter planen Retests ein, um die Wirksamkeit der Fixes zu bestätigen (vgl. ADVISORI). Ein starker Report ist der sichtbarste Qualitätsbeleg deiner Arbeit.

Die PTES‑Phasen sind im genannten AWARE7‑Überblick detailliert beschrieben. Ihr roter Faden prägt die Arbeitsweise im Projekt – von der Erstaufnahme bis zur Nachverfolgung.

Tages- und Projektalltag: Wie sieht die Praxis aus?

Praxisnahe Projektsequenz: Kick‑off mit Scope‑Feinschliff und Kommunikationswegen, dann Aufklärung und technische Tests, kontinuierliche Notizen/Artefakte für das Reporting, Eng‑Abstimmung bei kritischen Funden, Abschlussworkshop und Retest. Dazwischen: kurze Synchronisationen mit Dev/Ops, um Missverständnisse früh zu vermeiden.

Ein typischer Tag in der Durchführung kann so aussehen: Vormittags manuelle Überprüfung auffälliger Endpunkte aus dem Vortag, Variation eines Exploit‑Pfads und saubere Dokumentation der Reproduktionsschritte. Mittags kurzer Kundentermin zu einem potenziell hochkritischen Fund. Nachmittags Priorisierung der Findings, CVSS‑Einstufung, Abgleich mit dem Scope und Pflege des Evidenz‑Pakets. Abends kurze Retro im Team, was am Folgetag vertieft wird.

DORA/TLPT: Was ändert sich im regulierten Finanzsektor?

Für bestimmte Finanzinstitute wird TLPT zur Pflicht. Kerndifferenzen zu Standard‑Pentests werden in einschlägigen Leitfäden so beschrieben:

Intelligence‑led: Die Szenarien folgen aktueller, zielgerichteter Threat Intelligence statt generischer Muster.
Live‑Produktion: Häufig wird an produktionsnahen oder produktiven Systemen getestet – abhängig vom konkreten Rahmen und Aufsichtsvorgaben; mit klaren Abbruchkriterien und eng geführter Governance.
Externe Rollen und Aufsicht: Einsatz externer spezialisierter Red‑Team‑ und TI‑Provider; Einbindung der Aufsicht und teils formale Bestätigungen gemäß Leitfäden.
Turnus: In der Regel in mehrjährigen Zyklen; Details zu Einstufung und Frequenz ergeben sich aus den jeweils geltenden Rahmenwerken (z. B. TIBER‑EU) und Aufsichtsvorgaben (siehe Regulationsüberblick).

Für dich als Bewerber:in bedeutet das mehr Prozess‑ und Dokumentationsanspruch, noch strengere Trennung der Rollen und ein sehr klares Erwartungsmanagement beim Testen „unter Aufsicht“.

Gefragte Fähigkeiten und Werkzeuge

Technische Schwerpunkte, die in fast allen Stellenprofilen wiederkehren:

Solide Netzwerk‑ und Web‑Security‑Grundlagen, Protokollverständnis und Authentifizierungsmechanismen.
Methodische Sicherheit: Threat‑Modelling, systematische Priorisierung, saubere Exploit‑/PoC‑Dokumentation und CVSS‑Einstufung.
Werkzeuge zur Breitenabdeckung und Voranalyse: Scanner wie Nessus oder OpenVAS; zusätzlich Skripting‑Routine, um Hilfstools zu bauen und Artefakte zu erzeugen. Der Mehrwert kommt aus der manuellen Verifikation und Kettenbildung.
Standards & Leitfäden: PTES und der OWASP Testing Guide helfen, Scope, Tiefe und Evidenzqualität konsistent zu halten.

Zertifizierungen sind kein Muss, aber oft vertrauensbildend. Häufig genannte Nachweise sind OSCP, OSCE3 (Offensive Security Experienced Expert), CEH und GPEN (siehe AWARE7‑Überblick). Wichtig bleibt: Zeige echte Hands‑on‑Kompetenz – Reports, reproduzierbare Findings und saubere Kommunikation schlagen reine Theorie.

Soft‑Skill‑Hebel: Klar schreiben, verständlich priorisieren und adressatengerecht sprechen – vom Dev bis zur Geschäftsführung. Wer Funde präzise erklärt und umsetzbare Schritte anbietet, erhöht die Fix‑Rate und baut langfristiges Vertrauen auf.

Jobvarianten und Trade‑offs

Beratungsunternehmen: Hohe Abwechslung an Branchen und Technologien, eingespielte Methodik und Teamkolleg:innen, die Feedback geben. Dafür oft klare Projekt‑Taktung und Reise‑/Remote‑Wechsel.
Inhouse: Tiefes Domänenwissen, direkter Einfluss auf Härtung und Entwicklungsprozesse, oft enger Schulterschluss mit Blue Team/DevSecOps. Dafür weniger Vielfalt in Zielumgebungen.
Freiberuflich: Hohe Gestaltungsfreiheit und Spezialisierung möglich. Gleichzeitig mehr Vertriebs‑, Vertrags‑ und Haftungsthemen – vom Scope bis zur Berufshaftpflicht.

Karriereentwicklung gelingt über Spezialisierung (z. B. Web/Cloud, AD/Windows, Mobile) oder die Erweiterung in Richtung Red Teaming/TLPT und Methodik‑Ownership (Reporting‑Standards, Schulungen, Purple‑Team‑Formate). In regulierten Sektoren zahlt sich Verlässlichkeit bei Governance, Rechtsrahmen und Nachweisen besonders aus.

Stellen prüfen: Woran erkenne ich einen guten Arbeitgeber oder Auftrag?

Scope‑Transparenz: Klare Systeme, Zieldefinitionen und verbotene Methoden (DoS etc.). Ohne sauberes Scope‑Dokument drohen Missverständnisse – oder rechtliche Risiken.
Reporting‑Qualität: Musterbericht erfragen. Sind Reproduktionsschritte, CVSS‑Einstufungen und priorisierte Maßnahmen enthalten – oder nur eine Tool‑Liste?
Rechtssicherheit: Schriftliche Autorisierung, Notfallwege, Haftpflichtabsicherung – aus Bewerber:innensicht essenziell.
Methodik & Standards: Bezug auf PTES/OWASP ist ein gutes Zeichen. In Finanzhäusern sollte der DORA‑/TLPT‑Bezug professionell adressiert sein.
Retest‑Praxis: Nachtests signalisieren Qualitätsbewusstsein und echten Verbesserungswillen der Kunden.
Lernkurve: Zeit für Research, Pair‑Testing, interne Reviews. Gute Teams sichern Kapazität für Weiterentwicklung.

Bewerbungsvorbereitung: Portfolio, Labs, Interviews

Baue ein kleines, kuratiertes Portfolio: 2–3 anonymisierte Report‑Ausschnitte mit sauberer Reproduktion, Impact‑Einordnung und Fix‑Vorschlägen. Qualität statt Menge.
Übe die „Kette“: Aus Scanner‑Indiz zu manuellem Nachweis, dann Post‑Exploitation und Business‑Impact – inklusive CVSS‑Begründung.
Standards sprechen: PTES‑Phasen, OWASP Testing Guide, CVSS‑Metriken – nicht auswendig, sondern sicher in der Anwendung.
Recht und Ethik: Autorisierung, Scope, Umgang mit sensiblen Daten. Hier trennt sich Professionalität von „Hacking‑Hobby“.
Kommunikation: Erkläre ein komplexes Finding in 60 Sekunden für Nicht‑Techniker:innen – und danach tief technisch für das Engineering‑Team.

90‑Tage‑Plan für den Einstieg

Tage 1–30: PTES und OWASP Testing Guide intensiv durcharbeiten, ein eigenes Test‑Playbook anlegen (Scoping‑Checkliste, Notfallkontakte, Reporting‑Vorlage). Zwei Mini‑Engagements im Lab nachstellen – inklusive vollständigem Report mit CVSS.
Tage 31–60: Breite durch Automatisierung: Scanner in eine kleine Pipeline integrieren, Befund‑Triaging üben, mindestens eine komplexe Schwachstellenkette (Recon → Auth‑Bypass → Privilege Escalation) reproduzierbar dokumentieren. Feedback von einer Mentorin oder einem Community‑Review einholen.
Tage 61–90: Praxisnaher Probelauf: Ein vollständiger Grey‑Box‑Webtest im Lab – inklusive Kick‑off‑Agenda, Zwischenmeldung bei „kritisch“, Abschlusspräsentation und Retest. Parallel Grundwissen zu DORA/TLPT aufbauen, falls Finanzsektor relevant ist (Überblick: TLPT‑Guide).

Fazit: Passt der Job zu dir?

Dieser Beruf liegt genau dann, wenn du strukturiert vorgehst, gerne tief in Systeme eintauchst und Verantwortung übernehmen willst – technisch wie kommunikativ. Entscheidend ist nicht der spektakulärste Exploit, sondern das professionelle Zusammenspiel aus sauberem Scoping, reproduzierbarer Evidenz, klarer Priorisierung und hilfreichen Empfehlungen. Wer das beherrscht, wird als Penetration Test Engineer in Deutschland – ob Beratung, Inhouse oder regulierter Sektor – langfristig gebraucht.

Hinweis zu Quellen: Die rechtliche und methodische Einordnung, der Unterschied zwischen Scans und Pentests sowie PTES‑Phasen und Zertifizierungen sind u. a. in der AWARE7‑Übersicht zusammengefasst. DORA/TLPT‑Spezifika stammen aus einem frei zugänglichen Leitfaden. Der praxisorientierte Ablauf und Qualitätsmerkmale in der Anbieterwahl werden in einem deutschsprachigen Überblick von ADVISORI erläutert.