Die Auswirkung der Zugriffsmöglichkeit auf Datenschutz-Pflichten

Muss IT-Dienstleister Daten löschen, obwohl er weiterhin Zugriff auf diese hat?

Immer mehr Unternehmen fordern von deren IT-Dienstleistern Löschkonzepte. Doch macht es überhaupt Sinn, Daten zu löschen, auf die der IT-Dienstleister trotzdem noch Zugriff hat?

  • Personenbezogene Daten müssen nach Erreichen des Zwecks der Verarbeitung gelöscht oder anonymisiert werden.
  • Die Zugriffsmöglichkeit spielt für die Pflicht zur Löschung keine Rolle.
  • Die Möglichkeit des Zugriffs auf personenbezogene Daten geht auch dann mit Datenschutzpflichten einher, wenn von der Möglichkeit kein Gebrauch gemacht wird.

Ein befreundeter Software-Entwickler hat mir vor Kurzem eine interessante Frage gestellt: Macht es als IT-Dienstleister rechtlich überhaupt einen Unterschied, wenn man personenbezogene Daten löscht, nachdem man diese zweckmäßig verarbeitet hat, wenn man dennoch weiterhin die theoretische Möglichkeit hätte, auf diese Daten zuzugreifen (z.B. weil man noch einen Access Token für die entsprechende Datenbank des Auftraggebers hat).

Muss ein IT-Dienstleister personenbezogene Daten löschen, obwohl er theoretisch weiterhin Zugriff darauf hat?

Ja, unbedingt. Wenn der Zweck, dem die Verarbeitung (hier: Speicherung) personenbezogener Daten dient, erreicht ist, müssen diese Daten gelöscht (oder anonymisiert) werden. Dieses Prinzip der Datenminimierung gilt sowohl für die Anzahl der Kategorien personenbezogener Daten (nur so viele wie für den Zweck erforderlich) als auch den zeitlichen Umfang (nur so lange wie erforderlich) der Verarbeitung.

Dass danach noch eine Zugriffsmöglichkeit besteht, ändert an dieser Verpflichtung nichts. Ein erneuter Zugriff wäre eine weitere Verarbeitung, die dann wegen Wegfalls des Zwecks rechtswidrig wäre. Aus der Zugriffsmöglichkeit ergeben sich aber andere Folgeprobleme:

Worin besteht dann überhaupt das Problem der Zugriffsmöglichkeit?

Die unmittelbare Zugriffsmöglichkeit führt dazu, dass der Dienstleister als Empfänger der personenbezogenen Daten gilt (selbst wenn er diese nie abgerufen hat). An den Status eines Empfängers wiederum knüpfen eine Reihe von Folgeprobleme auf beiden Seiten (Auftraggeber und Dienstleister), u.a.:

  • Der Empfänger muss mit Namen und vollständiger Anschrift in den Datenschutzhinweisen (auch Datenschutzerklärung genannt) des Auftraggebers genannt werden
  • Auftraggeber und Dienstleister müssen in der Regel einen Auftragsverarbeitungsvertrag abschließen
  • Wenn der Dienstleister in einem Drittland (z.B. USA) sitzt, müssen die weitern Pflichten zur Drittlandübermittlung eingehalten werden
  • Auftraggeber und Dienstleister müssen durch technische und organisatorische Maßnahmen (kurz TOM) die Sicherheit der Verarbeitung im Hinblick auf die Zugriffsmöglichkeit gewährleisten (z.B. sollte der Access Token bzw. Schlüssel sicher verwahrt werden)

Beispiel: Deployment direkt von GitHub

Um das Ganze etwas griffiger zu machen ein Praxisbeispiel: Häufig werden Softwareprojekte auf GitHub verwaltet und mittels GitHub Actions für das Deployment vorbereitet. Es ist dann natürlich sehr praktisch, bei GitHub auch die entsprechenden Schlüssel für das Deployment zu überlegen, damit aus GitHub heraus auch direkt die neueste Version der Software auf die Production Server ausgeliefert werden kann.

Der Haken ist: GitHub hat nun die Schlüssel für die Produktionsumgebung. Theoretisch kann also GitHub nun mit diesem Schlüssel auf die Server zugreifen oder jedenfalls eigenen (Schad-)Code dort ausrollen. Natürlich hätte GitHub (in der Regel) keinen Grund das zu tun, aber es wäre möglich. Und plötzlich gilt GitHub als Empfänger aller personenbezoenen Daten, die auf den Servern gespeichert sind.