DSGVO-Auskunftsanspruch gegenüber dem Auftragsverarbeiter? Dänische Datenschutzbehörde sagt „Nein, aber…“

Die dänische Aufsichtsbehörde hat am 20.5.2022 einen interessanten Fall (Entscheidung auf Englisch, PDF) zu der Frage, ob ein Auskunftsanspruch durch einen Auftragsverarbeiter erfüllt werden muss, entschieden. Zudem geht sie in ihrer Entscheidung auf die Unterstützungspflichten des Auftragsverarbeiters bei Betroffenenanfragen ein.

Sachverhalt

Der Betroffene kaufte auf ebay einen Artikel bei dem Unternehmen Asus. Im Rahmen des Kaufs gab der Betroffene die E-Mail-Adresse ebay@levaria.de an. Danach erhielt er eine E-Mail von noreply.invitations@trustpilot.com an die beim Kauf angegebene Adresse ebay@levaria.de, in der der Asus Online Shop als Absender angegeben war. Dort wurde der Betroffene gebeten, das Kauferlebnis bei Asus auf Trustpilot zu bewerten.

Daraufhin kontaktierte der Betroffene Trustpilot direkt, jedoch von einer anderen E-Mail-Adresse (service@levaria.de) und bat um Auskunft über die von Trustpilot möglicherweise verarbeiteten personenbezogenen Daten. Die Anfrage enthielt neben der E-Mail-Adresse auch den Namen und die Adresse. Trustpilot antwortete und teilte mit, dass Trustpilot keinen aktiven Nutzer für die E-Mail service@levaria.de ausfindig machen konnte und daher keine Daten über ihn verarbeitet.

Danach erhielt der Betroffene erneut eine E-Mail von Trustpilot im Namen des Asus Online Shops an ebay@levaria.de, in der er erneut gebeten wurden, den Einkauf bei Asus zu bewerten. Hierauf beschwerte sich der Betroffene zunächst bei der bayerischen Behörde (BayLDA), die die Beschwerde an die Berliner und diese an die dänische Aufsichtsbehörde weiterleitete.

Entscheidung

Die dänische Behörde ist die für Trustpilot zuständige Aufsichtsbehörde in der EU. Für die Behörde ging es um die Frage, ob Trustpilot nach Art. 15 DSGVO verpflichtet war, Auskunft zu erteilen und wenn ja, ob dies hier richtig erfolgte.

Trustpilot als Verantwortlicher?

Die dänische Behörde hebt in ihrer Begründung hervor, dass allein der Verantwortliche nach Art. 15 DSGVO verpflichtet ist, die Auskunft an Betroffene zu erteilen.

Es liegt daher in der Verantwortung des für die Verarbeitung Verantwortlichen, dass ein Antrag einer betroffenen Person auf Auskunft gemäß Artikel 15 der DSGVO bearbeitet wird“.

Im konkreten Fall gab Trustpilot an, in Bezug auf den Versand von Einladungs-E-Mails als Auftragsverarbeiter zu agieren. Dies beruhe u.a. darauf, dass Unternehmen, wie z.B. der Asus Online Shop, entscheiden, ob sie die Einladungssoftware von Trustpilot nutzen wollen oder nicht, ebenso wie die Unternehmen entscheiden, ob und wann Einladungen über die Einladungssoftware von Trustpilot verschickt werden.

Damit war aus Sicht der Aufsichtsbehörde die Frage beantwortet, ob Trustpilot verpflichtet war, im eigenen Namen die Auskunft zu erfüllen.

Da gemäß den Artikeln 12 und 15 nicht der Auftragsverarbeiter, sondern der Verantwortliche verantwortlich ist, einen Antrag auf Auskunft zu bearbeiten und zu beantworten, ist die dänische Datenschutzbehörde der Ansicht, dass Trustpilot nicht gegen diese Bestimmungen verstoßen hat.“

Identifikation des Betroffenen durch den Auftragsverarbeiter?

Zwar war Trustpilot also selbst nicht nach der DSGVO verpflichtet, die Auskunft zu erfüllen. Jedoch ist der Auftragsverarbeiter nach Art. 28 Abs. 3 e) DSGVO in dem AV-Vertrag darauf zu verpflichten, den Verantwortlichen dabei zu unterstützen, seiner Pflicht zur Beantwortung von Anträgen auf Wahrnehmung der in Kapitel III DSGVO genannten Rechte der betroffenen Person nachzukommen.

Es stelle sich also noch die Frage, ob Trustpilot hier dieser Unterstützungspflicht ausreichend nachkam.

Nach Ansicht der dänischen Aufsichtsbehörde hat Trustpilot in dem Verfahren ausführlich dargelegt, dass es bei der ersten und zweiten Kontaktaufnahme des Betroffenen mit Trustpilot eine Suche über die E-Mail service@levaria.de durchgeführt hat und dass Trustpilot die betroffene Person auf dieser Grundlage nicht identifizieren konnte, da Trustpilot die E-Mail service@levaria.de nicht registriert hatte.

Denn Trustpilot verarbeitete nur die mit der E-Mail-Adresse ebay@levaria.de (jene, die bei dem Kauf verwendet wurde) verbundenen Informationen als Auftragsverarbeiter für den Asus Online Shop. Da diese E-Mail-Adresse aber im Zusammenhang mit der Auskunftsanfrage nicht verwendet wurde, konnte Trustpilot in seinen Systemen keine Daten finden.

ABER: der Betroffene hatte ja im Rahmen seiner Anfrage u.a. auch seinen Namen und die postalische Adresse angegeben.

Die dänische Datenschutzbehörde kritisiert vor diesem Hintergrund, dass Trustpilot keine einheitliche Praxis bei der Suche nach relevanten Informationen, einschließlich des Namens und der Adresse, die die betroffene Person im Zusammenhang mit ihrer Anfrage übermittelt, umgesetzt hatte. Nach dem Namen und der Adresse konnte Trustpilot anscheinend nicht suchen und einen Abgleich durchführen.

So hätte Trustpilot die Möglichkeit der Identifizierung der betroffenen Person und könnte, in seiner Rolle als Auftragsverarbeiter, den für die Verarbeitung Verantwortlichen in dem vereinbarten Umfang unterstützen. Die dänische Behörde gab dies jedoch nur als Hinweis an Trustpilot und stellte das Verfahren ein.

Fazit

Die Aufsichtsbehörde scheint also zu empfehlen, dass Trustpilot zusätzliche Daten als Auftragsverarbeiter erhält (Name und Adresse), die zwar für die eigene Leistung (Versand der E-Mail) nicht erforderlich sind, jedoch im Rahmen der Betroffenenanfragen relevant werden können. Diese Ansicht mag man im Hinblick auf die Erleichterung von Betroffenenanfragen unterstützen. Gleichzeitig ist der Verantwortliche (für den Trustpilot hier als Auftragsverarbeiter ja auch bei Betroffenenanfragen unterstützen muss) aber nach Art. 11 DSGVO gerade nicht verpflichtet, zusätzliche personenbezogene Daten zu verarbeiten, nur für den Zweck, um Betroffenenrechte zu erfüllen.

Man wird hier wohl die Besonderheit beachten müssen, dass die erforderlichen Daten (Name und Adresse) aber natürlich schon bei dem Verantwortlichen vorhanden sind. Eventuell wäre es hier eine Option gewesen, dass Trustpilot die Anfrage des Betroffenen (auch mit der eigentlich unbekannten E-Mail-Adresse) direkt an Asus weiterleitet.

Europäischer Datenschutzausschuss: was ist ein internationaler Datentransfer und in welchen Fällen sind die Pflichten des Kapitel V der DSGVO zu beachten?

Letzte Woche hat der EDSA seine Leitlinien 05/2021 über das Zusammenspiel zwischen Art. 3 DSGVO und den Bestimmungen über internationale Übermittlungen veröffentlicht (PDF). Diese Leitlinien wurden seit einiger Zeit mit Interesse erwartet, da die DSGVO keine eigene Definition für „internationale Übermittlungen“ vorsieht. Daneben enthalten die Leitlinien einige sehr praxisrelevante Feststellungen der europäischen Behörden, wann die zusätzlichen Anforderungen des Kapitel V zu beachten sind und wann nicht.

Art. 46 DSGVO? Immer die Erforderlichkeit zusätzlicher Schutzmaßnahmen prüfen

Zunächst stellt der EDSA (erneut) fest, dass bei der Inanspruchnahme eines der in Art. 46 DSGVO aufgeführten Übermittlungsinstrumente, wie etwa von EU Standarddatenschutzklauseln, stets geprüft werden muss, ob zusätzliche Schutzmaßnahmen umgesetzt werden müssen, um das Schutzniveau der übermittelten Daten auf den EU-Standard der wesentlichen Gleichwertigkeit zu bringen. Diese Ansicht ist nicht neu, für die Praxis jedoch wichtig.

Dies gilt nach Ansicht des EDSA übrigens auch in Situationen, in denen die Verarbeitung unter Art. 3 Abs. 2 DSGVO fällt. Dies, um zu vermeiden, dass der durch die DSGVO gewährte Schutz durch andere Rechtsvorschriften, denen der Importeur unterliegt, untergraben wird. Bereits hier in der Einleitung wird also klar: der EDSA geht von einer internationalen Übermittlung im Sinne des Kapitel V aus, auch wenn der Importeur der Daten bereits selbst nach Art. 3 Abs. 2 DSGVO dem europäischen Recht unterliegt (hierzu aber später noch mehr).

Was ist eine „Übermittlung an ein Drittland oder eine internationale Organisation“?

Da die DSGVO keine rechtliche Definition des Begriffs „Übermittlung personenbezogener Daten in ein Drittland oder an eine internationale Organisation“ (vgl. Art. 44 S. 1 DSGVO) enthält, muss dieser Begriff nach Auffassung des EDSA „unbedingt geklärt werden“.

Vor diesem Hintergrund macht der EDSA einen eigenen Vorschlag für eine solche Definition. Zu beachten ist hierbei freilich, dass diese Auslegung „nur“ die Ansicht der europäischen Behörden darstellt und etwa die EU Kommission eine andere Auffassung vertreten könnte. Dennoch sind die Vorgaben des EDSA für die Praxis von besonderer Relevanz.

Der EDSA hat drei kumulative Kriterien vorgeschlagen, die eine Verarbeitung als Übermittlung qualifizieren. Es müssen also alle drei Anforderungen gemeinsam erfüllt sein:

1. Ein für die Verarbeitung Verantwortlicher oder ein Auftragsverarbeiter unterliegt in Bezug auf die betreffende Verarbeitung den Bestimmungen der DSGVO.

2. Dieser Verantwortliche oder Auftragsverarbeiter („Exporteur“) macht durch Übermittlung oder auf andere Weise personenbezogene Daten, die Gegenstand dieser Verarbeitung sind, einem anderen Verantwortlichen, gemeinsamen Verantwortlichen oder Auftragsverarbeiter („Importeur“) zugänglich.

Auch im Fall der Weitergabe von Daten zwischen gemeinsam Verantwortlichen kann also eine Übermittlung in ein Drittland vorliegen. Keine Privilegierung der Weitergabe zwischen diesen gemeinsam Verantwortlichen.

3. Der Importeur befindet sich in einem Drittland oder ist eine internationale Organisation, ungeachtet dessen, ob dieser Importeur in Bezug auf die betreffende Verarbeitung gemäß Art. 3 der DSGVO unterliegt oder nicht.

Wichtig: hier wird direkt eine relevante Klarstellung des EDSA deutlich. Der Exporteur muss gerade nicht (!) in der EU oder dem EWR ansässig sein. Nur der Empfänger der Daten, der Importeur, muss zwingend in einem Drittland ansässig sein. Diese Ansicht ist eigentlich auch nicht mehr überraschend, jedoch sollte man sich in der Praxis stets in Erinnerung rufen, dass für eine Anwendung der Vorschriften in Kapitel V gerade nicht Voraussetzung ist, dass der Exporteur unbedingt in der EU ansässig sein muss.

Zudem muss beachtet werden, dass es für die Frage der Anwendbarkeit von Art. 3 DSGVO stets auf die jeweilige Verarbeitung ankommt. Man muss also auf die einzelne Verarbeitung schauen und kann nicht global und allgemein die Anwendung von Art. 3 DSGVO allein mit Blick auf die datenverarbeitende Organisation prüfen.

Keine Übermittlung, wenn Betroffener selbst Daten freigibt

Das zweite Kriterium setzt nach Ansicht des EDSA stets voraus, dass entweder ein (gemeinsam) Verantwortlicher oder ein Auftragsverarbeiter handelt und die Daten durch Übermittlung oder in anderer Weise zur Verfügung stellt.

Dieses zweite Kriterium kann daher nicht als erfüllt angesehen werden, wenn die Daten direkt und auf auf eigene Initiative der betroffenen Person an den Empfänger weitergegeben werden. In diesem Fall gibt es keinen Verantwortlichen oder Auftragsverarbeiter, der die Daten übermittelt oder zur Verfügung stellt („Exporteur“).

„Übermittlung an ein Drittland“ kann auch vorliegen, wenn der Empfänger der DSGVO unterliegt

Besonders relevant ist die Ansicht des EDSA, ob die Vorgaben des Kapitel V auch dann zu beachten sind, wenn der Importeur der Daten bereits unmittelbar nach Art. 3 Abs. 2 DSGVO dieser unterliegt (derzeit arbeitet die EU Kommission wohl an weiteren Standardvertragsklauseln für genau diese Konstellation). Man könnte ja argumentieren, dass es in diesem Fall eigentlich nicht erforderlich ist, zusätzliche Übermittlungsanforderungen nach Kapitel V vorzusehen.

Der EDSA hebt hervor, dass für Verantwortliche und Auftragsverarbeiter, die nicht in der EU ansässig sind, gemäß Art. 3 Abs. 2 DSGVO für eine bestimmte Verarbeitung der DSGVO unterliegen können und daher bei der Übermittlung personenbezogener Daten an ein Drittland oder eine internationale Organisation die Bestimmungen von Kapitel V einhalten müssen, wenn sie personenbezogene Daten in ein Drittland übermitteln oder als Importeur diese Daten erhalten.

Spannend sind hier die Aussagen des EDSA zu zukünftigen Standardvertragsklauseln für diese Konstellation. Denn nach Ansicht des EDSA sind bei der Übermittlung personenbezogener Daten an einen Verantwortlichen in einem Drittland weniger Schutzmaßnahmen/Garantien erforderlich, wenn dieser für die betreffende Verarbeitung bereits der DSGVO unterliegt. Und im Grunde adressiert der EDSA dann direkt die EU Kommission:

Daher sollte bei der Entwicklung entsprechender Übermittlungsinstrumente (die derzeit nur theoretisch zur Verfügung stehen), d. h. Standardvertragsklauseln oder Ad-hoc-Vertragsklauseln, die Situation nach Art. 3 Abs. 2 berücksichtigt werden, um die Verpflichtungen der Datenschutz-Grundverordnung nicht zu duplizieren, sondern vielmehr die „fehlenden“ Elemente und Grundsätze anzusprechen, die notwendig sind, um die Lücken zu schließen…“.

Ein Beispiel: der reisende Mitarbeiter – es müssen verschiedene juristische Personen vorliegen

In den Leitlinien sind zudem einige Beispiele enthalten. In Beispiel 5 geht der EDSA davon aus, dass durch Drittländer reisende Mitarbeiter, die remote Zugriff auf die Systeme des Arbeitgebers in der EU nehmen, keine internationale Übermittlung auslösen.

Der Grund: Exporteur und Importeur der Daten müssen nach Ansicht des EDSA stets getrennte juristische Einheiten sein. Damit es sich um eine internationale Übermittlung handeln kann, muss es einen Verantwortlichen oder einen Auftragsverarbeiter geben, der die Daten offenlegt (der Exporteur), und einen anderen Verantwortlichen oder einen anderen Auftragsverarbeiter, der die Daten erhält oder Zugang zu ihnen erhält (der Importeur). Im Fall des reisenden Mitarbeiters werden die Verarbeitungen, einschließlich des Fernzugriffs, juristisch betrachtet von seinem Arbeitgeber durchgeführt, d. h. von einem für die Verarbeitung Verantwortlichen mit Sitz in der Union.

Absender und Empfänger der Daten müssen nach Auffassung der Aufsichtsbehörden nicht verschiedene für die Verarbeitung Verantwortliche/Auftragsverarbeiter sein. Sind sie dies nicht, sollte die Weitergabe von
personenbezogener Daten nicht als Übermittlung gemäß Kapitel V DSGVO betrachtet werden, „da die Daten
innerhalb desselben für die Verarbeitung Verantwortlichen/Auftragsverarbeiters verarbeitet werden
„.

Haftungsbegrenzung in den neuen SCC – rein kommerziell oder unzulässige Abweichung?

Bereits im Rahmen des Abschlusses der noch geltenden SCC war die Frage nach der Haftungsbegrenzung zwischen Exporteur und Importeur ein praktisch relevantes Thema. Zum Teil wurden SCC selbst angepasst, zum Teil wurde auf die Haftungsklausel in Hauptverträgen verwiesen.

Fraglich und meines Erachtens diskutabel ist, ob die nun von der EU-Kommission veröffentlichten Standardvertragsklauseln nach Art. 46 Abs. 2 lit. c DSGVO eine solche Haftungsbegrenzung erlauben. Die Antwort auf diese Frage dürfte gerade für Dienstleister als Auftragsverarbeiter elementar sein. Kann, im Fall des Verstoßes gegen den Vertrag oder die DSGVO, eine Haftung der verstoßenden Partei gegenüber dem Vertragspartner begrenzt werden? Es soll hier nicht um die Begrenzung von Schadenersatzansprüchen gegenüber Betroffenen gehen. Ich denke, es gibt diesbezüglich keine Diskussion, dass dies nicht möglich ist.

Ich meine, dass es wohl für beide Ansichten Argumente gibt. Nachfolgend möchte ich einige (mir schnell in den Sinn kommende) Argumente auflisten.

Pro Haftungsbegrenzung

Es soll allein die schuldrechtliche Haftung zwischen den Parteien begrenzt werden. Gegenüber Betroffenen erfolgt keine Begrenzung. Daher sind auch deren Rechte nicht beschränkt.

Nach ErwG 3 des Beschlusses der Kommission können Exporteur und Importeur ausdrücklich weitere Klauseln hinzuzufügen, sofern diese weder unmittelbar noch mittelbar im Widerspruch zu den Standardvertragsklauseln stehen oder die Grundrechte oder Grundfreiheiten der betroffenen Personen beschneiden. Die Begrenzung einer internen Haftung ist jedoch in den SCC nicht geregelt, womit auch kein Widerspruch besteht. Es handelt sich hierbei allein um eine „kommerzielle“ Regelung.

Contra Haftungsbegrenzung

Nach ErwG 14 des Beschlusses sollen die SCC Vorschriften über die Haftung zwischen den Parteien vorsehen. Also gerade die interne Haftung betreffend. Dann ist schwer zu argumentieren, dass eine solche Regelung rein „kommerziellen“ Charakter hat und von den SC nicht abweicht, wenn sie doch in dem Beschluss ausdrücklich als verpflichtender Bestandteil angesprochen ist.

Art. 12 SCC enthält ausdrücklich eine Klausel zur Haftung zwischen den Parteien (vergleiche in allen Modulen jeweils lit. a)). Dort ist keine Regelung für eine Begrenzung gegenüber dem Vertragspartner enthalten. Führt man eine solche Beschränkung aber ein, würde man von lit. a) abweichen.

Eine Haftungsbegrenzung könnte dazu führen, dass eine Partei (wegen des geringen finanziellen Risikos selbst bei Verstößen) ihre Pflichten aus dem Vertrag nicht so ernst nimmt, womit auch die Rechte der Betroffenen mittelbar beeinträchtigt sein könnten.

Aus meiner Sicht ein praktisch wahnsinnig relevantes und spannendes Thema, welches bei den nun anstehenden Abschlüssen der neuen SCC sicher auch für Diskussionen sorgt.

Muss über den Ort der Datenverarbeitung informiert bzw. Auskunft gegeben werden?

Im Rahmen der Erstellung von Datenschutzerklärungen oder auch bei der Beauskunftung von Anträgen nach Art. 15 DSGVO kann sich für Unternehmen die Frage stellen, ob denn der konkrete Ort der Datenverarbeitung anzugeben ist?

In der Praxis verlangen Betroffene zum Teil sehr spezifische Informationen darüber, wo ihre personenbezogenen Daten verarbeitet werden.

Als rechtlicher Anknüpfungspunkt zur Klärung dieser Frage bieten sich meines Erachtens zwei Vorschriften der DSGVO an. Zum einen Art. 13 Abs. 1 lit. e und f DSGVO. Danach soll der Verantwortliche „gegebenenfalls die Empfänger oder Kategorien von Empfängern der personenbezogenen Daten“ mitteilen und „gegebenenfalls die Absicht des Verantwortlichen, die personenbezogenen Daten an ein Drittland oder eine internationale Organisation zu übermitteln“. Zum anderen Art. 15 Abs. 1 lit. c) DSGVO, wonach Auskunft zu erteilen ist über „die Empfänger oder Kategorien von Empfängern, gegenüber denen die personenbezogenen Daten offengelegt worden sind oder noch offengelegt werden, insbesondere bei Empfängern in Drittländern oder bei internationalen Organisationen“.

Art. 13 Abs. 1 lit. e) DSGVO

Dem reinen Wortlaut nach, muss nicht über den Ort der Verarbeitung informiert werden. Rein faktisch kann es zudem sehr schwierig sein, wirklich den konkreten Ort der Verarbeitung mitzuteilen. Denn in Zeiten des Cloud-Computings und von gespiegelten Systemen, wissen ggfs. die Verantwortlichen gar nicht genau, wo die Daten liegen.

Abs. 1 lit. e) verlangt eine Information über die Empfänger (oder Kategorien). Es geht hierbei um die Benennung der Empfänger, also etwa des Unternehmens. Dass hierbei zwingend eine Adresse hinzugefügt werden muss, ergibt sich aus der Vorschrift nicht. Zumal der Unternehmenssitz eines Empfängers ja in der heutigen Zeit nun wirklich nicht immer auch der Ort der Datenverarbeitung ist.

Etwas strenger scheint dies der EDSA zu sehen. In der (durch den EDSA bestätigten) Stellungnahme der damaligen Art. 29 Gruppe zur Transparenz (WP 260) heißt es: „Entscheiden sich die Verantwortlichen für die Angabe der Kategorien von Empfängern, sollten diese Informationen unter Angabe der Empfängerart (d. h. der von diesen durchgeführten Aktivitäten), der Industrie, des Sektors und Teilsektors sowie des Standorts der Empfänger so genau wie möglich ausfallen“ (Hervorhebung durch mich, S. 47).

Aber auch hier zielt die Information auf den Standort des Empfängers, was faktisch nicht mit dem Ort der Verarbeitung gleichzusetzen ist. Bsp: der Empfänger mag einen Geschäftssitz in New York haben, jedoch seine Server in Gibraltar betreiben. Aus dieser Ansicht des EDSA würde ich daher auch keine Pflicht zur Information über den Ort der Datenverarbeitung ableiten.

Auch der Landesdatenschutzbeauftragte für Bayern (BayLfD) scheint hiervon auszugehen. In seiner (sehr lesenswerten) Orientierungshilfe zu Informationspflichten (PDF) erläutert er, dass Empfänger nach Möglichkeit konkret benannt werden sollten. Hierfür führt er das folgende Beispiel an: „Rechenzentrum [Name] als Auftragsverarbeiter“. Auch der BayLfD scheint also keine Pflicht zur Angabe einer Adresse oder des Ortes der Verarbeitung anzunehmen.

Art. 13 Abs. 1 lit. f) DSGVO

Auch aus Art. 13 Abs. 1 lit. f) DSGVO dürfte sich keine Pflicht ergeben, den Ort der Datenverarbeitung zu benennen. Nach der Vorschrift muss der Verantwortliche über die Absicht informieren, die personenbezogenen Daten an ein Drittland oder eine internationale Organisation zu übermitteln. Bereits dem Wortlaut der Norm nach, ist die Benennung des Ortes nicht vorgeschrieben. Mit Blick auf das Gebot der Transparenz wird man wohl davon ausgehen müssen, dass das Drittland genannt werden soll, in das die Daten übermittelt werden. Spannend finde ich in dieser Hinsicht die Ansicht des BayLfD in der oben erwähnten Orientierungshilfe. Dort erläutert die Behörde wie folgt: „

Art. 13 Abs. 1 Buchst. f DSGVO verlangt nicht, dass das betreffende Drittland oder die betreffende internationale Organisation namentlich genannt wird“.

Der BayLfD empfiehlt jedoch aus Transparenzgründen, diese Information ebenfalls zu erteilen. Für diese Ansicht der Behörde dürfte sprechen, dass nach der Norm nur über die „Absicht“ informiert werden muss, Daten in ein Drittland zu übermitteln. Also etwa wie folgt: „Wir beabsichtigen, Daten in ein Drittland zu übermitteln“. Freilich plus der Hinweis auf einen Angemessenheitsbeschluss oder dessen Fehlen sowie andere Garantien nach Art. 46 DSGVO oder Ausnahmen nach Art. 49 DSGVO.

Der EDSA vertritt hier übrigens eine ähnliche Position. In der Leitlinie zur Transparenz heißt es: „normalerweise bedeutet dies, dass die Drittländer namentlich angegeben werden“ (S. 48). Auch der EDSA scheint also nicht per se von einer Pflicht zur Angabe des Drittlands auszugehen. Dann kann erst recht keine Pflicht zur Angabe des Ortes der Datenverarbeitung bestehen.  

Art. 15 Abs. 1 lit. c) DSGVO

Die Vorgabe zur Information im Rahmen von Auskunftsverfahren ähnelt sehr stark der Pflicht nach Art. 13 Abs. 1 lit. e) DSGVO. Die Gründe für eine Ablehnung zur Benennung des Ortes der Verarbeitung, lassen sich daher meines Erachtens übertragen.

Zusätzlich könnte man hier (im Fall der Diskussion) noch die Ansicht des AG Seligenstadt (Urt. v. 23.06.2020 – 1 C 7/19 (3)) anführen. Dort wurden Ansprüche gegen eine Sparkasse geltend gemacht, u.a. mit der Forderung, Auskunft wie folgt zu erteilen: „Alle Daten, die zu Verarbeitungszwecken zu den Klägerinnen gespeichert werden, wo diese gespeichert werden und wer auf die gespeicherten Daten Zugriff hat. … Ferner ist Auskunft zu erteilen, welche Daten über Clouddienste gespeichert werden“.

Das AG lehnte diesen Anspruch ab. Da nach Ansicht des AG bereits interne Vermerke und Vorgänge nicht unter den Auskunftsanspruch des Art. 15 DSGVO fallen,

ist die Beklagte erst recht nicht dazu verpflichtet, die Datenträger und etwaige Cloudspeicher, die sie für die Datenspeicherung nutzt, offenzulegen“. Zudem geht das AG davon aus, dass es ausreicht, wenn Kategorien von Drittempfängern genannt werden.

Ganz unabhängig hiervon, hätte ich aus Unternehmenssicht auch Sicherheitsbedenken, anfragenden Betroffenen den konkreten Ort meiner Datenverarbeitung zu benennen. Denn die Angabe zum Standort der Server (bzw. auch der Backups), kann ja im schlimmsten Fall durchaus ein Sicherheitsrisiko für Unternehmen darstellen. Ggfs. kann man im Rahmen derartiger Anfragen daher auch die Pflichten des Unternehmens nach Art. 32 DSGVO zum Schutz der personenbezogenen Daten anführen (etwa im Rahmen des Art. 15 Abs. 4 DSGVO).

Online-Terminvereinbarung in Arztpraxen – Anforderungen des ULD

In seinem aktuellen Tätigkeitsbericht 2021 stellt das ULD Schleswig-Holstein u.a. auch seine Ansicht zu den datenschutzrechtlichen Anforderungen beim Einsatz von Terminbuchungssoftware bzw. -dienstleistern im medizinischen Bereich vor (ab S. 52).

Zum Ersten stört sich das ULD daran, dass zwar eine Terminbuchung auf einer solchen Plattform verschlüsselt möglich ist, jedoch die Antwort oft unverschlüsselt erfolgt. Ich vermute, dass ULD meint hier vor allem eine auf Webseiten eingesetzte TLS-Verschlüsselung bei der Übertragung der Daten. Jedoch merkt das ULD kritisch an, dass die Antwort per unverschlüsselter E-Mail an Patienten erfolge. Nach Ansicht des ULD genügt dies wohl nicht den Anforderungen des Art. 32 DSGVO (richtig deutlich wird es im Bericht aber nicht).

Praktisch relevant für Arztpraxen und andere Institutionen im Gesundheitsbereich ist der Hinweis des ULD, dass die „Verantwortung“ für die sichere Übermittlung der Arzt trage.

„Durch geeignete technische und organisatorische Maßnahmen ist sicherzustellen, dass Unbefugte keine Kenntnis davon erhalten, wann wer warum in der Praxis einen Termin hat.“

An dieser Feststellung ist sicher richtig, dass der Arzt oder etwa ein Krankenhaus als Verantwortlicher nach Art. 32 DSGVO verpflichtet ist. Doch muss man auch darauf hinweisen, dass ein eingesetzter Auftragsverarbeiter (z.B. der Dienstleister für die Buchung von Online-Terminen) originäre Pflichten nach Art. 32 DSGVO bzgl. der Sicherheit der Verarbeitung hat. In der Konsequenz bedeutet dies nach Art. 82 Abs. 2 S. 2 DSGVO auch, dass ein Auftragsverarbeiter gegenüber Betroffenen selbst für Verstöße auf Schadensersatz haften kann. Natürlich könnte aber etwa das ULD dennoch überlegen, in einem solchen Fall ein Bußgeld gegen den Verantwortlichen zu verhängen, etwa mit der Begründung, er habe den Dienstleister nicht ordentlich ausgewählt oder die technischen Maßnahmen des Dienstleisters akzeptiert.

Zum Zweiten geht das ULD davon aus, dass der Einsatz solcher externen Dienstleister für Terminbuchungen „regelhaft“ eine Auftragsverarbeitung darstellen wird. Und hieraus ergeben sich für das ULD zwei Anforderungen, die ich so jedoch aus der DSGVO nicht herauslese und hinsichtlich derer man daher zumindest auch anderer Ansicht sein kann.

Zum einen verlangt das ULD tatsächlich, dass „ein schriftlicher Auftragsverarbeitungsvertrag abgeschlossen wurde“. Nur dann sei die Auftragsverarbeitung zulässig. Diese Ansicht widerspricht klar den Vorgaben der DSGVO, konkret Art. 28 Abs. 9 DSGVO. Danach ist der Vertrag zwar schriftlich abzufassen, was aber auch in einem elektronischen Format erfolgen kann. Bedeutet (auch nach Ansicht anderer Behörden): Auftragsverarbeitungsverträge können auch elektronisch (zB per PDF und E-Mail Versand) abgeschlossen werden.

Zum anderen verlangt das ULD, dass die bei dem Dienstleister tätigen Personen „auf das Datengeheimnis verpflichtet“ wurden. Zumindest formell muss diesbezüglich angemerkt werden, dass die DSGVO den Begriff „Datengeheimnis“ nicht kennt. Nach Art. 28 Abs. 3 lit. b DSGVO müssen bei dem Dienstleister tätige Personen auf Vertraulichkeit verpflichtet worden sein. Jedoch kann man festhalten, dass sich der Inhalt des früheren Datengeheimnisses nach § 5 BDSG aF, also das Verbot der unrechtmäßigen Verarbeitung, in verschiedenen Regelungen der DSGVO wiederfindet. Mehr Informationen und Empfehlungen hierzu, hatte ich einmal in den BVD News niedergeschrieben (PDF, S. 16). Das in § 53 BDSG erwähnte „Datengeheimnis“ spielt hier keine Rolle, da die Vorschrift eine Umsetzung der JIRL darstellt und nicht in den Anwendungsbereich der DSGVO fällt.

Landgericht Frankfurt: Kein Schadensersatzanspruch allein wegen fehlender Vereinbarung zwischen gemeinsam Verantwortlichen

Mit Urteil vom 18.9.2020 (Az. 2-27 O 100/20) hat das Landgericht Frankfurt am Main einige interessante Aussagen rund um Schadensersatzansprüche nach Art. 82 DSGVO getroffen. Ich beschränke mich hier auf solche zur gemeinsamen Verantwortlichkeit nach Art. 26 DSGVO.

Sachverhalt

In dem Verfahren ging es (vermute ich), um Ansprüche eines ehemaligen Mitglieds des Bonusprogramms von Mastercard „Priceless Specials“, bei dem es im Jahr 2019 zu einem Sicherheitsvorfall bei einem Dienstleister kam, aufgrund dessen Datensätze der Teilnehmer im Internet landeten. Der Kläger machte aus verschiedenen Gründen Schadensersatzansprüche geltend. U.a. auch mit folgender Begründung:

„Dass zwischen der Beklagten und der XXX eine Vereinbarung nach Art. 26 DSGVO fehle, obwohl beide ausweislich des vorgelegten Datenverarbeitungsvertrages Zwecke und Mittel der Verarbeitung durch die XXX festgelegt hätten, verstoße gleichfalls gegen die DSGVO.“

Der Kläger machte mit der Behauptung, es fehle an einer Vereinbarung zur gemeinsamen Verantwortlichkeit, was ihm zusätzlich nicht mitgeteilt worden sei, einen Schadensersatzanspruch in Höhe von insgesamt 1200 EUR geltend.

Entscheidung

Das LG musste sich also auch mit der Frage befassen, ob das (angebliche) Fehlen einer Vereinbarung nach Art. 26 Abs. 1 S. 2 DSGVO bereits einen ersatzfähigen Schaden für betroffene Personen darstellt. Nach Ansicht des Gerichts ist dies jedoch nicht der Fall.

Das LG führt hierzu aus:
„Überdies regelt Art. 26 DSGVO lediglich, dass bei zwei oder mehr Verantwortlichen festzulegen ist, wer welche Verpflichtung gemäß der Verordnung erfüllt. Wo der Schaden des Klägers liegen soll, wenn dies nicht geschehen ist und er nicht informiert wurde, ist nicht ersichtlich. Dies gilt insbesondere vor dem Hintergrund des Art. 26 Abs. 3 DSGVO“.

Das Gericht geht also davon aus, dass allein ein möglichen Fehlen der Vereinbarung zwischen gemeinsam Verantwortlichen noch nicht einen ersatzfähigen Schaden begründet. Dies liegt durchaus auf der Linie auch anderer Gerichte zu dem Schadensersatzanspruch nach Art. 82 DSGVO, die stets verlangen, dass ein konkreter Schaden durch Betroffene auch nachgewiesen wird. Allein der Verstoß gegen eine DSGVO-Pflicht, berechtigt noch nicht per se zum Schadensersatz. Das LG begründet seine Ansicht zudem auch mit einem Verweis auf Art. 26 Abs. 3 DSGVO, wonach Betroffene, unabhängig von Regelungen in der Vereinbarung, ihre Rechte gegen jeden der Verantwortlichen geltend machen können.

Fazit Allein eine fehlende JC-Vereinbarung begründet für sich noch keinen Schadensersatzanspruch. Anders mag dies sein, wenn tatsächlich ein Schaden eingetreten ist, der kausal auf diesem Mangel beruht. Spannend ist sicherlich auch die Frage, ob man die Argumentation des LG auf Verträge nach Art. 28 DSGVO übertragen kann.

Das SchremsII-Urteil des EuGH: Folgen für die Praxis des Einsatzes von Standarddatenschutzklauseln

Was sind die Konsequenzen des Schrems II-Urteils des EuGH (C-311/18)? Was ist bei Datentransfers in die USA und auch andere Drittländer zu beachten? Diese Fragen stellen sich aktuell natürlich viele Unternehmen und allgemein datenverarbeitende Stellen. Ich habe nicht den Anspruch, hierauf abschließende Antworten zu geben.

Gerne möchte ich aber in diesem Beitrag versuchen, das Urteil zum einen systematisch einzuordnen und etwas „aufzudröseln“. Zum anderen auch mögliche (!) praktische Konsequenzen für datenverarbeitende Stellen abzuleiten. Im Blick sollen hierbei die Standardvertragsklauseln (jetzt: Standarddatenschutzklauseln, „SDK“) stehen. Das andere Interpretation des Urteils sicherlich ebenso vertretbar sind, versteht sich meines Erachtens von selbst.

Ich verzichte hier bewusst auf eine Darstellung, was Hintergrund des Verfahrens war und auch auf Erläuterungen, was das EU US Privacy Shield oder die SDK sind.

Da dieser Beitrag relativ lang ist, stelle ich ihn auch in einem PDF-Dokument zum Download bereit.

A. Systematik des Urteils

Meines Erachtens bietet sich zunächst an, den Prüfaufbau des EuGH in den Blick zu nehmen. Dies ist, gerade aufgrund der Länge des Urteils relevant. Denn man kann sich gut in der Begründung verlieren, nur um dann die Frage zu stellen, was denn eigentlich gerade geprüft wird. Hierzu habe ich eine kleine Gliederung erstellt:

1. Das erforderliche Schutzniveau nach Art. 46 Abs. 1 und Art. 46 Abs. 2 lit. c DSGVO, wenn Daten auf der Grundlage von Standarddatenschutzklauseln in ein Drittland übermittelt werden? (ab Rz. 90)

2. Aussetzungspflicht der Datenschutzbehörde, wenn die Klauseln in diesem Drittland nicht eingehalten werden oder nicht eingehalten werden können? (ab Rz. 106)

3. Gültigkeit des Standarddatenschutzklausel-Beschlusses im Hinblick auf die Art. 7, 8 und 47 der Charta („angemessenes Schutzniveau“)? (ab Rz. 122)

4. Ob und inwieweit eine Datenschutzbehörde („DSB“) eines Mitgliedstaats an die Feststellungen im Privacy Shield-Beschluss gebunden ist // ob die auf die Standarddatenschutzklauseln gestützte Übermittlung personenbezogener Daten in die USA die durch die Art. 7, 8 und 47 der Charta verbürgten Rechte verletzt? (ab Rz. 150)

a. Zum Inhalt des Privacy Shield-Beschlusses (ab Rz. 163)

b. Zur Feststellung eines angemessenen Schutzniveaus (ab Rz. 168)

B. Einheitliches Schutzniveau für Kapitel V der DSGVO

Aus der Gliederung wird bereits deutlich, dass der EuGH in dem Urteil zunächst prüft, was denn überhaupt für ein Schutzniveau zu erreichen ist, wenn Daten auf der Grundlage von Art. 46 DSGVO übermittelt werden. In der Prüfung im ersten Abschnitt befasst sich der EuGH ganz allgemein mit der Frage, welches Schutzniveau „geeignete Garantien“ erreichen müssen.

Also ganz abstrakt: gibt es einen Unterschied des zu erreichenden Schutzniveaus bei den Transfermechanismen nach Kapitel V DSGVO?

Nein. Nach dem EuGH gilt für die ganze DSGVO und damit auch Kapitel V ein einheitliches Schutzniveau. Das bedeutet, dass die in Art. 46 Abs. 1 DSGVO genannten „geeigneten Garantien“ so beschaffen sein müssen, dass sie für Personen, deren personenbezogene Daten auf der Grundlage von SDK in ein Drittland übermittelt werden – wie im Rahmen einer auf einen Angemessenheitsbeschluss gestützten Übermittlung – ein Schutzniveau gewährleisten, das dem in der Union garantierten Schutzniveau der Sache nach gleichwertig ist (Rz. 96).

In den Rz. 90-105 geht es noch gar nicht spezifisch um die aktuell geltenden SDK, sondern allgemein um dieses Transferinstrument an sich. Das Gericht betrachtet den allgemeinen Prüfungsmaßstab, der an Datentransfers nach Art. 46 DSGVO zu stellen ist. Die SDK stellen dabei ein Beispiel dar.

C. Anforderungen an Datentransfers ohne Angemessenheitsbeschluss

Nach dem EuGH (und der Vorgaben in Art. 46 Abs. 1 DSGVO) dürfen, bei fehlendem Angemessenheitsbeschluss, personenbezogene Daten an ein Drittland übermitteln werden, wenn der Exporteur folgende drei Ziele erreicht:

  • er „geeignete Garantien“ vorgesehen hat (diese können u.a. in den SDK bestehen)
  • den betroffenen Personen „durchsetzbare Rechte“ und
  • wirksame Rechtsbehelfe“ zur Verfügung stehen (Rz. 91)

Dies sind, für Art. 46 DSGVO, die maßgeblichen drei Kriterien des angemessenen Schutzniveaus.

Wichtig: im Rahmen des Art. 46 DSGVO (und damit auch der SDK) muss aber nicht das Zielland und die dortige Rechtsordnung ein der Sache nach gleichwertiges Schutzniveau aufweisen. Sondern die „geeigneten Garantien“ selbst, also zB die SDK, sollen für Personen ein Schutzniveau gewährleisten, das dem in der Union garantierten Schutzniveau der Sache nach gleichwertig (Rz. 96).

Das bedeutet dann auch, dass der Prüfungsmaßstab für das Schutzniveau inhaltlich ein anderer ist, als im Fall des Angemessenheitsbeschlusses nach Art. 45 DSGVO (vgl. auch Rz. 129 und 130). Das zu erreichende Ziel (Gleichwertigkeit) ist aber dasselbe.

Meine verbildlichte Darstellung: im Fall des Angemessenheitsbeschlusses ist das ganze Drittland eine schöne grüne Datenschutzwiese. Im Fall des Art. 46 DGSVO (also etwa des Einsatzes von SDK) ist das Drittland aber eine böse Vulkanlandschaft, in der Daten nicht sicher sind und mit den SDK wollen wir nun einen Tunnel zu einem bestimmten Empfänger schaffen. Es existiert also, quasi als Voraussetzung, ein Mangel an Datenschutz, der durch den Tunnel für eine Übermittlung ausgeglichen werden muss (Rz. 95). Dieser Tunnel muss die Daten entsprechend den Anforderungen des Art. 46 DSGVO gegen die Vulkanlandschaft schützen.

D. Schutzniveau beim Einsatz von SDK

Das vorlegende Gericht wollte vom EuGH auch wissen, welche Gesichtspunkte denn konkret zu berücksichtigen sind, um festzustellen, ob ein angemessenes Schutzniveau besteht, wenn personenbezogene Daten auf der Grundlage der SDK übermittelt werden (Rz. 102).

Die Antwort des EuGH hierauf ist wenig spezifisch und praxistauglich. Er orientiert sich natürlich an dem oben aufgestellten Schutzniveau für Art. 46 DSGVO. Hinsichtlich seiner bereits zuvor herausgestellten drei Kriterien, erläutert er aber in Rz. 104 zusätzlich, dass in Bezug auf eine Übermittlung auf Grundlage der SDK folgende Punkte zu berücksichtigen sind:

  • insbesondere die vertraglichen Regelungen, die zwischen dem in der Union ansässigen Verantwortlichen und dem im betreffenden Drittland ansässigen Empfänger der Übermittlung vereinbart wurden, sowie,
  • was einen etwaigen Zugriff der Behörden dieses Drittlands auf die übermittelten personenbezogenen Daten betrifft, die maßgeblichen Elemente der Rechtsordnung dieses Landes.

Und hier vollzieht der EuGH einen wichtigen vergleichenden Schwenk zu den Voraussetzungen für einen Angemessenheitsbeschluss: hinsichtlich des Zugriffs von Behörden des Drittlands auf die übermittelten personenbezogenen Daten entsprechen die Elemente, die im Kontext von Art. 46 DSGVO zu berücksichtigen sind, jenen, die in Art. 45 Abs. 2 DSGVO in nicht abschließender Weise aufgezählt werden.

E. Bewertung der aktuell geltenden SDK (2010/87/EU)

Erfüllen die aktuell geltenden SDK diese Anforderungen? Und was ist konkret bei ihrem Einsatz zu beachten? Mit den aktuell geltenden SDK (bzw. genauer, mit dem zugrundliegenden Beschluss der Kommission) befasst sich der EuGH ab Rz. 122.

Die erste wichtig Feststellung des EuGH ist, dass es Situationen geben kann, in denen die SDK unverändert genutzt werden können, da sie selbst das angemessene Schutzniveau schaffen. Der EuGH unterscheidet zwei Szenarien (Rz. 126):

  • Szenario 1: Der Empfänger einer Übermittlung kann, in Anbetracht der Rechtslage und der Praxis im betreffenden Drittland, den erforderlichen Datenschutz allein auf der Grundlage der SDK garantieren kann.
  • Szenario 2: Situationen, in denen die in den SDK enthaltenen Regelungen möglicherweise kein ausreichendes Mittel darstellen, um in der Praxis den effektiven Schutz der in das betreffende Drittland übermittelten personenbezogenen Daten zu gewährleisten.

Zu Szenario 2 nennt das Gericht ein Beispiel: wenn das Recht dieses Drittlands dessen Behörden bezüglicher dieser Daten Eingriffe in die Rechte der betroffenen Personen erlaubt.

Achtung: nur weil Eingriffe in die Rechte der Betroffenen möglich und durch die nicht angepasste Form der SDK nicht ausgeschlossen werden können, sind die SDK aber nicht untauglich. Das ist meines Erachtens wichtig zu erkennen.

Denn Art. 46 Abs. 2 DSGVO verlangt laut dem EuGH nicht, dass sämtliche Garantien zwangsläufig in einem Beschluss der Kommission wie dem SDK-Beschluss vorgesehen sind (Rz. 128). Dies ist auch gar nicht möglich, denn die SDK sind nur allgemein erstellt und gelten für alle Drittländer (Rz. 130, 133).

Ab Rz. 137 befasst sich der EuGH dann mit dem Beschluss der Kommission zu den aktuell geltenden SDK. Die Ausführungen sind also eher abstrakt wertender Natur. Jedoch geht der EuGH in seiner Prüfung der Gültigkeit des Beschlusses auch auf Pflichten ein, die für Verantwortliche gelten und er erläutert, wie diese auszuüben sind.

F. Pflichten des Verantwortlichen (Exporteur) und des Auftragsverarbeiters (Importeur)

Und nun nähern wir uns auch praktischen Vorgaben. Nach dem EuGH kann es, aufgrund dieses allgemeinen Charakters der SDK, in dem oben erwähnten Szenario 2, je nach der in einem bestimmten Drittland gegebenen Lage erforderlich sein, dass der Verantwortliche zusätzliche Maßnahmen ergreift, um die Einhaltung des Schutzniveaus der SDK zu gewährleisten (Rz. 133).

Noch einmal zur Erinnerung: Schutzniveau der SDK ist nach EuGH ein der Sache nach gleichwertiges Schutzniveau wie in der EU.

Und der EuGH geht noch weiter: es obliege vor allem Verantwortlichen, in jedem Einzelfall – gegebenenfalls in Zusammenarbeit mit dem Empfänger der Übermittlung – zu prüfen, ob das Recht des Bestimmungsdrittlands nach Maßgabe des Unionsrechts einen angemessenen Schutz der auf der Grundlage von SDK übermittelten personenbezogenen Daten gewährleistet, und erforderlichenfalls mehr Garantien als die durch diese Klauseln gebotenen zu gewähren (Rz. 134).

Achtung: das bedeutet, dass der exportierende Verantwortliche zumindest vor der Übermittlung validieren muss, ob die unveränderte Form der SDK zum Einsatz kommen kann, um das Schutzniveau (das sie per se schaffen) zu halten. Es geht bei dieser Prüfung nicht um das komplette Recht des Drittlandes. Der EuGH verweist klar auf die konkret übermittelten Daten: „einen angemessenen Schutz der auf der Grundlage von Standarddatenschutzklauseln übermittelten personenbezogenen Daten gewährleistet“ (Rz. 134). Zudem wäre eine Prüfung der gesamten Rechtsordnung nicht mit der vorherigen Begründung des EuGH zu dem Unterschied zwischen Angemessenheitsbeschluss und SDK vereinbar.

Kann der Exporteur oder der Empfänger der Daten keine zusätzlichen Maßnahmen ergreifen, um den Standard der SCC zu halten, ist er verpflichtet, die Übermittlung personenbezogener Daten in das betreffende Drittland auszusetzen oder zu beenden (Rz. 135). Der EuGH nennt auch ein Beispiel: wenn das Recht des Drittlands dem Empfänger Verpflichtungen auferlegt, die den SDK widersprechen und daher geeignet sind, die vertragliche Garantie zu untergraben.

1. Umfang der Prüfpflicht des Verantwortlichen

Und es stellt sich dann natürlich die Frage, was konkret der Verantwortliche vor der Übermittlung zu prüfen hat? Reicht der Nachweis durch den Importeur, dass er sich an die SDK halten kann? Muss der Verantwortliche eigene Untersuchungen anstellen?

Die Antwort hierauf ergibt sich nach dem EuGH (Rz. 141) aus den Klauseln der SDK, konkret Klausel 4 Buchst. a sowie Klausel 5 Buchst. a und b. Diese verpflichten den in der Union ansässigen Verantwortlichen und den Empfänger, sich vor der Übermittlung personenbezogener Daten in ein Drittland zu vergewissern, dass das Recht des Bestimmungsdrittlands es dem Empfänger erlaubt, die SDK einzuhalten.

Das bedeutet, dass die Prüfungsfrage hier auf erster Stufe lautet: kann der Empfänger die SDK auf Basis des für ihn geltenden Rechts einhalten?

Daraus ergeben sich direkt einige wertvolle Erkenntnisse:

  • Es geht immer um die in den SDK festgelegte Übermittlung; nicht generell um Übermittlungen in das Drittland.
  • Das bedeutet, die Einhaltung der SDK ist grundsätzlich vertragsspezifisch zu prüfen.
  • Die Einhaltung der SDK im Hinblick auf das Recht im Drittland, muss daher wohl auch konkret anhand der zu übermittelnden Daten und des spezifischen Empfängers geprüft werden (und nicht allgemein).
  • Sowohl der Verantwortliche als auch der Empfänger sind verpflichtet, sich entsprechend zu vergewissern (natürlich insbesondere in Form der Zusammenarbeit).

2. Inhalt der Prüfpflicht

Und der EuGH gibt zudem noch einen Hinweis darauf, was die Vertragsparteien bei dieser Prüfung als Bewertungskriterien zu berücksichtigen haben, wovon sie sich also „vergewissern“ müssen.

In der Fußnote zu Klausel 5 der SDK wird klargestellt, dass zwingende Erfordernisse des Rechts im Drittland, die nicht über das hinausgehen, was in einer demokratischen Gesellschaft zur Gewährleistung u. a. der Sicherheit des Staates, der Landesverteidigung und der öffentlichen Sicherheit erforderlich ist, nicht den Standarddatenschutzklauseln widersprechen.

Das heißt: ein angemessenes Schutzniveau kann auf Basis der SDK auch dann bestehen, wenn Behörden des Drittlandes Zugriff auf die übermittelnden Daten nehmen. Das ist eine wichtige Klarstellung des EuGH, die auch in der Praxis Relevanz hat.

Nur muss dieser Zugriff legislativ so ausgestaltet sein, dass er den Anforderungen des vormaligen Art. 13 Abs. 1 RL 95/46/EG genügt. Dort wurden Ziele aufgeführt, die einschränkende Gesetzesmaßnahmen verfolgen müssen, damit sie zulässig sind.

Art. 13 RL 95/46/EG existiert jedoch nicht mehr. Da nach Art. 94 Abs. 2 DSGVO Verweise auf die RL 95/46/EG als Verweise auf die DSGVO zu verstehen sind, muss man hier meines Erachtens an die Stelle des Art. 13 Abs. 1 RL 95/46/EG nun Art. 23 Abs. 1 DSGVO und die dort benannten Ziele setzen (die jenen des Art. 13 Abs. 1 RL 95/46/EG sehr ähnlich sind. Hierzu gehören:

  • die nationale Sicherheit;
  • die Landesverteidigung;
  • die öffentliche Sicherheit;
  • die Verhütung, Ermittlung, Aufdeckung oder Verfolgung von Straftaten oder die Strafvollstreckung, einschließlich des Schutzes vor und der Abwehr von Gefahren für die öffentliche Sicherheit;
  • den Schutz der Unabhängigkeit der Justiz und den Schutz von Gerichtsverfahren;
  • den Schutz der betroffenen Person oder der Rechte und Freiheiten anderer Personen;
  • die Durchsetzung zivilrechtlicher Ansprüche.

Aber: es reicht nicht, dass das Recht des Drittlandes bei dem Zugriff auf die Daten ein solches Ziel verfolgt. Der Zugriff muss auch zur Verfolgung dieses Ziels erforderlich sein. Verlangt wird also eine Verhältnismäßigkeitsprüfung. Und hier wird es meines Erachtens für europäische Unternehmen alleine sehr schwer, diese Prüfung valide vornehmen zu können. Insbesondere sollten hierbei daher die Empfänger im Drittland unterstützen.

Der EuGH stellt klar, dass es als Verstoß gegen die SDK anzusehen ist, wenn einer aus dem Recht des Bestimmungsdrittlands folgenden Verpflichtung nachgekommen wird, die über das hinausgeht, was für Zwecke wie die oben genannten erforderlich ist.

3. Umsetzung in der Praxis?

In der Praxis könnte der Verantwortliche etwa über einen vorgefertigten Fragenkatalog an den Empfänger validieren, ob Zugriffe möglich sind und wenn ja, zu welchem Zweck. Sind Zugriffe auf die Daten möglich, so muss dieser Zugriff auf seine Erforderlichkeit hin geprüft werden. Meines Erachtens ergibt sich aus dem Urteil nicht, dass der Verantwortliche selbst diese Prüfung vorzunehmen hat. Es dürfte auch in Ordnung sein, wenn der Importeur (etwa über ein rechtliches Gutachten) dem Verantwortlichen nachweisen kann, dass die Zugriffe durch Behörden die europäischen Anforderungen erfüllen.

Die Prüfung erfolgt also grob wie folgt:

Stufe 1: Einsatz der unveränderten SDK. Kann der Empfänger alle SDK Pflichten einhalten?

  • Verantwortlicher muss sich hiervon „vergewissern“ (ggfs. in Zusammenarbeit mit dem Empfänger).
  • „Vergewissern“ umfasst die Prüfung, ob Zugriffe von Behörden auf die Daten möglich sind.
  • Wenn ja, dann muss geprüft werden, ob die Zugriffe erforderlich sind, um einem in Art. 23 Abs. 1 DSGVO erwähnten Ziel zu dienen und erforderlich sind.

Stufe 2: Pflichten der SDK reichen allein nicht aus. Zusätzliche Maßnahmen sind umzusetzen (Rz. 146).

  • Diese Maßnahmen können sowohl vertraglicher als auch technischer Natur sein.
  • Achtung: Risiko für den Importeur, gegen nationales Recht zu verstoßen.

Meines Erachtens ist noch einmal wichtig klarzustellen, dass die fehlende Möglichkeit, die SDK Pflichten einzuhalten, nach Ansicht des EuGH nicht direkt zur Unzulässigkeit der Übermittlung führt. Nur wenn dann auch zusätzliche Mittel bzw. Garantien nicht helfen, muss die Aufsichtsbehörde den Transfer untersagen bzw. vorher schon der Exporteur. Dies ergibt sich aus Rz. 146: „…,dass die Klauseln in diesem Drittland nicht eingehalten werden oder nicht eingehalten werden können und dass der nach dem Unionsrecht erforderliche Schutz der übermittelten Daten nicht mit anderen Mitteln gewährleistet werden kann“.

Der EuGH endet dann in Rz. 149 mit der Feststellung, dass die SDK in ihrer aktuellen Fassung und durch die dort enthaltenen Garantien grundsätzlich das erforderliche Schutzniveau (Rz. 96, „gleichwertig“) bieten. Ist die Einhaltung der SDK nicht möglich, müsste man mit der oben genannten Stufe 2 der Prüfung und Umsetzung weiterer Garantien fortfahren.

Datenschutzbehörde Niedersachsen: umfassende FAQ zur Auftragsverarbeitung nach der DSGVO

Die LfD Niedersachsen hat auf ihrer Webseite ein Dokument mit FAQ zur Auftragsverarbeitung nach der DSGVO veröffentlicht (Stand: Juni 2020).

Derartige Dokumente und Hinweise sind in der Praxis gerade mit Blick auf das Thema Auftragsverarbeitung sehr wertvoll, da die DSGVO diesbezüglich gar keine Beispiele enthält und sich immer wieder Abgrenzungsfragen stellen.

Nachfolgend greife ich ein paar Ansichten und Hinweise der LfD heraus.

Wann liegt eine Auftragsverarbeitung vor?

Nach Auffassung der LfD geht es bei einer Auftragsverarbeitung „um eine spezifische Form der Aufgabenübertragung bei der Verarbeitung personenbezogener Daten“. Als Beispiel nennt die Behörde datenschutzkonforme Vernichtung von Dokumenten oder Datenträgern.

In Frage 2 stellt die LfD zwei Prüffragen zur Einordnung dar, ob eine AV-Konstellation vorliegt. Sollten beide Fragen mit „ja“ beantwortet werden, so liege eine Auftragsverarbeitung vor.

Erste Frage: Werden bei dem Verarbeitungsprozess personenbezogene Daten verarbeitet?

Zweite Frage: Ist die mit der Verarbeitung personenbezogener Daten beauftragte Stelle nicht verantwortlich?

Meines Erachtens sind diese beiden Fragen jedoch in der Praxis nicht unbedingt zielführend. Insbesondere hinsichtlich der ersten Frage gibt es oft Situationen, in denen zwar Daten verarbeitet werden, aber natürlich keine Auftragsverarbeitung vorliegt. Zudem kann man eigentlich die zweite Frage für sich alleinstehen lassen. Denn diese betrifft schon das Ergebnis, was eigentlich mit Beantwortung beider Fragen erst gefunden werden soll. Oder anders: wenn jemand Verantwortlicher in Bezug auf eine Verarbeitung ist, dann ist er nicht Auftragsverarbeiter. Das ist klar, soll aber durch die beiden Fragen eigentlich erst festgestellt werden.

Für die Praxis relevant sind einige bei der zweiten Frage genannten Regelbeispiele für Auftragsverarbeitungen:

  • Verarbeitung von Kundendaten durch ein Call-Center ohne wesentliche eigene Entscheidungsspielräume dort,
  • Datenverarbeitungstechnische Arbeiten für die Lohn- und Gehaltsabrechnung oder die Finanzbuchhaltung durch Rechenzentren,
  • elektronische Rechnungserstellung.

Privilegierung der Auftragsverarbeitung?

Zudem geht die LfD auch darauf ein, ob der Auftragsverarbeiter eine eigene Rechtsgrundlage für die Verarbeitung benötigt.

Dies ist nach Ansicht der LfD nicht der Fall. Aber: es ist das Vorliegen einer Rechtsgrundlage nötig, jedoch nicht beim Auftragsverarbeiter. Der Auftragsverarbeiter stützte sich für die Verarbeitung personenbezogener Daten „im Auftrag“ auf die dem Verantwortlichen zustehende Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO. Wie die LfD zu diesem Ergebnis auf Grundlage der DSGVO kommt, bleibt aber unklar.

Entscheidend ist der Kern der beauftragten Leistung

Im Zusammenhang mit den obigen Kontrollfragen stellt die LfD dann bei Frage 4 klar, dass es auch Konstellationen gibt, in denen zwar Daten verarbeitet werden, die andere Stelle aber nicht als Auftragsverarbeiter agiert. Ähnlich wie schon das BayLDA, stellt die LfD (meines Erachtens zurecht) auf den Kern der beauftragten Leistung ab. Eine Auftragsverarbeitung kann daher verneint werden,

wenn die Datenverarbeitung lediglich im Zusammenhang mit der Erbringung einer (Haupt-)Dienstleistung für einen anderen erfolgt. Gemäß Erwägungsgrund 81 zur DS-GVO muss der Verantwortliche den Auftragsverarbeiter mit der Verarbeitung von personenbezogenen Daten „betrauen wollen“. Dieses kann im Einzelfall verneint werden, wenn die Datenverarbeitung nicht speziell beabsichtigt ist beziehungsweise nicht den Schwerpunkt oder einen wichtigen (Kern-)Bestandteil der Leistung des Auftragnehmers darstellt.

Die LfD nennt hierfür auch Beispiele:

  • Wenn ein Copyshop den Auftrag erhält, einige T-Shirts mit Namen zu bedrucken
  • Der Hersteller von Produkten erhält für mit Endkunden vereinbarte Direktlieferungen vom Online-Händler die Adresse des Kunden (Dropshipping) (hierzu enthält das Dokument auch ein Schaubild)
  • Blumen- oder Weinhändler erhält zur Versendung von Blumen- beziehungsweise Weingeschenken an dritte Personen von seinem Kunden eine Liste mit Adressdaten der Empfänger

Vertrag ist nicht immer erforderlich

Interessant ist zudem die Ansicht der LfD, ob immer ein Vertrag zur Auftragsverarbeitung (Art. 28 DSGVO) abzuschließen ist. Zwar sein für die Auftragsverarbeitung ein konkreter Rahmen festzulegen.

Dafür müssen der Verantwortliche und der Auftragsverarbeiter in der Regel einen Vertrag zur Auftragsverarbeitung schließen. Alternativ kann sich der Auftragsverarbeiter zum Beispiel auch einseitig gegenüber dem Verantwortlichen verpflichten.

Die LfD lässt mithin auch die einseitige Verpflichtung des Auftragsverarbeiters ausreichen. Näher begründet wird diese Ansicht nicht. Ich vermute, die LfD stützt sich auf Art. 38 Abs. 3 DSGVO, in dem es heißt: „oder eines anderen Rechtsinstruments nach dem Unionsrecht oder dem Recht der Mitgliedstaaten, der bzw. das den Auftragsverarbeiter in Bezug auf den Verantwortlichen bindet“.

Antworten auf Einzelfragen

In Antwort 7 des Dokuments finden sich dann verschiedene Antworten auf spezifische Einzelfragen.

Dort verweist die LfD u.a. auf eine abgestimmte Position der deutschen Behörden, dass für IT-Wartungsdienstleistungen ein Vertrag zur Auftragsverarbeitung abzuschließen ist. Grund sei, dass im Rahmen der beauftragten Tätigkeit für den Dienstleister zumindest die Möglichkeit des Zugriffs auf personenbezogene Daten der Beschäftigten des Auftraggebers oder auf Kundendaten bestehe, zum Beispiel bei Fehleranalysen, bei Remote-Zugriffen oder bei Support-Arbeiten. Meines Erachtens steht diese Ansicht aber der zuvor genannten Sichtweise entgegen, dass es auf den Kern der Beauftragung ankommt. Wenn ein Unternehmen aber gerade nicht mit der Verarbeitung von Daten (oder dem Zugriff darauf) beauftragt wird, dann liegt eigentlich keine Auftragsverarbeitung vor. Nach Ansicht der Behörden hier dann aber wohl doch. Die Begründung: aufgrund der

bestehenden technischen Möglichkeit zur systematischen und umfassenden Verarbeitung personenbezogener Daten ist im Hinblick auf die Leistung des Auftragnehmers stets ein entsprechender Schwerpunkt in der Datenverarbeitung zu sehen.

Die Möglichkeit (!) des Zugriffs, führt also zum Schwerpunkt der Tätigkeit. Interessant. Meines Erachtens ist diese Auffassung nicht mit der zuvor von der LfD selbst genannten Ansicht, nach der es stets um den Kern der beauftragten Leistung geht, vereinbar. Zumindest fehlt mir eine plausible Begründung für diese Abweichung. Ich vermute, die deutschen Behörden möchten gerne die gesetzliche Fiktion des § 11 Abs. 5 BDSG aF in das neue Datenschutzrecht „retten“. Dazu muss man aber sagen: § 11 Abs. 5 BDSG aF existiert weder im neuen BDSG und erst recht nicht in der DSGVO. Diese Auffassung halte ich daher für diskutabel, zumal sie in der Praxis Unsicherheiten schafft, wann allein die Möglichkeit eines Zugriffs quasi zur Auftragsverarbeitung führt.

Hessische Datenschutzbehörde: Keine hohen Anforderungen an „Schriftform“ von Auftragsverarbeitungsverträgen

Der Hessische Datenschutzbeauftragte (HBDI) hat kürzlich seinen neuen, 48. Tätigkeitsbericht veröffentlicht (pdf).

Unter anderem befasst sich die Aufsichtsbehörde dort auch mit einem immer noch praxisrelevanten Thema: in welcher Form dürfen bzw. müssen Verträge zur Auftragsverarbeitung (AVV) abgeschlossen werden?

Bereits in der Vergangenheit hatte ich darauf hingewiesen, dass selbst die Europäische Kommission keine allzu hohen Anforderungen an die Form eines AVV stellt.

Art. 28 Abs. 9 DSGVO gibt vor:

Der Vertrag oder das andere Rechtsinstrument im Sinne der Absätze 3 und 4 ist schriftlich abzufassen, was auch in einem elektronischen Format erfolgen kann.“

Bedeutend ist also, was mit „schriftlich“ und „elektronischen Format“ gemeint ist.

Nach Ansicht des HBDI ist das Schriftformerfordernis des Art. 28 Abs. 9 DSGVO nicht identisch mit der Schriftform nach § 126 BGB. Meines Erachtens ist diese Ansicht zutreffend. Unter anderem auch deshalb, weil es sich bei der DSGVO um EU-Recht handelt und eine europarechtsautonome Auslegung erforderlich ist. Der Verweis auf nationale Formvorschriften im Zivilrecht passt daher nicht.

Der HBDI geht davon aus, dass demnach nicht wie nach § 126 Abs. 1 BGB zwingend eine vom Aussteller eigenhändig unterschriebene Urkunde erstellt werden muss. Oder anders ausgedrückt: ein AVV muss nicht handschriftlich unterzeichnet werden.

Danach geht der HBDI auf den Sinn und Zweck der Formvorschrift in Art. 28 DSGVO ein. Mit der in der DSGVO angeordneten Schriftform soll sichergestellt werden, dass die Beteiligten die Möglichkeit haben, sich dauerhaft und zuverlässig über den Inhalt des AVV oder einer einseitigen Verpflichtungserklärung zu informieren.

Diese dauerhafte Informationsfunktion erfüllt auch die Textform, wie sie in § 126b BGB geregelt ist.

Der HBDI lässt also auch solche AVV als wirksam gelten, die „nur“ das deutsche Erfordernis an die Textform erfüllen würden.

Und dann nennt der HBDI auch konkrete Beispiele, wie in der Praxis ein AVV wirksam abgeschlossen werden kann:

  • Austausch von Computerfaxen
  • Austausch von E-Mails mit oder ohne PDF-Anhang

Beide Varianten genügen dem Schriftformerfordernis des Art. 28 Abs. 9 DSGVO.

Zudem weist der HBDI darauf hin, dass der Auftragsverarbeiter auch einen Vertragstext auf seiner Webseite einstellen und der Verantwortliche die Annahmeerklärung durch Anklicken eines Kästchens wirksam abgeben kann.

Jedoch muss dann sichergestellt sein, dass der Verantwortliche den Vertrag speichern und ausdrucken kann. Nach Ansicht des HBDI verlangt die DSGVO nicht, dass ein Download tatsächlich erfolgt.

Zudem geht der HBDI auch auf das Merkmal „elektronischem Format“ ein. Hiermit kann nicht ein nach § 126 a BGB elektronisch signiertes Dokument gemeint sein. Begründet wird diese Ansicht (meines Erachtens zutreffend) u.a. damit, dass sich in Art. 30 Abs. 3 DSGVO für das Führen des Verarbeitungsverzeichnisses eine wortgleiche Schriftformregelung findet.

Es ist jedoch kein Grund ersichtlich, weshalb ein Verzeichnis von Verarbeitungstätigkeiten mit einer qualifizierten elektronischen Signatur versehen werden sollte. Es gibt aber auch keine Anhaltspunkte, dass der Unionsgesetzgeber den Begriff „elektronisches Format“ in den beiden Regelungen mit unterschiedlichem Inhalt verwendet hat.

Einsatz von Dienstleistern im Rahmen der Erfüllung von Betroffenenrechten – LDA Brandenburg verhängt 50.000 EUR Bußgeld

In seinem aktuellen Tätigkeitsbericht für 2019 (S. 29 ff, pdf), berichtet das LDA Brandenburg über einen praktisch interessanten und relevanten Fall, in dem gegen ein Unternehmen wegen Verstößen gegen Art. 28 Abs. 9 DSGVO und Art. 12 DSGVO ein Bußgeld verhängt wurde.

Abschluss eines Auftragsverarbeitungsvertrages

Das Unternehmen setzte im Rahmen der Auskunftserteilung nach Art. 15 DSGVO einen Dienstleister ein, der Zugriff auf die für die Auskunftserteilung notwendigen personenbezogenen Daten der betroffenen Person hatte. Die Korrespondenz im Rahmen der Auskunftserteilung wurde unter dem Logo des Dienstleisters durchgeführt.

Erste wichtige Erkenntnis: das LDA scheint grundsätzlich davon auszugehen, dass Dienstleister als Auftragsverarbeiter Betroffenenrechte erfüllen dürfen.

Jedoch wurde hier ein Vertrag nach Art. 28 Abs. 9 DSGVO wohl nicht schriftlich abgeschlossen. Aus den Darstellungen geht nicht klar hervor, ob gar kein Vertrag abgeschlossen wurde oder nur nicht schriftlich. Leider geht das LDA nicht auf die Möglichkeit ein, dass der Vertrag auch in einem elektronischen Format abgeschlossen werden kann. Ich vermute aber daher, dass gar kein Vertrag vorlag.

Das LDA verweist mit Blick auf Art. 28 Abs. 9 DSGVO darauf, dass diese Regelung Dokumentations-, Beweissicherungs- und Authentizitätssicherungszwecke verfolge.

Die Schriftform soll sicherstellen, dass die Parteien, die in dem Dokument genannt sind, sich zu den eingegangenen Verpflichtungen mit dem konkreten Inhalt bekennen.

Ein Verstoß kann nach Art. 83 Abs. 4 lit. a DSGVO mit einer Geldbuße von bis zu 10 Millionen Euro oder im Falle eines Unternehmens mit bis zu 2 % seines gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahres geahndet werden.

Transparenz der Auskunft

Ein zweiter Aspekt des Falles war, dass die Betroffenen nicht wussten, dass es sich bei dem antwortenden Unternehmen um den Dienstleister des Verantwortlichen handelte. Insofern konnten sie nach Ansicht des LDA nicht erkennen, wer der Verantwortliche der Datenverarbeitung war. Zudem erfolgte die erste Antwort an anfragende Betroffene nach Antragstellung zur Auskunftserteilung zunächst nur in englischer Sprache.

Nach Art. 12 Abs. 1 DSGVO muss der Verantwortliche geeignete Maßnahmen treffen, um der betroffenen Person zum Beispiel alle Mitteilungen gemäß dem Art. 15 DSGVO (also im Rahmen der Auskunftserteilung) in präziser, transparenter, verständlicher und leicht zugänglicher Form zu übermitteln.

Vorliegend befand das LDA, dass das Unternehmen dadurch, dass es die Antragsteller nicht darüber aufklärte, dass es sich bei dem eingesetzten Dienstleister um einen Auftragsverarbeiter handelte und dass, trotz Erteilung der Auskunft unter dem Logo des Dienstleisters, das Unternehmen selbst für die Datenverarbeitung verantwortlich blieb, gegen den in Art. 12 DSGVO niedergelegten Transparenzgrundsatz verstieß.

Gleichzeitig habe das Unternehmen dadurch, dass es die Antragsteller zunächst in englischer Sprache kontaktierte, gegen den in Art. 12 DSGVO niedergelegten Grundsatz der Verständlichkeit verstoßen.

Die Ansicht des LDA ist hier meines Erachtens für die Praxis ziemlich relevant:

Wenn sich ein Unternehmen mit seinem Angebot an den deutschsprachigen Markt richtet, muss die Auskunftserteilung (zumindest auch) auf Deutsch erfolgen.

Das bedeutet, dass selbst international tätige Unternehmen in der jeweiligen Landessprache der von ihnen bedienten Märkte gegenüber Betroffenen kommunizieren müssen, wenn diese von ihren Rechten Gebrauch machen.

Das LDA beurteilte diesen Verstoß gegen Art. 12 DSGVO auf der Grundlage von Art. 83 Abs. 5 DSGVO. Danach können Geldbußen von bis zu 20 Millionen Euro oder im Fall eines Unternehmens von bis zu 4 % seines gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahres verhängt werden.

Insgesamt verhängte das LDA für die vorbenannten Verstöße ein Bußgeld in Höhe von 50.000 EUR.