AVV bei Cloud-Anbietern: Was bei AWS, Azure, Google Cloud & Co. wirklich zu prüfen ist

Wer personenbezogene Daten in der Cloud verarbeitet, landet schnell bei Art. 28 DSGVO und der Frage nach einem Auftragsverarbeitungsvertrag (AVV).

Die kurze Antwort lautet: Verarbeitet ein Cloud-Anbieter personenbezogene Daten im Auftrag des Kunden, muss die Auftragsverarbeitung den Anforderungen des Art. 28 DSGVO entsprechen.

Aber genau hier beginnt die eigentliche Prüfung. Denn ein unterschriebener oder automatisch einbezogener AVV macht einen Cloud-Dienst noch nicht datenschutzkonform.

Entscheidend ist das Gesamtbild: Rollenverteilung, Vertrag, technische Konfiguration, Unterauftragsverarbeiter, technische und organisatorische Maßnahmen sowie mögliche Drittlandtransfers müssen zusammenpassen.

Ist ein Cloud-Anbieter Auftragsverarbeiter?

Bei klassischen Cloud-Infrastrukturleistungen ist der Anbieter regelmäßig Auftragsverarbeiter, soweit er personenbezogene Daten für seinen Kunden und nach dessen Weisungen verarbeitet.

Typische Beispiele sind:

• Hosting von Anwendungen,

• Speicherung personenbezogener Daten,

• Datenbanken,

• Backups,

• Rechen- und Plattformleistungen oder

• sonstige technische Verarbeitung von Kundendaten.

Der Kunde bestimmt dabei regelmäßig die Zwecke der eigentlichen Verarbeitung und konfiguriert beispielsweise, welche Daten verarbeitet, wie lange sie gespeichert und in welcher Region sie verarbeitet werden.

Wichtig: Die datenschutzrechtliche Rolle lässt sich nicht allein anhand des Etiketts „Cloud-Anbieter“ bestimmen.

Ein Anbieter kann für bestimmte Verarbeitungen Auftragsverarbeiter und für andere Verarbeitungen selbst Verantwortlicher sein. Entscheidend ist deshalb immer die konkrete Verarbeitung.

Gerade bei großen Cloud- und SaaS-Anbietern lohnt sich daher ein Blick darauf, ob und für welche Daten sich der Anbieter eigene Verarbeitungszwecke vorbehält.

Brauche ich mit AWS, Microsoft Azure oder Google Cloud einen AVV?

Wer AWS, Microsoft Azure oder Google Cloud zur Verarbeitung personenbezogener Daten als Auftragsverarbeiter einsetzt, benötigt eine den Anforderungen des Art. 28 DSGVO entsprechende vertragliche Regelung.

Die großen Anbieter stellen dafür eigene Data Processing Addenda bzw. Data Processing Terms bereit.

Bei AWS ist das GDPR Data Processing Addendum beispielsweise Bestandteil der AWS Service Terms und gilt nach Angaben von AWS automatisch für die entsprechenden Kunden.

Das erleichtert den formalen Abschluss erheblich.

Es beantwortet aber noch nicht die wichtigere Frage:

Ist der konkrete Einsatz des Cloud-Dienstes datenschutzrechtlich sauber aufgesetzt?

Warum ein AVV allein nicht reicht

In der Praxis wird viel Energie auf die Frage verwendet, ob ein AVV „vorhanden“ ist.

Das greift zu kurz.

Art. 28 DSGVO verlangt vom Verantwortlichen nicht nur einen Vertrag. Der Verantwortliche darf vielmehr nur Auftragsverarbeiter einsetzen, die hinreichende Garantien dafür bieten, dass geeignete technische und organisatorische Maßnahmen so durchgeführt werden, dass die Verarbeitung den Anforderungen der DSGVO entspricht.

Deshalb sollte die Prüfung nicht beim AVV enden.

Ein 40-seitiger AVV macht einen Cloud-Dienst nicht datenschutzkonform. Entscheidend ist, ob Vertrag, tatsächliche Datenflüsse, technische Konfiguration und Risikobewertung zusammenpassen.

Meine 7-Punkte-Prüfung für Cloud-Dienste

1. Rollenverteilung klären

Zunächst muss geklärt werden, wer für welche Verarbeitung Verantwortlicher oder Auftragsverarbeiter ist.

Bei einem klassischen Hosting-Service ist die Einordnung häufig relativ einfach. Bei komplexen SaaS-, Analyse- oder KI-Diensten kann sie erheblich schwieriger sein.

Insbesondere sollte geprüft werden, ob der Anbieter bestimmte Daten auch für eigene Zwecke verarbeitet.

2. AVV nach Art. 28 DSGVO prüfen

Anschließend ist zu prüfen, ob der Vertrag die Anforderungen des Art. 28 Abs. 3 DSGVO abbildet.

Dazu gehören insbesondere Regelungen über:

• Gegenstand und Dauer der Verarbeitung,

• Art und Zweck der Verarbeitung,

• Kategorien personenbezogener Daten,

• betroffene Personen,

• Weisungsbindung,

• Vertraulichkeit,

• technische und organisatorische Maßnahmen,

• Unterauftragsverarbeiter,

• Unterstützung bei Betroffenenrechten und Datenschutzvorfällen,

• Löschung bzw. Rückgabe der Daten und

• Kontroll- und Nachweismöglichkeiten.

Bei Hyperscalern und großen SaaS-Anbietern sind diese Bedingungen regelmäßig standardisiert und praktisch kaum verhandelbar.

Die entscheidende Frage lautet dann nicht, ob man jeden Vertragspunkt ändern kann, sondern ob das verbleibende Risiko für den konkreten Einsatz vertretbar ist.

3. Technische und organisatorische Maßnahmen bewerten

Cloud-Sicherheit funktioniert nach dem Prinzip geteilter Verantwortlichkeiten.

Der Anbieter sichert beispielsweise Rechenzentren und bestimmte Infrastrukturkomponenten. Der Kunde bleibt aber regelmäßig für wesentliche Teile seiner eigenen Konfiguration verantwortlich.

Dazu können insbesondere gehören:

• Identity & Access Management,

• Rollen- und Berechtigungskonzepte,

• Verschlüsselung,

• Schlüsselmanagement,

• Logging,

• Backup-Konfiguration,

• Mandantentrennung und

• Löschkonzepte.

Deshalb reicht es nicht, eine umfangreiche TOM-Anlage des Anbieters abzuheften.

Die interessantere Frage ist:

Sind die Maßnahmen für unsere konkrete Verarbeitung und unser konkretes Risiko angemessen?

4. Unterauftragsverarbeiter im Blick behalten

Große Cloud-Anbieter arbeiten regelmäßig mit weiteren Dienstleistern.

Art. 28 Abs. 2 und 4 DSGVO stellt deshalb Anforderungen an den Einsatz weiterer Auftragsverarbeiter.

In der Praxis arbeiten große Anbieter häufig mit einer allgemeinen Genehmigung und informieren ihre Kunden über Änderungen ihrer Subprozessoren.

Unternehmen sollten deshalb zumindest wissen,

• wo die aktuelle Subprozessoren-Liste zu finden ist,

• wie über Änderungen informiert wird,

• welche Widerspruchsmöglichkeiten bestehen und

• ob dadurch neue Drittlandtransfers entstehen können.

5. Tatsächliche Datenstandorte und Datenflüsse verstehen

„EU-Region ausgewählt“ bedeutet nicht automatisch:

Kein datenschutzrechtlich relevanter Drittlandbezug.

Neben der primären Speicherung können beispielsweise Support, Administration, Telemetrie, Sicherheitsleistungen oder Unterauftragsverarbeiter relevant sein.

Deshalb sollte nicht nur der vertraglich gewählte Speicherort betrachtet werden, sondern der tatsächliche Datenfluss.

Das bedeutet nicht, dass jedes theoretisch denkbare Zugriffsszenario einen Cloud-Dienst unzulässig macht. Datenschutz-Compliance sollte auch hier risikoorientiert bleiben.

6. Drittlandtransfers separat prüfen

Werden personenbezogene Daten in ein Drittland übermittelt, kommt zusätzlich Kapitel V der DSGVO ins Spiel.

Bei Übermittlungen in die USA ist heute zunächst zu prüfen, ob der jeweilige Empfänger unter das EU-US Data Privacy Framework (DPF) fällt.

Für zertifizierte US-Unternehmen besteht ein Angemessenheitsbeschluss der Europäischen Kommission. Eine Übermittlung kann dann grundsätzlich auf Art. 45 DSGVO gestützt werden.

Das ist ein wesentlicher Unterschied zur Situation unmittelbar nach dem Schrems-II-Urteil.

Greift kein Angemessenheitsbeschluss, können insbesondere die Standardvertragsklauseln nach Art. 46 DSGVO relevant werden. Dann ist gegebenenfalls auch zu prüfen, ob das Recht und die Praxis des Empfängerstaates die Wirksamkeit der vereinbarten Garantien beeinträchtigen und ob ergänzende Maßnahmen erforderlich sind.

Deshalb gilt:

US-Anbieter bedeutet nicht automatisch SCC plus TIA. Der konkrete Transfermechanismus muss geprüft werden.

7. Entscheidung dokumentieren

Am Ende sollte nachvollziehbar dokumentiert werden, warum ein Cloud-Anbieter eingesetzt werden kann.

Dabei geht es nicht darum, möglichst viele Seiten Datenschutzdokumentation zu produzieren.

Es geht darum, die wesentlichen Entscheidungen nachvollziehbar festzuhalten:

• Welche Verarbeitung findet statt?

• Welche Daten sind betroffen?

• Welche Rolle hat der Anbieter?

• Welcher AVV gilt?

• Welche wesentlichen TOM bestehen?

• Welche Subprozessoren sind relevant?

• Gibt es Drittlandtransfers?

• Auf welchen Transfermechanismus werden diese gestützt?

• Welche verbleibenden Risiken wurden akzeptiert?

Gute Datenschutz-Compliance bedeutet nicht maximale Dokumentation. Sie bedeutet, die richtigen Risiken zu erkennen, zu bewerten und die Entscheidung nachvollziehbar zu machen.

AWS und DSGVO: Reicht das AWS Data Processing Addendum?

AWS stellt ein GDPR Data Processing Addendum bereit. Nach Angaben von AWS ist dieses in die AWS Service Terms integriert und gilt automatisch für Kunden, für deren Nutzung die entsprechenden datenschutzrechtlichen Anforderungen gelten.

AWS weist selbst darauf hin, dass das Unternehmen je nach Verarbeitung sowohl als Auftragsverarbeiter als auch als Verantwortlicher handeln kann.

Deshalb sollte auch bei AWS nicht abstrakt gefragt werden:

„Ist AWS DSGVO-konform?“

Sinnvoller ist:

„Können wir unseren konkreten AWS-Workload DSGVO-konform betreiben?“

Dafür sind beispielsweise die eingesetzten Services, die gewählte Region, die Konfiguration, Berechtigungen, Verschlüsselung, Datenübermittlungen und der konkrete Schutzbedarf relevant.

Microsoft Azure und Google Cloud: Das Grundproblem ist dasselbe

Auch Microsoft und Google stellen umfangreiche Datenschutzbedingungen für ihre Cloud-Angebote bereit.

Die Grundsystematik unterscheidet sich aber nicht:

Ein vorhandenes DPA ist nur ein Baustein.

Unternehmen müssen für ihre konkrete Nutzung insbesondere Rollenverteilung, technische Maßnahmen, Datenflüsse, Unterauftragsverarbeiter und Drittlandtransfers bewerten.

Gerade bei großen Cloud-Plattformen sollte deshalb nicht versucht werden, „die Cloud“ als Ganzes datenschutzrechtlich freizugeben.

Geprüft werden sollte der konkrete Use Case.

Das ist präziser, praktikabler und führt meistens auch zu besseren Ergebnissen.

Fazit: Cloud-Datenschutz ist Risikomanagement

Die Frage „Haben wir einen AVV?“ lässt sich schnell beantworten.

Die wichtigere Frage lautet:

Haben wir den Cloud-Dienst so ausgewählt, konfiguriert und dokumentiert, dass die verbleibenden Datenschutzrisiken vertretbar sind?

Dafür braucht es keine Datenschutzbürokratie um ihrer selbst willen.

Es braucht einen strukturierten Prozess:

Rolle → AVV → TOM → Subprozessoren → Datenflüsse → Drittlandtransfer → Dokumentation.

Wer diese Punkte sauber prüft, ist bei AWS, Azure, Google Cloud und anderen Cloud-Diensten erheblich weiter als mit einem AVV, der lediglich irgendwo im Datenschutzordner liegt.

Häufige Fragen zu AVV und Cloud-Anbietern

Brauche ich für AWS einen AVV?

Soweit AWS personenbezogene Daten als Auftragsverarbeiter für Ihr Unternehmen verarbeitet, muss die Verarbeitung den Anforderungen des Art. 28 DSGVO entsprechen. AWS stellt dafür ein Data Processing Addendum bereit, das nach Angaben von AWS in seine Service Terms integriert ist. Zusätzlich sollten insbesondere der konkrete AWS-Service, die Konfiguration, Datenstandorte, TOM, Subprozessoren und mögliche Drittlandtransfers geprüft werden.

Muss ich für jeden AWS-Service einen eigenen AVV abschließen?

Grundsätzlich stellt AWS ein übergreifendes Data Processing Addendum für die Nutzung seiner Services bereit. Das bedeutet aber nicht, dass jeder AWS-Service datenschutzrechtlich identisch bewertet werden kann. Die konkrete Verarbeitung und Konfiguration müssen servicebezogen betrachtet werden.

Reicht eine EU-Cloud-Region aus?

Nein. Die Wahl einer EU-Region ist ein wichtiger Baustein, beantwortet aber nicht sämtliche datenschutzrechtlichen Fragen. Zusätzlich können beispielsweise Supportzugriffe, Subprozessoren oder andere Datenflüsse relevant sein.

Brauche ich bei einem US-Cloud-Anbieter immer Standardvertragsklauseln?

Nein. Zunächst ist zu prüfen, ob überhaupt eine Drittlandübermittlung vorliegt und welcher Transfermechanismus greift. Bei einem entsprechend zertifizierten US-Empfänger kann insbesondere der Angemessenheitsbeschluss zum EU-US Data Privacy Framework relevant sein. Greift kein Angemessenheitsbeschluss, können beispielsweise Standardvertragsklauseln erforderlich werden.

Brauche ich immer ein Transfer Impact Assessment?

Nicht allein deshalb, weil ein Anbieter seinen Sitz in den USA hat. Maßgeblich sind die tatsächliche Drittlandübermittlung und der dafür verwendete Transfermechanismus.

Was ist der Unterschied zwischen IaaS, PaaS und SaaS beim AVV?

Die Kategorien IaaS, PaaS und SaaS entscheiden nicht automatisch über die datenschutzrechtliche Rollenverteilung. Je stärker ein Anbieter aber selbst Funktionen und Verarbeitungsprozesse bestimmt, desto genauer sollte geprüft werden, welche Verarbeitung tatsächlich noch ausschließlich im Auftrag des Kunden erfolgt.

Muss ich Cloud-Anbieter regelmäßig kontrollieren?

Art. 28 DSGVO verlangt hinreichende Garantien des Auftragsverarbeiters und entsprechende Nachweismöglichkeiten. Bei großen Cloud-Anbietern bedeutet das nicht zwangsläufig ein eigenes Vor-Ort-Audit. Zertifizierungen, Auditberichte und andere Nachweise können wichtige Bestandteile eines risikoorientierten Kontrollkonzepts sein.