Begründen Personenbezogene Zugangsdaten (k)eine Auftragsverarbeitung?

Hm. Einen Unterschied vermag ich zu dem, was eingangs beschrieben wurde, nicht zu erkennen. Auch dort steht der Inhalt der nicht-personenbezogenen Analysen / Auswertungen im Vordergrund. Die Datenverarbeitung der Accounts scheint mir nicht im Vordergrund zu stehen.

Aber es wäre schön, wenn sich @Sandra nach so vielen Beiträgen, Fragen und Meinungen, selbst äußern würde.

Später ergänzender Nachtrag: ich hatte dazu bei unsrem LfDI in Baden-Württemberg nachgefragt und aus der Abteilung für technisch-organisatorischen Datenschutz die folgende Antwort erhalten:

“Beim Clouddienstleister kommt es im Einzelfall weiterhin darauf an, welche Daten für welche Zwecke verarbeitet werden. Wenn der Dienstleister lediglich Name, E-Mail-Adresse usw. verarbeitet, um damit die Dienstleistung bereitstellen bzw. sicherstellen oder verbessern zu können, spricht dies grundsätzlich für eine Auftragsverarbeitung. Wenn der Dienstleister die Daten (zunächst) für eigene Zwecke verarbeitet und die Mittel dazu bestimmt, insbesondere durch eine von Ihnen genannte Verarbeitung des Nutzungsverhaltens, liegt jedoch im Lichte der Rechtsprechung des EuGH eine gemeinsame Verantwortlichkeit nahe. Wenn tatsächlich solch eine Verarbeitung auf Seiten des Dienstleisters stattfindet, ist wegen der Grundsätze der Rechtmäßigkeit der Verarbeitung sowie der Datensparsamkeit jedoch zu raten, den Einsatz dieses Dienstleisters nochmals zu prüfen.”

Danach scheint es wahrscheinlich, dass die ursprünglich von @Sandra beschriebene Verarbeitung eine AV ist.

1 „Gefällt mir“

Da bisher keine Konkretisierung erfolgte, die eine genauere Bewertung ermöglicht, will ich mal einfach die Diskussion wieder aufnehmen.
Ich sehe hier als wesentliches Unterscheidungskriterium das Systemlevel, auf dem der Dienstleister eingebunden ist. Ein Platform-as-a-Service oder Intrastructure-as-a-Service Dienstleister stellt dem Unternehmen den Zugang insgesamt auf Infrastrukturebene (mittels Zertifikate, VPN o.ä.) bereit - die Zugangskennung des Einzelnen dient also dem Unternehmen und nicht vordergründig dem Dienstleister als Sicherheitsmerkmal.
Bei Software-as-a-Service ist das nicht so eindeutig. Der Dienstleister muss ja die Zugangskennung ggf. dahingehend auswerten, um den Nutzer dem richtigen Clienten (Unternehmen) zuordnen zu können und darufhin die korrekte Datenbank, Softwareinstanz, Lizenz etc. anzuwenden. Wie bitte soll dem einzelnen Clienten vorab eine AV zugesichert werden, wenn an der Zugangsstelle gar nicht vorab feststeht, ob ein Nutzer dieses Clienten oder eines anderen gerade Zugang wünscht? Wie gesagt, das gilt für die Situation, wo praktisch “jeder” eine Lizenz kaufen und einen Zugang erlangen kann und der Dienstleister erst anhand des erfolgreichen authentifizierten Zugangsversuches entscheiden kann, welche Datenverarbeitung zugänglich gemacht werden soll.
Da es Cloud nunmal in allen Ausprägungen IaaS, PaaS und SaaS gibt, sehe ich in der zitierten Äußerung noch kein hilfreiches Entscheidungskriterium.

Kommt drauf an… m.E. ist beides (AV, kein AV) anwendbar. Ich würde diesen spezifischen Fall in der einen wie der anderen Konstellation auf “berechtigtes Interesse” abstützen.

Für “kein AV” spricht: mit der gleichen Argumentation wäre jegliche Kommunikation im B2B Bereich Auftragsverarbeitung (“Senden Sie die Rechnung als E-Mail an stefanie.meyer@meinefirma.de”). Verarbeitung pbD ist hier “Nebengeräusch”.

Für AV spricht: der Auftragnehmer “erbt” nicht nur die Rechtsgrundlage des Verantwortlichen, sondern könnte sich auch von Informationspflichten und Betroffenenrechten entlasten.

Spätestens bei “Produktverbesserung” besteht ein eigenes wirtschaftliches Interesse. Wenn dann noch nutzerbezogene Auswertungen und Befragungen hinzu kommen, würde ich auch einen 26er oder 28er Vertrag schließen.