Datenschutz

Datenschutzfreundliche Voreinstellungen & Co. – Was müssen Softwareanbieter beachten & vor allem nicht beachten

Seit die DSGVO „relevant“ wurde, wurden Softwarehersteller auf einmal von Kunden oder potentiellen Kunden entweder direkt oder indirekt über Fragebögen zum Datenschutz mit dieser Frage konfrontiert:

Wie werden die Vorgaben zum Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen in Ihrer Software umgesetzt?

Mit der Beantwortung dieser Fragen waren schon viele überfordert. Gut war schon, wenn dann bekannt war, dass die Frage auf die Vorgaben von Art. 25 DSGVO abzielt.

Entgegen der ersten Vermutung steht dort jetzt nichts davon, dass Softwarehersteller die Anforderungen von „Datenschutz durch Technikgestaltung“ („Privacy by Design“) und „Datenschutz durch datenschutzfreundliche Voreinstellungen“ („Privacy by Default“). Vielmehr ist primär jetzt erst einmal der „Verantwortliche“ verpflichtet, also derjenige, der die Software praktisch zur Verarbeitung von Daten einsetzt.

Entspannung gab es aber für kundige Softwarehersteller dadurch nicht. Denn auf einmal wurden „Privacy by Design“ und „Privacy by Default“ Kundenanforderung. Bei Kundenanforderung kann ein Softwarehersteller natürlich sofort auf die Idee kommen, dass dies vielleicht auch super als kostenpflichtiges Datenschutz-Feature berechnet werden kann. Die Insider würden sagen: „Jo…das nenne ich mal einen Change Request“. Und der wäre, wenn der Hersteller einen ordentlichen Vertrag zu seinen Gunsten gemacht hat, natürlich dann auch kostenpflichtig.

Aber so einfach ist das nicht. Denn hier spielt ja auch noch das IT-Recht mit hinein. Da stellen sich nämlich spannende Fragen wie z.B.:

  • Hat eine Software, die nicht den Vorgaben von Art. 25 DSGVO entspricht, einen Mangel?
  • Kann ich Gewährleistungsansprüche (bei Kauf) oder z.B. Schadensersatzansprüche aus Werkvertragssrecht geltend machen? Oder vielleicht auch im Falle einer „Miete“ von Software die Vergütung mindern?
  • Abhängig von den vertraglichen Rahmenbedingungen kamen auch schon Unternehmen auf die Idee, sich wegen eines „Mangels“ wegen vermeintlich nicht vorhandener Umsetzung von Art. 25 DSGVO nach Fristsetzung und erfolglosem Fristablauf, die Migrationskosten zu einer anderen Software vom Hersteller ersetzt zu verlangen.

Ich denke, viele IT-Anwälte können von entsprechenden Anfragen ein Lied singen.

Was bedeutet jetzt also dieses „Privacy by Design“ und „Privacy by Default“ für Softwarehersteller konkret?

Richtig ist, dass der Verantwortliche von dem Hersteller einer Software verlangen kann, dass beim Einsatz dieser Software eine Umsetzung der Pflichten nach Art. 25 DSGVO für das einsetzende Unternehmen möglich ist. Es bedeutet aber eben nicht zwingend, dass die Software selbst diese Features von Privacy by Design & Default implementiert haben müsste.

Ausnahmen bestehen aber z.B. häufig bei Ausschreibungen, in denen entsprechende Features verlangt werden. Das ist übrigens z.T. schon vor der DSGVO in einigen Bundesländern zwingend verlangt wurden (so z.B in Schleswig-Holstein).

Was bedeutet denn nun „Privacy by Design“ i.S.d. Art. 25 Abs. 1 DSGVO?

Nach Art. 25 Abs. 1 DSGVO trifft der Verantwortliche sowohl zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung geeignete technische und organisatorische Maßnahmen – wie z. B. Pseudonymisierung –, die dafür ausgelegt sind, die Datenschutzgrundsätze wie etwa Datenminimierung wirksam umzusetzen und die notwendigen Garantien in die Verarbeitung aufzunehmen, um den Anforderungen dieser Verordnung zu genügen und die Rechte der betroffenen Personen zu schützen.

Das alles aber auch unter Berücksichtigung von Implementierungskosten, Schutzbedarf der Daten usw.

Versuchen wir mal, das etwas einfacher zu fassen.

  1. Es gibt also eine Pflicht, technische und organisatorische Maßnahmen (sog. TOMs) zu treffen.
  2. Mit den TOMs sollen die Datenschutzgrundsätze (siehe Art. 5 DSGVO) umgesetzt werden. Außerdem sollen die Maßnahmen „Garantien“ beinhalten, damit die Anforderungen der DSGVO und insbesondere der Betroffenenrechte eingehalten werden können.

Einfacher formuliert heißt das, dass ich meine Datenverarbeitung so gestalten soll, dass ich technische und organisatorische Maßnahmen treffe, die die Einhaltung der Anforderungen der DSGVO und speziell der Betroffenenrechte gewährleisten. That’s it.

Und wenn wir mal ganz ehrlich sind, ist der Regelungsgehalt von „Privacy by Design“ nach Art. 25 Abs. 1 DSGVO insoweit nicht sonderlich hoch. Denn auch so bin ich schon durch andere Regelungen verpflichtet, die DSGVO einzuhalten und auch technische und organisatorische Maßnahmen zum Datenschutz zu treffen. Das ist jetzt also per se nichts Besonderes.

Das einzig Besondere ist dann die zeitliche Komponente, die in Art. 25 DSGVO zum Tragen kommt. Denn sie betrifft nicht nur meine Datenverarbeitung zum Zeitpunkt der Verarbeitung, sondern ich soll auch – und das ist das eigentliche „Design-Element“ bei „Privacy by Design“ – den „Datenschutz“ zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung berücksichtigen. Ich soll also schon z.B. bei der Beschaffung von IT-Systemen und/oder Software und auch bei deren Ausgestaltung die Einhaltung der DSGVO und speziell auch die Betroffenenrechte berücksichtigen.

Und so ist es natürlich nachvollziehbar, dass Softwarehersteller auf einmal diese Fragen zu „Privacy by Design“ erhielten und erhalten.

Für den Softwarehersteller selbst ergibt sich hieraus erst einmal keine spezielle Pflicht. Es gilt gleichwohl natürlich, dass hier mit guten Datenschutz-Features nicht nur Wettbewerbspunkte, sondern auch Karmapunkte gesammelt werden. Ihr lacht…höhnisch vielleicht sogar. Aber jeder gute Vertriebler weiß, dass der Kunde keine Software kauft, weil die Software wirklich gut funktioniert. Er kauft bei „Feature-Parity“ das Produkt, das die besten Gefühle vermittelt. Das ist auch der Grund, warum ich gegenüber meinen Mandanten von mir erstellte „Whitepaper zum Datenschutz“ eines Produktes gerne als „Feel Good Paper“ bezeichne.

Als Softwarehersteller könnt ihr hier punkten, wenn ihr Dinge wie einen flexiblen „Audit Trail“ und gute Berechtigungsfunktionen mit möglichst feingranularer Einstellungen von Benutzerrechten implementiert habt. Auch gut ist natürlich, wenn ihr schon im Vorwege den Anwender unterstützt, indem ihr z.B. vorgefertigte Vorschläge für Angaben für das Verarbeitungsverzeichnis zur Verfügung stellt. Selbst bei System, die „on premise“ – also in der Infrastruktur des Kunden – laufen wird eine Verschlüsselung von Daten immer wichtiger. Also können Hersteller hier an Dinge wie Datenbankverschlüsselung etc. denken.

Sehr gut ist übrigens auch, wenn die Software auch eine Revisor- oder DSB-Rolle unterstützt, die einem Revisor oder dem Datenschutzbeauftragten ermöglicht, über einen reinen Lesezugriff Daten und Protokolle zu sichten. Und zwar auch die der Administratoren.

Es gibt hier aber keine „verbindlichen“ Vorgaben. Bei allen Maßnahmen dürfen und sind stets Stand der Technik, Implementierungskosten, das Risiko und Art und Umfang der Datenverarbeitung zu berücksichtigen.

Und was bedeutet „Privacy by Default“ i.S.d. Art. 25 Abs. 2 DSGVO?

Wenn wir in den Wortlaut von Art. 25 Abs. 2 DSGVO schauen, steht da etwas von geeigneten TOMs, die sicherstellen, dass durch Voreinstellung nur personenbezogene Daten verarbeitet werden, deren Verarbeitung für den jeweiligen bestimmten Verarbeitungszweck erforderlich ist.

Das soll nach dem Wortlaut im Hinblick auf die

  • Menge der erhobenen Daten,
  • den Umfang ihrer Verarbeitung,
  • ihrer Speicherfrist und
  • ihrer Zugänglichkeit

zu treffen sein.

Im Zuge der Diskussionen auf Ebene der EU-Kommission und des EU-Parlaments wurde damals in dem Kontext von „Privacy by Default“ (lang ist’s her…) davon gesprochen, dass z.B. das Benutzerprofil in einem sozialen Netzwerk wegen „Privacy by Default“ auf „geschlossen“ stehen müsse, damit nicht bei Eröffnung des Accounts gleich jeder das Profil des neuen Nutzers einsehen könne.

Das heißt aber übrigens nicht, dass ein soziales Netzwerk dies nicht durch Nutzungsbedingungen vorsehen könnte, wenn nachvollziehbar und in rechtlich zulässigem Rahmen diese „Öffentlichkeit“ genau ein Kernfeature des Netzwerkes und vom Zweck des Netzwerkes gedeckt wäre.

Aber weiter im Programm…
Softwarehersteller können im Bereich Privacy by Default richtig Punkte sammeln. Sie können es aber auch „verhauen“. Und zwar bei den Kunden. Das können wir am Beispiel eines CRM-Softwareherstellers einmal „durchspielen“.

Ein Anbieter einer etablierten „Kundenverwaltung“ hat im Zuge der DSGVO bestimmte Felder, die beim Anlegen eines neuen Kontakts früher automatisch gesetzt wurden – wie z.B. dass der Kunde per E-Mail (z.B. für Werbezwecke) angeschrieben werden darf – so eingerichtet, dass die Felder künftig standardmäßig nicht aktiv sind.

Wenn ein neuer Kontakt angelegt wird, muss der Benutzer also aktiv diese Checkbox im Kundendatensatz aktivieren?

Frage: Ist das nach Art. 25 DSGVO erforderlich?

In diesem Fall hat der Softwarehersteller genau richtig gehandelt. Denn der Anwender der Software hat als Verantwortlicher Sorge dafür zu tragen, dass die Datenverarbeitung den Vorgaben der DSGVO und auch anderer datenschutzrechtlicher Vorschriften wie hier z.B. § 7 UWG (als Umsetzung der ePrivacy-Richtlinie der EU).

Auch wenn es nicht die Pflicht ist, dass der Softwarehersteller sich um diesen Umstand kümmert, unterstützt er den Anwender hier in der richtigen Umsetzung der datenschutzrechtlichen Vorgaben. Vorbildlich.

Nur etwas trübte das Bild. Denn die Kunden des Softwareherstellers waren mit diesen Änderungen zum Teil gar nicht zufrieden. So gab es eine Reihe von Unternehmen, die ihre Kontakte so generieren, dass diese zunächst ein Formular ausfüllen und dort die Auswahl bzgl. E-Mail-Werbung schon treffen. Also jenseits der Software. Und da in den Fällen – ja, die gibt es – in aller Regel nach Angaben der Kunden eine E-Mail-Kommunikation gewünscht ist, führt das „Kreuzchen-Machen“ in der Software zu einem nervigen Mehraufwand.

Jetzt können wir sagen, dass das Unternehmen mit dem Mehraufwand halt leben muss. Muss es rechtlich aber eben nicht. Denn das Unternehmen darf sehr wohl selbst die Entscheidung treffen, wie sie die Maßnahmen von „Privacy by Default“ umsetzt. Und so darf ich als Unternehmen sehr wohl in diesem Bereich, in dem der Schutzbedarf der Daten und das Risiko für den Betroffenen nicht sonderlich hoch ist, auch eine rein organisatorische Maßnahme einsetzen. Und das kann z.B. mein eigenes Papier-Aufnahmeformular sein, das laut „Marketing-Deutsch“ exzellente „Conversion Rates“ hat.

In diesem Szenario haben also beide Recht: Softwarehersteller und Verantwortlicher

Wenn Softwarehersteller in dieser misslichen Situation sind, bietet sich an, mit zwei (oder mehr) Softwareversionen bzw. -varianten zu agieren. So gibt es eine „DSGVO“-Version, die im Hinblick auf Datenschutz optimiert ist und vielleicht eine „Extended“-Variante oder wie auch immer ihr das dann nennen mögt. Gut wäre dann halt nur, wenn die „Standardversion“, wenn es denn eine gibt, die DSGVO-Version wäre.

Übrigens bieten sich für Softwarehersteller noch folgende Maßnahmen zur Umsetzung von „Privacy by Default“ an:

Bei der Gestaltung von Frontend-Interfaces dürft ihr bei Formularfeldern darauf achten, diese nach Möglichkeit auf das Notwendigste zu beschränken. Zumindest bei den Pflichtfeldern. Und diese sollten deutlich gekennzeichnet sein. Wenn die Betroffenen selbst die Eingaben am Frontend machen, wäre es prima, wenn es eine kontextbezogene Erläuterung von Feldern gibt. Also z.B. bei einer Telefonnummer die Angabe, warum man die benötigt oder warum es sinnvoll wäre, diese anzugeben etc.

Vorsicht übrigens mit Freitextfeldern. Nicht, dass die per se nicht zulässig wären. Hier kann ich aber nur dringend empfehlen, dass jedes Freitextfeld auch eine Beschreibung hat. Damit der Zweck des Feldes erkennbar wird. Sonst kann dem Softwarekunden bei einer Prüfung schön um die Ohren fliegen. Jetzt sagt ihr, dass die Aufsichtsbehörden doch sowieso nicht prüfen. Mag sein, aber sie gehen Beschwerden von Betroffenen nach. Und wenn eine Beschwerde sich auf eine Software bezieht, dann habe ich nicht nur einmal Screenshots von Formularmasken an Aufsichtsbehörden senden müssen. Und dann kann das Problem doch noch relevant werden.

Prima ist es auch, wenn die Software bei Löschroutinen unterstützt und z.B. Fristen für die Löschung vorgesehen werden können. Als Anwalt möchte ich leider aus gegebenem Anlass von vollautomatisierten Löschungen abraten, wenn man damit keine „belastbaren“ Erfahrungen hat. So ein Feature will gut getestet sein. Nicht nur ein Rechtsstreit ging verloren, weil der Mandant keine Daten mehr hatte. Aber das ist halt meine „Anwaltsbrille“.

Wenn ihr Benutzer-Rollen vorseht, dann setzt die Recht für die Rolle bitte möglichst restriktiv. Also nur so viele Rechte, wie es für die Rolle wirklich erforderlich ist. Das darf das Unternehmen, das die Software einsetzt, gerne ändern können. Es muss also nicht erzwungen werden. Aber die Standard-Variante sollte restriktiv sein.

Und genau das ist der Spagat, den viele Softwarehersteller jetzt machen müssen. Auf der einen Seite soll der Datenschutz unterstützt werden und auf der anderen Seite können genau diese Features dazu führen, dass Software manchmal „gefühlt“ schlechter zu bedienen ist. Ich glaube, das Entscheidende ist hier, dass der Kunde – soweit möglich – beim „Customizing“ unterstützt wird. Er sollte also leicht die Einstellungen finden, die typischerweise bei den Endanwendern für „Reibung“ und Unmut sorgen. Wenn die Grundeinstellungen dort stimmen, kann Datenschutz auf dienlich sein. Nicht immer, aber eben oft.

Ihr wisst schon…erfolgreich sind in diesem Bereich dann die Softwarehersteller, die die „Extra-Meile“ gehen.

Ähnliche Beiträge