Wer im deutschen Mittelstand heute einen Pentest beauftragt, trifft auf einen Widerspruch: DSGVO Art. 32 schreibt „Sicherheit der Verarbeitung" vor — aber ein Pentest selbst ist oft schon ein DSGVO-Problem. In diesem Beitrag erklären wir, warum und was die Lösung ist.
Der Widerspruch
Ein Standard-Pentest bei einem SaaS-Anbieter läuft so: Der Kunde gibt seine Domains/IP-Ranges ins Tool ein, der Scan startet, Ergebnisse werden auf dem Anbieter-Server gespeichert, ein PDF-Report wird erzeugt. Für US-basierte Tools (Intruder, Tenable, Qualys) bedeutet das:
- Scan-Rohdaten (inkl. Subdomain-Strukturen, Software-Versionen, offene Ports) gehen in US-Infrastruktur
- Rechtsgrundlage: meist EU-US Data Privacy Framework (DPF) seit 2023 — rechtlich wackelig, da es vom EuGH jederzeit gekippt werden kann (wie bei Schrems I und II)
- Für Unternehmen mit Gesundheitsdaten, Finanzdaten oder Kommunaldaten: gar nicht zulässig, auch mit DPF
Was die Aufsichtsbehörden sagen
Die Datenschutz-Konferenz (DSK) hat in ihrer Orientierungshilfe „Maßnahmen zum Schutz personenbezogener Daten" (2023) klargestellt: Auch Metadaten wie IP-Strukturen, Nutzer-Zuordnungen und Zugriffsmuster sind personenbezogen, sobald sie mit realen Personen verknüpfbar sind.
Für ein Krankenhaus heißt das konkret: der Scan der internen Netze (mit Hostnamen wie
radiologie-arzt-meier-pc) darf nicht in ein US-Tool hochgeladen werden.
Nicht mit DPF, nicht mit Standardvertragsklauseln.
Die drei Wege aus dem Dilemma
Weg 1: Intern aufbauen
Interne Pentester einstellen, eigene Toolchain entwickeln. Realistisch nur für Organisationen ab 500 Mitarbeitern mit IT-Sicherheitsbudget.
Weg 2: Rein deutschsprachige Dienstleister
Dienstleister wie SySS, usd, Secuvera führen Pentests vor Ort durch, Daten bleiben in DE. Hochwertig, aber teuer (ab ~15.000 EUR pro Pentest) und nur einmal jährlich sinnvoll.
Weg 3: Self-hosted Tooling
Tools wie OpenVAS (veraltet), Nuclei (gut, aber ohne KI-Planung), Metasploit (nur Exploit-Framework, keine Scan-Automatisierung). Historisch fehlte eine moderne, KI-gestützte Self-hosted Plattform. Das ändern wir mit SentinelClaw.
Was ein DSGVO-konformer Pentest mindestens erfüllen muss
- Ausführung vollständig auf Infrastruktur unter Kunden-Kontrolle — eigener Server, eigene Cloud-Instanz in DE/EU, oder vor Ort beim Dienstleister
- Keine Metadaten-Telemetrie — das Tool darf keine „anonymisierten" Scan-Ergebnisse an den Hersteller senden (auch nicht für „Produktverbesserung")
- Rohdaten-Löschung nach Pentest — inkl. Log-Files, temporärer Caches, KI-Trainingsdaten. Konfigurierbare Retention-Periode
- Audit-Trail — jede Pentest-Aktion wird protokolliert (ISO 27001 Annex A.12.4.1), damit der Kunde bei einer Datenschutzprüfung nachweisen kann, was genau passiert ist
- Klare TOM-Dokumentation — technische und organisatorische Maßnahmen müssen im AV-Vertrag stehen, falls ein externer Dienstleister den Pentest ausführt
Was SentinelClaw konkret macht
Kurz zusammengefasst: SentinelClaw läuft als Docker-Compose-Stack auf einem Server Ihrer Wahl (eigener VPS, Hetzner-Instanz, On-Premise-Maschine). Der gesamte Pentest — Reconnaissance, Planung, Ausführung, Report — passiert auf diesem Server. Die KI-Planung nutzt lokale LLMs (Ollama), kein Call-Home. Rohdaten werden nach konfigurierbarer Zeit automatisch gelöscht. Audit-Logs im SIEM-kompatiblen JSON-Format.
Technische Details zur Architektur gibt es in unserem Post „SentinelClaw-Architektur: Landlock LSM + NemoClaw erklärt".
Fazit
DSGVO-konforme Pentests sind kein theoretisches Problem — sie sind die neue Normalität für jeden deutschen Mittelständler mit sensiblen Daten. Self-hosted Tooling wird zum Compliance-Standard, nicht zum Nice-to-have.
Wenn Sie Fragen zur konkreten Umsetzung haben — ob mit SentinelClaw oder anderen Tools — melden Sie sich unter kontakt@techlogia.de. Erstberatung kostenlos.