Zum Inhalt springen Zur Navigation springen
Software mit Echtdaten testen – Geht das unter der DSGVO?

Software mit Echtdaten testen – Geht das unter der DSGVO?

Ist eine Software oder Datenbankanwendung erstellt worden (oder „implementiert“), wird sie irgendwann zur Nutzung freigegeben bzw. eingesetzt (oder „produktiviert“). Doch vorher folgt das Testen – natürlich DSGVO-konform. Was das genau bedeutet und ob auch ein Test mit Echtdaten möglich ist, lesen Sie hier.

Welche Grundsätze der DSGVO müssen bei Softwaretests beachtet werden?

Um die DSGVO-Konformität einer Softwaretestung zu gewährleisten, müssen insbesondere die entsprechenden Datenschutz-Grundsätze gem. Art. 5 DSGVO eingehalten werden. Außerdem kommt es darauf an, im Rahmen der IT-Sicherheit angemessene technische und organisatorische Maßnahmen (siehe Art. 32 DSGVO) für den Softwaretest sicherzustellen.

Datenschutzgrundsätze: Zweckbindung & Grundsatz der Datenminimierung

Bei der Softwaretestung ist der Grundsatz der Zweckbindung von besonderer Relevanz. Dieser besagt, dass jeder Verarbeitung ein bestimmter Zweck zugrunde gelegt werden muss, der bereits im Vorfeld der Verarbeitung zu bestimmen ist. Eine spätere Weiterverarbeitung der Daten zu anderen als den festgelegten Zwecken ist grundsätzlich nicht erlaubt.

Aber es gibt mit Art. 6 Abs. 4 in der DSGVO eine Vorschrift, die quasi als Ausnahme zu dem Zweckbindungsgrundsatz eine Zweckänderung durchaus ermöglicht, wenn die neuen Zwecke mit den ursprünglichen Verwendungszwecken „vereinbar“ sind (= „Kompatibilitätsprüfung“). Zu beachten ist, dass die Vorschrift nicht anwendbar ist, wenn Rechtsgrundlage der ursprünglichen Verarbeitung Art. 6 Abs. 1 lit. a DSGVO ist. Bezüglich der Softwaretestung ist nun anhand der Kriterien aus Art. 6 Abs. 4 DSGVO zu prüfen, ob dieser neue Verarbeitungszweck vereinbar mit dem ursprünglichen Verarbeitungszweck ist.

Meinungsstreit über Erfordernis einer neuen Rechtsgrundlage für neuen Verarbeitungszweck

Jedoch führt ein weiterhin herrschender, dogmatischer Meinungsstreit zu Art. 6 Abs. 4 DSGVO über die Erforderlichkeit einer neuen Rechtsgrundlage für den jeweils neuen Verarbeitungszweck zu teilweise konträren Ergebnissen hinsichtlich der Rechtmäßigkeit von speziellen Verarbeitungen, was die Anwendung der Vorschrift erheblich erschweren kann.

Geht man davon aus, dass eine zusätzliche Rechtsgrundlage für die neue Verarbeitung erforderlich ist, hat nach Feststellung der „Vereinbarkeit“ die Prüfung zu erfolgen, ob für die Softwaretestung mit Echtdaten die Voraussetzungen von Art. 6 Abs. 1 lit. f DSGVO vorliegen, da eine andere Rechtsgrundlage in der Regel nicht ersichtlich sein wird. Im Rahmen der Prüfung der „Erforderlichkeit“ in diesem Zusammenhang muss eine Begründung des Einsatzes der Klardaten für die Testung im Gegensatz zur Testung mit anonymisierten Daten angebracht werden können, ansonsten darf die Testung mit Klardaten nicht erfolgen.

Wenn allerdings in dem oben genannten Meinungsstreit, die die Auffassung vertreten wurde, dass eine zusätzliche Rechtsgrundlage nicht erforderlich ist, hat der Aspekt der „Erforderlichkeit“ über den allgemeinen weiteren Grundsatz der Datenminimierung trotzdem Beachtung zu finden. Nach diesem Grundsatz müssen die personenbezogenen Daten, die verarbeitet werden, dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein.

Daraus ergibt sich, dass auf jeden Fall eine Testung mit personenbezogenen, nicht anonymisierten Daten (= „Echtdaten“) nur nach Prüfung im Einzelfall zulässig sein kann.

IT-Sicherheit: DSGVO fordert angemessene ToM

Eines vorweg: Zu den technischen und organisatorischen Maßnahmen i.S.d. Art. 32 DSGVO gehört stets auch die Trennung von Test- und Produktivsystem (siehe beispielhaft Auflistung der ToM des BayLDA, S. 8), ohne die es niemals geht.

Sollte mit Echtdaten getestet werden, so ist aus datenschutzrechtlicher Sicht festzustellen, dass natürlich innerhalb des Testsystems dieselben Maßstäbe an die technischen und organisatorischen Maßnahmen gestellt werden müssen wie in dem Produktivsystem. Es darf kein „weniger“ an Schutz für die Testdaten geben, denn diese sind halt keine „Fake-Daten“, sondern echte personenbezogene Daten. Auch hier gelten daher die Vorgaben des Art. 32 DSGVO.

Von besonderer Wichtigkeit sind hier dezidierte Regelungen dazu, wer im Laufe des Projektes einen Zugriff auf die Daten nehmen, kann (Berechtigungskonzept) und an wen bzw. zu welchen Zwecken die Daten ggf. weitergegeben werden. Zudem sollte die Einbindung externer Dienstleister und / oder Softwareentwickler mit Maßnahmen flankiert werden, zu beachten ist auch der ggf. notwendige Abschluss eines Vertrags zur Auftragsverarbeitung gem. Art. 28 DSGVO.

Zu dem Thema IT-Sicherheit bzw. spezielle Ausgestaltung der ToM in der Testumgebung können weiterhelfen

  • der Baustein „Software-Tests und -Freigaben“ aus dem BSI Grundschutzkompendium,
  • die Bitkom-Handreichung „Anonymisierung und Pseudonymisierung von Daten für Projekte des maschinellen Lernens“ (S. 87)
  • sowie eine ältere Orientierungshilfe zum Thema „Datenschutz und Datensicherheit in Projekten: Projekt- und Produktivbetrieb“ des Arbeitskreises „Technische und organisatorische Datenschutzfragen“ der Konferenz der DSK.

Wieso kann es notwendig sein, Software mit Echtdaten zu testen?

Eine Softwaretestung lässt sich grundsätzlich in mehrere Teststufen einteilen. Vor dem Hintergrund der obigen Ausführungen zur notwendigen DSGVO-Konformität der Testung ist davon auszugehen, dass für die ersten Testungen neuer Software (z.B. für die einzelner Module der Software oder deren Zusammenwirken) Originaldaten noch nicht erforderlich sind.

Erst wenn alle vorherigen Teststufen kaum noch Fehler ausweisen, kann ein Test mit Echtdaten überhaupt in Betracht kommen. Hier wird lediglich noch überprüft, ob alle real auftretenden Sonderfälle auch von der entwickelten Software berücksichtigt werden – ein Test, der ohne die Echtdaten unmöglich ist, sodass die „Erforderlichkeit“ gegeben ist. Diese Testung mit Echtdaten ist dann außerdem auf das erforderliche Maß reduziert – nämlich auf die Prüfung darauf, dass die Software die Daten ohne Fehlermeldung durchläuft.

LAG zur Nutzung von Beschäftigtendaten, um HR-Software zu testen

Zum Testen von Software mit Mitarbeiterdaten hat das LAG Baden-Württemberg mit seiner Entscheidung vom 25.02.2021 (17 Sa 37/20) Arbeitgebern sehr klare Vorgaben gemacht.

Was war vorgefallen?

Im Kern des Streits ging es darum, dass der Kläger, ein Betriebsratsvorsitzender, seinem Arbeitgeber vorgeworfen hatte, seine Personaldaten rechtswidrig für eine Testung des cloudbasierten Personalinformationssystems „Workday“ zu verarbeiten, das neu eingeführt werden sollte.

Innerhalb des Konzerns, dessen Konzernmutter in den USA sitzt, sollte die HR-Software „Workday“ eingesetzt werden. Vor Gültigkeit der DSGVO im Jahr 2017 übermittelte der Arbeitgeber eine Tochtergesellschaft auf die Sharepoint-Seite des Mutterkonzerns bereits Beschäftigtendaten, um Workday mit diesen Daten zu befüllen (Gehalt, Privatanschrift, SV-Nummer, Steuer-ID, etc.). Es gab zu diesem Vorgang zwar Betriebsvereinbarungen, die allerdings nicht sämtliche Daten umfassten, die transportiert wurden. Parallel dazu wurden die Daten in dem bisherigen SAP-System verarbeitet. Die dublizierten Daten wurden also zur Testung in „Workday“ eingestellt.

Der Kläger hielt diese Verarbeitungsvorgänge bezüglich der über die Betriebsvereinbarung hinausgehenden Daten für rechtswidrig und erhob eine Klage auf Schadensersatz gem. Art. 82 DSGVO.

Hohe Anforderungen an Erforderlichkeit bei Softwaretest mit Echtdaten

Das Gericht prüfte zunächst, ob § 26 BDSG als Rechtsgrundlage für die Verarbeitung der betreffenden, zu Testzwecken transferierten Daten herangezogen werden konnte, stellte in diesem Zusammenhang allerdings fest, dass es hier an entsprechender „Erforderlichkeit“ der Verarbeitung für die Durchführung des Arbeitsverhältnisses fehle, da eben lediglich getestet werden sollte.

Schließlich blieb Art. 6 Abs. 1 lit. f DSGVO als mögliche Rechtsgrundlage für die Datenverarbeitung zu Testzwecken. Doch auch hier sah das Gericht das Kriterium der „Erforderlichkeit“ als nicht erfüllt an. Das Gericht wird deutlich, wenn es betont (Rz. 76):

„Mildere Mittel, um das System zu testen, wäre in jedem Fall die Verwendung von Daten fiktiver Beschäftigter („Max Mustermann“) gewesen. Hätte die Beklagte eine Vielzahl von fiktiven Beschäftigten mit entsprechenden fiktiven personenbezogenen Daten in ihrem System angelegt, wäre in gleicher Weise ein Testlauf möglich gewesen.“

Und weiter:

„Jedenfalls ist das von der Beklagten angedeutete Vorbringen zu Testzwecken hätten Echtdaten verwendet werden müssen, nicht mit einem konkreten Vorbringen der maßgeblichen (technischen und organisatorischen) Zusammenhänge nachvollziehbar gemacht.“

Beide Normen scheiden als Rechtsgrundlage für die Softwaretestung im vorliegenden Fall damit aus.

Betriebsvereinbarung als mögliche Rechtsgrundlage

Nach alledem blieb im vorliegenden Fall lediglich die Betriebsvereinbarung i.S.d. § 26 Abs. 4 BDSG als einzig denkbare Rechtsgrundlage für den Testbetrieb der Software „Workday“ mit Echtdaten von Arbeitnehmern. Daten, auf die sich die Betriebsvereinbarung nicht bezog, hätten daher nicht zu Testzwecken verarbeitet werden dürfen.

Auftragsverarbeitung und Übermittlung in Drittländer

Wie oben bereits angesprochen, handelt es sich bei der Softwareentwicklung oft um eine Form der Auftragsverarbeitung, sodass entsprechende datenschutzrechtliche Anforderungen zu beachten sind bzw. demnach ist ein Vertrag zur Auftragsverarbeitung gem. Art. 28 DSGVO zu schließen.

Auch ein Drittlandstransfer kann vorliegen, sodass ggf. auch diesbezüglich datenschutzrechtliche Voraussetzungen, an dessen Gestaltung (wie ein Abschluss von Standardvertragsklauseln und die Durchführung eines Transfer Impact Assessment) zu erfüllen sind.

Nach Ende des Softwaretests unbedingt die Daten löschen

In der Vergangenheit kam es immer wieder dazu, dass Daten nach Ende von Tests mit Echtdaten nicht (richtig) gelöscht wurden und darauf im Rahmen einer Datenpanne die Aufsichtsbehörden aufmerksam wurden – mit entsprechenden Konsequenzen bis hin zu einer Meldepflicht.

DSGVO-Konformität im Testsystem

Soll Software rechtssicher mit Echtdaten getestet werden, ist zunächst einmal maßgeblich, dass dies ganz grundsätzlich in einem separierten Testsystem zu Geschehen hat – das heißt außerdem, dass die Echtdaten kopiert und nicht im Original benutzt werden.

Abgesehen davon sind die wichtigsten Voraussetzungen für eine DSGVO-Konformität des Tests mit Echtdaten, dass die Voraussetzungen des Art. 6 Abs. 1 DSGVO und der Zweckänderung gem. Art. 6 Abs. 4 DSGVO vorliegen, dass der Test nicht ohne Echtdaten möglich wäre und dass angemessene technische und organisatorische Maßnahmen i.S.d. Art. 32 DSGVO in der separaten Testumgebung installiert sind.

Geht es um den Test einer Software unter dem Einsatz von Echtdaten Beschäftigter, so dürfte in der Regel als erforderliche Rechtsgrundlage für die Testung eine Betriebsvereinbarung infrage kommen, § 26 Abs. 1 BDSG scheidet grundsätzlich aus, die Erfolgsaussichten von Art. 6 Abs. 1 lit. f DSGVO als Rechtsgrundlage können sich als schwierig erweisen.

Informieren Sie sich über unsere praxisnahen Webinare
  • »Microsoft 365 sicher gestalten«
  • »Informationspflichten nach DSGVO«
  • »Auftragsverarbeitung in der Praxis«
  • »DSGVO-konformes Löschen«
  • »IT-Notfall Ransomware«
  • »Bewerber- und Beschäftigtendatenschutz«
Webinare entdecken
Mit dem Code „Webinar2024B“ erhalten Sie 10% Rabatt, gültig bis zum 30.06.2024.
Beitrag kommentieren
Fehler entdeckt oder Themenvorschlag? Kontaktieren Sie uns anonym hier.
  • Vielen Dank für den Beitrag. In Bezug auf die Betriebsvereinbarung als Rechtsgrundlage stellt sich bei mir die Frage nach einer möglichen Absenkung des Schutzstandard. Der Wortlaut von Art. 88 legt m.E. nicht nahe, dass die Betriebsparteien erheblich vom von der DSGVO vorgegebenen Schutzstandard abweichen können. Wenn 26 BDSG und 6f DSGVO wegen fehlender Erforderlichkeit als Rechtsgrundlage in diesem Fall ausscheiden, müssten die Vereinbarungen der BV die fehlende „Erforderlichkeit“ kompensieren und würden somit „automatisch“ unterhalb des Schutzstandards der DSGVO fallen. Dann könnten die Betriebsparteien Recht setzen, dass nicht den Anforderungen der DSGVO entspricht. VG

    • Ich kann Ihre Bedenken durchaus nachvollziehen. Leider ist das Verhältnis zwischen den einzelnen von Ihnen genannten Normen (§ 26 Abs. 1 BDSG und Art. 6 Abs. 1 lit. f DSGVO) zu § 26 Abs. 4 BDSG bzw. ist die Reichweite des § 26 Abs. 4 BDSG noch nicht vollständig höchstrichterlich geklärt und für beide Meinungen lassen sich durchaus Argumente finden, eine Abwägung kann an dieser Stelle nicht voll umfänglich vorgenommen werden.

  • Das Urteil des LAG BaWü ist in mehrfacher Hinsicht „erstaunlich“. Soll Art. 8 der Grundrechte der EU wirklich in der Disposition von Parteien einer Betriebsvereinbarung liegen? Hoffentlich nicht. Der EuGH betont gebetsmühlenartig, dass es nur die Rechtsgrundlagen des europäischen Rechts gibt. Warum glaubt man hierzulande dies ignorieren zu können und noch viel schlimmer das Datenschutzniveau der DSGVO in dem Bereich senken zu können, wo doch der Schutz der Daten und der betroffenen Personen, so wichtig ist? Der EuGH wird diesen Hokuspokus hoffentlich in 2024 beenden und vielleicht versteht man hierzulande dann endlich das europäische Datenschutzrecht etwas besser.
    Mit besten Grüßen
    Kleiner Europäer

Die von Ihnen verfassten Kommentare erscheinen nicht sofort, sondern erst nach Prüfung und Freigabe durch unseren Administrator. Bitte beachten Sie auch unsere Nutzungsbedingungen und unsere Datenschutzerklärung.