In der Praxis stellt sich immer wieder die Frage, ob Echtdaten als Testdaten Verwendung finden können. Häufig taucht diese Fragestellung auf, wenn ein Unternehmen oder eine Behörde die Entwicklung einer Software bei einem Dienstleister in Auftrag geben möchte.

Nicht selten fehlt seitens der Unternehmen und Behörden das Bewusstsein für die datenschutzrechtliche Problematik bei der Verwendung von Echtdaten als Testdaten. Grundlage des fehlenden Problembewusstseins ist vielleicht die Annahme, dass die personenbezogenen Daten ja nur zu Testzwecken verwendet werden sollen. Die Verwendung der Daten sei ja nicht produktiv und deshalb unproblematisch. Dass bei Softwaretests regelmäßig keine Echtdaten zur Anwendung kommen können, ist seitens der Datenschützer zu vermitteln.

Dabei ergibt sich die Pflicht zur Vermeidung von Echtdaten in Testumgebungen unmittelbar aus dem Datenschutzrecht. Denn grundsätzlich verstößt eine Verwendung von personenbezogenen Daten zu Testzwecken gegen den datenschutzrechtlichen Zweckbindungsgrundsatz und ist daher in der Regel unzulässig. Des Weiteren verstößt die Verwendung von Echtdaten zu Testzwecken auch gegen das Prinzip der Datensparsamkeit.

Der Grundsatz der Zweckbindung ist ein datenschutzrechtlicher Grundsatz, der unbedingt Beachtung finden muss. Das Gebot der Zweckbindung soll sicherstellen, dass Daten nur für den Zweck verarbeitet werden dürfen, für den diese auch erhoben worden sind. Eine Datenverarbeitung, die über den ursprünglich festgelegten Zweck hinausgeht, ist als Zweckänderung nur aufgrund einer Erlaubnisnorm im Gesetz oder mit vorheriger freiwilliger Einwilligung des Betroffenen zulässig. In der Regel ist bei der Verwendung von Daten zu Testzwecken davon auszugehen, dass keine Erlaubnisnorm vorhanden ist und dass die Betroffenen (z.B. Kunden oder Bürger) keine Einwilligung in die Verwendung ihrer personenbezogenen Daten zu Testzwecken erteilt haben.

Das Prinzip der Datensparsamkeit verlangt von der verantwortlichen Stelle bereits im Vorfeld der Datenverarbeitung eine Ausrichtung des Datenverarbeitungsvorganges dahingehend, dass keine oder so wenig wie möglich personenbezogenen Daten verarbeitet werden.

Die Gefahr von Datenpannen

Ein weiterer Grund, der gegen die Verwendung von Echtdaten als Testdaten spricht, ist die Gefahr von Datenpannen in der Testumgebung. Denn zum einen sind Testdaten häufig den besonderen Gefahren von Systemen ausgesetzt, die noch nicht abschließend entwickelt und daher fehleranfällig sind. Hier ist auch zu beachten, dass die Umgebung, in der die Entwicklungsarbeiten stattfinden, oftmals weniger reglementiert ist, als die Umgebung, in der Echtdaten verarbeitet werden. Häufig fehlt sogar eine Regelung, wer auf die Testdaten zugreifen darf.

Des Weiteren werden Testdaten häufig gedankenlos verarbeitet. Werden Echtdaten in Testumgebungen als solche nicht erkannt, so kann es vorkommen, dass „Testdaten“ auf Messen in Vorführsystemen einsehbar sind, dass „Testdaten“ unverschlüsselt versendet oder nicht gelöscht werden und die Datenträger, auf denen sich die Daten befinden, weniger geschützt werden.

Verwendung fiktiver Testdaten oder Anonymisierung von Echtdaten

Wegen des Zweckbindungsgrundsatzes, des Prinzips der Datensparsamkeit und nicht zuletzt aufgrund der oben skizzierten Szenarien ist daher in der Praxis zwingend zu prüfen, ob

  • fiktive Testdaten zu generieren sind oder ob
  • Echtdaten zu anonymisieren sind.

Dabei ist der Generierung von Testdaten der Vorzug zu geben. Denn bei der Anonymisierung von Echtdaten ist besondere Sorgfalt an den Tag zu legen. Eine wirksame (!) Anonymisierung ist in der Praxis schwerer zu erreichen, als es auf den ersten Blick den Anschein haben mag. Es werden ganz unterschiedliche Methoden der Anonymisierung angewandt. Welche Methode dabei zum Erfolg führt, hängt von dem jeweiligen Datenbestand ab und kann daher an dieser Stelle nicht konkret ausgeführt werden. Häufig ist eine Anonymisierung jedoch sehr anspruchsvoll und sollte nur unter fachlich fundierter Beratung erfolgen.

Notwendigkeit eines Auftragsdatenverarbeitungsvertrages?

Werden die Daten an einen externen Entwickler weitergegeben, stellt sich des Weiteren die Frage, ob der Abschluss eines Auftragsdatenverarbeitungsvertrages (ADV-Vertrages) mit dem Dienstleister angestrebt werden sollte. Die Erforderlichkeit des Abschlusses eines ADV-Vertrages ergibt sich aus § 11 BDSG und ist immer dann erforderlich, wenn personenbezogene Daten im Auftrag durch andere Stellen verarbeitet werden sollen bzw. ein Zugriff auf personenbezogene Daten nicht ausgeschlossen werden kann.

Sofern eine wirksame Anonymisierung vorliegt und soweit ausgeschlossen werden kann, dass die Entwickler im weiteren Verlauf mit personenbezogenen Daten in Berührung kommen, wird grundsätzlich kein ADV-Vertrag benötigt. Denn das BDSG definiert die Anonymisierung dahingehend, dass diese dann vorliegt, wenn personenbezogene Daten derart verändert werden, „dass die Einzelangaben über persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können“, mithin der Personenbezug der Daten also entfällt. Da aber eine wirksame (!) Anonymisierung in der Praxis schwer zu erreichen ist und der Personenbezug der Daten in vielen Fällen nicht so einfach aufgehoben werden kann, wie man sich das vielleicht vorstellt, muss man an dieser Stelle sehr genau prüfen, ob man die Daten in der Praxis wirklich ohne ADV-Vertrag aus der Hand geben will. Welche Fallstricke bei der Anonymisierung lauern und wie herausforderungsvoll eine Anonymisierung sein kann, zeigt auch dieses Papier.

Können Echtdaten ausnahmsweise Testdaten sein?

Sowohl von Aufsichtsbehörden als auch vom BSI wird die Möglichkeit gesehen, dass Echtdaten unter gewissen Umständen gleichwohl Testdaten sein können – nämlich dann, wenn es (vereinfacht dargestellt) anders nicht geht und die erforderlichen Sicherheitsmaßnahmen getroffen wurden.

Die von den Aufsichtsbehörden und dem BSI formulierten Orientierungshilfen regeln die Verwendung von Echtdaten als Testdaten jedoch sehr streng und umfangreich. Eine Darstellung der von den Aufsichtsbehörden und dem BSI entwickelten Voraussetzungen würde den Rahmen dieses Beitrags sprengen. Daher wird an dieser Stelle auf die nachfolgenden Links verwiesen.

  • Für die Aufsichtsbehörden hier,
  • vom BSI hier.

In jedem Fall sollte vor der Durchführung von Softwaretests der betriebliche bzw. behördliche Datenschutzbeauftragte kontaktiert werden, damit der Test datenschutzrechtskonform durchgeführt werden kann. Diese Empfehlung gilt unabhängig davon, ob der Test betriebsintern oder durch einen externen Dienstleister durchgeführt wird.