Die neuen Standarddatenschutzklauseln für Datenübermittlungen in Drittländer

Inhaltsverzeichnis:

  1. Überblick, Aufbau und allgemeine Hinweise
  2. Rechtliche Änderungen – Allgemeine Regelungen für alle Transferkonstellationen
  3. Besondere Regelungen für die verschiedenen Transferkonstellationen
  4. Fazit und Ausblick: Gefahr gebannt?
  5. Praktische Arbeitshilfe und Handlungsleitfaden

Vorwarnung: Diese Mandanteninformation ist lang. Sehr lang. Angesichts der Komplexität des Themas und der Vielzahl an relevanten Details geht es leider nicht anders. Am Ende des Dokuments finden sich im 4. und 5. Teil eine Bewertung der neuen Standarddatenschutzklauseln für Drittlandübermittlungen sowie praktische Umsetzungshinweise. Außerdem werden wir in den nächsten Tagen noch eine Zusammenfassung („One Pager“) veröffentlichen. Damit fassen wir die wesentlichen Aussagen noch einmal für Unternehmensleitungen und Andere zusammen, welche die Details für ihre tägliche Arbeit nicht benötigen.

1. Überblick, Aufbau und allgemeine Hinweise

Am 16.7.2020 hat der EuGH mit dem sog. „Schrems II“ Urteil (C-311-18) das sog. EU-US Privacy Shield für unwirksam erklärt. Zugleich hat der EuGH die für alle Datenübermittlungen in Drittländer geltenden Anforderungen aus den Art. 44 ff. DSGVO konkretisiert.

Es genügt hiernach nicht (mehr), bei Datenübermittlungen in Drittländern ohne sog. Angemessenheitsbeschluss die alten Standardvertragsklauseln („SCC“) abzuschließen oder auf sog. Binding Corporate Rules („BCR“) abzustellen. Zusätzlich musste, soweit im Übrigen nicht gewährleistet, positiv durch technische, vertragliche und organisatorische Maßnahmen vom Datenexporteur in der EU ein angemessenes Datenschutzniveau für die exportierten personenbezogenen Daten sichergestellt sein (ausführlich zum Urteil und den Folgen: EuGH kappt Datenübermittlungen in die USA und Schrems II in der Praxis: Handlungsmöglichkeiten bei Drittlandübermittlungen).

Am 10.11.2020 veröffentlichte der Europäische Datenschutzausschuss („EDSA“) dann seine Empfehlungen zur Umsetzung des Schrems II-Urteils in der Praxis. Bestandteil dieser Empfehlungen war ein sog. Transfer Impact Assessment („TIA“) des Datenexporteurs. Zugleich wurden konkrete Anforderungen an zusätzliche vertragliche Vereinbarungen zu den SCC formuliert, um Drittlandübermittlungen in dem vom EuGH geforderten Umfang abzusichern (ausführlich zu den Empfehlungen des EDSA: Drittlandübermittlungen: EDSA veröffentlicht Empfehlungen).

Es bestand also Handlungsbedarf bei der EU-Kommission, endlich die veralteten Standardvertragsklauseln für Drittlandübermittlungen aus den Jahren 2006 und 2010 zu aktualisieren und an die DSGVO sowie das „Schrems II“ Urteil und die Empfehlungen des EDSA anzupassen. Mit dem am 4.6.2021 veröffentlichten Durchführungsbeschluss der EU-Kommission über Standardvertragsklauseln für die Übermittlung personenbezogener Daten an Drittländer sind die Weichen für die künftige Vertragsgestaltung bei Drittlandübermittlungen nunmehr gestellt (siehe Durchführungsbeschluss (EU) 2021/914 der EU Kommission).

Begriffsverwirrung: SCC oder SDK? Art. 46 Abs. 2 Buchst. c DSGVO spricht bei Drittlandübermittlungen von Standarddatenschutzklauseln (kurz SDK) als geeigneten Garantien, während Art. 28 Abs. 7 DSGVO bei der Auftragsverarbeitung Standardvertragsklauseln (kurz SVK oder auf Englisch SCC) als Gestaltungsmöglichkeit nennt. Die EU-Kommission verwendet leider beide Begriffe gleichbedeutend. In der Sache ist die Bezeichnung unschädlich: Wichtig ist nur, zwischen den Standardbedingungen für Drittlandübermittlungen einerseits und den Musterverträgen für Auftragsverarbeitungen in der EU andererseits (siehe separate Mandanteninformation dazu und EU-Kommission: Neue Standarddatenschutzklauseln veröffentlicht – und Standardvertragsklauseln auch) zu differenzieren.

Wirksamkeit und Übergangsfristen

Der Beschluss tritt am 27.6.2021 in Kraft.

Nach einer Übergangsfrist von drei Monaten sind ab dem 27.9.2021 für neue Datenübermittlungen ausschließlich die neuen Standarddatenschutzklauseln („SDK“) zu nutzen, die früheren Standardvertragsklauseln („SCC-alt“) dürfen ab dann nicht mehr eingesetzt werden. Neue Drittlandübermittlungen, die noch auf die SCC-alt gestützt werden, sind ab dann rechtswidrig.

Für Bestandsübermittlungen in Drittländer gilt eine erweiterte Übergangsfrist von noch einmal 15 Monaten, insgesamt also 18 Monaten. Ab dem 27.12.2022 sind mithin auch alle vor dem Wirksamwerden der SDK begonnenen Drittlandübermittlungen von den SCC-alt auf die SDK umzustellen. Werden Altübermittlungen hiernach weiter auf die SCC-alt gestützt, sind diese ebenfalls rechtswidrig.

Achtung: Die erweiterte Übergangsfrist gilt nur für solche Bestandsübermittlungen, bei denen zusätzlich zu den SCC-alt auch die weiteren vom EuGH formulierten Bedingungen zur Schaffung eines angemessenen Datenschutzniveaus gegeben sind (dazu oben). Wurden also zu den SCC-Alt keine zusätzlichen technischen, organisatorischen und vertraglichen Maßnahmen getroffen, obwohl ohne solche Maßnahmen das Schutzniveau beim Datenimporteur im Drittland (etwa in den USA) nicht hoch genug ist, besteht das Risiko, dass solche Altverträge ebenfalls schon bis zum 27.9.2021 auf die SDK umzustellen sind.

Modularer Aufbau

Die SDK folgen einem modularen Aufbau.

Während die SCC-alt für die Konstellationen „Controller to Processor“ (C2P, also Übermittlungen an Auftragsverarbeiter) und „Controller to Controller“ (Set I und Set II) (C2C, also Übermittlungen zwischen zwei Verantwortlichen) jeweils ein eigenes Dokument waren, unterteilen sich die SDK in insgesamt vier Abschnitte und kombinieren dabei allgemeine und besondere Regelungen:

  • Abschnitt I enthält allgemeine Regelungen, die vor die Klammer gezogen werden und damit unabhängig von der/den konkreten Transferkonstellation(en) Geltung beanspruchen sollen.
  • Abschnitt II enthält die besonderen Pflichten der Vertragsparteien. Als Kernstück der SDK werden hier für die jeweilige(n) Transferkonstellation(en) spezifische Regelungen getroffen. Damit sollen die SDK den verschiedenen Transferszenarien und Komplexität moderner Verarbeitungsketten gerecht werden.
  • Abschnitt III adressiert die Auswirkungen lokaler Rechtsvorschriften und Gepflogenheiten, die sich auf die Einhaltung der SDK auswirken sowie Pflichten des Datenimporteurs beim Zugang staatlicher Staaten zu den importierten Daten. Insbesondere dieser Abschnitt dient der Erfüllung der vom EuGH postulierten Anforderungen, wonach jeder in der EU ansässige Datenexporteur vor der Übermittlung an einen Datenimporteur in einem Drittland eine dokumentierte Risikobewertung („Data Transfer Impact Assessment“ oder „TIA“) durchzuführen hat.
  • Abschnitt IV enthält Schlussbestimmungen. Hiernach kann der Datenexporteur den Vertrag kündigen, sollte der Datenimporteur den Vertrag verletzt haben oder die darin festgelegten Bedingungen nicht erfüllen. Ferner wird dort das anwendbare Recht festgelegt sowie die Beilegung von Streitigkeiten vor Gerichten der EU-Mitgliedstaaten bestimmt.

Anhänge

Die SDK haben nun die folgenden Anhänge:

  • Anhang I dient der Festlegung der Einzelheiten zu den Vertragsparteien, personenbezogenen Daten und deren Übermittlung. Dies beinhaltet auch Einzelheiten zu der jeweils vorliegenden Transferkonstellation sowie die Nennung der zuständigen Aufsichtsbehörde(n).
  • Anhang II dient der Festlegung der technischen und organisatorischen Maßnahmen („TOM“), einschließlich der Gewährleistung der Sicherheit der Daten. Zur Beschreibung der TOM ist eine Erläuterung ergänzt.
  • Anhang III enthält die Angaben zu den an der Verarbeitung beteiligten, weiteren Auftragsverarbeitern (Unterauftragsverarbeiter).

Berücksichtigte Transferkonstellationen

Während die SCC-alt lediglich die Transferkonstellationen „Controller to Processor“ (C2P) und „Controller to Controller“ (C2C) abbildeten, erfassen die SDK alle denkbaren Transferkonstellationen, unterteilt in vier verschiedene Module:

  • Modul 1: Transfer „Controller to Controller“
    (C2C = Verantwortlicher an anderen Verantwortlichen),
  • Modul 2: Transfer „Controller to Processor“
    (C2P = Verantwortlicher an einen Auftragsverarbeiter),
  • Neu – Modul 3: Transfer „Processor to Processor“
    (P2P = Auftragsverarbeiter an einen weiteren Auftragsverarbeiter), und
  • Neu – Modul 4: Transfer „Processor to Controller“
    (P2C = Auftragsverarbeiter an einen Verantwortlichen).

Dies ist eine wesentliche Neuerung gegenüber den SCC-alt.

Durch den modularen Aufbau können die für alle Transferkonstellationen geltenden, allgemeinen Regelungen beibehalten werden, während die einzelnen Module entsprechend der tatsächlich vorliegenden Konstellation(en) ausgewählt werden. Der modulare Ansatz ermöglicht es, die SDK in eine Mehrparteienparteienvereinbarung aufzunehmen, welche alle vier Szenarien abdeckt. Das Modularsystem verlangt eine präzise Abbildung der jeweiligen Transfersituation in den Anhängen zu den SDK. Es muss jederzeit feststellbar sein, welcher Akteur welche Rolle in Bezug auf eine bestimmte Übermittlung oder eine Reihe von Übermittlungen personenbezogener Daten einnimmt.

Die SDK sind für verschiedenen Einsatzszenarien nutzbar. Dies betrifft zunächst die Nutzung sowohl durch Verantwortliche als auch Auftragsverarbeiter jeweils als Datenexporteur. Weiterhin sind die SDK bei einer Weiterübermittlung personenbezogener Daten durch einen nicht in der EU ansässigen Verantwortlichen, Auftragsverarbeiter oder Unterauftragsverarbeiter einsetzbar, wenn der nachfolgende Datenimporteur (im gleichen oder einem anderen Drittland) den SDK beitritt.

Unklarheit: Erwägungsgrund 7 legt fest, dass die SCC nicht bei Datenübermittlungen an Empfänger in Drittländern eingesetzt werden dürfen, die selbst wegen Art. 3 Abs. 2 DSGVO in den Anwendungsbereich der DSGVO fallen. Ob das bedeutet, dass auf der DSGVO unterworfene Datenimporteure in Drittländern die Art. 44 ff. DSGVO überhaupt keine Anwendung finden (unwahrscheinlich) oder eine andere Rechtfertigung für die Drittlandübermittlungen erforderlich ist (wahrscheinlich), ist ungeklärt. Die EU-Kommission hat bereits die Veröffentlichung von FAQ zu den SDK in den kommenden Wochen angekündigt, welche u.a. diese Frage adressieren sollen.

Anpassungen oder Ergänzungen

Die SDK dürfen von den Vertragsparteien nicht geändert werden, damit die Garantiefiktion einer sicheren Datenübermittlung eintritt und der Datentransfer genehmigungsfrei ist (Art. 46 Abs. 2 Buchst. c DSGVO). Allerdings steht es den Vertragsparteien frei, die SDK in einen umfassenderen Vertrag einzubeziehen und weitere Regelungen oder zusätzliche Garantien zu ergänzen. Sollten diese Regelungen den SDK zuwiderlaufen oder diese aushöhlen enthalten die SDK eine Vorrangklausel, wonach gegenüber anderen Vereinbarungen der Vertragsparteien die SDK bei Widersprüchen stets Vorrang haben.

Kein zusätzlicher Auftragsverarbeitungsvertrag

Die SDK enthalten außerdem alle von Art. 28 DSGVO geforderten Regelungen für Auftragsverarbeiter und Unterauftragsverarbeiter und berücksichtigen die aus Art. 28 Abs. 3 und Abs. 4 DSGVO resultierenden Anforderungen. Bei für eine Auftragsverarbeitung (C2P oder P2P, siehe oben) abgeschlossenen SDK hat das zur Folge, dass einen zusätzlicher Auftragsverarbeitungsvertrag gemäß Art. 28 Abs. 3 DSGVO überflüssig ist.

2. Rechtliche Änderungen – Allgemeine Regelungen für alle Transferkonstellationen

Im Folgenden werden die wichtigsten rechtlichen Änderungen von SCC-alt zu SDK vorgestellt.

Kopplungsklausel (Docking Clause)

Nach Abschnitt I, Klausel 7, kann eine weitere Vertragspartei mit Zustimmung der ursprünglichen Vertragsparteien jederzeit den SDK als Datenimporteur oder Datenexporteur beitreten. Umgesetzt werden soll dies durch Ausfüllen der Anlage und Unterzeichnung des Anhangs I.A. Die beitretende Vertragspartei erhält damit für Ihre Rolle sämtliche Rechte und Pflichten, die sich aus den SDK ergeben. Eine Rückwirkung erfolgt nicht. Die Kopplungsklausel eröffnet damit die Möglichkeit, flexibel auf Änderungen in der Leistungskette zu reagieren, ohne jeweils neue Verträge abschließen zu müssen.

Drittlandübermittlungs-Folgenabschätzung („Data Transfer Impact Assessment“)

Nach Klausel 14 in Abschnitt III (beim Modul „P2C“ nur eingeschränkt anwendbar) müssen die Vertragsparteien eine Prüfung des Bestimmungsdrittlands auf Grundlage spezifischer Umstände der Rechtsordnung des Drittlandes durchführen („Transfer Impact Assessment“ – TIA – oder „Data Transfer Risk Assessment“). Die Vertragsparteien müssen sich davon überzeugen, dass der Datenimporteur in der Lage ist, seinen Verpflichtungen aus den SDK nachzukommen und er nicht durch Gesetze im Drittland daran gehindert ist, seinen Pflichten aus den SDK nachzukommen. Damit greift die Kommission das Schrems II-Urteil auf.

In der Risikobewertung sind die besonderen Umstände der Übermittlung, einschließlich des Inhalts und der Dauer des Vertrags, der Umfang der Übermittlung, die Empfänger, der Zweck der Verarbeitung und die Art der übermittelten Daten zu berücksichtigen. Zudem soll auf die anwendbaren Rechtsvorschriften und Gepflogenheiten im Drittland sowie dort jeweils geltenden Beschränkungen und Garantien eingegangen werden. Schließlich sind von den Vertragsparteien im TIA alle relevanten technischen und organisatorischen Garantien miteinzubeziehen, die bei der Verarbeitung umgesetzt werden. Die EU-Kommission entspricht damit grundsätzlich der Forderung des EDSA, der in seinen Empfehlungen eine Prüfung der Risiken des Transfers anhand objektiver Faktoren fordert (siehe oben).

Zusätzlich sieht der Beschluss die Beachtung von einschlägigen und dokumentierten Erfahrungen vor und enthält damit eine subjektive Komponente im TIA. So könnte zur Ermittlung der Auswirkungen von Rechtsvorschriften und Gepflogenheiten auf die Einhaltung der SDK auch eingebracht werden, ob es bspw. in der Vergangenheit bereits Ersuchen um Offenlegung seitens Behörden gab.

Die Risikobewertung muss dokumentiert werden, wobei der Wortlaut von Klausel 14 d) („The parties agree to document …“) offenlässt, ob dies durch beide Vertragsparteien zu erfolgen hat oder ob die Dokumentation auf eine Vertragspartei delegiert werden kann. EDSA und der Europäische Datenschutzbeauftrage („EDSB“) regten in ihrer Stellungnahme zum Entwurf der SDK an, diese Risikobewertung in einem weiteren Anhang zu den SDK aufzunehmen und damit die Vertragsparteien zu verpflichten, vor der Unterzeichnung des Vertrags diese Risikobewertung zu dokumentieren; dies wurde jedoch nicht umgesetzt. Die Risikobewertung ist auf Anfrage den Aufsichtsbehörden zur Verfügung zu stellen.

Praxishinweis: Die nach den SDK zu berücksichtigenden Faktoren wichen in ihrer Entwurfsfassung noch deutlicher von den Empfehlungen des EDSA zum Schrems II-Urteil ab, wonach subjektive Faktoren bei der Beurteilung der Angemessenheit der rechtlichen Regelung des Ziellandes nicht zu berücksichtigen sein sollen. In der Stellungnahme von EDSA und EDSB zum Entwurf der SDK wurde das Abstellen auf subjektive Faktoren kritisch hinterfragt, da vom EuGH im „Schrems II“ Urteil allein darauf abgestellt worden sei, das Daten in den Anwendungsbereich einer Drittlandgesetzgebung fallen, welche den Datenzugriff durch Behörden erlaubt. Dies würde per se darauf hinauslaufen, dass ein solcher Zugriff auch stattfinden kann. EDSA und EDSB empfahlen daher die subjektiven Faktoren durch die ergänzenden Maßnahmen der EDSA-Empfehlungen (siehe oben) zu ersetzen. Die EU-Kommission ist dieser Empfehlung insofern nachgekommen, dass die vormals im Vertragstext befindlichen „practical experience with prior instances, or the absence of requests for disclosure from public authorities received by personal data” dort gestrichen wurden und sich nun lediglich in einer Fußnote wiederfinden.

Im Zusammenhang mit dem TIA wird der Datenimporteur durch die SDK verpflichtet, sich nach besten Kräften um die Bereitstellung der für das TIA sachdienlichen Informationen zu bemühen. Zudem hat der Datenimporteur den Datenexporteur zu benachrichtigen, wenn er Grund zur Annahme hat, dass die für ihn geltenden rechtlichen Rahmenbedingungen der Einhaltung der SDK entgegenstehen, z.B. aufgrund einer Gesetzesänderung. Der Datenexporteur ist sodann verpflichtet, unverzüglich geeignete Maßnahmen durch ihn oder den Datenimporteur vorzunehmen bzw. vorzunehmen lassen, ggf. in Absprache mit der zuständigen Aufsichtsbehörde. Der Datenexporteur hat die Datenübermittlung auszusetzen, wenn er der Auffassung ist, dass keine geeigneten Garantien (mehr) für eine derartige Übermittlung gewährleistet sind. Das gilt ebenso, wenn der Datenexporteur von der dafür zuständigen Aufsichtsbehörde dazu angewiesen wird oder – falls es sich beim Datenexporteur um einen Auftragsverarbeiter im Modul 3 handelt – eine entsprechende Weisung vom Verantwortlichen erteilt wird.

Umgang mit Zugriffsbefugnissen staatlicher Stellen im Drittland

Klausel 15 in Abschnitt III regelt das Verfahren bei Anfragen auf Offenlegung personenbezogenen Daten durch staatliche Stellen im Drittland (etwa Regierungsbehörden). Der Datenimporteur ist verpflichtet, den Datenexporteur und – sofern möglich – die betroffenen Personen zu benachrichtigen,

  • wenn er von einer staatlichen Stelle im Drittland ein rechtlich bindendes Ersuchen auf Offenlegung personenbezogener Daten erhält, oder
  • wenn er Kenntnis von einem direkten Zugriff einer staatlichen Stelle auf personenbezogenen Daten erhält, die unter den SDK übermittelt wurden.

Ist eine Benachrichtigung nach den Rechtsvorschriften im Drittland untersagt, hat sich der Datenimporteur um eine Aufhebung des Verbots zu bemühen, um schnellstmöglich Informationen an den Datenexporteur übermitteln zu können.

Der Datenimporteur ist darüber hinaus verpflichtet, die Rechtmäßigkeit des Offenlegungsersuchens zu überprüfen. Bei hinreichenden Erfolgsaussichten hat der Datenimporteur Rechtsmittel gegen das Offenlegungsersuchen einzulegen und ggf. zusätzlich Maßnahmen im vorläufigen Rechtsschutz zu ergreifen.

Diese Verpflichtungen sind vom Datenimporteur zu dokumentieren und dem Datenexporteur auf dessen Verlangen hin nachzuweisen.

Hinweis: Abhängig von Art und Umfang der Verarbeitung sowie den im Drittland geltenden Gesetzen kann die Umsetzung dieser Pflichten in der Praxis für den Datenimporteur erheblichen Aufwand bedeuten. Offen bleibt, wer für die dem Datenimporteur bei Einhaltung dieser Pflichten entstehenden Kosten aufkommt. Es ist absehbar, dass der Datenimporteur versuchen wird, diese Kosten dem Datenexporteur aufzuerlegen.

Abhilfe für betroffenen Personen

Nach Klausel 3 kann eine betroffene Person als Drittbegünstigter bestimmte Klauseln gegenüber den Vertragsparteien der SDK durchsetzen, ähnlich wie dies bereits in den SCC-alt vorgesehen ist. Zudem kann eine betroffene Person gemäß Klausel 12 b) Schadenersatz gegen mindestens eine der Vertragsparteien geltend machen (der konkrete Mechanismus variiert abhängig von der Transferkonstellation, dazu unten Teil 3 dieser Mandanteninformation).

Macht die betroffene Person als Drittbegünstigte ein Recht geltend, hat der Datenimporteur die Entscheidung der betroffenen Person anzuerkennen, wenn diese eine Beschwerde bei der zuständigen Aufsichtsbehörde einreicht, oder den Streitfall an die zuständigen Gerichte im Sinne von Klausel 18 zu verweisen. Diese Rechte der betroffenen Person gelten unbeschadet der Rechte der betroffenen Person und/oder einer möglichen Haftung der Vertragsparteien nach der DSGVO.

Haftung und Aufsicht

Die getroffenen Haftungsregelungen in Klausel 12 differenzieren nach der jeweiligen Transferkonstellation (und enthalten Regelungen über die Haftung zwischen den Vertragsparteien und gegenüber den betroffenen Personen.

Jede Vertragspartei haftet gegenüber der anderen Vertragspartei für Schäden aus dem Verstoß gegen die SDK. Weiterhin haftet Jede Vertragspartei gegenüber den betroffenen Personen, u.a. auf Schadenersatz für alle materiellen oder immateriellen Schäden, welche die jeweilige Vertragspartei der betroffenen Person durch eine Verletzung der Rechte der betroffenen Person als Drittbegünstigtem nach den SDK zufügt.

Ist mehr als eine Vertragspartei für einen Schaden verantwortlich, welcher der betroffenen Person durch einen Verstoß gegen die SDK entstanden ist, so ist allen Konstellationen eine gesamtschuldnerische Haftung der Vertragsparteien gemein. Die betroffene Person kann sich aussuchen, gegen welche Vertragspartei er vorgeht. Der Ausgleich der Vertragsparteien im Innenverhältnis nach dem Verschuldensanteil entspricht dabei der Regelung zum Schadensersatz in Art. 82 DSGVO.

In aufsichtsbehördlichen Verfahren, welche die Einhaltung der SDK gewährleisten sollen, der Verwaltungshoheit der zuständigen Aufsichtsbehörde unterwerfen, Klausel 13, in der Regel also derjenigen des Datenexporteurs. Unklar ist, welche Aufsichtsbehörde zuständig sein soll, wenn mehrere Datenexporteure unter einem einheitlichen SDK Daten in ein Drittland übermitteln und es hierfür keine einheitliche, federführende Aufsichtsbehörde gibt. Auf diesen Sachverhalt hatten EDSA und EDSB hingewiesen, ohne dass die EU-Kommission diesen Hinweis jedoch aufgegriffen hat.

Schließlich muss Datenimporteur Anfragen beantworten, sich Audits unterziehen und die von der Aufsichtsbehörde getroffenen Maßnahmen befolgen, einschließlich Abhilfe- und Entschädigungsmaßnahmen. Da der Datenimporteur allerdings im Drittland sitzt, dürfte das – ebenso wie die Pflicht zur Benennung eines Vertreters gemäß Art. 27 DSGVO – ein zahnloser Tiger sein, solange es keine Amtshilfe- oder Rechtshilfeabkommen gibt, unter dem die Aufsichtsbehörde im Mitgliedstaat diese Rechte dann auch im Drittland gegenüber dem Datenimporteur durchsetzen kann. Hier wird es dabeibleiben, dass Verstöße des Datenimporteurs gegen die SDK vornehmlich durch ein Einwirken auf den Datenexporteur innerhalb der EU behoben werden.

Aussetzen der Datenübermittlung und Kündigungsrecht des Datenexporteurs

Der Datenexporteur hat die Datenübermittlung auszusetzen, wenn der Datenimporteur gegen die SDK verstößt. Besonders bedeutsam ist, dass der Datenexporteur in bestimmten Fällen den Hauptvertrag (nicht die SDK – „terminate the contract“) mit dem Datenimporteur kündigen kann. Dieses gegenüber dem Entwurf der SDK eingeschränkte Kündigungsrecht des Datenexporteurs ist in folgenden Fällen vorgesehen:

  • Klausel 14 f): Der Datenimporteur kann seinen Verpflichtungen aus den SDK nicht (mehr) nachkommen und die vom Datenexporteur ermittelten Maßnahmen schaffen keine geeigneten Garantien für die Übermittlung. Sind an dem Vertrag mehr als zwei Vertragsparteien beteiligt, kann der Datenexporteur das Kündigungsrecht nur in Bezug auf die verantwortliche Vertragspartei ausüben, es sei denn, die Vertragsparteien haben etwas anderes vereinbart. Wird der Vertrag gekündigt, finden Klausel 16 Buchst. d) und e) Anwendung.
  • Klausel 16 c): (i) Nach Aussetzung der Datenübermittlung kann die Einhaltung der SDK nicht innerhalb einer angemessenen Frist wiederhergestellt werden, längstens innerhalb eines Monats, (ii) der Datenimporteur verstößt in erheblichem Umfang oder fortlaufend gegen die SDK, oder (iii) der Datenimporteur kommt einer verbindlichen Entscheidung eines zuständigen Gerichts oder einer zuständigen Aufsichtsbehörde nicht nach.
  • Klausel 9 e): Vereinbarung einer Drittbegünstigtenklausel zwischen Datenimporteur und Unterauftragsverarbeiter, wonach der Datenexporteur bei Zahlungsunfähigkeit des Datenimporteur den Untervergabevertrag kündigen kann.

__________________________________

3. Besondere Regelungen für die verschiedenen Transferkonstellationen

Modul 1 – C2C: „Transfer Controller to Controller”

„Module One“ regelt die Transferkonstellation „Controller to Controller“ (C2C). Hier übermittelt ein Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO („Datenexporteur“) die personenbezogenen Daten an einen anderen Verantwortlichen in einem Drittland („Datenimporteur“), wobei die Verantwortlichen entweder allein oder gemeinsam über Zwecke und Mittel der Verarbeitung entscheiden.

Beispiel: Eine Tochtergesellschaft als Datenexporteur übermittelt der Konzernmutter in einem Drittland als Datenimporteur personenbezogene Daten. Die Konzernmutter verarbeitet diese Daten im Controlling.

Die besonderen Regelungen betreffen vornehmlich den Datenimporteur im Drittland. Dieser unterliegt zusätzlichen Verpflichtungen zur Transparenz (Klausel 8.2) und Speicherbegrenzung (Klausel 8.4). Der Datenimporteur hat für alle Verarbeitungszwecke eine datenschutzkonforme Verarbeitung zu gewährleisten. Er unterliegt erweiterten Sicherheitsverpflichtungen (Klausel 8.5), einschließlich der Anwendung spezifischer Schutzmaßnahmen für die Verarbeitung besonderer Kategorien personenbezogener Daten im Sinne von Art. 9 Abs. 1 DSGVO (Klausel 8.6). Der Datenimporteur ist verpflichtet, den Anträgen betroffener Personen gemäß Art. 15 ff. DSGVO nachzukommen (Klausel 10 a)). Hierbei hat der Datenexporteur den Datenimporteur ggf. zu unterstützen.

Ferner unterliegt der Datenimporteur bei Datenschutzverletzungen einer Meldepflicht gegenüber dem Datenexporteur und der zuständigen Aufsichtsbehörde (Klausel 8.5 e)). Darüber hinaus ist der Datenimporteur ausdrücklich dazu verpflichtet, die Einhaltung der SDK zu dokumentieren und die Dokumentation der zuständigen Aufsichtsbehörde auf deren Verlangen zur Verfügung zu stellen.

Modul 2 – C2P: „Transfer Controller to Processor “

„Module Two“ regelt die Transferkonstellation „Controller to Processor“ (C2P). Hier übermittelt ein Verantwortlicher („Datenexporteur“) personenbezogene Daten an einen Auftragsverarbeiter gemäß Art. 4 Nr. 8, Art. 28 Abs. 1 DSGVO in einem Drittland („Datenimporteur“).

Beispiel: Der Datenexporteur nutzt einen Cloudservice („Software as a Service“, SaaS) in einem Drittland, um personenbezogene Daten zu verarbeiten, z.B. ein CRM, DMS oder ERP-System.

Neu ist gegenüber den SCC-alt, dass die besonderen Regelungen nun die zwingenden Festlegungen in einem Auftragsverarbeitungsvertrag gemäß Art. 28 Abs. 3 DSGVO umfassen, die vollständig in die SDK integriert sind. Ein separater Auftragsverarbeitungsvertrag ist bei Abschluss der SDK nicht nötig.

Alle Vertragsparteien sind verpflichtet, die Einhaltung der SDK nachzuweisen, wobei dem Datenimporteur die besondere Verpflichtung auferlegt wird, geeignete Aufzeichnungen über die im Auftrag durchgeführten Verarbeitungstätigkeiten zu führen (Klausel 8.9 b)), dem Datenexporteur alle Informationen hinsichtlich der Einhaltung der SDK zur Verfügung zu stellen (Klausel 8.9 c)) sowie die genannten Informationen der zuständigen Aufsichtsbehörde auf deren Anfrage zur Verfügung zu stellen (Klausel 8.9 e)). Diese Pflichten gehen über die Dokumentationspflichten im Modul 1 hinaus.

Ferner wurden die Prüfrechte und Auditpflichten erweitert. So hat der Datenimporteur auf Verlangen des Datenexporteurs diesem zu ermöglichen, die unter die SDK fallenden Verarbeitungstätigkeiten in angemessenen Abständen oder bei Anzeichen für eine Nichteinhaltung zu prüfen (Klausel 8.9 c)). Der Datenexporteur kann die Prüfung selbst durchzuführen oder einen unabhängigen Prüfer beauftragen. Ausdrücklich erwähnt wird, dass die Inspektionen in den Räumlichkeiten des Datenimporteurs ggf. mit angemessener Vorankündigung durchgeführt werden können.

Hinweis: Im Entwurf der SDK war wegen der Beauftragung eines unabhängigen Prüfers eine Kostenregelung zu Lasten des Datenexporteurs vorgesehen. Auch konnte sich der Datenexporteur auf die Ergebnisse einer vom Datenimporteur veranlassten Prüfung stützen, bei der wiederum der Datenimporteur die Kosten zu tragen hatte. Derartige Kostentragungsregelungen finden sich in der finalen Fassung der SDK nicht mehr. Diese können frei verhandelt werden.

Die Regelungen zur Einbindung weiterer Auftragsverarbeiter in der Leistungskette setzen die Vorgaben aus Art. 28 Abs. 2 und Abs. 4 DSGVO um. Ergänzt wurden die Alternativen der vorherigen gesonderten Genehmigung oder der allgemeinen schriftlichen Genehmigung für Unterauftragsverarbeiter (Klausel 9 a)) sowie ein Mechanismus, der dem Datenexporteur unmittelbar gegenüber dem Unterauftragsverarbeiter die Möglichkeit gibt, den Untervergabevertrag zu kündigen und den Unterauftragsverarbeiter anzuweisen, die personenbezogenen Daten zu löschen oder herauszugeben (Klausel 9 e)).

Modul 3 – P2P: „Transfer Processor to Processor “

„Module Three“ regelt die Transferkonstellation „Processor to Processor“ („P2P“). Hier übermittelt ein Auftragsverarbeiter in der EU („Datenexporteur“) die personenbezogenen Daten an einen Unterauftragsverarbeiter in einem Drittland („Datenimporteur“). Beide Vertragsparteien sind dem Verantwortlichen gegenüber weisungsgebunden. Die Ergänzung dieser Transferkonstellation ist ein erheblicher Fortschritt in den SDK, da in den SCC-alt derartige Regelungen fehlten und es deshalb in solchen Konstellationen immer eines Vertragsschlusses zwischen dem Verantwortlichen und dem Unterauftragsverarbeiter bedurfte, obwohl der Hauptvertrag nur zwischen Verantwortlichem und Auftragsverarbeiter besteht.

Beispiel: Der Verantwortliche beauftragt einen Auftragsverarbeiter (beide in einem Mitgliedstaat niedergelassen) mit der Erbringung des First-Level-Supports für seine Mitarbeiter bei technischen Problemen. Da der First-Level-Support weltweit und 24/7 angeboten werden soll, beauftragt der Auftragsverarbeiter (Datenexporteur) einen weiteren Auftragsverarbeiter (Unterauftragsverarbeiter, Datenimporteur) in einem Drittland, um den First-Level-Support wie beauftragt anbieten zu können.

Die besonderen Regelungen umfassen ebenfalls die zwingenden Festlegungen in einem Auftragsverarbeitungsvertrag gemäß Art. 28 Abs. 3 DSGVO. Daher ist auch für diese Konstellation der Abschluss eines (Unter-)Auftragsverarbeitungsvertrag nicht erforderlich.

Die Klauseln für „Module Three“ spiegeln die Klauseln des „Module Two“ wider, berücksichtigen aber, dass an der Verarbeitung neben Auftragsverarbeiter und Unterauftragsverarbeiter auch ein Verantwortlicher beteiligt ist, der nicht zwingend Vertragspartei der SDK ist. Der Datenexporteur fungiert in dieser Konstellation als „Weiterleitungsstelle“, indem er die Weisungen des Verantwortlichen dem Datenimporteur fortlaufend zur Verfügung stellen muss (Klausel 8.1 a) und b)). So wird sichergestellt, dass der Verantwortliche seine Rechte und Pflichten gegenüber dem Auftragsverarbeiter und wegen der DSGVO-konformen Drittlandübermittlung behält, obwohl bestimmte Rechte und Pflichten auf den die Datenübermittlung tatsächlich durchführenden Auftragsverarbeiter ausgedehnt werden.

Jede weitere Übermittlung personenbezogener Daten an Dritte bedarf einer dokumentierten Weisung des Verantwortlichen (Klausel 8.8). Diese Weisungen werden dem Datenimporteur vom Datenexporteur mitgeteilt. Informations- und Prüfungsrechte erstrecken sich auf den Verantwortlichen und den Datenexporteur (Klausel 8.9 d)-f)). Der Datenimporteur darf Anfragen betroffener Personen nicht beantworten und ist verpflichtet, den Verantwortlichen, ggf. mit Unterstützung des Datenexporteurs, bei der Erfüllung seiner diesbezüglichen Pflichten zu unterstützen (Klausel 10 b)).

Zum Nachweis der Einhaltung der SDK hat insbesondere der Datenimporteur angemessene Aufzeichnungen über die Verarbeitungstätigkeiten zu führen, welche er im Auftrag des Verantwortlichen durchführt (Klausel 8.9 b)). Insbesondere stellt der Datenimporteur dem Datenexporteur alle Informationen zur Verfügung, welche die Einhaltung der SDK nachweisen (Klausel 8.9 c)). Diese Informationen sind zu dokumentieren und der zuständigen Aufsichtsbehörde auf deren Verlangen zur Verfügung zu stellen (Klausel 8.9 g)).

Modul 4 – P2C: „Transfer Processor to Controller“

„Module Four“ regelt die Transferkonstellation „Processor to Controller“ („P2C“), die bislang ebenfalls nicht berücksichtigt war. Hier übermittelt ein Auftragsverarbeiter in einem Mitgliedstaat („Datenexporteur“) personenbezogene Daten an einen Verantwortlichen in einem Drittland („Datenimporteur“), der diese Daten dort für eigene Zwecke (weiter) verarbeitet.

Beispiel: Ein Unternehmen in einem Drittland (Leistungserbringer) erbringt unter einem Second-Level-Support-Vertrag für eine Software zum Personalmanagement Leistungen für ein anderes Unternehmen in einem anderen Drittland (Leistungsempfänger). Hierfür bedient sich der Leistungserbringer eines Auftragsverarbeiters in einem Mitgliedstaat. Dieser Auftragsverarbeiter (Datenexporteur) verarbeitet in der EU personenbezogene Daten für den Leistungsempfänger (Datenimporteur).

Diese besonderen Regelungen verpflichten insbesondere den Datenimporteur im Drittland, alle Maßnahmen zu unterlassen, welche den Auftragsverarbeiter als Datenexporteur an der Erfüllung seiner ihm obliegenden Pflichten aus der DSGVO hindern. Dennoch fungiert der Datenimporteur als Verantwortlicher und der Datenexporteur verarbeitet die personenbezogenen Daten nur auf dessen dokumentierte Weisung (Klausel 8.1 a)).

Datenexporteur und Datenimporteur sind verpflichtet, geeignete Schutzmaßnahmen zu ergreifen (Klausel 8.2) und sich gegenseitig bei der Bearbeitung von Anfragen betroffener Personen zu unterstützen (Klausel 10). Auch in dieser Transferkonstellation müssen beide Vertragsparteien die Einhaltung der SDK nachweisen können (Klausel 8.3 a)) und der Datenexporteur muss dem Datenimporteur die für den Nachweis erforderlichen Informationen zur Verfügung stellen (Klausel 8.3 b)). Eine Verpflichtung diese Informationen einer anfragenden Aufsichtsbehörde zur Verfügung zu stellen, gibt es nicht.

Die Regelungen in Abschnitt III (Klausel 14 und 15) wegen Anfragen auf Offenlegung von bzw. Anträgen auf Zugang zu personenbezogenen Daten durch staatliche Stellen gelten für diese Transferkonstellation nur insoweit, als der Auftragsverarbeiter personenbezogene Daten des Verantwortlichen im Drittland mit weiteren vom Auftragsverarbeiter in der EU erhobenen Daten kombiniert. In der Begründung zum Beschluss heißt es, dass „keine derartigen Anforderungen gerechtfertigt sind, wenn die Auslagerung lediglich die Verarbeitung und Rückübermittlung personenbezogener Daten beinhaltet, die vom für die Verarbeitung Verantwortlichen erhalten wurden und die in jedem Fall der Gerichtsbarkeit des betreffenden Drittlandes unterlagen und unterliegen werden„. Damit soll sichergestellt werden, dass der Verantwortliche im Drittland keinen Pflichten unterworfen wird, nur weil „seine“ Daten einen „Umweg“ über die EU genommen haben, ohne hierbei verändert worden zu sein.

Hinweis: Die Regelungen zu Modul 4 sind im Verhältnis zu den anderen Modulen deutlich reduziert. In ihrer Stellungnahme zur Entwurfsfassung sahen EDSA und EDSB nicht alle Anforderungen von Art. 28 DSGVO berücksichtigt und forderten Ergänzungen. So sollte der Auftragsverarbeiter, die zur Verarbeitung der personenbezogenen Daten befugten Personen zur Vertraulichkeit verpflichten bzw. diese sollten einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen. Dies wurde von der EU-Kommission berücksichtigt und eine entsprechende Klausel 8.2 c) aufgenommen. Auch wurde die zuvor fehlende Verpflichtung des Auftragsverarbeiter gemäß Art. 33 Abs. 2 DSGVO zur Meldung von Verletzungen des Schutzes personenbezogener Daten in der neu aufgenommen Klausel 8.2 b) ergänzt. Die von EDSA und EDSB zudem geforderte ergänzende Klausel bzgl. einer Unterauftragsverarbeitung durch den Auftragsverarbeiter/Datenexporteur wurde hingegen nicht ergänzt.

 4. Fazit und Ausblick: Gefahr bei Drittlandübermittlungen gebannt?

Die SDK hinterlassen gemischte Gefühle:

  • Positiv: Die EU-Kommission reagiert mit den SDK auf den überfälligen Überarbeitungsbedarf und die Vorgaben aus dem „Schrems II“ Urteil. Die hiernach diskutierten, zusätzlichen organisatorischen und vertraglichen Maßnahmen bei Drittlandübermittlungen sind in den neuen Klauseln enthalten.
  • Positiv: Die Einbeziehung der Vorgaben aus Art. 28 Abs. 3 DSGVO für Auftragsverarbeitungsverträge sorgt dafür, dass ein Auftragsverarbeitungsvertrag bei Abschluss der SDK entbehrlich ist. Auch die Möglichkeit zum Beitritt weiterer Auftragsverarbeiter vereinfacht das Vertragsmanagement für Datenexporteure deutlich und sorgt für ein einheitliches Vertragswerk in der gesamten Leistungskette.
  • Schwierig: Die erweiterten Auditrechte und Prüfrechte des Datenexporteurs werden die Akzeptanz der SDK und deren Durchsetzbarkeit in Drittländern nicht erleichtern. Schon heute zeigt sich, dass Datenimporteure jeden Versuch unternehmen, die nach Art. 28 Abs. 3 S. 2 Buchst. h DSGVO bestehenden, zwingenden Überprüfungsrechte des Verantwortlichen auszuhebeln oder deutlich zu beschränken.
  • Schwierig: Die Verpflichtung der Datenimporteure, aktiv gegen staatliche Zugangs- oder Offenlegungsversuche wegen der personenbezogenen Daten vorzugehen, dies ggf. auch gerichtlich, könnte viele Verantwortliche und Auftragsverarbeiter in Drittländern in Konflikte mit den dortigen nationalen Gesetzen bringen und ebenfalls die Akzeptanz und Durchsetzbarkeit der SDK behindern. Als zusätzliche Garantien nach dem „Schrems II“ Urteil sind derartige Verpflichtungen aber unverzichtbar.
  • Schwierig: Es ist lobenswert, dass die Kommission Datenimporteure im Drittland zur Unterwerfung unter Maßnahmen der Aufsichtsbehörden in den Mitgliedstaaten verpflichten will, einschließlich Abhilfe- und Entschädigungsmaßnahmen. Ohne entsprechende Amtshilfe- oder Rechtshilfevereinbarungen mit den Drittländern scheitert das jedoch an der mangelnden Durchsetzbarkeit.
  • Kritisch: Obgleich die SDK spezifische Regelungen enthalten, um den Anforderungen an Drittlandübermittlungen nach dem „Schrems II“ Urteil gerecht zu werden (siehe oben), bleiben die SDK nur eine Vereinbarung zwischen Datenexporteur und Datenimporteur(en). Sie entfalten lediglich Wirkung zwischen den beigetretenen Vertragsparteien. Sie können daher weder die Rechtslage noch die Befugnisse staatlicher Stellen in Drittländern ändern.

Regierungsbehörden werden durch die SDK nicht daran gehindert, weiterhin zur Offenlegung von personenbezogenen Daten aufzufordern oder, bei entsprechender Rechtslage, direkt auf diese zuzugreifen. Dies kann allein durch zusätzliche technische Maßnahmen unterbunden werden, die jedoch in vielen Fällen nicht zur Verfügung stehen, worauf der EDSA in seinen Empfehlungen 1/2020 zu Recht hingewiesen hat (siehe oben). Damit könnten derartige Drittlandübermittlungen weiterhin (abhängig von der Übergriffigkeit der staatlichen Befugnisse im Drittland) datenschutzrechtswidrig sein.

Die Frage, ob der Abschluss der SDK plus Durchführung des TIA bereits ausreicht, um wieder eine wirksame Garantie i.S.d. Art. 46 Abs. 2 Buchst. c DSGVO zu haben, oder ob weiterhin neben der Bewertung des Datenschutzniveaus im Drittland – wie vom EDSA in Folge des EuGH-Urteils gefordert – auch technische Maßnahmen erforderlich sind, bleibt ungeklärt. Das Risiko hieraus trägt insbesondere der Datenexporteur in der EU.

  • Kritisch: Insbesondere KMU als Datenexporteuren ist es kaum möglich, die für das TIA erforderliche Prüfung des Schutzniveaus in einem oder mehreren Drittländern wirtschaftlich und rechtlich zu bewältigen. Die Alternative wäre dann der Verzicht auf die Nutzung aktueller IT-Services insbesondere aus der Cloud – und damit ein massiver Wettbewerbsnachteil gegenüber Konzernen oder Mitbewerbern außerhalb der EU.

Auch in ihrer finalen Fassung sind die SDK nicht das Allheilmittel, um Drittlandübermittlungen in jedem Fall rechtskonform vorzunehmen. Da die SDK als Mittel zur Übermittlung personenbezogener Daten in Drittländer auch ohne angemessenes Datenschutzniveau, insbesondere die USA, Russland, China oder Indien, aber von der EU-Kommission und der DSGVO grundsätzlich anerkannt werden, dürften sich Drittlandübermittlung künftig zumindest rechtssicherer gestalten lassen. Die Prüfung des Schutzniveaus im Drittland im TIA sowie die Festlegung zusätzlicher technischer Maßnahmen, wo erforderlich, bleiben Datenexporteur und Datenimporteur jedoch auch durch die neuen SDK nicht erspart.

5. Praktische Arbeitshilfe und Handlungsleitfaden

Die neuen SDK bringen für Verantwortliche und Auftragsverarbeiter, die auf Drittlandtransfers angewiesen sind, arbeitsreiche Zeiten mit sich. Wir empfehlen dabei folgendes Vorgehen. Sollten Sie einzelne Schritte schon erledigt haben, beginnen Sie einfach später im vorgeschlagenen Vorgehen.

Fristen notieren

Vermerken Sie die jetzt laufenden Fristen:

Mit den SDK werden die SCC-alt mit Wirkung zum 27.09.2021 aufgehoben. Das bedeutet, dass ab diesem Zeitpunkt die SCC-alt für die Übermittlung personenbezogener Daten nicht mehr aktiv genutzt werden dürfen. Bis wann dann die SDK umgesetzt sein müssen, hängt davon ab, ob es sich um Neuübermittlungen oder Bestandsübermittlungen personenbezogener Daten in ein Drittland handelt:

  • Bei ab dem 27.9.2021 neu begonnenen oder wesentlich geänderten Datenübermittlungen in Drittland sind die SDK zu nutzen bzw. die SCC-alt durch die SDK zu ersetzen. Anderenfalls ist Datenübermittlung rechtswidrig.
  • Bei Bestandsübermittlungen ohne wesentliche Änderungen gilt eine Übergangsfrist von 15 Monaten nach Aufhebung der SCC alt bis zum 27.12.2022, also von insgesamt 18 Monaten ab dem 27.6.2021. Innerhalb dieser Frist dürfen die zuvor abgeschlossenen SCC-alt weiterhin „passiv“ zur Rechtfertigung der Drittlandübermittlungen genutzt werden. Das gilt allerdings nur, soweit die Nutzung der SCC-alt gewährleistet, dass die Übermittlung personenbezogener Daten geeigneten Garantien im Sinne des Artikels 46 Abs. 1 DSGVO unterliegt, also den Vorgaben aus dem „Schrems II“-Urteil entsprochen wird. Ohne TIA und ggf. zusätzlichen technischen, vertraglichen und organisatorischen Maßnahmen ist das nicht der Fall (siehe oben), sodass dann auch Bestandsübermittlungen bis zum 27.9.2021 auf die SDK umzustellen sind.
  • Spätestens ab dem 27.12.2022, also 18 Monate nach Wirksamwerden der SDK und dem zu Grunde liegenden Beschluss der EU-Kommission, dürfen ausschließlich die SDK für Drittlandübermittlungen genutzt werden.

Checkliste umsetzen

1. Schritt: Bestandsaufnahme aller Drittlandübermittlungen – „Know your transfers“

Im 1. Schritt muss eine Bestandsaufnahme aller Drittlandübermittlungen erfolgen. Dabei ist für jede Verarbeitungstätigkeit die gesamte Verarbeitungskette zu berücksichtigen, einschließlich der Auftragsverarbeiter und etwaiger Unterauftragsverarbeiter. Ebenso relevant sind potenzielle Zugriffe aus Drittländern durch verbundene Konzerngesellschaften (z.B. beim Remote-Zugriff für den Support), selbst wenn die personenbezogenen Daten innerhalb von EU/EWR verarbeitet werden. Im Idealfall wurde hier bereits in Reaktion auf das EuGH-Urteil eine entsprechende Liste erstellt.

Hinweis: Zu erfassen sind auch Cloud-Dienste, die zwar eine Datenverarbeitung auf Servern in EU/EWR zusichern, Remote-Zugriffe aus Drittländern wie den USA aber nicht ausschließen (z.B. Amazon Web Services/AWS, Microsoft Azure, Microsoft 365 oder Salesforce CRM).

2. Schritt: Rechtsgrundlage für Drittlandübermittlung erfassen

Im 2. Schritt ist zu ermitteln, auf welche Rechtsgrundlage die Drittlandübermittlung gestützt wird.

Liegt ein Angemessenheitsbeschluss der EU-Kommission für das Drittland vor (Liste hier abrufen) oder eine sich auf Einzelsachverhalte beziehende Ausnahme nach Art. 49 DSGVO, z.B. eine Einwilligung der betroffenen Person oder eine Übermittlung zur Erfüllung eines Vertrags mit der betroffenen Person, sind keine weiteren Schritte notwendig. SDK sind dann nicht abzuschließen.

Wird die Drittlandübermittlung auf die SCC-alt als eine der in Art. 46 Abs. 2 DSGVO genannten Garantien gestützt, sind die weiteren Schritte durchzuführen. Ergänzend sollten die für die jeweiligen Drittlandübermittlungen gefunden Rechtsgrundlagen in der nach Schritt 1 erstellten Liste angegeben werden. Auch dieser Schritt sollte bereits nach dem EuGH-Urteil erledigt worden sein. Ggf. ist es erforderlich, andere – bislang auf eine andere, „wackelige“ Rechtsgrundlage gestützte Drittlandübermittlungen – zukünftig mit den SDK abzusichern. Auch dann sind die weiteren Schritte durchzuführen.

3. Schritt (Zwischenschritt): Anfrage nach SDK und Schutzmaßnahmen

Als Zwischenschritt bietet es sich an, die relevanten (potentiellen) Vertragsparteien, mit denen die SDK abgeschlossen werden müssten, zu kontaktieren und anzufragen, ob SDK zur Verfügung gestellt werden können bzw. ob mit evtl. vorhandenen Unterauftragsverarbeitern SDK geschlossen wurden.

Weiterhin kann es im Vorfeld der Durchführung des TIA (4. Schritt) sinnvoll sein, etwaig ergriffene Schutzmaßnahmen zur Absicherung der Drittlandübermittlung (bspw. Serverstandorte, Verschlüsselungsverfahren) beim Dienstleister oder einem Unterauftragsverarbeiter abzufragen und sich deren Umsetzung bestätigen zu lassen.

4. Schritt: Durchführung TIA

Im 4. Schritt ist das in Klausel 14 der SDK beschriebene „Data Transfer Impact Assessment“ („TIA“) durchzuführen, denn die Vertragsparteien sichern mit den SDK zu, dass kein Grund zur Annahme besteht, dass Rechtsvorschriften und Gepflogenheiten im Drittland den Datenimporteur daran hindern, seine Pflichten aus den SDK zu erfüllen.

Die möglichen Risiken sind dabei im TIA im Einklang mit den Empfehlungen des EDSA vorrangig anhand objektiver Kriterien zu prüfen (siehe hierzu auch unsere frühere Mandanteninformation). Die Durchführung des TIA ist zu dokumentieren. Bei der Prüfung der Rechtslage im Drittland sind die konkreten Umstände der Datenübermittlung zu berücksichtigen, also etwa

  • die Zwecke der Verarbeitung,
  • Kategorien und Format der übermittelten personenbezogenen Daten,
  • Länge der Verarbeitungskette und Anzahl der beteiligten Akteure,
  • Übertragungskanäle und beabsichtigte Datenweiterleitungen,
  • die tatsächlichen Umstände der Übermittlung, beispielsweise ob die Daten im Drittland gespeichert werden oder es lediglich zu Zugriffen aus dem Drittland kommt, sowie
  • alle relevanten vertraglichen, technischen oder organisatorischen Garantien und angewandte Maßnahmen.

Die konkreten Umstände sind für jeden Einzelfall einer Drittlandübermittlung zu bewerten, weil unterschiedliche gesetzliche Regelungen existieren können. Hierbei ist zu beachten, dass zur Ermittlung der Auswirkungen der gesetzlichen Regelungen auch subjektive Elemente wie Erfahrungen mit bereits erfolgten Offenlegungsersuchen oder deren Häufigkeit im Rahmen einer Gesamtschau nach dem Beschluss der Kommission ergänzend ebenfalls berücksichtigt werden können. Allerdings muss, sofern anhand dieser praktischen Erfahrungen der Schluss gezogen wird, dass dem Datenimporteur die Einhaltung dieser Klauseln nicht unmöglich ist, dies durch weitere relevante objektive Elemente untermauert werden.

Die Prüfung kann zu zwei Ergebnissen führen:

  1. Die SDK schaffen als Garantie gemäß Art. 46 Abs. 2 Buchst. c DSGVO bezogen auf die konkreten Umstände der Verarbeitung und die Rechtslage im konkreten Drittland beim Datenimporteur ein angemessenes Datenschutzniveau. Damit besteht kein Grund zur Annahme, dass die Vorgaben der SDK vom Datenimporteur nicht eingehalten werden können. Ein entsprechender Vertragsentwurf der SDK kann erstellt werden.
  2. Die Rechtslage im Drittland verhindert bezogen auf die konkreten Umstände und den Datenimporteur ein angemessenes Datenschutzniveau, etwa weil der Datenimporteur die vertraglichen Pflichten aus den SDK wegen der für ihn geltenden Gesetze nicht einhalten kann.

Nach den bisherigen Empfehlungen des EDSA zu den SCC-alt wären dann zusätzliche technische Maßnahmen zur Absicherung der Drittlandübermittlung zu ermitteln und festzulegen, soweit möglich. Besteht hiernach weiterhin Grund zur Annahme, dass die Vorgaben der SDK vom Datenimporteur nicht eingehalten werden können, sollte eine Übermittlung und Verarbeitung personenbezogener Daten auf Grundlage der SDK nicht erfolgen (siehe Durchführungsbeschluss C(2021) 397 final, Ziffer 19, weitere Erläuterungen oben).

5. Schritt: Bestimmen der Transferkonstellation(en)

Nach Durchführung des TIA ist anhand des konkreten Lebenssachverhalts zu bestimmen, welche(s) Modul€ aus den SDK anzuwenden ist/sind bzw. ob das ggf. vom Dienstleister bereits gewählte Modul zutreffend ist (zur Bestimmung des Moduls siehe oben).

Anhand der verbindlichen Vorlage der EU-Kommission im Annex zum Beschluss über die SDK ist sodann eine passende Vertragsversion zu erstellen. Dabei ist insbesondere darauf zu achten, dass die Klauseln nicht geändert werden dürfen. Die Anhänge zu den SDK sind mit den erforderlichen Angaben zu befüllen. Sofern Angaben hinsichtlich der technischen und organisatorischen Maßnahmen (Anhang II) und den eingesetzten Unterauftragsverarbeitern (Anhang III) beim Datenexporteur (noch) nicht vorliegen, sind diese vom Datenimporteur zu befüllen.

Achtung: Auch wenn es so einfach wirkt – das Ableiten eines konkreten Vertragstextes aus dem Muster der SDK ist nicht trivial. Das gilt insbesondere für SDK mit mehr als zwei Vertragsparteien. Wir erarbeiten deshalb derzeit einen digitalen Vertragsgenerator, der hierbei unterstützen und die Abhängigkeiten zwischen den Klauseln für die verschiedenen Module abbilden wird.

6. Schritt: Vervollständigung und Unterzeichnung der SDK durch den Datenimporteur

Im 6. und letzten Schritt ist der Vertragsentwurf vom Datenimporteur zu prüfen, ggf. zu vervollständigen und unterzeichnet zurückzusenden. Ergänzend sind ggf. etwaige Beitritte weiterer Vertragsparteien zu realisieren.

Wer sind Ihre Ansprechpartner?

Wenn Sie von uns im Datenschutz bereits beraten werden, wenden Sie sich bitte an die/den Sie betreuende/n Rechtsanwältin/Rechtsanwalt – zu unserem Team hier entlang. Nehmen Sie anderenfalls jederzeit gerne Kontakt zu einer/einem der folgenden Ansprechpartner/innen auf:

Alle Ansprechpartner/innen erreichen Sie unter 0221/27141874 und persönlich bei Bedarf in der Brückenstraße 21, 50667 Köln (Innenstadt).

Wer sind KREMER RECHTSANWÄLTE?

KREMER RECHTSANWÄLTE ist eine auf Digitalisierungsberatung spezialisierte Sozietät und berät ihre Mandanten und Auftraggeber hochspezialisiert an der Schnittstelle zwischen Technik und Recht. Zu unseren Mandanten und Auftraggebern – national und international – gehören DAX-Konzerne, KMU, Kreditinstitute und Finanzdienstleister jeglicher Größe, kirchliche Einrichtungen und Startups.

Die Rechtsanwältinnen, Rechtsanwälte, Wirtschaftsjuristinnen und Wirtschaftsjuristen veröffentlichen regelmäßig Fachbeiträge, Muster und Bücher zum Datenschutz. Sie sind auch in der Aus- und Weiterbildung von Datenschutzbeauftragten, Personalverantwortlichen, Unternehmensleitungen, Juristinnen und Juristen sowie Referendar/inn/en und Studierenden tätig. KREMER RECHTSANWÄLTE ist von der WirtschaftsWoche 2019 als TOP Kanzlei im Datenschutzrecht ausgezeichnet worden. Außerdem wird die Sozietät im kanzleimonitor.de 2018/2019 und im kanzleimonitor.de 2020/2021 als von Unternehmensjuristinnen und -juristen gewählte, führende Kanzlei im IT- und Datenschutzrecht gelistet.

Von Sascha Kremer

Rechtsanwalt, Datenschutzbeauftragter, Unternehmer, Vater.