Stand: Oktober 2026
Einleitung: Welche Penetrationstest-Anbieter passen zu deinen Anforderungen?
Die zentrale Frage vor jeder Ausschreibung lautet: Wie findet man einen Anbieter, der technische Tiefe und branchenspezifisches Verständnis mitbringt? Ein reiner Preisvergleich greift zu kurz. Wer nur Tagessätze abfragt, riskiert Fehlinvestitionen und Lücken bei der Compliance. Ein strukturierter Auswahlprozess zwingt dazu, Prüfziele, Scope und regulatorische Vorgaben sauber zu definieren – bevor Angebote eingeholt werden.
Aktuelle Regularien verschärfen die Anforderungen massiv. DORA, NIS2 sowie BAIT und KAIT fordern nachweisbar methodische Tests mit auditierbarer Dokumentation. Ein Pentest nach Scanner-Logik reicht nicht mehr; Prüfer und Auditoren erwarten dokumentierte Vorgehensmodelle wie OWASP WSTG oder MITRE ATT&CK. Die Auswahlkriterien für Anbieter müssen daher Methodik, Zertifizierungen der Tester und Branchenreferenzen gewichten – nicht nur den Stundensatz.
Preisspannen variieren stark: Ein fokussierter Webserver-Test startet im niedrigen vierstelligen Bereich, komplexe Red-Team-Engagements erreichen schnell sechsstellige Summen. Dieser Guide skizziert acht konkrete Kriterien für die Ausschreibung – von Methodik und Hands-On-Zertifikaten über Berichtsgüte und Haftpflicht bis zu Retest-SLAs und Vertragsgestaltung. So wird der nächste Pentest nicht nur ein Haken auf der Compliance-Liste, sondern ein echter Sicherheitsgewinn.
Bevor du startest: 3 Klärungsfragen
Bevor du eine Ausschreibung verschickst, müssen drei Fragen intern verbindlich beantwortet sein. Ohne diese Basis liefern Anbieter nur vage Kostenschätzungen statt vergleichbarer Angebote.
1. Welches konkrete Prüfziel steht im Fokus?
Geht es um eine einzelne Webanwendung, ein internes Netzwerksegment oder ein Red-Team-Szenario mit physischer und sozialer Komponente? Jedes Ziel erfordert andere Methodiken, Toolchains und Tester-Profile. Die BSI-Studie zum Durchführungskonzept nennt hierfür acht verbindliche Festlegungspunkte – Zieldefinition ist der erste.
2. Welche Rahmenbedingungen sind bereits bekannt?
Sammle Systemanzahl, vorhandene Dokumentationen (Architekturskizzen, Datenflussdiagramme, API-Specs) und bestehende Berechtigungen. Kläre, ob Tester mit White-Box-Zugang starten oder Black-Box-Rekognition Teil des Auftrags ist. Fehlende Infos verlängern den Scoping-Workshop und treiben den Aufwand.
3. Welcher Zeitraum und Aufwand sind realistisch?
Ein fokussierter Webserver-Test bewegt sich oft im niedrigen vierstelligen Bereich, komplexe Infrastruktur- oder Red-Team-Engagements erreichen schnell fünf- bis sechsstellige Summen. Definiere Testzeitraum, gewünschte Retest-Fristen (z. B. 14 Tage nach Patch) und ob Continuous Pentesting angedacht ist. Die TeleTrusT-Handreichung 2026 liefert dafür einen strukturierten Fragenkatalog.
Diese drei Punkte klärst du am besten in einem halbtägigen Workshop mit IT-Betrieb, Informationssicherheitsbeauftragten und den betroffenen Fachbereichen. Das Ergebnis: eine einseitige Leistungsbeschreibung, die Anbieter in vergleichbare Angebote umsetzen können.
Kriterium 1: Methodik & Standards
Ein seriöser Anbieter dokumentiert seine Vorgehensweise entlang anerkannter Referenzwerke – OWASP Web Security Testing Guide, NIST SP 800-115 oder MITRE ATT&CK Framework – statt sich auf reine Scanner-Ergebnisse zu verlassen. Diese Standards sichern eine systematische Abdeckung relevanter Schwachstellenklassen und schaffen Nachvollziehbarkeit für interne Prüfer wie externe Auditoren. In der Ausschreibung fordern Sie daher explizit eine Methodikbeschreibung sowie einen Testplan, die konkrete Bezüge zu diesen Frameworks herstellen. Fehlen solche Dokumente, handelt es sich oft um automatisierte Scans ohne manuelle Tiefenprüfung.
Achten Sie darauf, dass der Anbieter zwischen Vulnerability Assessment und echtem Penetrationstest unterscheidet. Erstere liefern Listen potenzieller Schwachstellen; letztere validieren Ausnutzbarkeit und Wirkkette – ein Unterschied, den Sodu Secure in seiner Anbieter-Übersicht herausarbeitet. Ergänzend sollten Sie nach Purple-Team- oder Red-Team-Erfahrung fragen: Simulationen realer APT-Taktiken entlang von MITRE ATT&CK ersetzen zunehmend reine Punkt-Tests, wie Deepstrike für den deutschen Markt bestätigt. Verlangen Sie zudem Nachweise zur kontinuierlichen Weiterbildung der Tester – aktuelle Exploit-Techniken, Cloud-nativen Angriffsvektoren und KI-gestützte Reconnaissance erfordern ständiges Training, das über Zertifikate hinausgeht.
Kriterium 2: Tester-Qualifikation (Hard Skills)
Die tatsächliche Qualifikation der durchführenden Tester ist der härteste Qualitätsnachweis. Zertifizierungen wie OSCP, OSWE, OSEP, CPTS oder der BSI-anerkannte IS-Penetrationstester belegen praktische Angriffsfertigkeiten statt reiner Theoriekenntnisse. Seriöse Anbieter benennen im Angebot die Namen und Zertifikate der zugewiesenen Tester – nicht nur die des Account-Managers.
Fordern Sie diese Nachweise explizit ein. Prüfen Sie die Gültigkeit direkt bei den Ausstellern: Offensive Security verwaltet OSCP, OSWE und OSEP über ein öffentliches Verzeichnis; der BSI listet anerkannte IS-Penetrationstester auf seiner Behörden-Seite. Ein abgelaufenes oder nicht auffindbares Zertifikat disqualifiziert den Tester für den Auftrag.
Unterscheiden Sie zudem zwischen Sicherheitsberatung und hands-on Penetration Testing. Berater erstellen oft Konzepte, Policies oder Risikoanalysen – Tester hingegen brechen aktiv in Systeme ein, ketten Exploits und dokumentieren technische Auswirkungen. Nur letztere liefern die für Compliance-Audits (PCI DSS, DORA, ISO 27001 A.18.2.3) verwertbaren Beweise. Eine Checkliste zur Validierung der Tester-Profile bietet Apollon Security; ergänzende Hinweise zu Zertifikats-Prüfung und Vertragsgestaltung finden sich im Leitfaden von VisionCompliance.
Kriterium 3: Branchen- & Regulierungserfahrung
Wer einen Penetrationstest für ein reguliertes Umfeld beauftragt, muss prüfen, ob der Anbieter die jeweilige Norm nicht nur zitiert, sondern operativ beherrscht. PCI DSS verlangt andere Testschwerpunkte als DORA oder BAIT/KAIT; ISO 27001 Control A.18.2.3 fordert regelmäßige technische Compliance-Reviews, die methodisch sauber in den Auditzyklus eingebettet sein müssen. Ein Anbieter, der bisher nur klassische Web-Applikationen geprüft hat, wird bei einem Kernbankensystem unter BAIT-Vorgaben schnell an Grenzen stoßen – etwa bei der Bewertung von Nebenkanalrisiken in HSM-Clustern oder der Validierung von Notfallzugriffsprozessen.
Fordern Sie konkrete Referenzprojekte aus dem eigenen Regulierungsraum. Akzeptabel sind anonymisierte Abschlussberichte, Bestätigungen über bestandene Audit-Nachweise oder Aussagen ehemaliger Prüfer, die die Testdokumentation als „auditreif“ bewertet haben. Allgemeine Kundenlisten reichen nicht. Die usd AG empfiehlt, branchenspezifische Szenarien bereits im Scoping-Workshop abzufragen: Wie geht der Tester mit PCI-DSS-Segmentierung um? Welche DORA-relevanten IKT-Drittparteien werden in den Test einbezogen? Wie mappt er Findings auf BAIT-Module?
Branchenerfahrung zeigt sich auch in der Sprache der Findings. Ein Report für die Zahlungskartenindustrie priorisiert Karteninhaberdaten und Tokenisierung; ein KRITIS-Bericht bewertet Ausfallketten und Meldepflichten nach BSI-KritisV. ADVISORI weist darauf hin, dass Anbieter ohne Regulierungserfahrung oft generische CVSS-Scores liefern, statt risikobasierte Bewertungen vorzunehmen, die ein Auditor akzeptiert. Wer die Compliance-Logik nicht versteht, liefert Daten – keine Entscheidungsgrundlage.
Kriterium 4: Berichtsgüte & Haftpflicht
Der Abschlussbericht entscheidet über den praktischen Nutzen des Tests. Er muss zwei Zielgruppen bedienen: Die Executive Summary liefert der Geschäftsführung eine risikobasierte Priorisierung ohne Fachjargon. Der technische Anhang gibt Entwicklern und Admins reproduzierbare Nachweise — Requests, Responses, Screenshots, konkrete Remediation-Hinweise mit Code-Beispielen. Fehlt eine der beiden Ebenen, bleibt der Test ein teures Papier.
Prüfen Sie im Angebot explizit: Gliederung nach Schweregrad (CVSS), Zuordnung zu OWASP-Top-10 oder MITRE-ATT&CK-Taktiken, Nachweis der manuellen Validierung jedes Findings. Ein Nachbereitungs-Workshop zur Ergebnisbesprechung sollte fester Bestandteil sein, nicht Option. VisionCompliance empfiehlt zudem, die Berufshaftpflichtversicherung des Anbieters auf mindestens 5 Mio. € Deckungssumme zu prüfen — die Bestätigung gehört ins Angebot, nicht in die Verhandlung nach Vertragsschluss.
Infodas weist darauf hin, dass Haftungsfreistellungen im Vertrag oft Lücken lassen. Fordern Sie eine aktuelle Versicherungsbescheinigung an und prüfen Sie, ob auch Folgeschäden (z. B. Produktionsausfall durch Testaktionen) gedeckt sind. Ein Anbieter, der hier mauert, überlässt Ihnen das Restrisiko.
Kriterium 5: Scoping-Workshop & Angebotsdetail
Ein strukturierter Scoping-Workshop vor der Angebotserstellung gehört zum professionellen Standard. Er klärt Systemanzahl, Applikationslogik, Rollen und Berechtigungen, Testtiefe sowie konkrete Angriffszenarien. Seriöse Anbieter fordern vorab Netzwerkdiagramme, Anwendungsbeschreibungen und bestehende Sicherheitsdokumentation ein. Im Workshop sollten sie gezielt nach Compliance-Vorgaben, kritischen Assets, Ausschlusskriterien und gewünschten Retest-Fenstern fragen. Der Ablauf eines solchen Workshops zeigt, wie Anbieter Unklarheiten frühzeitig auflösen und den Prüfumfang messbar machen.
Auf dieser Basis entsteht ein Angebot, das Vorgehensweise, Zeitplan, erwarteten Aufwand und Lieferumfang transparent ausweist. Es nennt die eingesetzten Methodiken (etwa OWASP WSTG, NIST SP 800-115), definiert Einstiegs- und Ausstiegskriterien und regelt Retest-SLAs – beispielsweise 14 Tage nach Patch-Einspielung. Die Analyse typischer Angebotsbestandteile hilft, Lücken zu erkennen. Fehlen diese Details, drohen spätere Änderungsnachverhandlungen und Scope-Creep. Wer den Workshop als gemeinsame Planungsgrundlage nutzt, stellt sicher, dass Kunde und Anbieter von identischen Voraussetzungen ausgehen und der Test die tatsächlich relevanten Risiken abdeckt.
Kriterium 6: Transparenz über Tool-Einsatz & KI
Moderne Dienstleister nutzen zunehmend KI-gestützte Reconnaissance und automatisierte Exploit-Entwicklung. Ausschreibungen müssen daher verlangen, dass Anbieter das Verhältnis von Scanner-Läufen zu manueller Tiefe offenlegen. Ein transparenter Tool-Plan nennt konkrete Produkte – etwa Burp Suite, Nmap oder selbstentwickelte Skripte – und grenzt ab, wo menschliche Analyse ansetzt.
Fehlende Angaben führen zu nicht vergleichbaren Angeboten: Ein günstiger Pauschalpreis basiert oft auf reinen Vulnerability-Scans, während echte Penetrationstests manuelle Nachprüfung, Chaining und Business-Logic-Prüfung erfordern. Die versteckten Kosten von Penetrationstests zeigen sich häufig erst im Nachgang, wenn Nachtests oder Reporting separat berechnet werden.
KI-Unterstützung ist nicht per se problematisch, solange der Anbieter darlegt, welche Schritte algorithmisch vorselektiert und welche final validiert werden. Wer „KI-Pentest“ als Alleinstellungsmerkmal bewirbt, ohne manuelle Kontrollschichten zu benennen, verschiebt Haftungsrisiken auf den Auftraggeber. Ein praxisnaher Leitfaden empfiehlt, im Scoping-Workshop explizit nach Tool-Chain, Automatisierungsgrad und Retest-SLA zu fragen. Nur so lassen sich Angebote methodisch vergleichen und Qualitätsunterschiede vor Vertragsabschluss erkennen.
Kriterium 7: Purple-/Red-Team-Ansätze
Klassische Schwachstellenscans reichen für regulatorisch getriebene Nachweise oft nicht mehr aus. Immer mehr Ausschreibungen fordern Purple-Team- oder Red-Team-Szenarien, die reale APT-Taktiken nach dem MITRE ATT&CK Framework nachstellen. Dabei agiert das Red Team als Angreifer, während das Blue Team Verteidigung und Erkennung trainiert – idealerweise in enger Abstimmung, damit beide Seiten unmittelbar voneinander lernen.
Im Leistungsverzeichnis sollten konkrete Ziele stehen: Erkennungsrate für definierte Taktiken, mittlere Reaktionszeit bis zur Eindämmung, Abdeckung kritischer Pfade (Initial Access, Privilege Escalation, Lateral Movement). Erfolgskriterien lassen sich über ATT&CK-Techniken messbar machen – etwa „Erkennung von T1059.001 innerhalb von 30 Minuten“.
Referenzen prüfen Sie am besten über dokumentierte Engagements: Welche Threat-Actor-Profile wurden simuliert? Welche Telemetrie-Quellen (EDR, SIEM, Netzwerk) lagen vor? Wie wurde der Wissenstransfer an das interne Team organisiert? Anbieter, die Methodik, Tool-Einsatz und Lessons Learned transparent darlegen, zeigen operative Reife. Marktübersichten helfen, Anbieter mit nachweisbarer Red-Team-Erfahrung einzugrenzen.
Kriterium 8: Continuous Pentesting / PTaaS & Retest-SLA
Klassische Punkt-Tests bilden den Sicherheitszustand nur zum Prüfzeitpunkt ab. In agilen Entwicklungszyklen und dynamischen Cloud-Umgebungen veralten diese Ergebnisse innerhalb von Tagen. PTaaS-Modelle (Penetration Testing as a Service) schließen diese Lücke durch kontinuierliche Prüfintervalle und automatisierte Re-Tests nach Code-Änderungen. Der Vertrag muss dabei verbindliche Retest-SLAs enthalten: Ein gängiger Standard sieht einen kostenfreien Nachweis der Behebung innerhalb von 14 Tagen nach Patch-Freigabe vor.
Damit dieser Mechanismus greift, braucht es einen definierten Freigabe-Prozess: Das Entwicklungsteam dokumentiert die Maßnahme, löst den Retest über die Plattform oder per Ticket aus und stellt Testdaten sowie Zugänge bereit. Fehlt diese Prozesskette, bleibt die SLA zahnlos. Besonders bei Microservice-Architekturen oder wöchentlichen Deployments zahlt sich das Modell aus, da Schwachstellenfenster von Wochen auf Tage schrumpfen.
Preislich setzen Anbieter auf Abonnements (monatlich/jährlich) oder Kontingentmodelle mit Credits für manuelle Tiefeprüfungen. Entscheidend ist Transparenz: Welche Assets sind wie oft im Scope? Welche Tiefe (automatisiert vs. manuell) ist inkludiert? Der heise-Workshop zur Ausschreibung empfiehlt, Frequenz, Scope-Grenzen und Eskalationspfade bereits im Vertrag festzuschreiben, um spätere Kostenexplosionen zu vermeiden.