
Schnittstellen
Ausstieg aus Cloud-Diensten: Datenrückgabe, Löschung und Portabilität
Wer einen Cloud-Dienst verlässt, verliert keine Pflichten: Nach der EDÖB-Wegleitung zu Datenbearbeitungen in der Cloud handelt die Anbieterin in der Regel als Auftragsdatenbearbeiterin nach Art.
Ausstieg geplant statt überstürzt
Wer einen Cloud-Dienst verlässt, verliert keine Pflichten: Nach der EDÖB-Wegleitung zu Datenbearbeitungen in der Cloud handelt die Anbieterin in der Regel als Auftragsdatenbearbeiterin nach Art. 9 DSG, der Kunde bleibt Verantwortlicher. Er muss dafür sorgen, dass die im Auftrag erfolgten Bearbeitungen datenschutzkonform sind und die Rechte betroffener Personen durch die Auslagerung nicht geschmälert werden. Der Ausstieg ist daher ein eigenes Projekt mit Terminplanung, nicht eine nachgeschobene Kündigung.
Aus dieser Rollenverteilung folgt, was zurückzuholen ist: nicht nur die selbst hochgeladenen Daten, sondern alles, was im Auftrag bearbeitet wurde – einschliesslich der Bestände bei Unterauftragsbearbeitern. Der EDÖB nennt als typische Cloud-Nutzungen Online-Zusammenarbeit wie Office 365, Online-Verwaltungstools für E-Mail-Adressen in Newsletter- oder Kundenberatung, Online-CRM-Systeme, das Hochladen von Videos auf Streaming-Plattformen und Dateiablage auf einem über das Internet erreichbaren Server.
Planen Sie rückwärts von den Vertragsterminen: Kündigungsfrist und Vertragsende bestimmen, wie viel Zeit für Export, Prüfung und Nachlieferung bleibt. Für jede Phase der Übergangszeit gehört festgelegt, wer zuständig ist – Fachbereich für fachliche Vollständigkeit, IT für Export und Import, Datenschutzberatung für die Beurteilung, Geschäftsleitung für die Vertragsunterschrift.
Ebenfalls festzuhalten ist, bis wann welche Zusage der Anbieterin vorliegen muss. Ohne diese Ordnung laufen die Zugriffe in der Übergangsphase ab, ohne dass jemand die eingehenden Daten prüft.
Massgebende Rechtsgrundlagen sind das DSG vom 25. September 2020 (SR 235.1) und, soweit anwendbar, die DSGVO. Art. 9 DSG regelt die Auftragsbearbeitung; Betroffene haben nach anwendbarem Recht ein Auskunftsrecht sowie das Recht auf Löschung und Einschränkung der Bearbeitung. Diese Rechte sind bis zur bestätigten Löschung zu erfüllen.
Rechtsgrundlagen und Entscheidungshöhe im Schweizer Datenschutz
- Anwendbare EU-Richtlinie
- DSGVO (falls anwendbar)
- Verantwortlicher
- Kunde bleibt Verantwortlicher nach Art. 9 DSG
- Betroffene Rechte
- Auskunft, Löschung, Einschränkung der Bearbeitung
- Resolution Privatim
- Verschlüsselung besonders schützenswerter Daten durch das Organ selbst
Wissen, welche Daten überhaupt in der Cloud liegen
Erstellen Sie pro Dienst ein Inventar und unterscheiden Sie nach Datenkategorien und betroffenen Personenkreisen. Orientierung bieten die Kategorien aus Datenschutzerklärungen: Bestands- und Kontaktdaten, Inhaltsdaten, Vertragsdaten, Nutzungsdaten, Meta-, Kommunikations- und Verfahrensdaten sowie Protokolldaten. Betroffen sind typischerweise Nutzer, Beschäftigte, Kundinnen und Kunden, Kommunikationspartner sowie Geschäfts- und Vertragspartner. Wer diese beiden Achsen nicht ausfüllt, weiss am Ende nicht, ob die Rücklieferung vollständig ist.
Erfassen Sie je Kategorie den Speicherort und alle Beteiligten: Primärsystem, Auswertungs- und Suchindizes, Anhänge in Support- und Ticketdaten, Test- und Demoumgebungen sowie Sicherungskopien. Der EDÖB nennt als Kernpunkte jeder Cloud-Nutzung den Einsatz von Auftrags- und Unterauftragsbearbeitern, die Sicherheit der Datenbearbeitung und die Übermittlung von Personendaten in Drittländer – diese drei Punkte gehören in die Bestandesaufnahme. Halten Sie fest, welcher Unterauftragsbearbeiter für welche Kategorie tätig ist; seine Löschung erledigt sich nicht automatisch mit der Löschung beim Hauptanbieter.
Ergänzen Sie je Dienst die Exportmöglichkeit: Gibt es einen vollständigen, maschinenlesbaren Export oder nur Bildschirmansichten und Einzelausdrucke? Welche Felder, Anhänge und Metadaten enthält er, und in welchem Rhythmus lässt er sich erzeugen? Das Ergebnis ist eine Tabelle mit Dienst, Datenkategorie, Betroffenenkreis, Speicherort, beteiligtem Unterauftragsbearbeiter, Exportformat und Zuständigkeit. Ohne diese Übersicht bleibt jede Rückgabeforderung unvollständig, weil kein Abgleich zwischen Soll und Ist möglich ist.
Erfassen Sie je Dienst das Exportformat: CSV, JSON und XML sind offene, maschinenlesbare Formate; Parquet ist ein offenes, spaltenorientiertes Dateiformat für grosse Datenmengen. Verlangen Sie vollständige Feldbelegung und Metadaten, nicht nur PDF-Ansichten. Das Format gehört in die Tabelle neben Exportmöglichkeit und Zuständigkeit.
Rückgabe und Löschung vor der Kündigung regel
Halten Sie Rückgabe und Löschung schriftlich und vor der Kündigung fest; eine Zusage nach ausgesprochener Kündigung ist schwerer durchzusetzen. Zu regeln sind: Format der Herausgabe (maschinenlesbar und vollständig, einschliesslich Metadaten, Anhängen und Verknüpfungen), genauer Umfang (Datenkategorien, Zeitraum, Unterauftragsbearbeiter), Frist für die Übergabe, Zugriffsrechte während der Übergangsphase sowie Kosten der Rückgabe. Der EDÖB verlangt vom Cloud-Nutzer, dass er sich vergewissert und vertraglich absichert, die Anforderungen an eine Auftragsbearbeitung nach Art. 9 DSG einzuhalten; die Rückgabe- und Löschklausel gehört dazu.
Zur Löschung gehören vier Angaben: bis wann nach Abschluss der Rückgabe gelöscht wird; welche Daten erfasst sind (Produktionsdaten, Sicherungskopien, Protokolldaten, Zwischen- und Testkopien); bis wann eine schriftliche Bestätigung vorliegt; und dass Unterauftragsbearbeiter ausdrücklich einbezogen sind. Halten Sie auch fest, wer auf Kundenseite die Rückgabe prüft, nach welchen Kriterien und innert welcher Frist Mängel gerügt werden, sowie die Namen der Ansprechpersonen beider Seiten für Nachlieferungen.
Klären Sie vor dem Abschluss, ob die Nutzung mit einer Datenbekanntgabe ins Ausland verbunden war oder noch ist. Der EDÖB hält fest, dass vor der Bekanntgabe ins Ausland zu prüfen ist, ob sie den gesetzlichen Anforderungen genügt. Diese Prüfung gilt bis zur endgültigen Löschung, nicht nur für den Betrieb: Solange Daten bei der Anbieterin oder ihren Unterauftragsbearbeitern liegen, dauert die Bekanntgabe an.
Datenrückgabe: Was tatsächlich ankommt
Prüfen Sie die gelieferten Daten in drei Schritten. Erstens Vollständigkeit: Stimmen Datensatz- und Dateizahlen sowie der abgedeckte Zeitraum mit der Bestandesaufnahme überein? Sind alle Datenkategorien und betroffenen Personenkreise enthalten? Zweitens Lesbarkeit: Lässt sich das Format ohne Zusatzsoftware öffnen? Sind Zeichensatz, Datums- und Zahlenformate sowie Zeitzonen konsistent? Drittens Zuordnung: Sind Metadaten, Anhänge und Verknüpfungen erhalten, sodass jeder Datensatz der richtigen betroffenen Person zugeordnet werden kann?
Führen Sie den Nachweis über Stichproben und einen Importtest: ausgewählte Datensätze ins Zielsystem einspielen und dort mit dem Original vergleichen. Ein solcher Test deckt Feldverluste, fehlende Beziehungen und nicht übertragene Anhänge zuverlässiger auf als eine Sichtprüfung der Exportdatei. Dokumentieren Sie je Datenkategorie, was übernommen wurde und was fehlt.
Bei unvollständiger oder verspäteter Rückgabe: Mängel schriftlich unter Bezug auf die vereinbarte Frist und den vereinbarten Umfang melden, Nachlieferung mit neuem Termin verlangen und die Übergangsphase erst beenden, wenn die Nachlieferung geprüft ist. Verzögert sich die Rückgabe, müssen Begehren betroffener Personen dennoch beantwortet werden können. Nach anwendbarem Datenschutzrecht – in der Schweiz DSG vom 25. September 2020 (SR 235.1), soweit anwendbar ergänzt durch die DSGVO – haben Betroffene Rechte wie Auskunft sowie Löschung und Einschränkung der Bearbeitung; solange solche Begehren eingehen können, braucht es Zugriff auf die noch nicht zurückgegebenen Bestände.
Prüfen Sie das Format: CSV, JSON, XML und Parquet sind offene Formate. Parquet-Dateien enthalten ein explizites Schema sowie Metadaten zu Datentypen; damit lassen sich Feldtypen und Vollständigkeit maschinell prüfen.
Offene vs. proprietäre Formate für Datenexport
- CSV
- Offenes Format, maschinenlesbar, gut für kleine bis mittlere Datensätze
- JSON
- Offenes Format, strukturiert, ideal für APIs und komplexe Daten
- XML
- Offenes Format, flexibel, aber oft grösser als JSON oder CSV
- Parquet
- Offenes, spaltenorientiertes Format für grosse Datenmengen, enthält Schema und Metadaten
- Nicht maschinenlesbar, nur für Darstellung geeignet – kein Arbeitsmittel
Löschung, die auch Sicherungskopien erreicht
Ein Löschkonzept listet jeden Ort auf, an dem Daten des Dienstes liegen, und ordnet jedem Ort eine Löschfrist und eine verantwortliche Stelle zu: Produktionsdatenbank, Such- und Auswertungsindizes, Anhänge in Support- und Ticketdaten, Zwischen- und Testkopien, Exportdateien auf Kundenseite sowie Sicherungskopien. Entscheidend ist, dass Unterauftragsbearbeiter einzeln aufgeführt werden; ihre Löschung folgt nicht automatisch aus der Löschung beim Hauptanbieter.
Sicherungskopien und Protokolldaten brauchen eine eigene Betrachtung. Bei Sicherungskopien kann die Löschfrist von jener der Produktionsdaten abweichen, weil Kopien erst mit dem nächsten Sicherungszyklus überschrieben werden; festzuhalten ist daher, bis wann die Daten wirklich weg sind, und nicht nur, ab wann sie nicht mehr aktiv genutzt werden. Protokolldaten sind getrennt zu behandeln: Sie können aus Gründen der Nachvollziehbarkeit oder aufgrund eigener Aufbewahrungspflichten länger liegen bleiben; das gehört ausdrücklich ins Löschkonzept.
Verlangen Sie eine schriftliche Löschbestätigung mit Datum, erfassten Datenkategorien und beteiligten Unterauftragsbearbeitern. Solange sie fehlt, bleibt die Verantwortung beim Kunden: Er steht als Verantwortlicher für die datenschutzkonforme Bearbeitung ein – auch für Bearbeitungen, die im Auftrag erfolgt sind. Halten Sie im Konzept zusätzlich fest, wie mit Daten umgegangen wird, die während der Übergangsphase neu anfallen, etwa Supportmeldungen zu den exportierten Beständen.
Portabilität: Daten mitnehmen statt nur kopieren
Klären Sie vor dem Export, in welchem Format die Daten im Zielsystem weiterverwendet werden können. Verlangen Sie offene, maschinenlesbare Formate und vollständige Feldbelegung; klären Sie den Umgang mit Beziehungen und Objekt-IDs, Anhängen und Binärdateien sowie Zeichensatz, Datumsformat und Zeitzone. Eine PDF-Übersicht ist eine Auskunft, aber kein Arbeitsmittel für die Weiterverwendung.
Testen Sie die Portabilität mit einem Import ins Zielsystem, bevor Sie die Kündigung bestätigen: Feldzuordnung (Mapping) erstellen, Pflichtfelder des Zielsystems abgleichen, nicht übertragbare Felder und Standardwerte dokumentieren. Der Test zeigt auch, ob die Datenmenge in der vorgesehenen Zeit überhaupt übertragen werden kann – bei grossen Beständen bestimmt das den Zeitplan.
Unterscheiden Sie die Portabilität des Dienstes vom Anspruch betroffener Personen auf ihre eigenen Daten. Nach anwendbarem Recht haben Betroffene ein Auskunftsrecht sowie das Recht auf Löschung und Einschränkung der Bearbeitung; die Datenschutzerklärung eines Dienstes informiert darüber. Der Verantwortliche muss diese Rechte auch nach dem Ausstieg erfüllen können. Der technische Export der Anbieterin deckt das nicht ab: Er umfasst in der Regel den gesamten Bestand, während ein Begehren nur die Daten einer betroffenen Person betrifft – dafür braucht es nach dem Ausstieg eine eigene, im Zielsystem suchbare Ablage.
Cloud-Portabilität heisst, Anwendungen, Daten und Workloads ohne umfassende Neuentwicklung und ohne Datenverlust von einer Cloud-Umgebung in eine andere zu verlagern. Dazu gehören offene Datenformate wie JSON, XML und CSV sowie offene APIs.
Kontrollieren Sie die Schnittstellen: offene APIs wie REST oder GraphQL statt proprietäre Endpunkte; Authentifizierung über Standards wie OAuth, SAML oder OpenID. Containerisierte Anwendungen mit Docker oder Kubernetes erleichtern das Verschieben.
Für grosse Datenmengen eignet sich das offene, spaltenorientierte Format Parquet, das Schema und Metadaten mitführt. Klären Sie vor dem Export, ob das Zielsystem CSV, JSON, XML oder Parquet verarbeiten kann.
Verschlüsselung und Schlüssel unter eigener Kontrolle
Die Konferenz der schweizerischen Datenschutzbeauftragten (Privatim) hält in ihrer Resolution zur Auslagerung von Datenbearbeitungen in die Cloud fest: Für öffentliche Organe ist die Nutzung von SaaS-Lösungen internationaler Anbieter nur zulässig, wenn die besonders schützenswerten Personendaten vom Organ selbst verschlüsselt werden. Dasselbe gilt für Personendaten, die einer gesetzlichen Geheimhaltungspflicht unterstehen. Der Cloud-Anbieter darf keinen Zugang zum Schlüssel haben.
Die Resolution wurde am 18. November 2025 verabschiedet und am 24. November 2025 veröffentlicht.
In der Praxis stösst diese Anforderung an Grenzen. Nach der Resolution ist bei den meisten Cloud-Diensten keine sinnvolle Nutzung mit Ende-zu-Ende-Verschlüsselung möglich. Bei Diensten, die sich mit durchgehender Ende-zu-Ende-Verschlüsselung sinnvoll nutzen lassen, ist es häufig nicht möglich, dem Anbieter jeglichen Zugang zu den Schlüsseln der Nutzer zu verwehren. Bei internationalen Diensten wie Amazon Web Services (AWS), Google oder Microsoft 365 bleibt öffentlichen Organen im Wesentlichen nur die Nutzung als reiner Online-Speicher.
Für den Ausstieg folgt daraus: Klären Sie vor der Rückgabe, welche Daten verschlüsselt gespeichert sind, wer die Schlüssel hält und in welcher Form die Daten übergeben werden – verschlüsselt mit mitgeliefertem Schlüsselmaterial oder entschlüsselt über einen gesicherten Kanal. Sichern und prüfen Sie die Schlüssel vor dem letzten Zugriff auf den Dienst; ohne Schlüssel sind die zurückgeholten Daten nicht mehr verwertbar. Legen Sie zudem fest, wer im Unternehmen Zugriff auf die Schlüssel hat und was bei Verlust oder Wechsel einer Schlüsselverantwortlichen geschieht.
Warum ein Serverstandort in Europa nicht genügt
Der EDÖB hält fest, dass bei der Nutzung von Cloud-Diensten vor einer Datenbekanntgabe ins Ausland zu prüfen ist, ob sie den gesetzlichen Anforderungen genügt. Diese Prüfung gehört zum Ausstieg wie zum Einstieg: Sie betrifft alle Daten, die bis zur bestätigten Löschung noch bei der Anbieterin oder ihren Unterauftragsbearbeitern liegen.
Ein Serverstandort in Europa genügt dafür nicht. Ein Fachbeitrag zur Cloud-Sicherheit in der Schweiz trägt im Titel die Feststellung «Cloud in Europa: Kein Schutz vor US-Zugriff» und hält fest, dass Cloud-Sicherheit in der Schweiz mehr bedeutet als ein europäischer Serverstandort. Für den Ausstieg heisst das: Angaben zur Datenbekanntgabe – Sitz und Muttergesellschaft der Anbieterin, Sitz der Unterauftragsbearbeiter, Ort der Bearbeitung, Rechtsgrundlage der Bekanntgabe – schriftlich einholen und nicht aus dem Serverstandort ableiten.
Für öffentliche Organe ist die Latte höher, weil die meisten ihrer Daten dem Amtsgeheimnis und damit einer gesetzlichen Geheimhaltungspflicht unterliegen. Die Resolution von Privatim hält fest, dass öffentliche Organe die Bearbeitung an Dritte auslagern dürfen, dabei aber sicherstellen müssen, dass Datenschutz und Informationssicherheit gewahrt bleiben; für besonders schützenswerte oder einer gesetzlichen Geheimhaltungspflicht unterstehende Personendaten verlangt sie die Verschlüsselung durch das Organ selbst. Beim Ausstieg ist deshalb zu dokumentieren, wo die Daten bis zur Löschung liegen und welche Zugriffsmöglichkeiten Dritter in dieser Zeit bestehen.
Vorteile und Risiken bei Serverstandort in Europa
- Vorteil
- Einhaltung der DSGVO-Anforderungen für europäische Daten
- Nachteil
- Kein Schutz vor US-Zugriff durch Gesetze wie FISA oder CLOUD Act
- Folge für Schweizer Organe
- Serverstandort allein genügt nicht für datenschutzkonforme Bekanntgabe ins Ausland
- Empfehlung
- Angaben zur Muttergesellschaft, Unterauftragsbearbeiter und Rechtsgrundlage schriftlich einholen
Offboarding dokumentieren
Nach Abschluss sollten diese Unterlagen vorliegen: Rückgabeprotokoll mit Datum, übergebenen Datenkategorien, Formaten und Datenträgern sowie Prüfvermerk mit Stichproben, Importtest und allfälligen Mängeln samt Nachlieferungen.
Ebenfalls vorliegen sollten eine schriftliche Löschbestätigung mit Datum und Umfang, die Bestätigung, dass Unterauftragsbearbeiter einbezogen wurden, und der Nachweis über Sicherung und Verwahrung der Verschlüsselungsschlüssel. Ohne diese Nachweise lässt sich später weder gegenüber Betroffenen noch gegenüber einer Aufsichtsbehörde belegen, wann welche Daten zurückgeholt und gelöscht wurden.
Passen Sie die internen Verzeichnisse an: Dienst und Unterauftragsbearbeiter aus dem Verarbeitungsverzeichnis bzw. Vertragsregister entfernen oder als beendet kennzeichnen, die Aufbewahrungs- und Löschfristen für die zurückgeholten Bestände neu festlegen und im Zielsystem die Zugriffsrechte nachziehen. Löschen Sie Konten, API-Schlüssel, Tokens und Servicebenutzer des beendeten Dienstes; sonst bleiben Zugänge bestehen, die niemand mehr betreut.
Prüfen Sie zuletzt die Aussenkommunikation. Wird der Dienst in der Datenschutzerklärung oder in einer Liste eingesetzter Anbieter und Services genannt, ist der Eintrag anzupassen. Informationspflichten und die Beantwortung von Auskunfts- und Löschbegehren betroffener Personen laufen nach dem Ausstieg im Zielsystem weiter; legen Sie fest, wer dafür zuständig ist und wie die zurückgeholten Bestände durchsucht werden können.


