Datenschutz bei Cloud-Backups: Löschung, Wiederherstellung und Nachweis

Eine Löschung ist bei Cloud-Backups erst nachvollziehbar, wenn das Unternehmen Primärsystem, Sicherungskopien und Wiederherstellung gemeinsam betrachtet. Die DSGVO schreibt keinen einheitlichen Überschreibungszeitraum für jedes Backup vor. Sie verlangt eine risikogerechte, dokumentierte Lösung, die unnötige Speicherung und eine unkontrollierte Reaktivierung gelöschter Daten verhindert.

Dieser Beitrag zeigt, wie ein Löschkonzept für Sicherungskopien aufgebaut werden kann. Im Mittelpunkt stehen die Abgrenzung zwischen Produktivsystem und Backup, technische Sperren, der Restore-Fall und der Nachweis gegenüber einer internen Prüfung oder der Aufsichtsbehörde. Die erstmalige Festlegung materieller Aufbewahrungsfristen für Kunden-, Bewerbungs- oder Beschäftigtendaten ist ein eigener Prüfschritt.

Für die Datenschutzprüfung zählt der Inhalt der Kopie. Ein Backup, ein Snapshot, ein Archivexport und ein Replikat können personenbezogene Daten enthalten, auch wenn sie im Alltag nicht als Anwendungsspeicher sichtbar sind. Inventarisieren Sie deshalb die Systeme, Speicherorte, Kopierarten und Verantwortlichkeiten. Entscheidend ist, ob sich die Daten einer Person noch zuordnen lassen.

Die Kopie hat eine andere Funktion als das Produktivsystem. Sie soll typischerweise Verfügbarkeit und Wiederherstellbarkeit sichern. Diese Funktion ändert jedoch nichts daran, dass die Speicherung begrenzt und der Zugriff geschützt werden muss. Nach Art. 25 und Art. 32 DSGVO sind Architektur und Sicherheitsmaßnahmen an Zweck und Risiko der Verarbeitung auszurichten.

Die erste Frage lautet daher nicht, ob ein Backup existiert, sondern welche Daten es enthält und wofür die Kopie benötigt wird. Die Entscheidung über die materielle Aufbewahrung im Primärsystem bleibt davon getrennt. Erst danach kann das Unternehmen bestimmen, ob eine Kopie sofort technisch bereinigt, bis zum regulären Überschreiben isoliert oder in einer besonderen Ausnahme weiter geschützt wird.

Wird ein personenbezogenes Datum im Produktivsystem gelöscht, muss der Löschprozess die dazugehörigen Sicherungskopien mitdenken. Art. 17 DSGVO ist im konkreten Fall zu prüfen. Besteht ein Löschanspruch und greift keine Ausnahme, darf das Unternehmen die Sicherungskopie nicht als dauerhaften Ersatzspeicher für denselben Bestand behandeln.

Eine sofortige Bearbeitung jeder einzelnen Datei in jedem unveränderbaren Backup ist technisch nicht in jeder Architektur möglich. Dann braucht es eine nachvollziehbare Kombination aus fehlendem Produktivzugriff, strenger Restore-Sperre und einem festgelegten Überschreibungsprozess. Die Kopie darf währenddessen nicht für neue Verarbeitungszwecke verwendet werden. Der Grund für diese Lösung und ihre Angemessenheit gehören in die Dokumentation.

Prüfen Sie auch Nebenpfade. Dazu zählen manuelle Exporte, Testumgebungen, lokale Downloadordner sowie Kopien beim Cloud-Dienstleister. Ein Löschlauf, der nur die sichtbare Datenbank erfasst, lässt den Nachweis unvollständig. Das Löschkonzept für Kunden- und Lead-Daten behandelt die vorgelagerte Zweck- und Fristenprüfung.

Ein belastbarer Backup-Lifecycle verbindet den Zweck der Sicherung mit einem überprüfbaren Überschreibungszyklus. Eine pauschale Aussage wie „Backups werden nach sieben Jahren gelöscht“ ersetzt keine Prüfung, wenn der Zyklus weder zum Zweck noch zum Risiko passt. Umgekehrt darf ein technischer Zyklus nicht dazu führen, dass personenbezogene Daten ohne nachvollziehbaren Grund dauerhaft vorgehalten werden.

Legen Sie fest, welche Rollen Backups lesen, exportieren, löschen oder wiederherstellen dürfen. Für den Normalbetrieb sollte der Zugriff auf Sicherungskopien beschränkt und protokolliert werden. Verschlüsselung, getrennte Berechtigungen und ein Vier-Augen-Prinzip können je nach Risiko geeignete Maßnahmen sein. Welche Maßnahme genügt, hängt von der konkreten Umgebung ab.

Der Zyklus muss mit der Restore-Logik verbunden sein. Ein altes Backup, das jederzeit vollständig zurückgespielt werden kann, ist anders zu bewerten als eine verschlüsselte, technisch isolierte Kopie. Prüfen Sie, ob der Anbieter unveränderbare Snapshots, georedundante Kopien oder eigene Papierkörbe führt. Diese Funktionen gehören in das Verzeichnis der Verarbeitungstätigkeiten und in die TOM-Dokumentation, soweit sie für den konkreten Prozess relevant sind.

Ein Restore kann einen früheren Datenstand in eine neue Umgebung bringen. Vor der Aktivierung muss deshalb geklärt sein, ob der Stand gelöschte, berichtigte oder gesperrte Daten enthält. Legen Sie eine Freigabe mit Anlass, Umfang, Zielsystem und verantwortlicher Person fest. Ein Notfall darf den Zugriff beschleunigen, die Datenschutzprüfung aber nicht unsichtbar machen.

Sinnvoll ist eine getrennte Wiederherstellungsumgebung, in der der Bestand zunächst geprüft und bereinigt wird. Abgleichen lassen sich etwa aktuelle Löschkennzeichen, Sperrlisten und die seit dem Backup vorgenommenen Berichtigungen. Erst danach sollte der erforderliche Teil in den aktiven Betrieb übernommen werden. Nicht benötigte Daten sind aus dem Restore-Bestand zu entfernen.

Nach dem Restore gehört ein kurzer Abschlussnachweis in die Akte: welches Backup verwendet wurde, welche Daten geprüft wurden, welche Bereinigungen erfolgten und wer die Aktivierung freigegeben hat. Das unterstützt die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO. Die Dokumentation technischer und organisatorischer Maßnahmen zeigt, wie Kontrollen und Verantwortlichkeiten nachvollziehbar beschrieben werden.

Art. 18 DSGVO kann eine Einschränkung der Verarbeitung verlangen, etwa wenn die Richtigkeit bestritten wird, die Verarbeitung unrechtmäßig ist und die betroffene Person statt Löschung die Einschränkung verlangt oder die Daten für Rechtsansprüche benötigt werden. Eine solche Einschränkung ist eine konkrete rechtliche Entscheidung. Sie darf nicht mit der bloßen Existenz eines Backups gleichgesetzt werden.

Für eine gesperrte Backup-Kopie müssen Zweck, Umfang und Zugriff feststehen. Die Daten dürfen dann nur unter den Voraussetzungen des Art. 18 Abs. 2 DSGVO weiterverarbeitet werden. Technisch sollte sich die Sperre im Restore-Prozess wiederfinden. Ein Restore darf einen eingeschränkten Bestand nicht als frei verfügbaren Produktivbestand behandeln.

Dokumentieren Sie, wann die Einschränkung beginnt, welches Ereignis ihre Aufhebung auslöst und wer die Prüfung vornimmt. Ändert sich die Lage, ist die betroffene Person vor einer Aufhebung grundsätzlich zu informieren. Die Einschränkung ist daher ein eigener Status mit eigener Kontrolle und keine allgemeine Rechtfertigung, jede Backup-Kopie unbegrenzt aufzubewahren.

Ein guter Nachweis verbindet Rechtsentscheidung, technische Konfiguration und tatsächliche Ausführung. Dazu gehören die Backup-Inventur, die Zuordnung der Datenkategorien, der Lösch- oder Sperrstatus und die Beschreibung des Überschreibungszyklus. Ergänzen Sie die Rollen, Zugriffskontrollen und den Restore-Ablauf. Eine einzelne Richtlinie ohne Kontrollbeleg reicht für die Rechenschaftspflicht regelmäßig nicht aus.

Prüfen Sie stichprobenartig, ob ein gelöschter Datensatz im aktiven System tatsächlich entfernt wurde, ob die Backup-Kopie nur den vorgesehenen Rollen zugänglich ist und ob ein Test-Restore die Sperr- und Löschlogik berücksichtigt. Testen Sie mit geeigneten Testdaten, wenn ein Produktionsrestore nicht erforderlich ist. Für jeden Test genügen ein klarer Anlass, das Ergebnis und ein allfälliger Korrekturschritt.

Ordnen Sie Abweichungen nach Risiko. Ein veralteter Berechtigungsaccount, ein nicht dokumentierter Snapshot oder ein Restore ohne Freigabe kann unterschiedliche Maßnahmen auslösen. Der Nachweis soll die Entscheidung erklären und den nächsten Prüftermin sichtbar machen. So bleibt die Sicherungsarchitektur auch bei einem Anbieterwechsel oder einer Systemmigration verständlich.

Verarbeitet ein Cloud- oder Backup-Anbieter personenbezogene Daten im Auftrag, ist seine Rolle nach Art. 28 DSGVO zu prüfen. Der Vertrag sollte die konkreten Backup-Funktionen, Unterauftragsverarbeiter, Speicherorte, Zugriffe und die Unterstützung bei Löschung und Einschränkung abbilden. Standardbedingungen müssen mit der tatsächlich gebuchten Architektur verglichen werden.

Fragen Sie den Anbieter, welche Kopien neben dem sichtbaren Backup bestehen. Relevant können Snapshots, Replikate, Papierkörbe, Supportkopien und technische Protokolle sein. Ebenso muss geklärt werden, wie ein Lösch- oder Sperrstatus bei einem Restore berücksichtigt wird. Eine Zusage, „gelöschte Dateien“ aus dem Hauptspeicher zu entfernen, beantwortet diese Fragen nicht vollständig.

Legen Sie intern fest, wer Löschanfragen bewertet, den Anbieter beauftragt und die Rückmeldung prüft. Die Übersicht zu Auftragsverarbeitern und Dienstleistern ordnet die Verantwortlichkeiten ein. Bei einer relevanten Änderung der Backup-Architektur sollte auch das Verzeichnis der Verarbeitungstätigkeiten aktualisiert werden.

Beginnen Sie mit einem konkreten Löschfall und verfolgen Sie ihn durch die Architektur. Welche Anwendung hat gelöscht? Welche Kopien wurden danach erstellt? Welche Kopien bleiben erreichbar? Die Antworten zeigen, ob der Prozess den tatsächlichen Datenfluss abbildet oder nur das Primärsystem beschreibt.

Prüfen Sie anschließend den Restore-Fall mit einem kontrollierten Szenario. Der Test soll zeigen, ob Lösch- und Sperrkennzeichen vor einer Aktivierung berücksichtigt werden, ob die Berechtigungen greifen und ob die Ausführung protokolliert wird. Für eine erste Bestandsaufnahme kann die Seite zu Zugriffsprotokollen und Beweisgrenzen hilfreich sein; den exakten Systempfad sollten Sie vor der Verlinkung an Ihre Umgebung anpassen.

Zum Schluss weisen Sie jedem offenen Punkt eine verantwortliche Rolle und einen Prüftermin zu. Das Thema Datenschutz-Governance hilft bei der Einordnung der Grundsätze. Die Backup-Dokumentation ist vollständig, wenn sie Entscheidung, technische Kontrolle, Restore-Verhalten und Ergebnisnachweis zusammenführt.