Penetrationstests sind gezielte Angriffe auf IT-Systeme, um deren Sicherheitsniveau zu prüfen und Schwachstellen aufzudecken. Tester simulieren dabei das Vorgehen von Hackern.
Es gibt drei Hauptkontexte für Penetrationstests:
Strafrecht
Ohne Einwilligung können Penetrationstests Straftatbestände erfüllen, insbesondere:
Wichtig: Das Einverständnis des Unternehmens (im Rahmen des Vertrags oder der Bug-Bounty-Regeln) schließt die Strafbarkeit meist aus. Handeln außerhalb dieser Grenzen ist nicht gedeckt.
Zivilrecht:
Unabhängig von der Strafbarkeit besteht immer das Risiko der zivilrechtlichen Haftung für Schäden, die während des Tests entstehen (z.B. Systemausfälle, Datenverluste, Reparaturkosten). Dies gilt auch bei vereinbarten Tests, wenn der Tester fehlerhaft handelt oder den vereinbarten Rahmen überschreitet. Für Hacker, die ohne Auftrag handeln, ist das Risiko besonders hoch.
Fazit:
Penetrationstests sind ein wichtiges Werkzeug zur IT-Sicherheit, bergen aber erhebliche rechtliche Risiken, vor allem wenn sie ohne klare vertragliche Grundlage oder außerhalb der Regeln von Bug-Bounty-Programmen durchgeführt werden.
Eine klare Einwilligung und die Einhaltung des vereinbarten Rahmens sind essenziell, um straf- und zivilrechtliche Konsequenzen zu vermeiden.
Nahezu jedem AV-Vertrag liegt ja ein Dienstleistungsvertrag zugrunde, in dem die Leistungen, die Rechte und Pflichten der Parteien beschrieben sind.
Wir empfehlen, folgende Punkte im Hauptvertrag mit dem Kunden/den Dienstleister zu beachten:
•Anonymisierung/Pseudonymisierung/Testdaten: Die sicherste Variante wäre, den Penetrationstest (insbesondere den internen Teil) in einer Testumgebung durchzuführen, die stark anonymisierte/pseudonymisierte Daten enthält, sodass kein Rückschluss auf Einzelpersonen mehr möglich ist. Prüfen Sie, ob dies für die Zwecke des Investors ausreichend sein könnte.
•Einschränkung des Testumfangs: Verhandeln Sie mit dem Investor und dem Tester, ob der Umfang des internen Tests reduziert werden kann. Muss wirklich auf alle Kundendaten zugegriffen werden? Reicht vielleicht der Test bestimmter Schnittstellen oder Systeme ohne direkten Zugriff auf die produktiven Datenbanken? Kann der Zugriff auf "Read-Only" beschränkt werden?
•Verschärfte Aufsicht: Lassen Sie den internen Test durch eigene Mitarbeiter eng begleiten und überwachen, um sicherzustellen, dass der Tester nur vereinbarungsgemäß agiert und nicht unnötig auf Daten zugreift.
•Noch besser: Argumentieren Sie gegenüber dem Investor, dass die bereits vorgelegten und positiv bewerteten ISMS/DSM-Unterlagen sowie ggf. vorhandene Zertifizierungen (z.B. ISO 27001) und frühere Auditberichte ausreichende Sicherheit über die Informationssicherheit geben und ein solch tiefer Eingriff nicht (oder nur in reduziertem Umfang) notwendig ist.
•Vertragliche Zusicherungen: Ergänzen Sie den AVV um besonders strenge Klauseln bezüglich Vertraulichkeit, Zweckbindung und Löschung der Daten nach Testende.
Zusätzliche Maßnahmen
Zusätzlich zum AV-Vertrag ist eine interne Dokumentation und Bewertung dringend zu empfehlen und praktisch notwendig, um der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO nachzukommen. Diese sollte mindestens folgende Punkte umfassen:
•Klare Definition des Ziels (Identifizierung von Schwachstellen im Rahmen der Due Diligence auf Anforderung des Investors).
•Rechtsgrundlage (Art. 6 DSGVO) definieren und dokumentieren für die Verarbeitung
•Das berechtigte Interesse: Sicherstellung der Informationssicherheit, Erfüllung der Anforderungen des Investors zur Ermöglichung des Vertragsschlusses.
•Interesse des Investors: Bewertung der IT-Sicherheit als Teil der Due Diligence vor einer Entscheidung
•Abwägung durchführen: Diese Interessen müssen gegen die Interessen, Grundrechte und Grundfreiheiten der betroffenen Personen (Kunden, Mitarbeiter) abgewogen werden. Hierbei ist entscheidend, wie tief der Zugriff erfolgt, welche Daten betroffen sind und welche Schutzmaßnahmen getroffen werden. Die Erwartungshaltung der Betroffenen spielt ebenfalls eine Rolle (können Mitarbeiter/Kunden damit rechnen, dass ihre Daten im Rahmen solcher Sicherheitstests eingesehen werden?).
•Umfang des Zugriffs & Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO): Definieren Sie genau, auf welche Systeme und welche Daten (Art, Umfang) der Tester Zugriff erhält. Der Zugriff muss auf das absolut Notwendige beschränkt sein. Kann der Test z.B. nur auf bestimmte Systeme oder mit Testdaten/anonymisierten/pseudonymisierten Daten erfolgen?
•Risikoanalyse: Bewerten Sie die Risiken, die durch den Zugriff des Dritten auf die personenbezogenen Daten entstehen (z.B. Risiko eines Datenabflusses, unbefugte Kenntnisnahme, Missbrauch).
•Schutzmaßnahmen (Art. 32 DSGVO): Dokumentieren Sie die technischen und organisatorischen Maßnahmen (TOMs), die Sie und der beauftragte Tester ergreifen, um die Daten während des Tests zu schützen (z.B. strenge Zugriffskontrollen, Verschlüsselung, Protokollierung, Vertraulichkeitsverpflichtungen für die Tester, sichere Löschung von Testdaten nach Abschluss). Prüfung der Notwendigkeit einer Datenschutz-Folgenabschätzung (DSFA) (Art. 35 DSGVO): Prüfen Sie, ob der Test wahrscheinlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Faktoren können sein: Umfang der Daten, Art der Daten (besondere Kategorien?), systematische Überwachung (auch wenn zeitlich begrenzt), Einsatz neuer Technologien. Wenn ein hohes Risiko wahrscheinlich ist, muss eine DSFA durchgeführt werden. Allein der Zugriff auf eine große Menge an Kundendaten durch einen externen Dritten könnte bereits eine DSFA-Pflicht auslösen. Dokumentieren Sie Ihre Prüfung und deren Ergebnis
Stand: Mai 2025
Zum Newsletter anmelden und sparen
10 € Rabatt auf Ihre erste Seminaranmeldung
