Penetrationstest beauftragen: 7 Fragen, die KMU vorher klären sollten

Was genau soll getestet werden – und welches Geschäftsrisiko wird adressiert?

Ein präziser Scope ist die Voraussetzung für belastbare Findings. Ohne klare Abgrenzung – welche Anwendungen, Netzwerksegmente oder Cloud-Dienste in den Test einbezogen werden – liefert ein Penetrationstest ungenaue Ergebnisse. Die wichtigste Frage vor dem Test lautet daher: Was genau soll geprüft werden und warum? Schutzbedarfsfeststellung und Risikoanalyse lenken den Umfang. Werden kritische Assets wie Produktionssysteme, Kundendatenbanken oder Zahlungsschnittstellen außen vor gelassen, verbrennt ein „Alles-auf-einmal“-Ansatz Budget, ohne die tatsächlich relevanten Risiken zu beleuchten.

Konkrete Abgrenzungskriterien verhindern Missverständnisse: Produktionssysteme versus Testumgebungen, interne versus externe Perspektive, Einbeziehung von APIs oder Mobile-Apps. Die TeleTrusT-Mindestanforderungen fordern eine projektspezifische Zielsetzung als verpflichtenden Bestandteil jedes Angebots. Laut TeleTrusT-Handreichung muss ein Angebot mindestens vier Punkte enthalten: projektspezifische Zielsetzung, Leistungsbestandteile mit Vorgehensweise, Qualifikation des Personals und Einsatzort. Besser ein kleinerer, fokussierter Test mit klaren Befunden als ein großer, oberflächlicher Scan. Der Scope muss das Geschäftsrisiko spiegeln – nicht die Anzahl der IP-Adressen.

Welche Methodik-Frameworks (OWASP, PTES, BSI-Leitfaden) wendet der Anbieter an?

Drei Standards prägen den deutschen Markt: Der OWASP Testing Guide deckt Web-Applikationen ab, der PTES liefert den prozessualen Rahmen von Voraufklärung bis Nachbereitung, der BSI-Praxis-Leitfaden übersetzt Anforderungen in nationale Compliance-Sprache. Ein seriöser Anbieter nennt die eingesetzten Frameworks im Angebot namentlich und grenzt manuelle Tests klar gegen reine Vulnerability-Scans ab. Der manuelle Anteil muss im Bericht dokumentiert sein – nur so lässt sich nachvollziehen, welche Logikfehler oder Business-Logic-Lücken automatisierte Tools übersehen.

Transparenz belegen geschwärzte Musterberichte: Sie zeigen Struktur, Schweregrad-Klassifizierung (CVSS, risikobasiert) und Handlungsempfehlungen ohne Kundendaten. Fehlt ein solches Sample, bleibt die Methodik eine Blackbox. Ein weiteres Qualitätsmerkmal sind rotierende Tester-Teams – unterschiedliche Perspektiven decken blinde Flecken auf, die ein festes Team übersehen kann. Für KRITIS-Betreiber, Finanzdienstleister unter DORA oder Unternehmen im NIS2-Geltungsbereich wird die Methodikwahl zum Compliance-Nachweis: Prüfer fordern nachweisbar standardkonforme Vorgehensweisen, keine Ad-hoc-Scans. Der BSI-Praxis-Leitfaden und PTES werden dabei als Referenzrahmen für die Prüfungstiefe herangezogen.

Welche Zertifikate haben die tatsächlich eingesetzten Tester (OSCP, GPEN, CRTO)?

Firmenzertifikate wie ISO 27001 belegen organisatorische Reife, sagen aber nichts über die Hände am Keyboard aus. Entscheidend sind personale Qualifikationen: OSCP (Offensive Security) für praktische Exploitation, GPEN (GIAC) für methodische Tiefe, CRTO für Red-Team-Taktiken, OSWE bei Web-Applikationen und CBBH für Bug-Bounty-Erfahrung. Fordern Sie namentliche Nachweise, dass genau diese Personen Ihr Projekt bearbeiten – kein „Bait-and-Switch“, bei dem Senior-Profile verkaufen und Juniors liefern.

Ergänzen Sie Zertifikate durch Referenzprojekte gleicher Branche und Größenordnung. Ein Anbieter, der Krankenhäuser oder Finanzdienstleister auditiert, kennt deren Regulatorik und Angriffsflächen. Neutrale Auswahlkataloge wie der von sodusecure oder der Leitfaden von Secuvera listen Kriterien auf, die über Zertifikatslisten hinausgehen: manueller Testanteil, Reporting-Qualität, Retesting-Regelung. Prüfen Sie Musterberichte (geschwärzt) – sie zeigen, ob Findings reproduzierbar dokumentiert werden oder nur Scanner-Output wiedergeben. Aktuelle Trends zeigen: Anbieter müssen nachvollziehbar darlegen, wie hoch der manuelle Anteil ggü. automatisierten Scans ist.

Liegen eine schriftliche Beauftragung vor, sind DSB und Personalvertretung eingebunden?

Ein Penetrationstest ohne schriftlichen Auftrag ist rechtlich angreifbar. Der Vertrag muss Scope, Rules of Engagement und Haftungsregelung verbindlich festlegen. Fehlt diese Basis, drohen Strafbarkeitsrisiken nach § 202a StGB (Ausspähen von Daten) oder § 303a StGB (Datenveränderung). Der BSI-Leitfaden für IS-Penetrationstests fordert ausdrücklich eine dokumentierte Beauftragung vor Testbeginn.

Verarbeiten Testsysteme personenbezogene Daten, greift Art. 28 DSGVO: Ein Auftragsverarbeitungsvertrag (AVV) ist Pflicht. Der Zweckbindungsgrundsatz verbietet die Nutzung der Daten über den Testzweck hinaus. Der Datenschutzbeauftragte muss nach Art. 39 DSGVO vorab eingebunden werden – nicht erst bei Findings. Ab 20 Personen, die ständig mit automatisierter Verarbeitung beschäftigt sind (§ 38 BDSG), besteht Benennungspflicht. Unabhängig davon hat der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG Mitbestimmungsrechte bei technischen Überwachungseinrichtungen. Die Orientierungshilfe der Datenschutzkonferenz (DSK) zu Penetrationstests & Datenschutz konkretisiert diese Pflichten für die Praxis.

Bei Cloud-Zielen gelten die BSI-Mindeststandards für Cloud-Dienste sowie die Orientierungshilfe der Datenschutzkonferenz. Beide verlangen klare Verantwortlichkeiten und technische Trennungen. Fachanwaltliche Begleitung sichert die rechtliche Absicherung aller Beteiligten ab. Compliance-getriebene Nachfrage durch BSI-Mindeststandards, KRITIS, DORA und NIS2 treibt KMU zunehmend zu regelmäßigen Pentests.

Wer ist 24/7 erreichbar, wenn kritische Findings (CVSS ≥ 9, Active Exploitation) auftreten?

Kritische Schwachstellen mit aktivem Exploit erfordern sofortige telefonische Alarmierung – E-Mail allein reicht nicht. Der Vertrag muss benannte Ansprechpartner auf Kundenseite festlegen: IT-Leitung, CISO oder Geschäftsführung, jeweils mit vertretungsberechtigtem Deputy. Ein Kommunikationsprotokoll regelt die Übermittlung: Finding-Beschreibung, Impact-Einschätzung, empfohlene Sofortmaßnahmen und verbindliches Retest-Zeitfenster. Dieser Prozess dockt direkt an den Incident-Response-Plan des Unternehmens an. Reaktionszeiten gehören vertraglich fixiert (SLA), damit im Ernstfall keine Diskussionen über Zuständigkeiten entstehen. Anbieter wie Schutzwerk listen Notfallkontakte bereits im Onboarding, während Nesec Eskalationsstufen im Methodik-Dokument ausweist. Fehlt die 24/7-Erreichbarkeit, verzögert sich die Eindämmung messbar – besonders bei internetseitigen Systemen mit Public-Exploit-Code. Voraussetzungen für die Beauftragung umfassen laut Schutzwerk: schriftliche Beauftragung, festgelegter Scope, definierte Bedrohungsszenarien und Notfallkontakte für kritische Findings.

Wie ist Retesting vertraglich geregelt (Umfang, Frist, Kosten, Dokumentation)?

Ein professioneller Pentest endet nicht mit dem Bericht. Entscheidend ist, ob und wie der Anbieter nachbessert, nachdem Schwachstellen geschlossen wurden. Verträge müssen unterscheiden: Ein verbindlicher Retest aller Critical- und High-Findings gehört zum Festpreis. Ein freiwilliger Retest aller Findings – auch Medium und Low – kann separat vereinbart werden, sollte aber nicht als Standard fehlen. Branchenleitfäden empfehlen einen festen Nachtest-Zeitraum von 30 bis 60 Tagen nach Report-Lieferung, ohne Zusatzkosten im Pauschalpreis secuvera.de.

Klarheit schafft auch die Methode: Erfolgt der Retest manuell durch die ursprünglichen Tester oder lediglich per automatisiertem Scan? Manuelle Verifikation wiegt schwerer, gerade bei Logikfehlern. Das Ergebnis muss dokumentiert werden – idealerweise als Delta-Report, der nur die nachgetesteten Positionen zeigt, oder als aktualisierter Hauptreport mit Status „behoben“, „teilweise behoben“, „offen“. Anbieter, die Retesting generell als separates Time-&-Material-Projekt kalkulieren, verschieben Kostenrisiko auf den Auftraggeber nica-it.de.

Vertraglich festzuhalten sind: Umfang (welche Findings), Frist (Start/Ende), Kostenmodell (inklusiv oder T&M), Dokumentationsform und Kommunikationsweg bei neuen Erkenntnissen während des Retests. Fehlen diese Punkte, drohen Diskussionen über Scope und Budget, sobald der erste Patch deployed ist. Retesting wird zunehmend zur Standard-Erwartung – vertragliche Fixierung von Nachtest-Zeitraum, -Umfang und -Dokumentation wird zum Auswahlkriterium.

Festpreis oder Time-and-Material – und ist ein jährlicher Turnus mit rotierenden Teams geplant?

Für den ersten Penetrationstest bei KMU empfiehlt sich ein Festpreis-Modell. Der Aufwand lässt sich bei bekanntem Scope gut abschätzen; Überraschungen bleiben kalkulierbar. Ein Praxisratgeber nennt als Orientierung ein Volumen unter 10.000 € für kleine Erstuntersuchungen. Manche Anbieter setzen für größere Projekte ein Stammkapital von 25.000 € voraus. Time-and-Material lohnt erst, wenn der reale Sicherheits-Aufwand aus vorangegangenen Tests bekannt ist – sonst drohen offene Kostenspiralen. Abo-Modelle (Continuous Pentesting) greifen erst ab Reifegrad 3+, also wenn Prozesse, Tooling und Retest-Routinen etabliert sind.

Die Mindestfrequenz liegt bei einmal jährlich – so die Empfehlung von BSI und it-daily.net. Wichtig: rotierende Tester-Teams zwischen den Zyklen einplanen. Unterschiedliche Prüfer finden unterschiedliche Schwachstellen; der Perspektivwechsel erhöht die Fundquote messbar. Vertraglich sollte feststehen, wer wann testet und wie der Wissenstransfer gelingt.

Budgetplanung: Zwischen Beauftragung und Teststart vergehen mehrere Wochen Lead-Time (Terminfindung, Scope-Abnahme, Zugriffsrechte). Das einpreisen. Bei der Kosten-Nutzen-Abwägung gilt: Scope-Erweiterung (z. B. weitere Applikation, internes Netz) liefert oft mehr Erkenntnis pro Euro als eine Frequenz-Erhöhung auf halbjährlich bei gleichem, schmalem Scope. Ein Anbieter-Vergleich zeigt, dass viele Dienstleister Retesting im Festpreis enthalten – das klären, bevor der Vertrag unterschrieben wird. Scope-Präzision vor Umfang: Lieber kleinerer, fokussierter Pentest mit klaren Findings als großer, oberflächlicher.

Welche Vorbereitungen (Asset-Inventar, Testumgebungen, Notfallkontakte) sind intern zu treffen?

Erstellen Sie ein aktuelles Asset-Inventar, bevor der Prüfer startet. Erfassen Sie alle IP-Ranges, öffentlichen Domains und APIs, die in den Scope fallen. Ohne vollständige Bestandsaufnahme bleiben Systeme unbeachtet und der Penetrationstest liefert nur lückige Ergebnisse. Ein konkretes Beispiel: Ein KMU vergass eine veraltete API-Schnittstelle im Subnetz 10.0.3.0/24 – der Scanner erfasste sie nicht, der manuelle Tester fand dort eine offene Admin-Konsole ohne Authentifizierung.

Richten Sie separate Test- oder Staging-Umgebungen ein. Produzierende Systeme dürfen nicht direkt angegriffen werden. Legen Sie Testaccounts mit den genau benötigten Rechten an und vermeiden Sie überhöhte Privilegien. Damit begrenzen Sie Seiteneffekte und schützen laufende Geschäftsprozesse. Für Datenbanktests empfiehlt sich eine anonymisierte Kopie der Produktivdaten – so testen Sie realistische Datenmengen ohne Datenschutzrisiko.

Konfigurieren Sie Whitelisting für die Prüfer-IPs in WAF und IPS. Blockieren Ihre eigenen Abwehrsysteme den Testverkehr, verfälschen sich die Befunde und der Test liefert keine valide Sicherheitslage. Dokumentieren Sie die Freigaben protokolliert, damit sie nach Testende wieder entfernt werden.

Benennen Sie Notfallkontakte mit 24/7-Erreichbarkeit und Entscheidungsbefugnis. Bei kritischen Findings muss eine verantwortliche Person sofort reagieren und Freigaben für Gegenmaßnahmen erteilen können. Hinterlegen Sie mindestens zwei Deputies pro Rolle – Urlaub oder Krankheit dürfen den Eskalationspfad nicht unterbrechen.

Prüfen Sie den Datenschutz vorab. Sind personenbezogene Daten in den Testdaten enthalten, binden Sie den Datenschutzbeauftragten und ggf. die Personalvertretung ein. Klären Sie zudem, ob ein Auftragsverarbeitungsvertrag (AVV) mit dem Testanbieter erforderlich ist. Die DSK-Orientierungshilfe empfiehlt, Zweck und vertragliche Regelung vor Testbeginn schriftlich zu fixieren.

Strukturierte Vorbereitung gelingt mit bewährten Checklisten aus der Praxis. Die Pentest-Vorbereitung von Wenske CS führt durch die zentralen Schritte. Auch n-komm beschreibt eine detaillierte Planung, mit der Sie den Scope rechtssicher und zielgerichtet definieren.

Welche häufigen Fehler (Scope-Creep, reiner Scan, fehlendes Retest) sollten vermieden werden?

Ein unscharfer Scope bleibt der klassische Einstieg in den Scope-Creep: Anforderungen wachsen während des Tests, das Budget läuft über, Findings bleiben vage. Klare Abgrenzung vor Vertragsschluss verhindert das. Zweiter Fehler: Ein reiner Vulnerability-Scan wird als Penetrationstest verkauft. Automatisierte Scanner finden bekannte CVEs, aber keine Business-Logic-Lücken und keine manuellen Exploits — echte Angreifer nutzen genau diese Pfade.

Dritter Stolperstein: Fehlende Retest-Vereinbarung. Kritische Findings (CVSS ≥ 9) bleiben oft Monate offen, weil Nachtest-Umfang, Frist und Kosten nicht vertraglich fixiert waren. Der Leitfaden von Sysadminslife empfiehlt, Retesting bereits im Angebot zu klären. Viertens: Datenschutzbeauftragter und Betriebsrat werden erst nach Testbeginn eingebunden. Bei personenbezogenen Daten verletzt das Art. 35 DSGVO und das BDSG — Zweckbindung und Auftragsverarbeitung müssen vorher stehen.

Fünftens: Berichte ohne Management-Summary. Entscheider erhalten 50 Seiten technischer Detail, aber keine priorisierte Handlungsempfehlung. Ein Überblick bei Sectepe zeigt, wie fehlende Zusammenfassungen Sanierungsbudgets verzögern. Fallbeispiel: Ein KMU ließ einen Webshop scannen, bekam nur CVE-Listen. Ein manueller Test fand später eine IDOR-Lücke im Bestellprozess — der Scanner hatte sie übersehen. Sechster Fehler: Keine rotierenden Teams bei Folgejahren. Derselbe Tester prüft dieselben Systeme – blinde Flecken bleiben bestehen. Siebter Fehler: Lead-Time unterschätzt. Ohne Puffer für Scope-Abnahme und Zugriffsrechte verschiebt sich der Teststart um Wochen.

Wann ist der richtige Zeitpunkt für den ersten (oder nächsten) Penetrationstest?

Ein Penetrationstest liefert nur dann belastbare Aussagen, wenn er zum passenden Zeitpunkt in den Lebenszyklus der Anwendung oder Infrastruktur fällt. Klassische Trigger sind der Go-Live neuer Anwendungen, größere Architekturänderungen wie Cloud-Migrationen oder der Umstieg auf Microservices sowie Compliance-Vorgaben – etwa ISO 27001, TISAX, KRITIS, DORA oder NIS2. Auch nach Sicherheitsvorfällen (Lessons Learned) und turnusmäßig mindestens einmal jährlich sollte getestet werden, wie der BSI-Praxisleitfaden und Fachbeiträge empfehlen (ccvossel.de).

Planen Sie mehrere Wochen Lead-Time zwischen Beauftragung und Teststart ein – Terminfindung, Scoping und rechtliche Freigaben brauchen Puffer. Wer nur punktuell prüft („Point-in-Time“), übersieht Lücken zwischen den Tests. Continuous Security Validation oder rotierende Tester-Teams schließen diese Lücke, indem sie Angriffsvektoren fortlaufend oder mit wechselnden Perspektiven prüfen (it-daily.net).

Koppeln Sie Testfenster an Patch-Management-Zyklen und Release-Kalender: Testen Sie nach größeren Patch-Tagen oder vor geplanten Major-Releases, nicht mitten im laufenden Sprint. So bleiben Findings relevant und Retests lassen sich in den regulären Deploy-Prozess einbetten, statt als Störfaktor zu wirken. Ein konkretes Zeitfenster: Zwei Wochen nach dem monatlichen Patch-Tuesday für Microsoft-Umgebungen, oder direkt vor dem Quartals-Release bei eigenen SaaS-Produkten.