Penetrationstest Kosten 2026: Preise & Budgetplanung

Antwort des Geschäftsführers

Penetrationstest Kosten haben 2026 keinen seriösen Einheitspreis. Ein eng begrenzter Test kann wenige tausend kosten; komplexe Cloud-, Multi-Application- oder Red-Team-Engagements liegen deutlich höher. Den Preis bestimmen Scope, Rollen, APIs, Testtiefe, Zugangsmodell, Reporting und Retest. Unternehmen sollten deshalb Angebote erst vergleichbar machen: gleiche Assets, gleiche Rollen, gleiche manuelle Prüftiefe und gleiche Deliverables. Erst danach ist ein Preisvergleich sinnvoll. So erkennen Einkäufer, ob ein günstigeres Angebot effizienter kalkuliert ist oder schlicht weniger Sicherheitsleistung enthält.

Warum Preislisten allein nicht reichen

Wer nach “Was kostet ein Penetrationstest?” sucht, möchte meist keine theoretische Definition, sondern eine belastbare Budgetentscheidung. Genau hier entstehen Fehlkäufe: Zwei Angebote können beide “Web-App-Pentest” heißen und trotzdem einen völlig unterschiedlichen Umfang enthalten.

Ein professioneller Penetrationstest kombiniert typischerweise technische Erkennung mit manueller Validierung. Wie viel davon im Angebot steckt, beeinflusst den Preis stärker als das Etikett auf dem Angebot.

Was kostet ein Penetrationstest 2026?

Als grobe internationale Planungsorientierung nutzt DeepStrike in seinem aktuellen Cost Guide einen breiten Bereich von etwa 5.000 bis 50.000 US-Dollar oder mehr für professionelle Third-Party-Pentests. Das ist kein unabhängiger deutscher Marktmedian und sollte nicht mechanisch in Euro umgerechnet werden. Der konkrete DACH-Preis hängt vom Scope, der benötigten Testzeit und den vereinbarten Deliverables ab.

Für deutsche Unternehmen ist deshalb eine andere Frage nützlicher: Wie viele qualifizierte Testtage und welche zusätzlichen Leistungen sind für den gewünschten Scope erforderlich? Ein Angebot für eine einzelne, kleine Anwendung ist nicht mit einem Test mehrerer Anwendungen, APIs, Rollen und Cloud-Komponenten vergleichbar.

Der Preis sollte zudem nicht isoliert betrachtet werden. Ein Angebot kann günstiger sein, weil der Scope enger, der Retest nicht enthalten oder das Reporting einfacher ist. Ein anderes kann teurer wirken, aber mehr manuelle Tiefe und verwertbare Evidenz liefern.

Typische Planungsbereiche nach Testart

Die folgende Tabelle ist eine DeepStrike-Planungsorientierung, keine Preisgarantie und kein unabhängiger DACH-Marktindex. Sie hilft, Größenordnungen zu verstehen; ein belastbares Angebot benötigt immer einen konkreten Scope.

Bei allen Bereichen gilt: Der Name der Testart ist nur die Startinformation. Die eigentliche Kalkulation entsteht aus Umfang, Tiefe und dem Aufwand für nachvollziehbare Ergebnisse.

Welche Faktoren bestimmen den Preis?

1. Scope: Wie viel wird wirklich getestet?

Der größte Kostentreiber ist meist der Umfang. Für Netzwerke zählen beispielsweise IP-Bereiche, Segmente und Identitätsdomänen; bei Webanwendungen zählen Funktionen, Rollen und relevante Datenflüsse; bei APIs zählen Endpoints und Berechtigungsmodelle.

Ein guter Scope beschreibt nicht nur “eine Anwendung”, sondern auch Staging oder Produktion, Admin- und Standardrollen, SSO, APIs, externe Integrationen und out-of-scope Komponenten. Je klarer diese Grenzen sind, desto besser kann ein Anbieter Aufwand und Risiko kalkulieren.

2. Komplexität: Wie viele Angriffspfade entstehen?

Zwei Anwendungen mit jeweils zehn Funktionen können sehr unterschiedlich aufwendig sein. Eine einfache stateless API ist leichter zu prüfen als eine Plattform mit OAuth, mehreren Mandanten, komplexer Rollenlogik und kritischen Workflows.

Komplexität entsteht auch zwischen Komponenten. Wenn Web-App, API und Cloud-IAM zusammenspielen, muss ein Tester nicht nur Einzelbefunde prüfen, sondern mögliche Angriffsketten über Systemgrenzen hinweg nachvollziehen.

3. Testtiefe: Scan, manuelle Validierung oder Angriffsketten?

Ein Vulnerability Scan und ein Penetrationstest sind keine austauschbaren Produkte. Ein Scan kann bekannte Schwachstellen und Fehlkonfigurationen effizient aufdecken; ein Pentest prüft zusätzlich, ob sich Schwächen praktisch ausnutzen oder zu relevanten Angriffspfaden verbinden lassen.

Die Unterschiede zwischen Vulnerability Assessment und Penetration Testing sollten deshalb bereits im Angebot sichtbar sein. Fragen Sie explizit nach manueller Validierung, Business-Logic-Tests, Berechtigungsprüfungen und Exploit-Chain-Analyse.

4. Black Box, Grey Box oder White Box

Das Zugangsmodell beeinflusst den Aufwand, aber es gibt keine verlässliche Regel “Black Box ist billiger” oder “White Box ist teurer”. Black Box kann viel Reconnaissance erfordern; White Box kann durch vorhandene Architekturinformationen effizienter werden, zugleich aber zusätzlichen Code- oder Konfigurationsreview einschließen.

Für viele Business-Anwendungen ist Grey Box eine effiziente Beschaffungsoption, weil der Tester mit definierten Testkonten schneller in Rollen- und Berechtigungslogik gelangt. Die detaillierten Unterschiede erklärt DeepStrike im Vergleich Black Box vs White Box Penetration Testing.

5. Reporting und Nachweisfähigkeit

Ein technischer Findings-Export ist günstiger zu erstellen als ein Bericht mit Executive Summary, Reproduktionsschritten, Evidenz, Risikobewertung, Remediation Guidance und sauberer Nachverfolgung.

Wenn der Bericht an Kunden, Auditoren oder Management geht, sollte die gewünschte Evidenzqualität im Statement of Work stehen. Ein guter Penetration-Testing-Report reduziert spätere Rückfragen und macht Remediation und Retest messbarer.

6. Retest und Remediation-Support

Ein Retest bestätigt, ob behobene Schwachstellen tatsächlich geschlossen wurden und ob die Korrektur neue Risiken erzeugt hat. Manche Anbieter inkludieren einen Retest, andere rechnen ihn separat ab.

Vergleichen Sie deshalb nicht nur den Initialpreis. Fragen Sie nach Retest-Fenster, Anzahl der enthaltenen Findings, Reopening-Regeln und zusätzlichem Aufwand bei verspäteten Fixes.

7. Dringlichkeit, On-site-Aufwand und Betriebsfenster

Express-Termine, Nacht- oder Wochenendfenster, Vor-Ort-Einsätze und komplexe Zugangsvorbereitungen können zusätzlichen Aufwand erzeugen. Auch die Notwendigkeit, mit mehreren Teams oder Change-Fenstern zu koordinieren, wirkt sich auf den Projektpreis aus.

Diese Punkte sollten separat ausgewiesen sein. So bleibt sichtbar, welcher Teil des Preises für Security Testing und welcher für Logistik oder Terminzwang anfällt.

So vergleichen Sie Pentest-Angebote wirklich fair

Der sinnvollste Weg zur Kostenkontrolle ist nicht, den billigsten Anbieter zu wählen, sondern alle Anbieter auf denselben Scope zu zwingen. Das folgende DeepStrike Quote Comparability Framework normalisiert sieben Felder.

1. Ziel definieren: Geht es um Release-Freigabe, Kundenanforderung, regulatorischen Kontext, allgemeine Risikoanalyse oder einen konkreten Angriffspfad?
2. Scope-Einheiten zählen: Anwendungen, Rollen, APIs, Endpoints, IP-Bereiche, Cloud Accounts, Mobile-Plattformen und Standorte.
3. Zugangsmodell festlegen: Black Box, Grey Box oder White Box sowie bereitgestellte Testkonten und Dokumentation.
4. Manuelle Tiefe festschreiben: Business Logic, Authorization, Exploit Chaining, Konfiguration, Identität und relevante Spezialtests.
5. Deliverables standardisieren: Bericht, Executive Summary, Evidence, Severity Model, Remediation Guidance und Abschluss-Call.
6. Retest-Regel vereinheitlichen: Inklusive oder separat, Frist, Umfang und Anzahl der Nachprüfungen.
7. Gesamtkosten vergleichen: Initialtest plus mögliche Reise-, Express-, Retest- und Zusatzkosten statt nur die Angebots-Summe auf Seite eins.

Wenn zwei Angebote diese sieben Punkte unterschiedlich beantworten, sind die Preise nicht direkt vergleichbar. Dann vergleichen Sie unterschiedliche Produkte, auch wenn beide “Pentest” heißen.

Festpreis, Tagessatz oder PTaaS?

Festpreis

Ein Festpreis ist attraktiv, wenn der Scope stabil und eindeutig ist. Der Anbieter trägt mehr Kalkulationsrisiko, deshalb muss das Statement of Work sehr präzise definieren, was ein- und ausgeschlossen ist.

Für Procurement ist das Modell planbar. Für dynamische Anwendungen kann es jedoch zu Change Requests kommen, wenn Rollen, Endpoints oder Umgebungen während des Tests wachsen.

Time & Materials

Time & Materials eignet sich, wenn Umfang oder technische Tiefe schwer vorhersehbar sind. Der Kunde bezahlt den tatsächlichen Aufwand und kann den Test bei wichtigen Funden gezielt verlängern.

Sinnvoll ist eine Kostenobergrenze oder ein Freigabepunkt, bevor zusätzliche Tage gebucht werden. So bleibt Flexibilität erhalten, ohne die Budgetkontrolle aufzugeben.

PTaaS und kontinuierliche Tests

Penetration Testing as a Service kann für Teams sinnvoll sein, die regelmäßig testen und Findings laufend nachverfolgen möchten. Der Vorteil liegt primär in wiederholbaren Workflows, schnellerer Koordination und zentraler Ergebnisverwaltung nicht in einem pauschal garantierten Preisvorteil.

Für häufige Releases kann auch Continuous Penetration Testing passen. Ob es wirtschaftlicher ist als Einzelprojekte, hängt von Testfrequenz, Umfang und Vertragsmodell ab.

Welche versteckten Kosten sollten Sie einplanen?

Der Lieferantenpreis ist nicht die gesamte Investition. Interne Teams benötigen Zeit für Scope-Definition, Testkonten, Freigaben, Monitoring, Rückfragen, Remediation und Retest.

Hinzu kommen mögliche Change-Fenster, Reiseaufwand, zusätzliche Umgebungen oder erneute Tests nach größeren Änderungen. Deshalb sollte das Budget einen Total Cost of Engagement betrachten, nicht nur die externe Rechnung.

Ein einfaches Beschaffungsmodell lautet:

Gesamtaufwand = Test + Vorbereitung + Reporting + interne Koordination + Remediation + Retest + optionale Logistik.

Diese Formel ist bewusst ohne pauschalen Prozentsatz. Der interne Aufwand unterscheidet sich stark zwischen einer kleinen SaaS-Anwendung und einem regulierten Enterprise-Programm.

Compliance: Wann wird ein Pentest teurer?

Regulatorische oder vertragliche Anforderungen können den Aufwand erhöhen, wenn ein bestimmter Scope, eine dokumentierte Methodik, zusätzliche Evidenz oder ein formaler Retest verlangt wird. Das bedeutet jedoch nicht, dass jedes Framework pauschal denselben Pentest oder dieselbe Frequenz fordert.

Prüfen Sie die konkrete Verpflichtung für Ihre Organisation und Ihren Systemkontext. Für NIS2-Fragen ist ein framework-spezifischer Leitfaden wie NIS2 Penetration Testing hilfreicher als eine pauschale “jährlich testen”-Regel.

Für methodische Qualität sind der OWASP Web Security Testing Guide und NIST SP 800-115 etablierte Referenzpunkte. Sie definieren keine universelle Preisliste, helfen aber dabei, den erwarteten Testansatz im Angebot klarer zu machen.

Ist ein günstiger Pentest automatisch schlecht?

Nein. Ein niedriger Preis kann durch einen sehr engen Scope, eine kleine Anwendung, vorhandene Testkonten, eine effiziente Grey-Box-Vorgehensweise oder eine bestehende Kundenbeziehung entstehen.

Problematisch wird ein günstiges Angebot erst dann, wenn unklar bleibt, wie viel manuelle Arbeit, welche Funktionen, welche Rollen, welcher Bericht und welcher Retest enthalten sind. Preis ist daher ein Signal für Rückfragen, aber kein Qualitätsbeweis.

Fragen Sie konkret: Wie viele Rollen werden getestet? Werden Berechtigungsfehler und Business Logic manuell geprüft? Werden Findings reproduzierbar belegt? Ist ein Retest enthalten? Welche Bereiche sind explizit ausgeschlossen?

Wie lässt sich das Budget reduzieren, ohne Testtiefe zu verlieren?

Beginnen Sie mit einem sauberen Scope. Entfernen Sie Testflächen, die keinen relevanten Risikobeitrag leisten, statt einfach Testtage zu kürzen.

Stellen Sie funktionierende Testkonten, API-Dokumentation und Architekturinformationen bereit, wenn das gewählte Testmodell das erlaubt. Das reduziert Leerlauf und verschiebt Testerzeit von Discovery zu echter Sicherheitsanalyse.

Beheben Sie bekannte Basishygiene vor dem Engagement. Ein belastbares Patch Management verhindert, dass wertvolle Testzeit ausschließlich in bereits bekannte Schwachstellen fließt.

Bündeln Sie wiederkehrende Tests nur dann, wenn der Bedarf real ist. Ein Rahmenvertrag kann Procurement vereinfachen, sollte aber nicht dazu führen, dass unnötige Tests nur zur Ausschöpfung eines Kontingents durchgeführt werden.

Lohnt sich ein Penetrationstest finanziell?

Ein sauberer Business Case sollte nicht behaupten, dass ein einzelner Pentest einen bestimmten Breach sicher verhindert. Diese Kausalität lässt sich in der Praxis meist nicht belegen.

Besser ist ein risikobasierter Ansatz: Welche kritischen Assets werden getestet? Welche realistischen Angriffspfade sollen validiert werden? Wie schnell können Findings behoben werden? Welche Kunden-, Vertrags- oder Governance-Anforderungen hängen vom Ergebnis ab?

Organisationen können externe Breach-Cost-Studien wie den IBM Cost of a Data Breach Report als Kontext verwenden. Die konkrete Budgetentscheidung sollte jedoch auf dem eigenen Risiko, Systemwert und Exposure basieren, nicht auf einem pauschalen ROI-Multiplikator.

Wann sollten Unternehmen erneut testen?

Es gibt keine universelle Frequenz, die für jede Organisation passt. Sinnvolle Trigger sind wesentliche Architekturänderungen, neue kritische Funktionen, größere Cloud- oder IAM-Änderungen, signifikante Remediation und konkrete regulatorische oder vertragliche Anforderungen.

Bei hochdynamischen Anwendungen kann ein jährlicher Test zu selten sein; bei stabilen, risikoarmen Systemen kann eine andere Frequenz sinnvoll sein. Entscheidend ist, dass die Testplanung an Veränderungsrate und Risiko gekoppelt wird.

Bereit für ein belastbares Angebot?

Wenn Scope, Ziel und gewünschte Deliverables definiert sind, kann DeepStrike ein passendes Engagement kalkulieren. Die Penetration Testing Services sind für Organisationen gedacht, die manuelle Validierung, nachvollziehbare Evidenz und einen klaren Remediation-Pfad benötigen.

FAQs

Was kostet ein Penetrationstest 2026?

Es gibt keinen belastbaren Einheitspreis. DeepStrike nutzt international grob 5.000–50.000 USD oder mehr als Planungsrahmen für professionelle Third-Party-Tests; deutsche Angebote sollten jedoch anhand von Scope, Testtiefe, Deliverables und Retest verglichen werden, nicht über eine pauschale Währungsumrechnung.

Warum unterscheiden sich Pentest-Angebote so stark?

Weil “ein Pentest” keine standardisierte Mengeneinheit ist. Unterschiede entstehen durch Anzahl der Assets, Rollen, APIs, Umgebungen, Zugangsmodell, manuelle Tiefe, Reporting, Retest, Dringlichkeit und Logistik.

Ist ein Pentest unter 5.000 Euro automatisch nur ein Scan?

Nein. Ein niedriger Preis beweist weder schlechte noch gute Qualität. Prüfen Sie stattdessen, ob der Scope eng definiert ist und ob manuelle Validierung, Business-Logic-Tests, Reporting und Retest tatsächlich enthalten sind.

Welche Methode ist am günstigsten: Black Box, Grey Box oder White Box?

Keine Methode ist automatisch die günstigste. Black Box kann mehr Reconnaissance erfordern, White Box kann zusätzliche Analyse enthalten, und Grey Box kann bei Business-Anwendungen effizient sein. Der Gesamtaufwand hängt vom konkreten Ziel und Scope ab.

Sollte ein Retest im Preis enthalten sein?

Idealerweise ist die Retest-Regel vor Vertragsabschluss klar. Ob er inklusive ist, hängt vom Anbieter ab. Wichtig sind Frist, Umfang, Anzahl der Findings und die Kosten, falls der Retest außerhalb des vereinbarten Fensters stattfindet.

Wie oft sollte ein Unternehmen einen Pentest durchführen?

Die Frequenz sollte sich an Risiko, Änderungsrate, kritischen Releases sowie regulatorischen und vertraglichen Anforderungen orientieren. Ein fixes jährliches Intervall ist nicht für jede Umgebung automatisch ausreichend oder erforderlich.

Conclusion: Pentest-Kosten richtig budgetieren

Die beste Budgetentscheidung beginnt nicht mit einer Preisliste, sondern mit einem vergleichbaren Scope. Definieren Sie Ziel, Assets, Rollen, Zugangsmodell, manuelle Tiefe, Reporting und Retest, bevor Sie Angebote bewerten. So erkennen Sie, ob ein niedriger Preis durch Effizienz oder durch fehlende Leistung entsteht. Für 2026 sollte der Einkauf außerdem interne Koordination und Remediation als Teil des Gesamtaufwands betrachten. Wer diese Faktoren standardisiert, kann Pentest-Kosten nachvollziehbar planen, Anbieter fair vergleichen und Security-Budget gezielter einsetzen.

Sources and References

Für Web-Anwendungstests dient der OWASP Web Security Testing Guide als etablierte Methodikreferenz.

Für technische Sicherheitsbewertungen ist NIST SP 800-115 eine zusätzliche methodische Referenz.

Bei EU-regulatorischem Kontext sollte die konkrete Verpflichtung direkt im maßgeblichen Rechtsrahmen geprüft werden; für NIS2 ist die offizielle EUR-Lex-Fassung der Richtlinie (EU) 2022/2555 die Primärquelle. Die in diesem Artikel genannten Preisbereiche sind als DeepStrike-Planungsorientierung gekennzeichnet und nicht als unabhängiger deutscher Marktmedian dargestellt.

Über den Autor

Mohammed Khalil ist Cybersecurity Architect bei DeepStrike und spezialisiert auf fortgeschrittene Penetrationstests und offensive Sicherheitsoperationen. Mit Zertifizierungen wie CISSP, OSCP und OSWE hat er zahlreiche Red-Team-Einsätze für Fortune-500-Unternehmen geleitet. Sein Fokus liegt dabei auf Cloud-Sicherheit, Anwendungsschwachstellen und der Simulation von Angreiferverhalten. Er analysiert komplexe Angriffsketten und entwickelt robuste Verteidigungsstrategien für Kunden aus den Bereichen Finanzen, Gesundheitswesen und Technologie.