„Wir hatten letztes Jahr schon einen Scan" höre ich häufiger, als man denkt. Ein automatisierter Schwachstellenscan und ein professioneller Penetrationstest sind aber zwei grundverschiedene Dinge. Ein Scan sagt Ihnen, welche Software-Versionen bekannte Lücken haben. Ein Penetrationstest zeigt, ob diese Lücken tatsächlich ausnutzbar sind — und was ein Angreifer damit anfangen könnte. Dieser Unterschied entsteht in fünf klar abgegrenzten Phasen.
Phase 1 — Scoping & Zieldefinition
Bevor irgendetwas getestet wird, legen Auftraggeber und Tester gemeinsam schriftlich fest, was geprüft werden darf. Das ist keine Formsache — ohne diese Vereinbarung wäre derselbe Vorgang rechtlich nicht von einem echten Angriff zu unterscheiden. Festgelegt wird dabei unter anderem, welche Systeme, Domains oder IP-Bereiche im Scope sind, welche Methoden ausgeschlossen sind, das Testzeitfenster, der Eskalationsweg bei kritischen Funden und die Ansprechpartner auf beiden Seiten.
Das Ergebnis dieser Phase ist ein unterschriebenes Scope-Dokument (Rules of Engagement), das beide Seiten rechtlich absichert.
Phase 2 — Reconnaissance & Enumeration
Jetzt wird systematisch erfasst, was von außen — und, sofern vereinbart, auch von innen — sichtbar ist: offene Dienste, eingesetzte Technologien, Subdomains, Konfigurationen. Das entspricht exakt dem, was auch ein realer Angreifer als Erstes tun würde. Der Unterschied: Alles bleibt im vereinbarten Scope, und es wird dokumentiert statt ausgenutzt.
Am Ende dieser Phase steht eine strukturierte Übersicht der Angriffsfläche — und eine erste Priorisierung möglicher Schwachpunkte.
Phase 3 — Exploitation
Erst jetzt werden gefundene Schwachstellen kontrolliert ausgenutzt — nicht um Schaden anzurichten, sondern um ihre tatsächliche Auswirkung nachzuweisen. Das ist der Kern dessen, was einen Penetrationstest von einem reinen Scan unterscheidet: Ein Scanner meldet „Version X ist verwundbar". Ein Tester zeigt, ob und wie sich daraus tatsächlich ein Datenzugriff oder eine Rechteausweitung ergibt.
Manuelle, gezielte Verifikation jedes Fundes — kein reines Scanner-Ergebnis, das unreflektiert weitergereicht wird.
Kritische oder potenziell destruktive Tests werden vorab mit dem Auftraggeber besprochen. Bei akut ausnutzbaren Lücken erfolgt eine sofortige Meldung — auch vor Abschluss des restlichen Tests.
Phase 4 — Reporting
Der Bericht ist das eigentliche Produkt eines Penetrationstests. Er ist so geschrieben, dass sowohl technische Teams als auch Entscheider ohne IT-Hintergrund verstehen, was gefunden wurde und was zu tun ist. Dazu gehören ein Management Summary in Klartext, jeder Fund mit Risikoeinstufung, Nachweis und konkreter Empfehlung, sowie eine priorisierte Reihenfolge zur Behebung.
Ein guter Bericht beantwortet zwei Fragen zuverlässig: Wie schlimm ist es wirklich? Und was mache ich als Erstes?
Phase 5 — Retest
Nach der Behebung wird erneut geprüft, ob die gemeldeten Schwachstellen tatsächlich geschlossen sind — nicht nur, ob irgendeine Änderung vorgenommen wurde. Das ist ein Schritt, der in der Praxis häufig übersprungen wird, weil das Budget für den ursprünglichen Test schon aufgebraucht ist. Genau hier zeigt sich aber, ob aus Erkenntnis tatsächlich Sicherheit geworden ist.
Fazit
Die Phasenstruktur orientiert sich an anerkannten Rahmenwerken wie dem OWASP Testing Guide und dem BSI-Durchführungskonzept für Penetrationstests — angepasst auf den jeweiligen Auftrag, nicht als starres Schema. Wer das versteht, erkennt auch schnell, woran sich ein seriöses Angebot von einem reinen Scan-Verkauf unterscheiden lässt: an der Tiefe von Phase 3 und daran, ob Phase 5 überhaupt vorgesehen ist.