Was kostet ein Pentest inklusive Re-Test?

Einordnung und Hintergrund

Ein Penetrationstest mit anschließendem Re-Test ist der gangbare Weg, um nicht nur Schwachstellen zu finden, sondern auch nachzuweisen, dass kritische Befunde tatsächlich behoben wurden. Viele Auftraggeber unterschätzen den Aufwand für saubere Remediation: Patches, Konfigurationsänderungen und gelegentlich Architekturanpassungen brauchen Zeit – der Re-Test stellt sicher, dass die Öffnung geschlossen ist und keine Regression eingeschlichen hat.

Der Umfang „50 Assets“ in diesem Szenario meint typischerweise eine fokussierte Menge an IP-Adressen, Hosts, URLs oder Anwendungen, die explizit in den Auftrag einbezogen sind. Was nicht genannt ist – z. B. angrenzende Testsysteme, Partner-VPNs oder Alt-Applikationen ohne Wartung – bleibt außen vor und sollte schriftlich festgehalten werden. So vermeiden Sie Erwartungskonflikte und halten den Test in einem realistischen Zeitfenster (hier grob vier Wochen inklusive Bericht und einem Re-Test).

External und Internal beschreiben zwei Perspektiven: aus dem Internet (wie ein externer Angreifer) und aus dem internen Netz (Insider, kompromittierte Clients, lateral movement). Die Kombination ist besonders wertvoll, weil viele Angriffe erst nach einem ersten Fuß in der Tür intern weiterlaufen. Wir stimmen Scope, Zeitfenster und Eskalationspfade mit Ihnen ab, damit der Test produktiv bleibt und keine ungeplanten Ausfälle verursacht.

Der Management- bzw. technische Report sollte nicht nur CVEs listen, sondern Risiken einordnen: Ausnutzbarkeit, betroffene Daten, Business-Impact und Empfehlungen zur Priorisierung. Entwicklungsteams profitieren von reproduzierbaren Schritten und klaren Fix-Hinweisen; das Security-Team von KPIs, die sich über mehrere Testzyklen vergleichen lassen. Ein Re-Test validiert die wichtigsten High/Critical-Findings und stärkt das Vertrauen von Kunden, Auditoren oder Vorstand im Nachgang.

Kosten treiben Komplexität der Anwendungen, Anzahl der Umgebungen, Authentifizierungsmodelle und Sonderfälle (z. B. Mainframe, Mobile Apps, APIs mit starkem Traffic). Wenn Sie deutlich mehr Assets prüfen lassen wollen oder mehrere Re-Test-Runden benötigen, verschiebt sich die Spanne nach oben – umgekehrt kann ein eng begrenzter Scope (eine kritische Webanwendung plus API) günstiger sein. Die hier gezeigte Bandbreite ist eine belastbare Orientierung für Mittelstand und Agenturumfeld.

Nach dem Test empfehlen wir, Befunde in Ihr Ticketsystem zu überführen, Verantwortliche zu benennen und Fristen zu setzen. Wo Fixes länger dauern, können temporäre Kompensationskontrollen (Monitoring, WAF-Regeln, reduzierte Exposition) diskutiert werden – transparent dokumentiert. Für Folgejahre lässt sich ein Zyklus definieren (z. B. jährlicher Volltest, quartalsweise gezielte Retests), der regulatorischen Erwartungen und Ihrem Risikoappetit entspricht.

Wenn Sie Unterstützung bei der Umsetzung wünschen, können Pentest-Ergebnisse direkt in ein Hardening- oder Architekturprojekt münden – etwa Verschärfung von IAM, Segmentierung oder CI/CD-Security. Unsere Leistungen zu IT-Sicherheit und Security-Audits bauen genau dort an, wo der Test aufhört: bei der nachhaltigen Absicherung statt beim einmaligen PDF.

Ein Re-Test validiert gezielt die geschlossenen Hochrisiko-Befunde – nicht zwangsläufig die gesamte Angriffsfläche erneut. Scope, Zeitfenster und Abnahmekriterien werden vorab fixiert (z. B. erneuter Check der identischen Angriffsvektoren). So bleiben Kosten beherrschbar und trotzdem ist der Nachweis belastbar, dass kritische Lücken nicht wieder geöffnet wurden.

Viele Kunden benötigen Zuordnung zu normativen oder branchenspezifischen Rahmenwerken. Aus Pentest-Findings lassen sich sinnvolle Brücken zu ISO/IEC 27001-Controls, BSI-Bausteinen oder TISAX ableiten – ohne die Tests selbst als Zertifizierung zu missverstehen. Wir kennzeichnen klar, was belegt wurde und was zusätzliche Audits oder Prozesse braucht.

Die Übergabe an Entwicklungsteams funktioniert am besten mit reproduzierbaren Schritten, Screenshot- bzw. Request-Pfaden und klaren Schweregraden. Optional vereinbaren wir Triage-SLAs: Wer priorisiert, bis wann liegt ein Fix-Plan vor, wann ist Retest geplant? Das verhindert, dass kritische Findings in Backlogs versanden, während Fristen von Kunden oder Regulatoren näher rücken.

Release-Fenster, Change-Freeze und Hochlastphasen (z. B. Black Week, Jahresabschluss) sollten in die Planung einbezogen werden. Ein Pentest kurz vor Go-live ohne Puffer für Fixes erhöht Druck und Kosten. Wir empfehlen, Test- und Remediation-Phasen bewusst vor kritischen Business-Events zu legen oder einen zweigeteilten Ansatz (Pre-Prod-Test, Produktion nach Stabilisierung) zu wählen.

APIs, Mobile Clients und Admin-Oberflächen teilen sich oft dieselbe Geschäftslogik, verhalten sich für Angreifer aber unterschiedlich. Im Scope sollte klar sein, ob GraphQL/REST-Endpunkte, Partner-Integrationen oder nur die öffentliche Web-UI geprüft werden – inklusive Rate-Limits, AuthZ auf Objektebene und Fehlerbehandlung, die keine sensitiven Daten leakt. Eine saubere Scope-Definition verhindert spätere Diskussionen über „vergessene“ Eingangstore.

Viele Rahmenverträge und Ausschreibungen verlangen einen aktuellen Pentest-Nachweis oder zumindest nachvollziehbare Security-Artefakte. Wir strukturieren Reports so, dass sie sich für Lieferantenfragebögen und Due-Diligence nutzen lassen, ohne unnötige technische Details preiszugeben. Wo erforderlich, liefern wir eine separate Management-Attestierung, die Fristen, Scope und Retest-Status zusammenfasst.

Logging und Monitoring sollten so geplant sein, dass Analysten während und nach dem Test relevante Spuren sehen – ohne dass der Pentest selbst produktive Traces „überschwemmt“. Wir stimmen Testfenster, Sampling-Regeln und Alarmierungs-Schwellen mit Ihrem SOC oder Betrieb ab, damit Übungen und echte Vorfälle unterscheidbar bleiben und keine falschen Major-Incidents ausgelöst werden.