Bevor Sie einen Pentest beauftragen: der vollständige Einkäufer-Leitfaden

Die meisten gescheiterten Pentests scheitern, bevor der Tester die erste Zeile schreibt. Sie scheitern am Briefing. Dieser Leitfaden hilft Ihnen, einen Test zu beauftragen, der liefert, was Sie wirklich brauchen — und nicht zweimal zu zahlen.

Warum das Briefing wichtiger ist als der Preis

Ein Penetrationstest ist eine der wenigen Dienstleistungen, bei der der Käufer die Qualität des Ergebnisses oft nicht beurteilen kann. Wenn Sie Ihr Auto reparieren lassen, merken Sie, ob es fährt. Bei einem Pentest bekommen Sie ein Dokument mit Findings — wissen aber nicht, ob der Tester wirklich abgedeckt hat, was er sollte, oder nur einen automatischen Scanner durchgeklickt hat.

Der Unterschied zwischen einem guten und einem schlechten Test zeigt sich nicht auf der Rechnung. Er zeigt sich am Tag, an dem jemand über etwas einbricht, das der Tester „nicht getestet hat, weil es nicht im Scope war". Und es war deshalb nicht im Scope, weil Sie es nicht hineingeschrieben haben.

Das Briefing ist also Ihr einziger echter Hebel auf die Qualität. Gehen wir durch, wie man es vorbereitet.

Schritt 1: Klären Sie, warum Sie testen

Klingt trivial, ist aber der häufigste Fehler. Es gibt mehrere sehr unterschiedliche Gründe, warum Firmen Pentests beauftragen — und jeder führt zu einem anderen Testtyp:

• Regulierung oder Audit (NIS2, ISO 27001, DORA, Kundenanforderung). Hier muss der Output das enthalten, was Auditor oder Regulator sehen will — nicht zwingend maximale technische Tiefe, sondern Nachweisbarkeit und das richtige Format.
• Echte Sicherheitsprüfung vor Launch eines neuen Systems oder nach einer großen Änderung. Hier zählen Tiefe und Realismus.
• Reaktion auf einen Vorfall oder den Verdacht, dass bereits etwas nicht stimmt.
• Druck von Management oder Kunde, die ein „Papier" sehen wollen.

Wenn Sie für ein Audit testen, aber den billigsten Scan kaufen, bekommen Sie zwar das Papier, aber prüfen die Sicherheit nicht wirklich. Umgekehrt: Wenn Sie nur Compliance nachweisen müssen, lohnt sich kein monatelanges Red Team.

Schreiben Sie einen Satz: „Wir machen diesen Test, weil ___, und Erfolg erkennen wir an ___." Dieser Satz sollte die erste Zeile Ihres Briefings sein.

Schritt 2: Verstehen Sie die Testtypen

Drei Begriffe werden in der Praxis vermischt, obwohl sie völlig unterschiedlichen Aufwand und Preis bedeuten:

Vulnerability Scan (Schwachstellenscan) ist überwiegend automatisiert. Ein Tool prüft das System und listet bekannte Schwachstellen. Schnell und billig, prüft aber nicht die Ausnutzbarkeit und findet keine Logikfehler. Sinnvoll als Routinehygiene, nicht als Ersatz für einen Test.

Penetrationstest kombiniert Tools mit der manuellen Arbeit eines Testers, der aktiv versucht, Schwachstellen auszunutzen und zu verketten. Findet auch Logikfehler, die kein Scanner sieht. Das ist, was die meisten Firmen wirklich brauchen.

Red Team / Threat-led Testing ist eine umfangreiche Simulation eines realen Angreifers über Technik, Menschen und physische Sicherheit hinweg, oft über Wochen bis Monate. Ziel ist nicht, jede Schwachstelle zu finden, sondern zu prüfen, ob jemand Sie wirklich knacken kann — und ob Sie es überhaupt merken. Teuer und nur für reife Organisationen sinnvoll.

Wenn Sie im RFP „wir wollen einen Pentest" schreiben, aber einen Scan meinen — oder umgekehrt — bekommen Sie nicht vergleichbare Angebote und wundern sich, warum die Preise um den Faktor 5 schwanken.

Schritt 3: Wählen Sie das Wissenslevel (Black / Grey / White Box)

Wie viele Informationen Sie dem Tester geben, ändert Ergebnis und Preis fundamental:

• Black Box — Tester weiß nichts, simuliert externen Angreifer. Realistisch, aber viel Zeit für Recon, manches bleibt unerreichbar.
• Grey Box — Tester bekommt einen Basiszugang, z. B. einen normalen User-Account. Bestes Verhältnis aus Realismus und Effizienz, daher Standardwahl.
• White Box — Tester bekommt alles: Quellcode, Doku, Zugänge. Findet am meisten, weil keine Zeit beim Raten verloren geht. Ideal für die gründliche Prüfung kritischer Systeme.

Faustregel: Je kritischer das System, desto mehr Informationen geben Sie dem Tester. „Blind testen, damit es fair ist" klingt edel, verschwendet aber meist Budget.

Schritt 4: Definieren Sie den Scope präzise

Das ist das Herzstück des Briefings. Der Tester muss genau wissen, was er darf und was nicht. Vorbereiten:

• Konkrete Ziele — Domains, App-URLs, IP-Bereiche, API-Endpunkte, Mobile Apps. Nicht „unsere Systeme", sondern eine namentliche Liste.
• Explizit out of scope — Drittsysteme, Produktiv-DBs, alles, was nicht ausfallen darf.
• Umgebung — Produktion oder Staging? Staging ist sicherer, muss aber der Produktion entsprechen, sonst sind die Ergebnisse wertlos.
• Zeitfenster — wann getestet werden darf, damit ein Ausfall nicht schmerzt.
• Erlaubte Techniken — darf der Tester Social Engineering versuchen? DoS? Physischen Einbruch? Alles, was Sie nicht erwähnen, sollte er nicht tun.

Je konkreter der Scope, desto vergleichbarer die Angebote — und desto weniger Raum für spätere Streitereien „das haben wir nicht getestet".

Schritt 5: Mitwirkung im Voraus vorbereiten

Ein großer Teil gescheiterter Projekte scheitert daran, dass der Auftraggeber nicht bereit ist. Der Tester kommt, wartet auf Zugänge und rechnet Leerlauf ab. Vor Testbeginn bereitstellen:

• Testaccounts mit verschiedenen Berechtigungsstufen
• Zugang zur Staging-Umgebung und IP-Whitelisting für den Tester
• API- und Architekturdokumentation
• Eine Kontaktperson, die während des gesamten Tests erreichbar ist
• Interne Freigabe — IT, Recht, ggf. Cloud- oder Hosting-Anbieter

Tipp: Cloud-Anbieter (AWS, Azure) verlangen oft eine vorherige Ankündigung des Pentests. Frühzeitig regeln.

Schritt 6: Konkrete Reportform einfordern

Der Report ist das Einzige, was nach dem Test bleibt. Vorab festlegen, was er enthalten muss:

• Management Summary verständlich für die Geschäftsführung — ohne Jargon.
• Technischer Teil mit jeder Schwachstelle, CVSS-Score, Nachweis der Ausnutzbarkeit und konkreter Maßnahmenempfehlung.
• Priorisierung nach realem Risiko, nicht nur nach automatischem Score.
• Retest — Verifikation, dass behobene Findings tatsächlich behoben sind. Oft separat berechnet, also vorab fragen.

Fordern Sie vor Beauftragung einen anonymisierten Beispielreport an. Die Qualität sieht man sofort — bester Filter für Anbieter.

Schritt 7: Realistische Preiserwartungen

Der Preis hängt von Scope und Tiefe ab, nicht von einer Pauschale. Kleinere Tests beginnen im unteren fünfstelligen Bereich (EUR), große oder Red-Team-Projekte deutlich höher. Wenn von drei Angeboten eines ein Drittel kostet, ist das keine gute Nachricht — fast sicher ist ein anderer (flacherer) Scope angeboten. Immer vergleichen, was konkret enthalten ist: Personentage, Tiefe, manuelle vs. automatische Arbeit und ob ein Retest inkludiert ist.

Zusammenfassung: Checkliste vor dem RFP

Vor dem Versand der Anfrage prüfen:

• Ich weiß, warum wir testen und woran wir Erfolg messen
• Ich weiß, ob ich Scan, Pentest oder Red Team will
• Ich habe das Wissenslevel gewählt (Black / Grey / White Box)
• Ich habe eine namentliche Zielliste und klare Out-of-Scope-Punkte
• Ich habe Umgebung, Zeitfenster und erlaubte Techniken geklärt
• Ich habe Mitwirkung bereit (Accounts, Zugänge, Doku, Kontakt)
• Ich habe Report- und Retest-Format definiert
• Ich habe interne und externe Freigaben

Ein gut vorbereitetes Briefing ist der Unterschied zwischen einem Test, der Ihre Sicherheit real erhöht, und einem Test, den Sie bezahlen und in der Schublade ablegen.

Ein vollständiges Pentest-Briefing manuell vorzubereiten dauert Stunden, und etwas geht leicht vergessen. TrustScope führt Sie Schritt für Schritt durch den gesamten Prozess und erzeugt am Ende ein strukturiertes Briefing, bereit zum Versand an Anbieter — inklusive Mitwirkungs-Checkliste.