Publié le 10 mai 2024

Der Serverstandort Deutschland allein schützt nicht vor US-Behördenzugriff; echte Datenhoheit erfordert eine proaktive, mehrschichtige Verteidigungsarchitektur.

  • Vertragliche Absicherung durch präzise AV-Verträge, Exit-Klauseln und Subunternehmer-Kontrolle ist die juristische Frontlinie.
  • Technische Massnahmen wie kundenseitige Verschlüsselung (BYOK/HYOK) sind entscheidend, um den direkten Datenzugriff zu unterbinden.
  • Organisatorische Richtlinien, Löschkonzepte und die Kontrolle von Schatten-IT bilden das Fundament der Compliance.

Empfehlung: Implementieren Sie ein mehrschichtiges Kontrollsystem, das vertragliche, technische und organisatorische Massnahmen kombiniert, anstatt sich auf einzelne, isolierte Lösungen zu verlassen.

Als IT-Leiter oder Datenschutzbeauftragter (DPO) in einem deutschen Unternehmen stehen Sie vor einem Dilemma: Die Hyperscaler wie AWS, Microsoft 365 oder Google Cloud bieten unbestreitbare Vorteile in Skalierbarkeit, Funktionalität und Innovation. Gleichzeitig schwebt das Damoklesschwert des US CLOUD Acts über jeder Entscheidung, Daten diesen Anbietern anzuvertrauen. Der CLOUD (Clarifying Lawful Overseas Use of Data) Act ermächtigt US-Behörden, auf Daten zuzugreifen, die von US-Unternehmen gespeichert werden – unabhängig vom physischen Serverstandort. Dies steht in direktem Konflikt mit den strengen Anforderungen der Datenschutz-Grundverordnung (DSGVO), die einen Datentransfer in Drittländer mit niedrigerem Datenschutzniveau grundsätzlich untersagt.

Viele suchen die Lösung in vermeintlich einfachen Antworten. Man verlässt sich auf die Marketingaussage « Serverstandort Frankfurt », schliesst einen Standard-Auftragsverarbeitungsvertrag (AVV) ab oder hofft, dass Verschlüsselung allein ausreicht. Diese Ansätze sind jedoch trügerisch und greifen zu kurz. Die Rechtsprechung, insbesondere nach dem « Schrems II »-Urteil des EuGH, macht deutlich, dass ein passiver Ansatz nicht genügt. Es bedarf zusätzlicher, wirksamer Massnahmen, um die Datenhoheit zu wahren und eine rechtssichere Nutzung von US-Cloud-Diensten zu gewährleisten.

Die wahre Lösung liegt nicht in einer einzelnen Massnahme, sondern in einer durchdachten Verteidigungsarchitektur. Dieser Artikel bricht mit der oberflächlichen Diskussion und taucht tief in die operativen Mechanismen ein, die Sie zur Risikominimierung benötigen. Wir analysieren die Schwachstellen in der gesamten Risikokette – vom Vertrag über die Technik bis zur Organisation – und zeigen Ihnen, wie Sie eine robuste Compliance-Strategie aufbauen. Statt der Frage « Ist es legal? », beantworten wir « Wie machen wir es so rechtssicher wie möglich? ».

Dieser Leitfaden führt Sie systematisch durch die entscheidenden Kontrollpunkte. Von der kritischen Bewertung des Serverstandorts über die technische Absicherung durch Verschlüsselung bis hin zur vertraglichen Gestaltung und der Kontrolle Ihrer Dienstleisterkette erhalten Sie eine fundierte Grundlage für Ihre strategischen Entscheidungen.

Serverstandort Frankfurt: Reicht « Hosted in Germany », um vor US-Zugriffen sicher zu sein?

Die klare Antwort lautet: Nein. Die Annahme, ein deutscher Serverstandort biete eine juristische Firewall gegen den US CLOUD Act, ist ein weitverbreiteter und gefährlicher Irrtum. Der CLOUD Act zielt nicht auf den Speicherort der Daten ab, sondern auf die Kontrolle durch das US-Unternehmen. Solange der Cloud-Provider ein amerikanischer Konzern wie Amazon (AWS) oder Microsoft ist, unterliegt er der US-Gesetzgebung. Der Zugriffsbefehl einer US-Behörde verpflichtet das Unternehmen zur Herausgabe der Daten, selbst wenn diese auf einem Server in Frankfurt am Main liegen. Aktuelle Marktanalysen zeigen, dass US-Anbieter mit über 51 % des deutschen Cloud-Marktes dominieren, was die Relevanz dieses Problems unterstreicht.

Wie Dr. Datenschutz in einem Fachbeitrag treffend formuliert, ist der reine Serverstandort bestenfalls ein Indikator, aber keinesfalls ein entlastender Faktor bei der Frage, ob ein problematischer Drittlandsbezug vorliegt. Er kann die Latenz verbessern und das « gute Gefühl » stärken, aber er ändert nichts an der rechtlichen Unterstellung des Anbieters unter US-Recht. Dieses Missverständnis ist der erste Punkt, an dem die Risikokette brechen kann.

Fallbeispiel: Das Scheitern der Microsoft Deutschland Cloud

Ein prägnantes Beispiel für diese « Treuhänder-Falle » war das frühere Modell der « Microsoft Cloud Deutschland ». Hier fungierte T-Systems als Datentreuhänder, um den direkten Zugriff von Microsoft auf die Daten zu verhindern. Das Modell scheiterte jedoch kläglich: Es bot laut Software-Express nur 15 funktionsfähige Dienste, war inkompatibel mit globalen Office 365-Strukturen und wurde letztendlich 2020 eingestellt. Microsoft betreibt nun neue Rechenzentren in Deutschland ohne Treuhänder, was die fundamentale Problematik des CLOUD Acts wieder in den Vordergrund rückt und beweist, dass isolierte Standortlösungen keine nachhaltige Sicherheit bieten.

Anstatt sich also blind auf den Standort zu verlassen, müssen Sie tiefer ansetzen. Die wahre Verteidigung beginnt mit der kritischen Prüfung des Mutterkonzerns und der Implementierung zusätzlicher technischer und vertraglicher Schutzmassnahmen. Der Serverstandort ist nur ein Puzzleteil in einer komplexen Verteidigungsarchitektur, nicht die Festung selbst.

Bring Your Own Key: Warum Sie den Schlüssel zur Cloud selbst halten sollten

Wenn der physische Standort der Daten keine ausreichende Sicherheit bietet, rückt die technische Kontrolle in den Fokus: die Verschlüsselung. Doch nicht jede Verschlüsselung ist gleich. Bei der Standardverschlüsselung der meisten Cloud-Anbieter behält der Provider die Kontrolle über die Schlüssel. Im Falle einer behördlichen Anordnung kann der Anbieter die Daten entschlüsseln und herausgeben. Echte Datenhoheit erlangen Sie nur, wenn Sie die kryptografischen Schlüssel selbst verwalten und der Cloud-Provider zu keinem Zeitpunkt darauf zugreifen kann.

Darstellung verschiedener Cloud-Verschlüsselungsmethoden und Schlüsselverwaltung nach BSI-Standards

Hier kommen Konzepte wie « Bring Your Own Key » (BYOK), « Hold Your Own Key » (HYOK) oder « Double Key Encryption » (DKE) ins Spiel. Diese Ansätze ermöglichen es Ihnen, Ihre eigenen Schlüssel zu generieren und zu verwalten, oft in einem eigenen Hardware-Sicherheitsmodul (HSM). Der Cloud-Anbieter verarbeitet dann nur noch verschlüsselte Daten und hat keine Möglichkeit, diese im Klartext zu lesen. Dies ist eine entscheidende technische Massnahme, um den potenziellen Zugriff durch den CLOUD Act wirksam zu unterbinden. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt solche Modelle als essenziellen Baustein für die sichere Cloud-Nutzung.

Die folgende Tabelle vergleicht die gängigsten Verschlüsselungsmethoden und zeigt, wie sich der Grad der Kontrolle auf die Konformität mit DSGVO und BSI-Standards auswirkt. Die Analyse basiert auf aktuellen Bewertungen von Cloud-Sicherheitsarchitekturen.

Vergleich der Verschlüsselungsmethoden nach BSI-Standards
Methode Kontrolle BSI-Konformität DSGVO-Eignung
Standard-Verschlüsselung Provider Nicht ausreichend Kritisch
BYOK Geteilt Bedingt Verbesserung
HYOK Kunde Empfohlen Gut
DKE (Double Key) Vollständig beim Kunden Best Practice Optimal

Die Wahl der richtigen Verschlüsselungsstrategie ist somit kein technisches Detail, sondern ein zentraler Hebel Ihrer rechtlichen Verteidigungsarchitektur. Es ist der Beweis, dass Sie proaktiv Massnahmen ergriffen haben, um den Datenzugriff durch Dritte technisch unmöglich zu machen – ein starkes Argument in jeder Datenschutz-Folgenabschätzung (DSFA).

Vendor Lock-in: Wie Sie Ihren Cloud-Vertrag so gestalten, dass Sie die Daten bei Kündigung wiederbekommen

Eine robuste Verteidigungsarchitektur stützt sich nicht nur auf technische, sondern auch auf solide vertragliche Grundlagen. Ein häufig übersehenes Risiko ist der sogenannte Vendor Lock-in: die technische oder vertragliche Abhängigkeit von einem Anbieter, die einen Wechsel unverhältnismässig teuer oder komplex macht. Was passiert mit Ihren Daten, wenn Sie den Vertrag kündigen müssen – sei es wegen neuer rechtlicher Bedenken, schlechter Performance oder aus strategischen Gründen? Ohne eine klare Exit-Strategie droht ein massiver Kontrollverlust.

Ihr Auftragsverarbeitungsvertrag (AVV) muss daher weit über die Standard-Formulierungen hinausgehen. Er muss präzise Klauseln zur Datenherausgabe (Exit-Plan) enthalten. Dazu gehört die vertragliche Zusicherung, dass alle Daten und Metadaten bei Vertragsende in einem gängigen, maschinenlesbaren und interoperablen Format übergeben werden. Nach deutschem Handelsrecht kann hier auf § 61 HGB verwiesen werden, um die Herausgabepflicht zu untermauern. Definieren Sie klare Fristen für die Herausgabe (z.B. maximal 30 Tage) und die anschliessende, nachweisbare Löschung aller Daten beim Anbieter.

Der reine Serverstandort ist zwar Indikator, aber keinesfalls entlastender Faktor bei der Frage, ob ein problematischer Drittlandsbezug vorliegt

– Dr. Datenschutz, Fachbeitrag zur Cloud-Server Standortwahl und DSGVO

Versteckte Kosten für den Datenexport sind eine weitere Falle. Lassen Sie sich die Kosten für die Migration und den Support im Exit-Szenario vorab schriftlich zusichern. Idealerweise testen Sie die technischen Schnittstellen und den Exportprozess bereits vor Vertragsabschluss oder führen quartalsweise Test-Exporte durch. Diese Massnahmen stellen sicher, dass Ihre Datenhoheit auch im Falle einer Trennung gewahrt bleibt und Sie nicht erpressbar werden. Ein Vertrag ohne durchdachten Exit-Plan ist wie ein Gebäude ohne Notausgang: im Normalbetrieb unauffällig, in der Krise katastrophal.

Ihr Exit-Plan: Checkliste für den Cloud-Vertrag

  1. Datenherausgabe-Klausel: Fordern Sie eine Vertragsklausel nach § 61 HGB für die Datenherausgabe in einem maschinenlesbaren Standardformat (z.B. CSV, JSON, XML).
  2. Test-Exporte: Führen Sie quartalsweise Test-Exporte wichtiger Daten durch und dokumentieren Sie den Prozess und das Ergebnis.
  3. Systemkompatibilität prüfen: Stellen Sie vorab sicher, dass die exportierten Datenformate mit Ihren Kernsystemen (z.B. DATEV, SAP) kompatibel sind.
  4. Kosten definieren: Klären Sie versteckte Kosten und den Umfang des Supports für die Datenmigration im Vertrag und lassen Sie diese schriftlich fixieren.
  5. Schnittstellen testen: Validieren Sie die technischen Schnittstellen (APIs) für den Datenexport vor dem finalen Vertragsabschluss.
  6. Fristen festlegen: Vereinbaren Sie eine maximale Frist für die vollständige Datenherausgabe nach Kündigung (z.B. 30 Tage).

Cloud down: Wer zahlt den Umsatzausfall, wenn der Cloud-Anbieter einen Ausfall hat?

Neben dem Risiko des Datenzugriffs durch Dritte ist die operative Verfügbarkeit der Cloud-Dienste ein kritischer Faktor. Ein Ausfall von AWS, Azure oder Google Cloud kann den Betrieb eines Unternehmens vollständig lahmlegen und zu erheblichen finanziellen Schäden führen. Die Service Level Agreements (SLAs) der grossen Anbieter klingen oft vielversprechend, doch im Ernstfall entpuppen sie sich als zahnlose Tiger. Eine typische Gutschrift bei Nichterreichen einer Verfügbarkeit von 99,9 % beträgt oft nur einen kleinen Prozentsatz der monatlichen Gebühr.

Diese Kompensation steht in keinem Verhältnis zum tatsächlichen Schaden. Die Diskrepanz zwischen SLA-Kompensationen und realen Ausfallkosten ist enorm: Einer Gutschrift von vielleicht 10 % der Monatsgebühr steht ein durchschnittlicher Stundenschaden von 25.000 € bei einem mittelständischen Unternehmen gegenüber. Der Anbieter haftet in der Regel nicht für Folgeschäden wie entgangenen Gewinn oder Reputationsverlust. Dieses Risiko tragen Sie als Kunde fast immer allein. Es ist daher unerlässlich, sich nicht auf die SLAs zu verlassen, sondern eigene Vorkehrungen für den Ernstfall zu treffen.

Eine robuste Strategie umfasst mehrere Ebenen. Technisch kann dies eine Multi-Cloud- oder Hybrid-Cloud-Architektur sein, die ein Failover auf ein alternatives System ermöglicht. Organisatorisch ist ein Notfallplan (Business Continuity Plan) entscheidend, der klare Prozesse und Verantwortlichkeiten im Falle eines Ausfalls definiert. Juristisch sollten Sie im AVV prüfen, welche Haftungsgrenzen vereinbart sind und ob eine Verhandlung möglich ist, auch wenn die Chancen hier gering sind. Zusätzlich ist der Abschluss einer Cyber-Versicherung, die Betriebsunterbrechungsschäden abdeckt, eine wichtige Massnahme zur finanziellen Absicherung. Im Schadensfall ist eine lückenlose Beweissicherung nach deutschem Recht (HGB) entscheidend, um überhaupt Ansprüche geltend machen zu können.

Folgende Schritte sind zur Beweissicherung bei einem Cloud-Ausfall essenziell:

  • Reichen Sie umgehend Störungstickets mit exaktem Zeitstempel beim Provider ein.
  • Dokumentieren Sie Fehlermeldungen durch Screenshots, die die Systemzeit anzeigen.
  • Berechnen und belegen Sie den entgangenen Gewinn nach HGB-Standards.
  • Protokollieren Sie Kundenbeschwerden und nachweislich abgebrochene Geschäftsvorgänge.
  • Sichern Sie Daten aus Monitoring-Tools extern, um einen unabhängigen Nachweis zu haben.

Dropbox privat genutzt: Wie Sie verhindern, dass Mitarbeiter Firmendaten in private Clouds hochladen

Die grösste Schwachstelle in jeder Sicherheitsarchitektur ist der Mensch. Während Sie aufwändige Verträge aushandeln und komplexe Verschlüsselungstechnologien implementieren, umgehen Mitarbeiter diese Schutzwälle möglicherweise durch die Nutzung privater Cloud-Dienste wie Dropbox, Google Drive oder WeTransfer. Diese sogenannte Schatten-IT entsteht oft nicht aus böser Absicht, sondern aus Bequemlichkeit oder dem Wunsch nach effizienten Tools. Das Ergebnis ist jedoch ein massiver Kontrollverlust: Sensible Firmendaten verlassen den geschützten Raum und landen auf Servern, für die Sie keinerlei vertragliche oder technische Kontrolle haben.

Visualisierung der Kontrolle von Schatten-IT und Schutz von Firmendaten vor privater Cloud-Nutzung

Die Bekämpfung von Schatten-IT erfordert eine Kombination aus technischen und organisatorischen Massnahmen. Technisch können Data Loss Prevention (DLP) Systeme den unbefugten Upload von Daten auf nicht genehmigte Dienste blockieren. Endpoint-Security-Lösungen helfen, die Aktivitäten auf den Endgeräten der Mitarbeiter zu überwachen. Viel wichtiger ist jedoch der organisatorische Ansatz. Es braucht eine klare, verständliche und verbindliche IT-Nutzungsrichtlinie, die festlegt, welche Dienste für welche Zwecke erlaubt sind und die private Nutzung von Cloud-Speichern für Firmendaten explizit verbietet.

In Unternehmen mit Betriebsrat ist dieser Schritt mitbestimmungspflichtig. Nach § 87 Abs. 1 Nr. 6 BetrVG hat der Betriebsrat ein Mitbestimmungsrecht bei der Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Eine formelle Betriebsvereinbarung zur Cloud-Nutzung ist daher nicht nur eine rechtliche Notwendigkeit, sondern auch ein wirksames Instrument, um für alle Seiten Klarheit und Verbindlichkeit zu schaffen.

Fallbeispiel: Betriebsvereinbarung als Instrument der Steuerung

Global tätige deutsche Unternehmen, die zwangsläufig internationale Hyperscale Cloud Provider nutzen, stehen vor der Herausforderung, die private Nutzung dieser Dienste durch Mitarbeiter zu regeln. Die Einführung einer klaren Betriebsvereinbarung ist hierbei ein zentrales Steuerungselement. Sie definiert nicht nur Verbote, sondern bietet oft auch sanktionierte, benutzerfreundliche Alternativen an (z.B. einen unternehmenseigenen sicheren Datenaustauschdienst). So wird die Akzeptanz der Mitarbeiter erhöht und das Risiko der Schatten-IT aktiv gemanagt, anstatt es nur zu verbieten.

Die beste technische und vertragliche Verteidigungsarchitektur ist nutzlos, wenn sie intern umgangen wird. Die Sensibilisierung und Schulung der Mitarbeiter sowie die Bereitstellung praktikabler, sicherer Alternativen sind daher entscheidende Bausteine Ihrer Compliance-Strategie.

Wann müssen Daten weg? Warum « Datenfriedhöfe » ein Risiko sind und wie ein Löschkonzept aussieht

Die DSGVO fordert nicht nur den Schutz von Daten, sondern auch deren gezielte Löschung, sobald der Zweck für ihre Speicherung entfällt (Grundsatz der Datenminimierung und Speicherbegrenzung, Art. 5 DSGVO). Viele Unternehmen neigen jedoch dazu, Daten unbegrenzt aufzubewahren – sei es aus Unsicherheit, Bequemlichkeit oder der vagen Hoffnung, sie könnten « irgendwann noch nützlich sein ». So entstehen riesige « Datenfriedhöfe » in der Cloud, die ein erhebliches rechtliches und finanzielles Risiko darstellen.

Jeder Datensatz, der unnötigerweise gespeichert wird, erhöht die Angriffsfläche bei einem Datenleck und potenziert den Schaden. Im Falle einer behördlichen Untersuchung oder eines Auskunftsersuchens nach Art. 15 DSGVO wird der Aufwand, relevante von irrelevanten Daten zu trennen, immens. Vor allem aber stellt ein fehlendes Löschkonzept einen direkten Verstoss gegen die Grundprinzipien der DSGVO dar. Die DSGVO sieht bei Verstössen gegen diese Löschpflichten empfindliche Strafen vor, die sich auf bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes belaufen können. Das Risiko ist also nicht nur theoretisch, sondern sehr konkret.

Ein wirksames Löschkonzept ist daher keine Option, sondern eine Pflicht. Es ist ein dokumentierter Prozess, der festlegt, welche Datenkategorien wie lange aufbewahrt und wann und wie sie sicher gelöscht werden. Ein solches Konzept beinhaltet:

  • Datenklassifizierung: Einteilung aller Daten in Kategorien (z.B. Kundendaten, Personaldaten, Buchhaltungsunterlagen).
  • Aufbewahrungsfristen: Festlegung von Fristen für jede Datenkategorie unter Berücksichtigung gesetzlicher Vorgaben (z.B. aus HGB oder AO) und des Verarbeitungszwecks.
  • Löschregeln: Definition des technischen Prozesses zur unwiederbringlichen Löschung der Daten nach Ablauf der Frist.
  • Verantwortlichkeiten: Klare Zuweisung, wer für die Überwachung der Fristen und die Durchführung der Löschung verantwortlich ist.
  • Dokumentation: Protokollierung der durchgeführten Löschungen als Nachweis für die Aufsichtsbehörden.

In der Cloud wird dies besonders relevant, da die technischen Löschprozesse oft komplexer sind (z.B. durch Backups und geografische Replikation). Ihr AVV mit dem Cloud-Anbieter muss daher dessen Pflichten zur Unterstützung bei der Umsetzung Ihres Löschkonzepts klar definieren. Ein Datenfriedhof ist eine tickende Zeitbombe in Ihrer IT-Landschaft; ein Löschkonzept ist die kontrollierte Entschärfung.

Kette von Dienstleistern: Muss Ihr Hoster Sie fragen, bevor er einen Subunternehmer in Indien beauftragt?

Ja, absolut. Die Verantwortung für den Datenschutz endet nicht bei Ihrem direkten Cloud-Anbieter. Sie erstreckt sich über die gesamte Kette der beteiligten Dienstleister. Nach Art. 28 DSGVO darf Ihr Auftragsverarbeiter (der Cloud-Anbieter) nicht ohne Ihre vorherige schriftliche Genehmigung einen weiteren Auftragsverarbeiter (einen Subunternehmer) hinzuziehen. Diese Regelung ist ein entscheidender Hebel, um den Kontrollverlust über Ihre Daten zu verhindern.

In der Praxis versuchen grosse Hyperscaler oft, diese Anforderung durch allgemeine Genehmigungsklauseln in ihren Standard-AGBs aufzuweichen. Dort wird Ihnen als Kunde oft nur ein Widerspruchsrecht eingeräumt, wenn ein neuer Subunternehmer hinzukommt. Das Problem: Wer überwacht diese Listen kontinuierlich? Ein neuer Subunternehmer in einem unsicheren Drittland wie Indien, China oder Russland kann Ihr gesamtes Datenschutzkonzept zunichtemachen. Plötzlich findet eine Datenverarbeitung statt, die Sie nie genehmigt haben und die nicht durch Ihre Risikobewertung abgedeckt ist.

Vergleich: Transparenz bei deutschen vs. internationalen Anbietern

Analysen von Standard-AVVs zeigen, dass sich gerade bei grossen internationalen Anbietern oft Fallstricke bezüglich der Subunternehmer in den AGB verstecken. Kleinere, spezialisierte deutsche Anbieter wie PC Cloud oder owncloud online, die ihre Infrastruktur selbst betreiben, können hier oft eine höhere Transparenz und eine stringentere Umsetzung der DSGVO-Vorgaben bieten. Sie werben explizit mit einer kontrollierten, transparenten Dienstleisterkette und garantieren teilweise vertraglich, keine Subunternehmer ausserhalb der EU einzusetzen. Dies kann ein entscheidendes Kriterium bei der Anbieterauswahl sein.

Eine proaktive Verteidigungsarchitektur erfordert daher ein aktives Management der Subunternehmerkette. Sie müssen vertraglich auf einer Informationspflicht bestehen, bevor neue Subunternehmer beauftragt werden. Verknüpfen Sie Ihr Widerspruchsrecht mit einem Sonderkündigungsrecht, falls ein neuer Subunternehmer für Sie inakzeptabel ist. Fordern Sie zudem regelmässige Audit-Berichte der wichtigsten Subdienstleister an, um deren Compliance-Niveau zu überprüfen. Die Kontrolle der Risikokette ist ein kontinuierlicher Prozess, keine einmalige Prüfung bei Vertragsabschluss.

Ihre Checkliste zur Überwachung der Subunternehmerkette

  1. Informationspflicht einfordern: Bestehen Sie auf einer quartalsweisen, proaktiven Zusendung der aktuellen Subunternehmerliste durch Ihren Dienstleister.
  2. Monitoring einrichten: Richten Sie Google Alerts für Ihre Hauptdienstleister mit Suchbegriffen wie « Übernahme », « Partnerschaft » oder « Fusion » ein, um frühzeitig von Änderungen zu erfahren.
  3. Vertragliche Fristen setzen: Vereinbaren Sie eine vertragliche Pflicht des Anbieters, Sie mindestens 14 Tage vor dem Einsatz eines neuen Subunternehmers zu informieren.
  4. Rechte verknüpfen: Koppeln Sie Ihr gesetzliches Widerspruchsrecht an ein vertragliches Sonderkündigungsrecht, falls der neue Subunternehmer Ihre Compliance-Anforderungen nicht erfüllt.
  5. Audits anfordern: Lassen Sie sich das Recht zusichern, jährlich die relevanten Audit-Reports (z.B. SOC 2, ISO 27001) der entscheidenden Subunternehmer einzusehen.

Das Wichtigste in Kürze

  • Der Serverstandort Deutschland ist keine Garantie für DSGVO-Konformität, solange der Anbieter ein US-Unternehmen ist.
  • Echte Datenhoheit wird durch technische Kontrolle (kundenseitige Verschlüsselung) und strenge vertragliche Regelungen (Exit-Pläne, Subunternehmer-Audits) erreicht.
  • Eine umfassende Compliance-Strategie muss auch interne Risiken wie Schatten-IT und das Fehlen von Löschkonzepten adressieren.

AVV vergessen? Warum Sie für jeden Freelancer und jedes Tool einen Vertrag brauchen (und wer ihn liefert)

Der letzte, aber fundamentalste Baustein jeder Verteidigungsarchitektur ist der Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Dieses Dokument ist die juristische Grundlage für jede Situation, in der ein externer Dienstleister potenziell Zugriff auf personenbezogene Daten hat, die Sie verantworten. Dies betrifft nicht nur den grossen Cloud-Anbieter, sondern jedes einzelne SaaS-Tool, jeden externen IT-Support und jeden Freelancer, der für Sie tätig wird. Ein fehlender oder mangelhafter AVV ist einer der häufigsten und am einfachsten zu ahndenden DSGVO-Verstösse.

Entscheidungsbaum zur Bestimmung der erforderlichen Datenschutzverträge für verschiedene Dienstleister

Ein AVV ist im Grunde eine klare Anweisung an Ihren Dienstleister. Er legt fest, dass der Dienstleister die Daten nur nach Ihrer Weisung verarbeiten darf, dass er angemessene technische und organisatorische Massnahmen (TOMs) zum Schutz der Daten ergreift, dass er Sie bei Datenschutzverletzungen informiert und die Daten nach Vertragsende löscht oder zurückgibt. Wer liefert diesen Vertrag? Grundsätzlich sind Sie als Verantwortlicher dafür zuständig, sicherzustellen, dass ein korrekter AVV vorliegt. In der Praxis stellen die meisten professionellen Dienstleister einen Standard-AVV zur Verfügung. Ihre Aufgabe als IT-Leiter oder DPO ist es, diesen Vertrag sorgfältig zu prüfen und sicherzustellen, dass er alle Anforderungen des Art. 28 DSGVO erfüllt und keine für Sie nachteiligen Klauseln enthält, insbesondere bezüglich der Subunternehmer und der Haftung.

Es ist entscheidend, genau zu differenzieren: Nicht jede Zusammenarbeit erfordert einen AVV. Bei gemeinsamen Projekten mit Partnern, bei denen beide Seiten den Zweck und die Mittel der Verarbeitung festlegen (z.B. ein gemeinsames Marketing-Event), liegt eine gemeinsame Verantwortlichkeit vor. Hier ist eine Vereinbarung nach Art. 26 DSGVO erforderlich. Bei arbeitnehmerähnlichen Freelancern, die eng in Ihre Organisation eingebunden sind, kann eine einfache Verpflichtung auf das Datengeheimnis ausreichen, da sie datenschutzrechtlich wie Mitarbeiter behandelt werden. Der AVV ist der Dreh- und Angelpunkt Ihrer Compliance und schliesst die Risikokette. Ohne ihn sind alle anderen Massnahmen rechtlich haltlos.

Um diese komplexen Strategien in die Praxis umzusetzen, besteht der nächste logische Schritt darin, eine systematische Prüfung Ihrer aktuellen Cloud-Verträge, technischen Konfigurationen und internen Richtlinien durchzuführen. Nur ein ganzheitlicher Ansatz gewährleistet eine robuste und rechtssichere Datenverarbeitung in der Cloud.

Häufig gestellte Fragen zu US-Cloud Act und DSGVO

Wann liegt gemeinsame Verantwortlichkeit vor?

Bei gemeinsamen Events oder Marketingaktionen mit Partnern – hier ist eine Vereinbarung nach Art. 26 DSGVO notwendig, nicht Art. 28.

Was ist bei Scheinselbstständigkeit zu beachten?

Arbeitnehmerähnliche Freelancer werden datenschutzrechtlich wie Mitarbeiter behandelt – kein AVV erforderlich, aber Verpflichtung auf Datengeheimnis.

Rédigé par Kevin Schneider, Fachanwalt für IT-Recht und zertifizierter Datenschutzbeauftragter (TÜV). Er ist spezialisiert auf E-Commerce, Urheberrecht im Internet und die Umsetzung der DSGVO für Unternehmen und Online-Shops.