UPDATE: Der nachfolgende Beitrag bezieht sich auf die Rechtslage vor dem 25. Mai 2018. Einen aktuellen Beitrag zur Einhaltung der Anforderungen der Datenschutzgrundverordnung (DSGVO) durch SaaS-Anbieter und andere Auftragsverarbeiter finden Sie in meinem Praxisleitfaden unter www.complyvacy.com/dsgvo-kit

Obwohl sich Software as a Service (SaaS) immer größerer Beliebtheit erfreut, herrscht noch viel Unsicherheit und zum Teil Unkenntnis im Hinblick auf die datenschutzrechtlichen Anforderungen. Kaum ein SaaS-Vertrag, den ich zur Prüfung oder Überarbeitung erhalten habe, erfüllte die Vorgaben des neuen § 11 Bundesdatenschutzgesetz (BDSG). Kunden aber auch Anbieter dürfen sich der Materie nicht verschließen.

Nach dem BDSG bleibt der Kunde für die Rechtmäßigkeit der Verarbeitung seiner Mitarbeiter- und Kundendaten durch den SaaS-Anbieter voll verantwortlich und ist verpflichtet, den Anbieter sorgfältig auszuwählen, regelmäßig zu kontrollieren und das Ergebnis der Kontrollen zu dokumentieren. Das BDSG enthält zudem seit dem 1. September 2009 einen 10-Punkte Katalog mit Regelungsgegenständen, die in einem schriftlichen Vertrag zur Auftragsdatenverarbeitung zwingend umgesetzt werden müssen. Bei mangelhaften Verträgen drohen Kunden Bußgelder bis zu € 50.000.

Aber auch Anbieter sollten darauf achten, dass Ihre Standardvertragsbedingungen (AGB) den gesetzlichen Anforderungen genügen. Leider ignorieren noch immer viele Anbieter die datenschutzrechtlichen Compliance Anforderungen ihrer Kunden. Dabei würden SaaS-Provider, deren AGB den Vorgaben des BDSG genügen, bei potentiellen Kunden und deren Datenschutzbeauftragten leicht Pluspunkte sammeln; oder anders gesagt: wessen AGB den gesetzlichen 10-Punkte Katalog ignorieren, fällt oftmals schon von vorne herein heraus, weil sich der Kunde nicht auf mühsame Vertragsverhandlungen einlassen will.

Sie snd Anbieter von Software as a Service oder anderen Cloud-Diensten? Dann lesen auch meine Broschüre "Haftung und Gewährleistung für Software - mit diesen Tipps reduzieren Sie ihr Risiko als IT-Anbieter"

Umsetzung des 10-Punkte Katalogs für die Auftragsdatenverarbeitungs (§ 11 BDSG) bei Software as a Service (SaaS) Verträgen 

In der Tabelle unten habe ich einige Punkte zusammengestellt, wie die Anforderungen des § 11 BDSG im Rahmen von SaaS-Verträgen praktisch umgesetzt werden können. Anregungen, Kommentare und Kritik sind herzlich willkommen. Wenn Sie Fragen haben oder einen Vertrag prüfen, überarbeiten oder entwerfen lassen wollen, kontaktieren Sie mich gerne.

Die Tabelle ist zugeschnitten auf Software as a Service Verträge, bei denen die zur Verfügung gestellte Anwendung stark standardisiert ist, d.h. es können für jeden Mandanten individuelle Parametrisierungen vorgenommen werden, in der Regel erfolgen aber keine kundenspezifischen Änderungen am Service selbst. Die Regelungsvorschläge erfolgen unter besonderer Berücksichtigung der Sondersituation der SaaS-Anbieter bei gleichzeitiger Erfüllung der Compliance Voraussetzungen (§ 11 BDSG) der Kunden.

Behandelt wird nur der Teil der Auftragsdatenverarbeitung in einem SaaS-Vertrag. Daneben sind im SaaS-Vertrag noch eine Reihe weiterer Vertragsbedingungen auf die Sondersituation bei SaaS hin auszugestalten (z.B. Anwendung mietrechtlicher Regelungen nach der ASP-Rechtsprechung des BGH, Service Levels, Haftung, Service-Beschreibung etc.).

Abgrenzung von Auftragsdatenverarbeitung und "Funktionsübertragung" bei SaaS

Der 10-Punkte Katalog zur Auftragsdatenverarbeitung nach § 11 BDSG ist natürlich nur einschlägig, wenn tatsächlich personenbezogene Daten im Auftrag verarbeitet werden. Personenbezogene Daten wie z.B. Mitarbeiter- oder Kundendaten werden bei den meisten SaaS Anwendungen verarbeitet, bereits das Speichern solcher Daten ist ein verarbeiten. Ausnahme: es handelt sich um rein technische Daten (Bauzeichnungen) oder die Daten wurden anonymisiert, so dass der Anbieter keinerlei Rückschluss auf bestimmte Personen ziehen kann.

Keine Auftragsdatenverarbeitung liegt vor, wenn der Anbieter die Daten nicht nach den Weisungen des Kunden verarbeitet, sondern seinerseits verantwortliche Stelle ist. Dies ist der Fall bei einer so genannten "Funktionsübertragung". Die Abgrenzung zwischen Auftragsdatenverarbeitung und Funktionsübertragung ist mitunter fließend und - nach umstrittener Ansicht - in gewissem Umfang auch von den Parteien durch vertragliche Regelungen beeinflussbar.

Teilweise wird beim SaaS wie auch beim Outsourcing versucht, ein Anbieter-Kunden Verhältnis als Funktionsübertragung auszugestalten, um so den strengen Anforderungen des § 11 BDSG zu entgehen. Juristisch steckt Folgendes dahinter: Sendet ein Unternehmen (SaaS-Kunde) personenbezogene Daten an einen "Dritten" (SaaS-Anbieter), oder gewährt diesem darauf Zugriff, so liegt ein "Übermitteln" im Sinne des § 3 (4) Nr. 3 BDSG vor. Eine solche Übermittlung ist nur zulässig, wenn hierfür eine Erlaubnisnorm existiert. Verarbeitet der Dritte hingegen personenbezogene Daten strikt nach den Weisungen (im Auftrag) des Kunden, so ist er "Auftragsdatenverarbeiter" und nach der Definition des § 3 (8) S. 2 BDSG kein "Dritter" mehr. Folge: Es findet rechtlich keine "Übermittlung" statt, womit für diese auch keine Erlaubnisnorm mehr benötigt wird (die Datenverarbeitung im Rahmen der SaaS-Anwendung selbst, muss natürlich weiterhin datenschutzrechtlich zulässig sein).

Der Auftragsdatenverarbeiter ist nach der Vorstellung des Gesetzes so eng an den Kunden gebunden, dass er datenschutzrechtlich eine Art interne Abteilung des Kunden darstellt. Dies setzt aber voraus, dass mit dem Auftragsdatenverarbeiter ein Vertrag geschlossen wird, der den Anforderungen des § 11 BDSG genügt. Vor dem Hintergrund diverser öffentlich bekannt gewordener Datenschutzpannen hat der Gesetzgeber mit Wirkung zum 1. September 2009 die inhaltlichen Anforderungen an Verträge zur Auftragsdatenverarbeitung verschärft.

Die Auftragsdatenverarbeitung ist seitdem etwas unpopulär und man versucht mitunter darauf zu verzichten und stattdessen auf Basis einer Datenübermittlung eine Datenschutz-Compliance sicherzustellen. Doch dieser Lösungsansatz hat Nebenwirkungen:

1. Ohne Auftragsdatenverarbeitung liegt eine "Übermittlung" von Daten an den Anbieter vor, die einer Erlaubnisnorm bedarf. Als Erlaubnisnorm stützt man sich häufig auf die Interessensabwägungsklausel des § 28 (1) Nr. 3 BDSG. Um eine Übermittlung nach dieser Vorschrift "hinzubekommen" müssen aber oft Regelungen zum Schutz der Interessen der Betroffenen (Mitarbeiter, Kunden) getroffen werden, und hierfür braucht man dann wieder vertragliche Regelungen, die zum Teil denen einer Auftragsdatenverarbeitung ähneln.
2. Eine Rechtfertigung nach der Interessensabwägungsklausel funktioniert nicht mehr, wenn "besondere Arten von Daten" im Sinne des § 3 (9) BDSG (z.B. Daten zur Gesundheit, Gewerkschaftszugehörigkeit etc.) im Raum stehen, was leider häufig der Fall ist bzw. nicht ausgeschlossen werden kann.
3. Wenn das Verhältnis der Parteien einer Auftragsdatenverarbeitung ähnelt, wirkt die Übermittlungs-Lösung etwas gekünstelt oder besser gesagt: ihr haftet der "Makel" an, es handle sich um eine Umgehung der gesetzlichen Anforderungen für eine Auftragsdatenverarbeitung. Damit will ich nicht sagen, dass die Übermittlungs-Lösung kein gangbarer Weg ist. Ich habe aber schon mehr als einmal erlebt, das der Datenschutzbeauftragte beim Kunden ein solches Modell nicht "durchschaut" und auf einem Auftragsdatenverarbeitungsvertrag besteht.
4. Das Übermittlungsmodell erspart dem Anbieter zwar die Einhaltung von § 11 BDSG, diesen Vorteil erkauft er sich aber dadurch, dass er als Datenempfänger mitverantwortlich für die Rechtmäßigkeit der Datenverarbeitung wird, was nach meiner Meinung ein nicht zu unterschätzender Nachteil ist.
5. Was gerne übersehen wird: Das Übermittlungsmodell sprengt die Kette von Auftragsdatenverarbeitungsverhältnissen. Verarbeitet der Kunde die Daten seinerseits für einen Dritten, mit dem er ein Auftragsdatenverarbeitungsverhältnis geschlossen hat, kann er regelmäßig einem Übermittlungsmodell nicht zustimmen. Beispiel: Ein Callcenter übernimmt für einen TK-Anbieter den Kundensupport, hierfür erhält das Callcenter Kundendaten des TK-Anbieters, die es typischerweise als Auftragsdatenverarbeiter verarbeitet. Das Callcenter will nun eine Software im Wege des SaaS Modells nutzen, um die Kundendaten zu verwalten. Dies ist nur möglich, wenn der SaaS Anbieter seinerseits Auftragsdatenverarbeiter ist, da der Vertrag zwischen Callcenter und TK-Anbieter in der Regel vorsieht, dass die Daten nur an Subunternehmer weitergegeben werden, die die Daten im Auftrag des Callcenters verarbeiten (und mindestens das gleiche Schutzniveau vorsehen, wie der Vertrag TK-Anbieter/Callcenter).

Der Verzicht auf eine Auftragsdatenverarbeitung (Übermittlungs-Lösung) ist also nicht der Königsweg und sollte vorher sorgfältig geprüft werden. In ihrer Stellungnahme zum "Cloud Computing und Datenschutz", geht auch die Datenschutzaufsichtsbehörde für Schleswig-Holstein davon aus, dass Cloud Computing technisch einer Auftragsdatenverarbeitung gleich kommt.

Auslandsbezug

Die Auftragsdatenverarbeitung nach § 11 BDSG ist einschlägig, wenn der Sitz des Kunden (Verantwortliche Stelle) in Deutschland liegt und der Anbieter (Vertragspartner) ebenfalls seinen Sitz in Deutschland oder einem anderen Mitgliedstaat der EU oder des Europäischen Wirtschaftsraumes (EWR) hat.

Sitzt die Vertragspartei auf Anbieterseite außerhalb der EU / des EWR gilt § 11 BDSG nicht mehr, sodass nach dem Wortlaut des Gesetzes eine zu rechtfertigende Daten-"Übermittlung" stattfindet. Dies hat nunmehr auch die Datenschutzbehörde von Schleswig-Holstein in der genannten Stellungnahme zum Cloud-Computing zum Ausdruck gebracht.

Zudem müssen in diesen Fällen des EU-Datenexports regelmäßig zusätzliche Vereinbarungen getroffen werden, um ein ausreichendes Datenschutzniveau beim Anbieter im Ausland sicherzustellen. Hierbei spielen die EU Standardvertragsklauseln eine wichtige Rolle, für die seit dem 15. Mai 2010 eine neue Fassung gilt. Hierzu verweise ich auf meinen Beitrag, der Hintergrund und Änderung der EU Standardvertragsklauseln erläutert.

Tabelle: Umsetzung des 10-Punkte Katalogs des § 11 BDSG bei der Auftragsdatenverarbeitung durch SaaS-Anbie

§ 11 (1), § 11 (3) 1 BDSG: Weisungsgebundenheit

• Verarbeitung personenbezogener Daten erfolgt im Auftrag und nach den Weisungen des Kunden - Inhalt und Umfang der Weisungsbefugnis sind SaaS-spezifisch zu konkretisieren (siehe unten)
• Klarstellung: Kunde bleibt für Rechtmäßigkeit der Verarbeitung verantwortlich
• ggf. Freistellungspflicht des Kunden, falls Betroffene gegen SaaS-Anbieter mit der Behauptung vorgehen, personenbezogene Daten würden rechtswidrig verarbeitet oder genutzt

§ 11 (2) 2 Nr. 1 BDSG: Gegenstand und Dauer des Auftrags

• Gegenstand: "Software as a Service" Hosting, Wartung, Betrieb und zur Verfügungstellung zum Online-Abruf einer bezeichneten Anwendung
• ggf. Beratung (Migration, Parametrisierung) und Anpassung (Customization)
• Dauer: Laufzeit des Vertrages, ggf. erweitert um Testphase/Migrationsphase

§ 11 (2) 2 Nr. 2 BDSG: Umfang, Art und Zweck der vorgesehenen Erhebung, Verarbeitung oder Nutzung von Daten, Art der Daten und Kreis der Betroffenen

• Art der Daten und Kreis der Betroffenen:
  • allgemein umschreiben; verhindern, dass bei kleineren Service-Änderungen Vertragsanpassungen nötig sind
  • ggf. Klarstellung, ob besondere Arten von Daten umfasst werden/ausgeschlossen sind
  • ggf. Hinweis auf Verantwortung des Kunden für Daten, die dem Berufsgeheimnis unterliegen, § 203 StGB (z.B. Rechtsanwälte, Ärzte, bestimmte Versicherungen)
• Umfang, Art und Zweck der Datenverwendung:
  • Allgemeiner Verweis auf Zweck der Anwendung, Funktionsbeschreibung, Zugriffsberechtigungssystem
  • Detailliertere Darstellung bei
    • besonderen Arten von Daten im Sinne des § 3 (9) BDSG (z.B. gesundheitsbezogene Daten)
    • Daten/Verarbeitungsschritten, die für den Kunden unternehmenskritisch sind (z.B. Finanzdaten)
    • Daten/Verarbeitungsschritten, die ein besonders hohes Risiko für Betroffene beinhalten (z.B. Export von Daten, externe Schnittstellen/APIs)
  • Datenempfänger festlegen (z.B. Zugriff durch Drittanbieter, die optionale Zusatzmodule für den Service bereitstellen; andere Service-Anbieter bei SOA; Subunternehmer)
  • Speicherorte/Serverstandorte positiv festlegen (Whitelist, z.B. nur EU/EWR) oder ausschließen (Blacklist)

§ 11 (2) 2 Nr. 3 BDSG: Nach § 9 BDSG zu treffenden technischen und organisatorischen Maßnahmen

• Anbieterspezifische Regelung (Sicherheitskonzept) in gesonderter Anlage (für SaaS besonders relevante Aspekte werden noch in einer gesonderten Übersicht zur Verfügung gestellt)
• Sicherheitskonzept sollte die in der Anlage zu § 9 BDSG genannten Punkte abbilden
• ggf. ergänzender Verweis auf IT-Sicherheitsstandards

§ 11 (2) 2 Nr. 4 BDSG: Berichtigung, Löschung und Sperrung von Daten

• Berichtigung, Löschung und Sperrung der Daten durch den Auftraggeber erfolgt in der Regel im Rahmen der allgemeinen Bedienung/Nutzung der Anwendung durch den Kunden
• Pflichtverletzung / Zahlungsverzug des Kunden
  • Sperrung oder Löschung von Daten nur nach rechtzeitiger vorheriger schriftlicher Androhung
  • Löschung nur wenn Kunde Daten zurückerhalten konnte oder wenn bei Treuhänder hinterlegt wird

§ 11 (2) 2 Nr. 5 BDSG: Nach § 11 (4) BDSG bestehenden Pflichten des Auftragnehmers, insbesondere von ihm vorzunehmenden Kontrollen

• Pflicht des Auftraggebers zur Verpflichtung auf das Datengeheimnis, § 5 BDSG, zur Sicherstellung von technischen und organisatorischen Maßnahmen nach § 9 BDSG und zur Beachtung von Weisungen.
• Kontrolle der technischen und organisatorischen Maßnahmen ggf. durch Vorlage aktueller Prüfberichte unabhängiger Organisationen vereinheitlichen

§ 11 (2) 2 Nr. 6 BDSG: Etwaige Berechtigung zur Begründung von Unterauftragsverhältnissen

• Cloud Umgebungen und multi-tenancy Modell verlangen flexible Einschaltung von Subunternehmern durch Anbieter
• Typische Subunternehmer:
  • Konzerngesellschaften des Anbieters, die die eigentliche technische Leistung erbringen
  • externe Infrastruktur- und Plattformanbieter, auf die die Anwendung aufsetzt (Speicherplatz, Rechnerinstanzen, Datenbankanbieter, Anwendungshosting-Umgebungen)
  • Bei Prüfungs- und Wartungstätigkeiten (§ 11 Abs. 5) genügt unter Umständen abgeschwächte Regelung zur ADV.
• Einschaltung ohne Einzelzustimmung des Kunden zulässig, wenn folgende Voraussetzungen kumulativ erfüllt sind:
  • Anbieter schließt mit Subunternehmer ADV, der das gleiche Schutzniveau sicherstellt, wie der Vertrag mit dem Kunden, insbesondere bzgl. technischer und organisatorischer Sicherheits-Maßnahmen, ggf. Eckpunkte für Sub-ADV festlegen
  • Ausübung der Kontrollrechte durch Kunde ist gegenüber Subunternehmer grundsätzlich möglich (zumindest über Anbieter)
  • Auf Anfrage des Kunden werden diesem Subunternehmer und datenschutz-wesentliche Vertragsbedingungen des Sub-ADV mitgeteilt
  • Bei Subunternehmern außerhalb der EU/des EWR wird ein ausreichendes Datenschutzniveau sichergestellt
    • ggf. hier Mitteilung oder Vorabzustimmung des Kunden nötig
    • ggf. Einschränkung / Ausschluss bestimmter Länder
  • Bei Service-orientierer Architektur (SOA): Klarstellen, dass Services anderer Anbieter, mit denen die SaaS Anwendung zusammenarbeitet, keine Subunternehmer des Anbieters sind

§ 11 (2) 2 Nr. 7 BDSG: Kontrollrechte des Auftraggebers und entsprechende Duldungs- und Mitwirkungspflichten des Auftragnehmers

• Multi-Tenancy Modell erfordert, dass Anbieter nicht durch ständige Kontrollen der Vielzahl von Kunden unangemessen belastet wird
• Grundsätzliches Kontrollrecht des Kunden bzgl. Einhaltung der technischen und organisatorischen Schutzmaßnahmen vor Ort, außer Anbieter legt regelmäßig geeignete Testate unabhängiger Dritter oder des internen Datenschutzbeauftragten vor
• Recht zur anlassbezogenen Einzelprüfung bleibt unberührt (Kostentragungspflicht regeln)
• Unterstützung des Kunden bei dessen Dokumenationspflicht, § 11 (2) 3 BDSG

§ 11 (2) 2 Nr. 8 BDSG: Mitzuteilende Verstöße des Auftragnehmers oder der bei ihm beschäftigten Personen gegen Vorschriften zum Schutz personenbezogener Daten oder gegen die im Auftrag getroffenen Festlegungen

• Meldepflicht darf durch schwammige Formulierungen nicht ausufern:
  • Nur Verstöße meldepflichtig, nicht "Verdacht" oder "Unregelmäßigkeiten"
  • Nur Verstöße meldepflichtig, bei denen personenbezogene Daten des konkreten Kunden betroffen waren.
  • Verstöße "gegen die im Auftrag getroffenen Festlegungen" nur meldepflichtig, wenn Bagatellgrenze überschritten (konkretes Risiko)
• Mitteilungs- und Unterstützungspflicht jedenfalls dann, wenn die Voraussetzungen der gesetzlichen Meldepflicht erfüllt vorliegen § 42a BDSG (Security Breach Notification Obligation).

§ 11 (2) 2 Nr. 9 BDSG: Umfang der Weisungsbefugnisse, die sich der Auftraggeber gegenüber dem Auftragnehmer vorbehält

• Allgemein: Aufgrund multi-tenancy Architektur klare Eingrenzung der Weisungsbefugnisse des Kunden nötig, da Einzelweisungen verschiedener Kunden unter Umständen nicht oder nur mit unverhältnismäßigem Aufwand abbildbar sind.
• Einschränkung:
  • Ausübung der Weisungsbefugnisse durch den Kunden erfolgt grundsätzlich im Rahmen der Parametrisierung/Bedienung/Nutzung der Anwendung
  • Darüber hinausgehende Weisungsbefugnisse ausdrücklich und abschließend regeln (z.B. im Rahmen der Test-, Migrations- oder Parametrisierungsphase)
  • Weisungsfreiheit: Berechtigung des Anbieters, Dienst angemessenem fortzuentwickeln und anzupassen, ggf. Recht des Kunden zur Kündigung bei ihn benachteiligenden Änderungen
• Bei Weisungen, deren Umsetzung aufgrund der multi-tenancy Architektur nicht möglich oder nur mit unverhältnismäßigen Aufwand möglich sind, Aufwandsentschädigungspflicht des Kunden oder Kündigungsrecht des Anbieters
• Hinweispflicht des Anbieters bei vermeintlich rechtswidrigen Weisungen, § 11 (3) 2 BDSG

§ 11 (2) 2 Nr. 10 BDSG: Rückgabe überlassener Datenträger und Löschung beim Auftragnehmer gespeicherter Daten nach Beendigung des Auftrags

• Regelung zu Zeitpunkt, Form, Unterstützungspflichten und Kosten der Rückgabe personenbezogener Daten
  • Zeitpunkt: Live-Daten spätestens zum Zeitpunkt des Vertragsendes, ggf. schon vorab für Backup-, Migrations- oder Testzwecke
  • Form: Format und Struktur der Daten, Art des Datenträgers, Schnittstellenbeschreibung festlegen
  • Unterstützungspflichten: bei Migration zu anderen Anbietern oder In-Housing regeln
  • Kosten: Offenlegung etwaig entstehender Kosten der Datenrückgabe
• Bestätigung der Löschung der Daten bei Anbieter und ggf. Subunternehmern