DSGVO und EU-Hosting: Worauf Teams bei Entwickler-Tools achten sollten

Wenn ein Unternehmen ein neues Analytics-Werkzeug einführen will, ist der Ablauf inzwischen eingespielt: Der Datenschutzbeauftragte fragt nach dem Auftragsverarbeitungsvertrag, jemand prüft den Serverstandort, die Datenschutzerklärung wird ergänzt. Beim Werkzeugkasten der Entwicklungsabteilung läuft es oft anders: Ein Teammitglied findet ein nützliches Tool, legt einen Account an, und drei Monate später ist es stiller Bestandteil des Arbeitsalltags. Diese Ungleichbehandlung hat keinen sachlichen Grund — auch Entwickler-Werkzeuge verarbeiten Daten, und manche mehr, als ihren Nutzern bewusst ist.

Testdienste sind dafür ein gutes Anschauungsobjekt. Ein Screenshot-Dienst etwa fotografiert Webseiten — und ein Foto einer Webseite enthält alles, was diese Webseite zeigt. Bei einer öffentlichen Marketingseite ist das unkritisch. Interessant wird es an den Rändern: Staging-Umgebungen, die mit Kopien echter Produktionsdaten befüllt wurden. Seiten, die Nutzerkommentare, Bewertungen oder Profilbilder anzeigen. Adressen, in deren URL-Parametern Sitzungsmerkmale oder Kennungen stecken. Wer solche Seiten in einen externen Dienst gibt, überträgt unter Umständen personenbezogene Daten — auch wenn im Kopf nur „wir testen das Layout" stattfindet.

Die DSGVO sortiert eine solche Konstellation klar: Das Unternehmen, das den Dienst nutzt, bleibt Verantwortlicher für die Daten; der Dienst wird in aller Regel als Auftragsverarbeiter tätig. Diese Rollenverteilung ist keine Formalie, sondern hat eine praktische Konsequenz: Es braucht einen Auftragsverarbeitungsvertrag nach Artikel 28 — üblicherweise als Standarddokument des Anbieters —, und die Verantwortung dafür, dass die Verarbeitung insgesamt rechtmäßig ist, wandert nicht mit den Daten zum Dienstleister. Sie bleibt beim Unternehmen.

Die zweite Standardfrage gilt dem Ort der Verarbeitung. Innerhalb der EU gilt die DSGVO unmittelbar; bei Anbietern, die Daten in Drittländern verarbeiten, beginnt dagegen ein eigenes Prüfkapitel: Angemessenheitsbeschlüsse, Standardvertragsklauseln, Transfer-Folgenabschätzungen. Für Übermittlungen in die USA existiert zwar ein Angemessenheitsbeschluss, doch dessen Vorgänger wurden bereits zweimal gerichtlich gekippt, und auch der aktuelle Rahmen bleibt juristisch umstritten. Nichts davon macht US-Dienste unbenutzbar — aber jede dieser Konstruktionen ist Prüfaufwand, der bei einem EU-Standort schlicht entfällt. EU-Hosting ist insofern weniger ein Gütesiegel als eine Abkürzung: Es macht die Bewertung kürzer, nicht überflüssig.

ScanU, ein Dienst für visuelle Regressionstests und Browser-Screenshots, eignet sich hier als konkretes Beispiel, weil der Anbieter den Datenstandort explizit macht: Die Daten werden nach Anbieterangaben in Frankfurt gehostet, und der Dienst positioniert sich ausdrücklich mit Blick auf die DSGVO — nachzulesen auf der deutschen Einstiegsseite von ScanU. Für ein deutsches Unternehmen heißt das: Die Drittlandsfrage stellt sich für den Kerndienst zunächst nicht, und die Prüfung kann sich auf die üblichen Punkte konzentrieren — Vertrag, Speicherfristen, Löschung, Unterauftragsverarbeiter.

Und genau hier gehört ein ehrlicher Satz hin, der für jeden Anbieter gilt, auch für den hier betrachteten: Aussagen auf einer Produktwebsite sind Ausgangspunkt der Prüfung, nicht ihr Ergebnis. „In Frankfurt gehostet" und „DSGVO-orientiert" sind Selbstauskünfte des Anbieters — wer den Dienst geschäftlich einsetzen will, liest den Auftragsverarbeitungsvertrag, prüft die Liste der Unterauftragsverarbeiter und klärt, was bei Kündigung mit den Daten geschieht. Ein Anbieter, der solche Dokumente bereitwillig herausgibt, macht damit mehr für das Vertrauen als jede Marketingformulierung; einer, bei dem sie nicht auffindbar sind, hat die wichtigste Frage bereits beantwortet.

Wer zum ersten Mal einen Auftragsverarbeitungsvertrag liest, kann sich dabei an vier Stellen orientieren. Erstens der Gegenstand: Beschreibt der Vertrag konkret, welche Daten zu welchem Zweck verarbeitet werden, oder bleibt er austauschbar generisch? Zweitens die technischen und organisatorischen Maßnahmen, meist als Anhang: Stehen dort nachvollziehbare Angaben zu Verschlüsselung, Zugriffskontrolle und Standort — oder Allgemeinplätze? Drittens die Regelung zu Unterauftragsverarbeitern: Wird der Kunde über Wechsel informiert, und kann er widersprechen? Viertens Rückgabe und Löschung der Daten nach Vertragsende. Keine dieser Fragen setzt ein Jurastudium voraus — es sind Verständnisfragen, die jede technisch versierte Person beantworten kann. Und wo der Vertrag schweigt, ist die gezielte Rückfrage beim Anbieter der ehrlichste Test seiner Auskunftsbereitschaft.

Ein oft übersehener Prüfpunkt sind Speicherfristen — dabei sind sie datenschutzrechtlich ein Kernthema, Stichwort Datenminimierung: Daten sollen nicht länger vorgehalten werden, als der Zweck es erfordert. Bei Screenshot-Diensten bestimmt die Aufbewahrung der Prüfhistorie, wie lange Abbilder der eigenen Seiten beim Anbieter liegen. ScanU staffelt diese Historie nach Preisstufe — von drei Tagen im kostenlosen Tarif über 15 und 30 Tage bis zu 90 Tagen in der größten Stufe, wie die Preisstufen von ScanU ausweisen. Bemerkenswert daran: Aus Datenschutzsicht ist die kleinste Stufe die sparsamste. Wer lange Verläufe braucht, etwa um Regressionen über Monate einzugrenzen, wählt bewusst die längere Frist — aber es sollte eine bewusste Wahl sein, keine Voreinstellung, über die nie jemand nachgedacht hat.

Mindestens so wichtig wie die Anbieterprüfung ist das eigene Nutzungsverhalten — denn die wirksamste Datenschutzmaßnahme ist, sensible Daten gar nicht erst in den Dienst zu geben. Für Testdienste heißt das konkret: Prüfumgebungen mit synthetischen Beispieldaten befüllen statt mit Kopien der Produktionsdatenbank. Öffentliche Seiten und Layouts testen statt eingeloggter Ansichten mit echten Kundendaten. Darauf achten, dass in getesteten URLs keine Sitzungstoken oder personenbezogenen Kennungen stecken. Diese Regeln kosten wenig, gelten für jedes URL-basierte Werkzeug — und sie entschärfen die Datenschutzfrage wirksamer als jede Vertragsklausel.

Wie solche Nutzungsregeln aussehen können, passt in drei Sätze für das Team-Wiki. Erstens: In den Dienst gehen nur Adressen öffentlicher Seiten oder von Staging-Umgebungen mit synthetischen Daten — niemals Ansichten, die echte Kundendaten zeigen. Zweitens: Vor dem Anlegen eines neuen Prüfprojekts wird die URL einmal bewusst auf ihre Parameter durchgesehen; Sitzungstoken und personenbezogene Kennungen haben darin nichts verloren. Drittens: Geteilte Berichte werden wie interne Dokumente behandelt — Weitergabe nur an Beteiligte, Links nicht in öffentliche Kanäle. Solche Regeln sind in zehn Minuten formuliert und beim Onboarding neuer Kolleginnen und Kollegen schnell vermittelt. Ihr Wert liegt weniger im Wortlaut als in der Tatsache, dass das Thema einmal ausgesprochen wurde: Datenschutzpannen bei der Werkzeugnutzung entstehen selten aus Absicht — meist aus Routine, in der nie jemand die Frage gestellt hat.

Auch geteilte Berichte verdienen einen Gedanken. Teilbare Prüfberichte sind für die Zusammenarbeit ausgesprochen praktisch — genau deshalb sollte geklärt sein, wer einen geteilten Bericht öffnen kann und wie lange er verfügbar bleibt. Das ist keine Besonderheit von Testdiensten: Für Berichte gilt dasselbe wie für geteilte Dokumente in jedem Cloud-Werkzeug. Ein Bericht, der Screenshots einer unveröffentlichten Produktseite enthält, ist vertrauliches Material und sollte so behandelt werden.

Wie tief soll die Prüfung gehen? Die DSGVO selbst gibt die Antwort vor: risikobasiert. Ein Screenshot-Dienst, der öffentliche Marketingseiten fotografiert, ist ein anderes Kaliber als eine Lohnbuchhaltungs-Software mit Gehaltsdaten. Es wäre unverhältnismäßig, beide mit demselben Fragenkatalog zu überziehen — aber ebenso falsch, den kleineren Fall gar nicht anzusehen. Ein pragmatischer Mittelweg für Entwickler-Werkzeuge: Rolle klären (Auftragsverarbeiter?), Vertrag einsammeln, Datenstandort und Unterauftragsverarbeiter notieren, Speicher- und Löschfristen festhalten, Nutzungsregeln fürs Team formulieren. Das ist in überschaubarer Zeit erledigt und deckt die wesentlichen Pflichten ab.

Durchgespielt am Beispiel eines Screenshot-Dienstes sieht dieser Katalog so aus. Rolle: Der Dienst verarbeitet die übermittelten Seiteninhalte im Auftrag des Unternehmens — Auftragsverarbeiter also, folglich Vertrag nach Artikel 28 einsammeln und ablegen. Datenstandort: beim Anbieter nachlesen und notieren; bei ScanU ist Frankfurt angegeben, womit die Drittlandsprüfung für den Kerndienst entfällt. Unterauftragsverarbeiter: Liste aus den Vertragsunterlagen entnehmen oder anfordern — auch ein EU-Anbieter kann Unterdienstleister einsetzen, und erst diese Liste macht die Kette vollständig. Speicherfristen: Die gewählte Preisstufe bestimmt, wie lange Prüfhistorie und damit Screenshots vorgehalten werden; die Frist mit dem tatsächlichen Bedarf abgleichen und die Entscheidung in einem Satz begründen. Löschung: klären, was bei Kündigung mit Berichten und Verläufen geschieht. Wer diese fünf Punkte auf einer Seite dokumentiert, hat für ein Werkzeug dieser Risikoklasse das Wesentliche getan — und zugleich eine Vorlage, die sich beim nächsten Werkzeug wiederverwenden lässt. Antworten auf typische Fragen zum Dienst selbst bündelt der Anbieter in den häufig gestellten Fragen zu ScanU.

Dazu gehört auch ein Eintrag im Verzeichnis der Verarbeitungstätigkeiten — jener Pflichtdokumentation, in der ein Unternehmen festhält, welche Dienste welche Daten zu welchem Zweck verarbeiten. Das klingt bürokratischer, als es ist: Für ein Entwickler-Werkzeug sind das wenige Zeilen. Der eigentliche Wert liegt woanders: Wer den Eintrag schreibt, muss die Fragen beantwortet haben. Die Dokumentation erzwingt die Prüfung, die sonst im Alltag versickert.

Ein Einwand aus der Praxis verdient dabei eine ehrliche Antwort: Wird die Prüfung zu schwerfällig, findet sie nicht gründlicher statt, sondern gar nicht. Liegen zwischen „Werkzeug gefunden" und „Werkzeug freigegeben" sechs Wochen und drei Zuständigkeiten, legen Entwicklerinnen und Entwickler den Account irgendwann privat an — und aus einem prüfbaren Dienst wird Schatten-IT, von der niemand mehr weiß. Die Konsequenz daraus ist nicht, auf Prüfung zu verzichten, sondern sie dem Risiko anzupassen: ein schneller, dokumentierter Kurzcheck für Werkzeuge mit geringem Datenbezug, die vollständige Prüfung für alles, was an Produktionsdaten oder Kundensysteme heranreicht. Ein Team, das weiß, dass der Kurzcheck wenige Tage dauert und meist mit einem Ja endet, hat keinen Grund, ihn zu umgehen. Die belastbarste Datenschutzorganisation ist am Ende die, deren offizieller Weg schneller ist als der Umweg.

Bleibt die Gesamteinordnung. Die Wahl datensparsamer, transparent gehosteter Werkzeuge ist keine juristische Spitzfindigkeit, sondern Teil der handwerklichen Sorgfalt, die Teams an anderer Stelle längst selbstverständlich finden — niemand würde eine Datenbank ohne Backup-Konzept betreiben. EU-Hosting, klare Speicherfristen und ein sauberer Auftragsverarbeitungsvertrag sind dabei drei gute Kriterien unter mehreren, kein Ersatz für die eigene Prüfung: Auch ein in Frankfurt gehosteter Dienst kann schlecht konfiguriert, falsch genutzt oder mit den falschen Daten befüllt werden. Die Verantwortung dafür trägt nicht der Anbieter, sondern das Unternehmen, das ihn einsetzt.

Die gute Nachricht zum Schluss: Der Aufwand ist einmalig und überschaubar. Eine Stunde strukturierter Prüfung pro Werkzeug, ein kurzer Eintrag in der Dokumentation, zwei Nutzungsregeln fürs Team — mehr braucht es für die meisten Entwickler-Werkzeuge nicht. Verglichen mit dem Aufwand, eine unbedachte Datenübermittlung nachträglich erklären zu müssen, ist das ein sehr guter Tausch.