Anonym vs. pseudonym: wann welches Formular zählt

Zwei Formulare können beide versprechen, die Identität der einreichenden Person zu schützen — und dabei völlig Verschiedenes meinen. Das eine ist tatsächlich anonym: Nichts in der Einsendung, in den umliegenden Metadaten oder in einem anderen System der Betreiberin lässt sich vernünftigerweise auf die Person zurückführen, die das Formular ausgefüllt hat. Das andere ist pseudonym: Die Einsendung trägt keinen Namen, aber ein Code, eine ID oder ein Token erlaubt der Betreiberin — oder einer Schlüsselinhaberin — die Identität später wieder anzuhängen. Auf der Oberfläche sieht der Unterschied klein aus; rechtlich, operativ und in Bezug auf den Anwendungsfall ist er enorm.

Dieser Beitrag arbeitet die Unterscheidung heraus, erklärt, weshalb sie unter DSGVO und revidiertem schweizerischem Datenschutzgesetz (nDSG) zählt, zeigt die technischen Gründe, weshalb die meisten sogenannten „anonymen“ Formulare leise Identität preisgeben, beschreibt, wann Pseudonymität die ehrlichere Wahl ist, und welche Architektur tatsächlich liefert, was auf der Schachtel steht. Er deckt Forschung, Journalismus, Whistleblower-Kanäle, klinische Nachverfolgung, HR-Untersuchungen und öffentliche Befragungen ab.

Die Unterscheidung, auf die es wirklich ankommt

Die kürzeste korrekte Definition: Eine Einsendung ist anonym, wenn niemand — weder die Betreiberin noch eine vernünftigerweise motivierte Drittperson — die einreichende Person mit praktisch eingesetzten Mitteln re-identifizieren kann. Eine Einsendung ist pseudonym, wenn die Verbindung zur Person durch einen Code ersetzt ist, eine separate Information (Schlüssel, Linker-Datei, Kontaktliste) diese Verbindung aber wiederherstellen kann.

Sowohl Aufsichtsbehörden als auch Forschende prüfen Anonymitätsbehauptungen mit dem Massstab „nach allgemeinem Ermessen wahrscheinlich“. Wenn die Betreiberin den Datensatz plus einen Seitenkanal hält (Account-E-Mail, IP-Log, Browser-Fingerprint, Zahlungsspur), der allein oder kombiniert die Person identifizieren kann, ist das Formular nicht anonym. Es ist im besten Fall pseudonym; es trotzdem als anonym zu führen, ist rechtlich riskant und operativ irreführend.

Weshalb die meisten „anonymen“ Formulare keine sind

Betreibende neigen zur Annahme, das Weglassen des Namensfelds reiche aus. In der Realität verlieren Formulare Identität über eine lange Liste von Seitenkanälen, von denen die meisten für die einreichende Person unsichtbar sind. Die ehrliche Prüfung fragt nicht „haben wir den Namen abgefragt?“, sondern „was könnte irgendjemand — intern oder unter Zwang — kombinieren, um die Person zu identifizieren?“

• Server-seitige IP-Logs, die der Anbieter oder sein CDN standardmässig 30 bis 90 Tage, manchmal unbefristet aufbewahrt
• Browser-Fingerprinting durch Analyse-, Anti-Fraud- oder Session-Replay-Skripte, die auf der Formularseite geladen sind
• Account-Daten, wenn das Formular hinter einem Login liegt (SSO, Microsoft 365, Google Workspace)
• E-Mail-Metadaten, wenn die Antwort eine automatische Mail auslöst und der empfangende Mailserver Quelle und Zeitstempel protokolliert
• Freitextfelder, in denen sich die einreichende Person selbst preisgibt („als einzige Person im Team, die X betreut …“)
• Kleine Grundgesamtheiten: in einer 12-köpfigen Abteilung machen Rolle plus Dauer plus Ort oft eine Person eindeutig
• Querverknüpfung zwischen Formularen: wer aus derselben Browser-Session zwei Formulare ausfüllt, verbindet beide Einsendungen, auch wenn jedes für sich Anonymität behauptet
• Zahlungsspuren, wenn das Formular in einen kostenpflichtigen Ablauf eingebettet ist (Forschungsentschädigung, Anmeldegebühr)
• Workflow-Systeme, die festhalten, wer welche Einsendung geöffnet, geprüft oder verschoben hat

Das Muster ist konsistent: die formularnahe Frage „fragen wir identifizierende Felder ab?“ ist nötig, aber bei Weitem nicht hinreichend. Anonymität muss über die Seite, den Netzwerkpfad, das Storage-Backend, das Workflow-Tool und die Zugriffspraxis hinweg gestaltet sein. Alles darunter ist Pseudonymität mit anderem Etikett.

Wann Pseudonymität die richtige Wahl ist

Pseudonymität ist kein Ausweichmanöver. Für viele legitime Anwendungsfälle braucht die Betreiberin tatsächlich die Möglichkeit, eine Identität später wieder an die Einsendung anzuknüpfen — das richtige Design ist nicht, das Bedürfnis abzuschütteln, sondern Pseudonymisierung bewusst einzusetzen, mit getrennt verwaltetem Schlüssel.

• Längsschnittforschung, in der Welle 2 und Welle 3 derselben Teilnehmerin zugeordnet werden müssen
• Klinische Nachverfolgung: ein Patientinnenfragebogen, der ein Sicherheitssignal markieren kann und einen Rückruf erfordert
• Qualitätssicherung mit Rückverfolgbarkeit: Kundenerfahrungs-Befragungen, die einer Transaktion zugeordnet werden, ohne die Kundin gegenüber Mitarbeitenden offenzulegen
• Widerruf der Einwilligung: Teilnehmende müssen die Löschung ihrer Daten verlangen können — das setzt Identifizierung des Datensatzes voraus
• Pharmakovigilanz, in der eine Behörde später unter definierter Rechtsgrundlage Re-Identifizierung verlangen kann
• Beta-Programme, in denen Bug-Berichte für die Reproduktion an konkrete Test-Accounts geknüpft sein müssen

Wie gute Pseudonymisierung aussieht

• Eine separate Linker-Datei, die Teilnehmer-ID → Identität abbildet, gehalten von einem anderen Team als die Auswertenden
• Zugriff auf die Linker-Datei wird geloggt, ist befristet und an definierte Gründe gebunden (Rückkontakt, Widerruf, Sicherheitssignal)
• Der pseudonyme Datensatz wird vor der Auswertung von Freitextkennzeichen und Hochrisiko-Demografien bereinigt
• Eine schriftliche Re-Identifizierungs-Prozedur mit benannten Genehmigern und Begründung pro Fall
• Ein Aufbewahrungsplan, der den Linker vor dem Datensatz selbst zerstört — Re-Identifizierung endet, aggregierte Auswertung bleibt möglich

Wann Anonymität die richtige Wahl ist

Echte Anonymität — über das gesamte System verifiziert, nicht auf der Formularseite behauptet — ist die richtige Wahl, wenn die Beziehung zwischen einreichender Person und Betreiberin nach der Einsendung nicht weiterbestehen soll und wenn die Folgen einer Re-Identifizierung gravierend wären.

• Whistleblower- und Ethik-Hotlines, in denen Vergeltungsrisiken real sind
• Quellenannahme im Journalismus und Tipplinien
• Sensible Befragungen zu öffentlicher Gesundheit oder häuslicher Gewalt
• Mitarbeitendenbefragungen zu Klima oder psychologischer Sicherheit, deren Wert von Offenheit lebt
• Menschenrechtsbeobachtung und NGO-Fallaufnahme unter staatlichem oder nicht-staatlichem Druck
• Akademische Forschung zu illegalem, stigmatisiertem oder politisch sensiblem Verhalten
• Öffentliche Konsultationen, in denen Tracking die Beteiligung lähmen würde

DSGVO & nDSG: was die Unterscheidung bringt

Die DSGVO macht es in Erwägungsgrund 26 deutlich. Personendaten, die so anonymisiert sind, dass die betroffene Person nicht mehr identifizierbar ist, fallen aus dem Anwendungsbereich der Verordnung. Pseudonyme Daten bleiben hingegen Personendaten — Art. 4 Nr. 5 definiert sie als Verarbeitung, bei der Personendaten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer Person zugeordnet werden können — und behält sie im Anwendungsbereich.

Das schweizerische nDSG folgt derselben Logik. Anonymisierte Daten, bei denen Re-Identifizierung nicht mehr vernünftigerweise möglich ist, sind keine Personendaten im Sinne des Gesetzes. Pseudonymisierte Daten schon. Die praktischen Folgen sind weitreichend:

Architekturentscheidungen, die die jeweilige Eigenschaft tatsächlich liefern

Echte Anonymität liefern

• Identifizierende Request-Metadaten am Rand abschneiden: IP-Adressen verwerfen oder hashen, bevor sie eine Datenbank erreichen, User-Agent-Logging deaktivieren, wo möglich
• Das Formular ohne Drittanbieter-Analyse, Fehler-Monitoring, Session-Replay oder Fingerprinting ausliefern — eine saubere Seite ist Voraussetzung, kein Feinschliff
• Keine Authentifizierung vor das Formular setzen, wenn Anonymität das Ziel ist; eine SSO-Spur zerstört sie, bevor jemand auf Senden klickt
• Tor- oder andere Anonymisierungsnetze für Hochrisikoeinreichungen erlauben und nicht blockieren
• Inhalte ende-zu-ende verschlüsseln, damit auch Mitarbeitende des Anbieters sie nicht lesen können; nur die Formular-Inhaberin entschlüsselt mit dem Access Code
• Freitextfelder und demografische Kombinationen so zuschneiden, dass Re-Identifizierung minimiert wird — gröbere Eimer reichen oft
• Aufbewahrung so setzen, dass Einsendungen und Rest-Logs nach einem Plan zerstört werden, der den Anwendungsfall nicht überschreitet
• Die Folge-Tools prüfen: Ticketing, E-Mail, Dashboards, Exporte — jedes System erbt die Anonymitätszusage oder bricht sie

Robuste Pseudonymität liefern

• Teilnehmer-Code bei der Rekrutierung erzeugen, Linker-Datei (Code → Identität) in einem separaten System halten
• Zugriff auf den Linker auf ein kleines, namentliches Team beschränken, das nicht auswertet — jeden Zugriff mit Begründung loggen
• Datensatz und Linker mit getrennten Schlüsseln verschlüsseln, die Schlüssel bei getrennten Verwahrenden
• Vor Studienstart die Bedingungen festlegen, unter denen Re-Identifizierung erlaubt ist (Sicherheitssignal, Widerruf, Behördenanfrage)
• Vor Veröffentlichung oder Datenweitergabe eine Re-Identifizierungs-Risikoanalyse durchführen (k-Anonymität, l-Diversität, Freitext-Screening)
• Den Linker vor dem Datensatz selbst zerstören, sobald der legitime Bedarf endet

Die richtige Eigenschaft wählen: ein Entscheidungsrahmen

Wie Schweizerform in dieses Bild passt

Schweizerform ist so gebaut, dass die Betreiberin glaubwürdig die jeweils passende Eigenschaft wählen kann. Die Standardhaltung trägt Anonymität; Pseudonymität entsteht, wenn ein Teilnehmer-Identifier bewusst ergänzt wird — als Designentscheidung, nicht als Nebenwirkung.

• Einsendungen werden im Browser der einreichenden Person mit Zero-Knowledge-Ende-zu-Ende-Verschlüsselung verschlüsselt — der Anbieter kann Inhalte selbst unter Zwang nicht lesen
• Formulare können ohne Authentifizierung, ohne dauerhafte IP-Aufbewahrung und ohne Drittanbieter-Analyse oder Fingerprinting auf der Formularseite betrieben werden
• Wenn Pseudonymität das Ziel ist, bindet die Betreiberin einen Teilnehmer-Code ein und hält die Linker-Datei ausserhalb von Schweizerform unter eigenen Zugriffskontrollen
• Schweizer Unternehmens- und Hosting-Jurisdiktion verkleinert die grenzüberschreitende Rechtsoberfläche gegenüber US-Anbietern
• Dokumentierte Aufbewahrungsregeln erlauben planmässige Zerstörung, abgestimmt auf das Re-Identifizierungs-Risikomodell

Nichts davon ersetzt sorgfältiges Design und ein dokumentiertes Bedrohungsmodell. Die Architekturentscheidungen, die Schweizerform anbietet, sind notwendige Bedingungen für glaubwürdige Anonymität oder belastbare Pseudonymität — sie sind allein nicht hinreichend. Das Formular ist eine Komponente; der Workflow drumherum ist der Rest.

Fazit

Anonym und pseudonym sind keine Synonyme. Das eine entfernt die Verbindung zur Person über alle Systeme hinweg; das andere trennt sie hinter einem Schlüssel. Jedes passt zu einem anderen Anwendungsfall, jedes trägt unter DSGVO und nDSG andere Pflichten, jedes versagt charakteristisch, wenn die Betreiberin sie verwechselt. Die meisten Formulare, die Anonymität behaupten, liefern nur schwache Pseudonymität, weil nur das Formular und nicht das System geprüft wurde.

Der ehrliche Schritt ist, bewusst zu wählen. Wenn Rückkontakt nötig ist, Pseudonymität sauber bauen: Linker trennen, Zugriffe sperren, Re-Identifizierungsrisiko prüfen. Wenn kein Rückkontakt nötig ist, echte Anonymität liefern — Seitenkanäle abschneiden, den ganzen Pfad prüfen, die operativen Kosten akzeptieren. Der unehrliche Schritt ist, ein Formular „anonym“ zu beschriften und darauf zu hoffen, dass niemand zu genau hinschaut.