Wo liegen die Daten aus Ihren Formularen?

Eine Fahrschule in Thun hat auf ihrer Website ein Anmeldeformular: Name, Adresse, Geburtsdatum, Telefonnummer, Kategorie, dazu ein Feld für Bemerkungen, in das gelegentlich etwas über eine Sehhilfe geschrieben wird. Das Formular funktioniert seit Jahren. Eines Tages fragt eine Kundin am Telefon, wo diese Angaben eigentlich gespeichert werden.

Die Frage ist einfach gestellt und überraschend schwer zu beantworten, wenn niemand im Betrieb je nachgesehen hat. Sie ist aber beantwortbar, und zwar ohne technisches Spezialwissen: Die Antwort steht in einer Handvoll Dokumente, die bereits existieren, und der Weg der Daten hat weniger Stationen, als man vermuten würde.

Die Kette, Station für Station

Zwischen dem Klick auf «Senden» und dem Moment, in dem jemand im Betrieb die Antwort liest, liegen meistens dieselben Stationen.

Station	Was dort geschieht
Browser	Die Eingaben werden zu einer HTTP-Anfrage zusammengesetzt
Zieladresse des Formulars	Die Anfrage geht an den Server, der im Formular hinterlegt ist
Anwendung des Anbieters	Die Antwort wird geprüft, gespeichert, protokolliert
Speicher und Sicherungen	Datenbank, Dateiablage für Uploads, Backups
Benachrichtigung	Eine E-Mail mit dem Inhalt der Antwort geht an den Betrieb
Anschlüsse	Export, Tabelle, Buchhaltung, Newsletter-Werkzeug, Webhook

Jede dieser Stationen ist ein Ort, und Orte lassen sich benennen. Die vier Unterscheidungen dahinter — Speicherort, Rechtsordnung, Zugriff und Unterauftragnehmer — haben wir in einem eigenen Beitrag auseinandergenommen; hier geht es um den konkreten Weg einer einzelnen Formularantwort.

Station 1: Wohin das Formular sendet

Ein HTML-Formular hat ein Attribut namens action. Es legt fest, wohin die Daten gehen. Die MDN Web Docs beschreiben es so: Das action-Attribut definiert, wohin die Daten gesendet werden, und sein Wert muss eine gültige relative oder absolute URL sein; fehlt das Attribut, gehen die Daten an die URL der Seite, auf der das Formular steht.

Diese eine Zeile entscheidet mehr als alles andere auf der Seite. Steht dort eine Adresse der eigenen Domain, bleibt die Antwort zunächst beim eigenen Hosting. Steht dort die Adresse eines Formulardienstes, verlässt die Antwort die eigene Website in dem Moment, in dem jemand «Senden» drückt — auch wenn das Formular optisch eingebettet ist und die Besucherin die eigene Website gar nie verlassen hat.

Ob die Übertragung verschlüsselt ist, hängt am Protokoll dieser Adresse. Wird eine HTTPS-Adresse verwendet, werden die Daten zusammen mit dem Rest der Anfrage verschlüsselt; liegt das Formular auf einer sicheren Seite, zeigt aber auf eine unverschlüsselte HTTP-Adresse, warnen laut MDN alle Browser beim Absenden.

Wichtig ist dabei, was die Verschlüsselung der Übertragung leistet und was nicht: Sie schützt den Transportweg. Über den Ort, an dem die Antwort danach abgelegt wird, und über die Frage, wer sie dort lesen kann, sagt sie nichts.

Station 2: Was die Dokumentation des Anbieters sagt

Am Ziel der Adresse steht ein Dienst, und die meisten Dienste dokumentieren öffentlich, wo sie speichern. Zwei Beispiele, beide aus der Dokumentation des jeweiligen Anbieters selbst.

Microsoft Forms. Microsoft führt Forms in der Liste der «Additional Microsoft 365 Services» — jener Dienste, für die, sofern die Produktbestimmungen nichts anderes festlegen, keine spezifischen Zusagen zur Datenresidenz bestehen. Die Tabelle nennt dann den vorgesehenen Speicherort nach der Standardgeografie des Mandanten: Für Mandanten in EU- oder EFTA-Ländern ist das die «Macro Region Geography 4 — European Union/EFTA», für alle übrigen Standorte die Vereinigten Staaten. Die Schweiz ist ein EFTA-Land. Daneben gibt es das Zusatzangebot Advanced Data Residency, das Zusagen für lokale Länderregionen macht; Microsoft führt die Schweiz dort unter den möglichen lokalen Regionen auf und listet die eingeschlossenen Dienste einzeln — Exchange Online gehört dazu, Forms nicht.

Google Forms. Google bietet für Google Workspace sogenannte Datenregionen an: Die abgedeckten Daten lassen sich an einem bestimmten geografischen Ort speichern, nämlich in den Vereinigten Staaten oder in Europa. Für Forms nennt Google als abgedeckte Daten «Text, embedded images, responses, and draft responses». Zwei Einschränkungen stehen auf derselben Seite: Die Abdeckung betrifft je nach Abonnement die ruhenden Daten, nicht zwingend die Bearbeitung, und Datenregionen lassen sich nicht auf Datentypen anwenden, die dort nicht ausdrücklich genannt sind — Protokolle und zwischengespeicherte Inhalte etwa.

Beide Beispiele zeigen dasselbe Muster, und es ist ein nützliches: Eine Angabe zum Speicherort gilt für bestimmte Daten, in einer bestimmten Produktvariante, in einer bestimmten Region. Die Frage «wo liegen die Daten» hat deshalb selten eine Antwort aus einem Wort, aber fast immer eine nachlesbare.

Station 3: Wer sonst noch mitarbeitet

Kaum ein Anbieter betreibt alles selbst. Hinter einem Formulardienst stehen üblicherweise ein Rechenzentrum, ein Versand für Benachrichtigungen, ein Fehlerprotokoll, ein Support-Werkzeug. Diese Dienstleister sind Unterauftragsbearbeiter, und viele Anbieter veröffentlichen sie in einer Liste.

Wie viel in einer solchen Liste steht, zeigt Google Workspace. Pro Eintrag nennt Google die Gesellschaft, die betroffenen Dienste, die Tätigkeit — etwa «Technical Support» oder «Security Risk Detection» —, die Länder, in denen die Bearbeitung stattfindet, die eingetragene Adresse, das Land der Eintragung und die oberste Muttergesellschaft. Frühere Fassungen der Liste sind auf derselben Seite abrufbar, sodass sich Veränderungen nachvollziehen lassen.

Rechtlich ist diese Kette kein Nebenschauplatz: Ein Auftragsbearbeiter darf die Bearbeitung nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen (Art. 9 Abs. 3 DSG). Fehlt eine öffentliche Liste, ist auch das eine Auskunft — und eine, die sich per E-Mail nachfragen lässt.

Station 4: Die zweite Kopie, die niemand mitzählt

Die meisten Formulardienste schicken bei einer neuen Antwort eine Benachrichtigungs-E-Mail, und in vielen Konfigurationen steht der vollständige Inhalt der Antwort in dieser E-Mail. Damit existiert die Antwort ab diesem Moment an mindestens zwei Orten: im Speicher des Formulardienstes und im Postfach des Betriebs.

Das Postfach ist eine eigene Station mit eigenen Antworten. Für Exchange Online etwa gelten die Zusagen aus Microsofts Advanced-Data-Residency-Angebot, das Forms nicht einschliesst — derselbe Konzern, dieselbe Anmeldung, zwei verschiedene Antworten auf dieselbe Frage. Dazu kommen die Anschlüsse: der Export in eine Tabelle, die Weitergabe an ein Buchhaltungs- oder Newsletter-Werkzeug, ein Webhook in ein Drittsystem. Jede dieser Verbindungen ist eine weitere Kopie an einem weiteren Ort, und sie ist in den Einstellungen des Formulars sichtbar, weil jemand sie dort einmal eingerichtet hat.

Für eine Fahrschule heisst das ganz praktisch: Die Anmeldung einer Kundin liegt nicht «im Formular», sondern im Dienst, im Postfach, in der heruntergeladenen Tabelle auf dem Bürorechner und je nachdem im Terminkalender.

Was der Vertrag dazu sagt

Für den Betrieb ist die technische Kette die eine Hälfte, der Vertrag die andere. Der EDÖB formuliert die Ausgangslage klar: Auch wenn die Bearbeitung von Personendaten einem Auftragsbearbeiter übertragen wird, bleibt der Auftraggeber für den Datenschutz verantwortlich; er ist verpflichtet, den Auftragsbearbeiter sorgfältig auszuwählen, angemessen zu instruieren und soweit als nötig zu überwachen. Zu den Punkten, die der EDÖB dabei aufführt, gehören die Bearbeitung nur gemäss Weisung, angemessene Massnahmen für die Datensicherheit und die vorgängige Zustimmung zum Beizug weiterer Dienstleister.

Bei vielen Anbietern liegt dieser Vertrag als Standarddokument zum Herunterladen bereit, oft unter «Data Processing Agreement» oder «Auftragsverarbeitungsvertrag». Er beantwortet die Fragen, die die technische Dokumentation offenlässt: welche Weisungen gelten, wie über neue Unterauftragsbearbeiter informiert wird, was bei einer Sicherheitsverletzung geschieht und was am Ende des Vertrags mit den Antworten passiert.

Und aus Sicht der Person, die das Formular ausgefüllt hat

Wer Personendaten beschafft, informiert die betroffene Person angemessen darüber und teilt ihr mindestens die Identität und Kontaktdaten des Verantwortlichen, den Bearbeitungszweck und gegebenenfalls die Empfängerinnen und Empfänger oder deren Kategorien mit (Art. 19 Abs. 1 und 2 DSG). Werden Daten ins Ausland bekanntgegeben, gehört auch der Staat dazu und gegebenenfalls die Garantie nach Art. 16 Abs. 2 DSG oder die Ausnahme nach Art. 17 DSG (Art. 19 Abs. 4 DSG).

Das ist der Grund, weshalb die Kette überhaupt interessiert: Was am Ende in einer Datenschutzerklärung steht, ist genau die Liste der Stationen, die jemand einmal zusammengetragen hat. Wer sie kennt, kann die Frage der Kundin am Telefon in einem Satz beantworten — und wer sie nicht kennt, kann sie in ein bis zwei Stunden zusammentragen: Quelltext, Anbieterdokumentation, Liste der Unterauftragsbearbeiter, Vertrag, Postfach, Anschlüsse.

Die App für Online-Formulare, die wir entwickeln, geht diese Kette von der anderen Seite an: Die Antworten werden bereits im Browser der antwortenden Person verschlüsselt, und Betrieb und Speicherung werden in der Schweiz liegen. Damit fällt die Kette nicht weg — sie wird kürzer und lässt sich in einem Satz beschreiben. Das ist ohnehin der brauchbarste Massstab: nicht, ob eine Antwort auf die Frage existiert, sondern ob sie in einen Satz passt.