Die rechtliche Definition: Artikel 4(1) DSGVO
Die DSGVO spannt bewusst ein weites Netz. Artikel 4(1) definiert personenbezogene Daten als:
"Alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden 'betroffene Person') beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind, identifiziert werden kann."
Artikel 4(1), Verordnung (EU) 2016/679
Vier Elemente machen diese Definition aus , und jedes davon ist entscheidend dafür, wie Sie Daten in Ihrer Organisation klassifizieren:
- "Alle Informationen" , keine Beschränkung auf ein bestimmtes Format. Text, Zahlen, Fotos, Tonaufnahmen, biometrische Vorlagen, Metadaten und Verhaltensmuster qualifizieren sich allesamt.
- "Die sich beziehen auf" , die Information muss die Person betreffen, sei es durch ihren Inhalt (sie beschreibt die Person), ihren Zweck (sie wird zur Bewertung der Person verwendet) oder ihr Ergebnis (ihre Verarbeitung wirkt sich auf die Person aus).
- "Identifiziert oder identifizierbar" , die Person muss nicht namentlich genannt werden. Wenn Sie sie durch die Kombination von Datenpunkten herausgreifen können, ist das ausreichend.
- "Natürliche Person" . Die DSGVO schützt lebende Personen, nicht Unternehmen. Daten über einen Einzelunternehmer oder einen namentlich genannten Mitarbeitenden sind jedoch personenbezogene Daten.
Die praktische Konsequenz: Wenn die realistische Möglichkeit besteht, dass irgendjemand , nicht nur Sie, sondern jede Partei mit Zugang , die Daten auf eine Person zurückführen könnte, handelt es sich um personenbezogene Daten gemäss DSGVO. Aus diesem Grund pflanzen sich Klassifizierungsfehler durch Ihr gesamtes Compliance-Programm fort.
Beispiele aus der Praxis: Was zählt dazu und was nicht
Die Grenze zwischen personenbezogenen und nicht personenbezogenen Daten ist weniger offensichtlich, als die meisten Organisationen annehmen. So werden gängige Datentypen gemäss DSGVO eingeordnet, basierend auf aufsichtsrechtlichen Leitlinien und der Rechtsprechung des EuGH:
| Datentyp | Personenbezogene Daten? | Warum |
|---|---|---|
| Vollständiger Name | Ja | Identifiziert eine Person direkt |
| E-Mail: [email protected] | Ja | Identifiziert eine natürliche Person namentlich |
| E-Mail: [email protected] | Nein | Generische Adresse, keine identifizierbare Person |
| Dynamische IP-Adresse | Ja | EuGH-Urteil Breyer (C-582/14): mit ISP-Datensätzen identifizierbar |
| Cookie-ID / Gerätefingerabdruck | Ja | Online-Kennung gemäss Erwägungsgrund 30; greift einen Nutzer heraus |
| Mitarbeiter-ID-Nummer | Ja | Kennnummer, die einer bestimmten Person zugeordnet ist |
| GPS-Standortdaten | Ja | Verfolgt die Bewegungen einer Person; Standortkennung |
| Mit der Funktion verknüpfte Gehaltsdaten | Ja | In Kombination mit Abteilung/Funktion wird die Person identifiziert |
| Anonymisierte Umfrageergebnisse | Es kommt darauf an | Nur dann nicht personenbezogen, wenn eine Re-Identifizierung nicht mit vertretbarem Aufwand möglich ist |
| Pseudonymisierte Kundendatensätze | Ja | Re-Identifizierung mit dem separat aufbewahrten Schlüssel möglich |
| Videoüberwachungsaufnahmen | Ja | Bilder identifizierbarer Personen |
| Aggregierte Statistiken (grosser Datensatz) | Nein | Nur dann, wenn Personen nicht aus dem Aggregat herausgegriffen werden können |
| Ergebnisse von Gentests | Ja (besondere Kategorie) | Besondere Kategorie nach Artikel 9 , genetische Daten |
| Gewerkschaftszugehörigkeit | Ja (besondere Kategorie) | Besondere Kategorie nach Artikel 9 , ausdrücklich aufgeführt |
Die Falle des "Mosaik-Effekts"
Viele Organisationen klassifizieren einzelne Datenpunkte isoliert , eine Mitarbeiternummer hier, ein Abteilungscode dort , und schliessen daraus, dass es sich nicht um personenbezogene Daten handelt. Die DSGVO betrachtet die Identifizierbarkeit jedoch über die Kombination. Wenn Ihr HR-System, Ihre Lohnabrechnungsplattform und Ihre Zugangskontrollprotokolle miteinander abgeglichen werden können, werden Daten, die in einem System anonym erscheinen, im Aggregat zu personenbezogenen Daten. Genau diese Lücke soll die einheitenübergreifende Datenkartierung schliessen.
Besondere Kategorien: Daten nach Artikel 9 erfordern zusätzlichen Schutz
Die DSGVO behandelt bestimmte Arten personenbezogener Daten als grundsätzlich risikoreich. Artikel 9 untersagt die Verarbeitung dieser Kategorien, sofern keine spezifische rechtliche Ausnahme greift , und die Strafen bei Verstössen fallen entsprechend höher aus.
Die besonderen Kategorien sind:
- Rassische oder ethnische Herkunft , umfasst Nationalitätsfelder in HR-Systemen, wenn diese die ethnische Herkunft offenbaren
- Politische Meinungen , Spenden an politische Parteien, Wahlregisterdaten
- Religiöse oder weltanschauliche Ueberzeugungen , Felder zu Ernährungspräferenzen, die die Religion offenbaren (z. B. "halal" oder "koscher" in Verpflegungssystemen)
- Gewerkschaftszugehörigkeit , Lohnabzüge für Gewerkschaftsbeiträge
- Genetische Daten . DNA-Testergebnisse, erbliche Informationen
- Biometrische Daten (zur Identifizierung verwendet) , Fingerabdruck-Scans, Vorlagen zur Gesichtserkennung. Hinweis: Biometrische Daten, die zur Authentifizierung verwendet werden (Entsperren eines Telefons), lösen Artikel 9 möglicherweise nicht in allen Auslegungen aus, Zugangsprotokolle mit Fingerabdruck hingegen sehr wohl
- Gesundheitsdaten , Krankenstandsdatensätze, Vorkehrungen bei Behinderungen, arbeitsmedizinische Beurteilungen, Versicherungsansprüchse. Dies ist die in Unternehmensumgebungen am häufigsten falsch klassifizierte Kategorie
- Sexualleben oder sexuelle Orientierung . HR-Felder zur Diversitätsüberwachung, Begünstigtenbestimmungen, die das Geschlecht des Partners offenbaren
Wo Organisationen mit mehreren Einheiten ins Stolpern geraten
Der häufigste Fehler, den wir bei Organisationen sehen, die den Datenschutz über mehrere Tochtergesellschaften hinweg verwalten: die inkonsistente Klassifizierung von Gesundheitsdaten. Ein Krankenstandsdatensatz wird in einer Tochtergesellschaft als "Standard-HR-Daten" und in einer anderen als "Gesundheitsdaten nach Artikel 9" eingestuft. Wenn eine Aufsichtsbehörde den Konzern prüft, wird die Inkonsistenz selbst zum Beleg für unzureichende Governance. Aus diesem Grund ist eine einheitliche Datentaxonomie über alle Einheiten hinweg nicht optional . sie ist die Grundlage einer belastbaren Compliance.
Rechtsgrundlagen für die Verarbeitung besonderer Kategorien
Die Verarbeitung von Daten besonderer Kategorien erfordert sowohl eine Rechtsgrundlage nach Artikel 6 als auch eine separate Ausnahme nach Artikel 9(2). Zu den am häufigsten herangezogenen Ausnahmen gehören:
- Ausdrückliche Einwilligung (Artikel 9(2)(a)) , muss freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich erfolgen. Eine stillschweigende Einwilligung reicht niemals aus.
- Verpflichtungen aus dem Arbeitsrecht (Artikel 9(2)(b)) , Verarbeitung, die zur Erfüllung von Pflichten aus dem Arbeits- und Sozialversicherungsrecht erforderlich ist
- Lebenswichtige Interessen (Artikel 9(2)(c)) , medizinische Notfallsituationen, in denen die betroffene Person nicht einwilligen kann
- Erhebliches öffentliches Interesse (Artikel 9(2)(g)) , muss verhältnismässig sein und Schutzmassnahmen vorsehen
Pseudonymisierte vs. anonymisierte Daten: Die entscheidende Unterscheidung
Hier laufen mehr Compliance-Programme schief als fast an jeder anderen Stelle. Die Unterscheidung bestimmt, ob die DSGVO überhaupt Anwendung findet , und die Grenze ist weitaus unschärfer, als die meisten Organisationen annehmen.
Pseudonymisierte Daten = weiterhin personenbezogene Daten
Die Pseudonymisierung ersetzt direkte Kennungen durch künstliche (Tokens, Codes, Hashes) und hält den Re-Identifizierungsschlüssel separat. Die DSGVO definiert die Pseudonymisierung ausdrücklich in Artikel 4(5) und behandelt pseudonymisierte Daten durchgehend als personenbezogene Daten.
Warum? Weil eine Re-Identifizierung möglich ist. Der Schlüssel existiert irgendwo. Solange irgendeine Partei , Sie, ein Auftragsverarbeiter, ein Datenempfänger oder ein Angreifer mit vertretbarem Aufwand , das Pseudonym wieder mit der Person verbinden könnte, bleiben es personenbezogene Daten, die allen DSGVO-Pflichten unterliegen.
Die Pseudonymisierung ist eine Sicherheitsmassnahme, keine Ausnahme. Sie kann das Risiko verringern (und die DSGVO anerkennt sie in den Artikeln 25 und 32 als Schutzmassnahme), aber sie entzieht die Daten nicht dem Anwendungsbereich der DSGVO.
Anonymisierte Daten = ausserhalb des Anwendungsbereichs der DSGVO
Wirklich anonymisierte Daten , bei denen eine Re-Identifizierung unumkehrbar und durch keine Partei mit vertretbar einsetzbaren Mitteln möglich ist , fallen vollständig aus dem Anwendungsbereich der DSGVO heraus (Erwägungsgrund 26).
Der Test ist streng: Sie müssen alle Mittel berücksichtigen, die "nach allgemeinem Ermessen wahrscheinlich genutzt werden" zur Re-Identifizierung, einschliesslich künftiger technologischer Entwicklungen, der Kosten der Re-Identifizierung und der Verfügbarkeit ergänzender Datensätze. Der Europäische Datenschutzausschuss (EDSA) hat eine hohe Latte gelegt, und Aufsichtsbehörden haben wiederholt festgestellt, dass Datensätze, die Organisationen für anonym hielten, tatsächlich pseudonym waren.
Praktische Auswirkung auf Ihr Verarbeitungsverzeichnis
Wenn Ihr Verarbeitungsverzeichnis Datensätze unter der Annahme ausschliesst, dass sie "anonymisiert" sind, überprüfen Sie diese Annahme mit einer dokumentierten Risikobewertung zur Re-Identifizierung. Wenn Sie sich irren, hätten diese Datensätze von Anfang an in Ihrem Verarbeitungsverzeichnis stehen müssen , und jede Verarbeitungstätigkeit, die sie betrifft, ist undokumentiert geblieben. Die Verwaltung des Verarbeitungsverzeichnisses von Priverion umfasst Workflows zur Datenklassifizierung, die genau diese Art von Lücke über alle Konzerneinheiten hinweg kennzeichnen.
Daten über strafrechtliche Verurteilungen: Artikel 10
Daten über strafrechtliche Verurteilungen und Straftaten erhalten ihre eigene Regelung nach Artikel 10. Es handelt sich nicht um eine besondere Kategorie nach Artikel 9, doch die Verarbeitung ist auf behördliche Stellen beschränkt oder dann zulässig, wenn sie durch das Recht der EU oder eines Mitgliedstaats mit geeigneten Schutzmassnahmen erlaubt ist.
Für Arbeitgeber: Hintergrundprüfungen, Offenlegungen von Strafregistern und selbst der Vermerk, dass ein Mitarbeitender eine saubere Akte hat, fallen allesamt unter Artikel 10. Wenn Ihre Tochtergesellschaften in verschiedenen Rechtsordnungen Vorbeschäftigungsprüfungen unterschiedlich handhaben, ist die inkonsistente Behandlung von Daten nach Artikel 10 ein häufiger Prüfungsbefund.
Daten von Kindern: Erweiterter Schutz nach Artikel 8
Bei der Verarbeitung personenbezogener Daten von Kindern auf der Grundlage einer Einwilligung für Dienste der Informationsgesellschaft verlangt die DSGVO die Einwilligung der Eltern für Kinder unter 16 Jahren (Mitgliedstaaten können diese Grenze jedoch auf 13 senken). Der Verantwortliche muss angemessene Anstrengungen unternehmen, um sich zu vergewissern, dass die Einwilligung durch den Träger der elterlichen Verantwortung erteilt wird.
Wenn Ihre Organisation Daten von Minderjährigen verarbeitet , Bildungsplattformen, Familienleistungsprogramme, Jugenddienste , fügt dies eine Klassifizierungsebene hinzu, die Ihre Datenkartierung abbilden muss.
Kartierung personenbezogener Daten über eine Organisation mit mehreren Einheiten hinweg
Das Verständnis der Definition ist der Ausgangspunkt. Die eigentliche Herausforderung für Organisationen mit mehreren Tochtergesellschaften besteht darin, diese Definition konsistent über jede Einheit, jedes System und jede Rechtsordnung hinweg anzuwenden.
Hier ist der Prozess, der funktioniert , und das, was wir scheitern gesehen haben:
Was funktioniert: Zentralisierte Taxonomie, verteilte Ausführung
- Etablieren Sie eine konzernweite Taxonomie zur Datenklassifizierung , definieren Sie die Kategorien personenbezogener Daten über alle Einheiten hinweg identisch. "Gesundheitsdaten" bedeutet in Ihrer Schweizer Tochtergesellschaft dasselbe wie in Ihrer deutschen.
- Kartieren Sie Verarbeitungstätigkeiten auf Einheitenebene , jede Tochtergesellschaft dokumentiert ihre eigenen Verarbeitungstätigkeiten anhand der gemeinsamen Taxonomie. Dies gewährleistet lokale Genauigkeit bei konzernweiter Konsistenz.
- Identifizieren Sie einheitenübergreifende Datenflüsse , wo personenbezogene Daten zwischen Tochtergesellschaften oder zu Dritten fliessen, kartieren Sie diese Flüsse ausdrücklich. Konzerninterne Uebermittlungen erfordern weiterhin eine Rechtsgrundlage.
- Automatisieren Sie die Rezertifizierung , wenn sich eine Klassifizierung ändert (z. B. wenn ein neuer Datentyp zu HR-Systemen hinzugefügt wird), muss sich diese Aenderung in das Verarbeitungsverzeichnis jeder Einheit fortpflanzen. Manuelle E-Mail-Ketten skalieren nicht.
- Prüfen und auditieren Sie regelmässig , die Datenklassifizierung ist keine einmalige Uebung. Neue Systeme, neue Anbieter und aufsichtsrechtliche Leitlinien ändern allesamt, was als personenbezogene Daten gilt.
Was scheitert: Dezentrale Klassifizierung ohne Aufsicht
Wenn jede Tochtergesellschaft personenbezogene Daten unabhängig definiert , oder wenn der Konzern-Datenschutzbeauftragte keinen Einblick in die Klassifizierungen auf Ebene der Tochtergesellschaften hat , häufen sich Inkonsistenzen stillschweigend an. Die deutsche Tochtergesellschaft klassifiziert Ernährungspräferenzen als Gesundheitsdaten (gemäss vielen Auslegungen der Aufsichtsbehörden korrekt). Die britische Tochtergesellschaft klassifiziert dasselbe Feld als "Standard-Mitarbeiterdaten". Das Verarbeitungsverzeichnis sieht in beiden Einheiten vollständig aus, doch die Compliance-Lage des Konzerns weist eine Lücke auf, die jedes grenzüberschreitende Audit aufdecken wird.
Genau dieses Problem führte zur Gründung von Priverion: ein Unternehmen mit 12 Tochtergesellschaften, das die DSGVO-Compliance über 47 Tabellenkalkulationen hinweg verwaltete, ohne eine konsistente Möglichkeit, sicherzustellen, dass dieselben Daten überall gleich klassifiziert wurden.
