Kurzposition: Personenbezogene Daten bei Software‑Entwicklung und ‑Tests

Im Rahmen der Entwicklung, Einführung und Erprobung von Software stellt sich oft die Frage, wie mit Testdaten umgegangen werden soll. Konkret stellt sich die Frage, ob personenbezogene Daten für die Generierung von Testdaten genutzt und in den Testdatenbestand übernommen werden dürfen oder die Nutzung ausgeschlossen ist. Dabei kommt es auf die konkrete Verarbeitung an: Mit dem Begriff Testdaten können, je nach getesteter Funktion oder Eigenschaft, sehr unterschiedliche Daten gemeint sein, die sich in der Menge, im Umfang und im Detailgrad stark unterscheiden. Ebenso variabel ist der Grad des Risikos der Verarbeitung selbst, die je nach Ausgestaltung mit einem sehr hohen Risiko oder nur geringem Risiko für betroffene Personen einhergehen kann. Im Folgenden werden Software-Entwicklung und -Tests in den datenschutzrechtlichen Rahmen eingeordnet. Anschließend werden zu berücksichtigende Aspekte und ein vereinfachtes Vorgehen zur Bewertung aufgezeigt.

Sobald personenbezogene Daten verarbeitet werden, handelt es sich bei der Entwicklung oder den Tests in der Regel um eigenständige Verarbeitungen für die alle Anforderungen der Datenschutzgrundverordnung (DSGVO) einzuhalten sind. Das heißt, eine entsprechende Rechtsgrundlage muss vorliegen, die Datenschutzprinzipien müssen eingehalten, Betroffenenrechte gewährleistet werden, etc. Nach dem Prinzip „Data Protection by Design“ (Art. 25 DSGVO) müssen Software-Entwicklung und -Tests datenschutzfreundlich gestaltet werden, sodass in der Regel keine oder weniger personenbezogene Daten verarbeitet werden, als bei der Verarbeitung im produktiven Betrieb. Software-Entwicklung und -Tests sind keine Ausnahmebereiche für die niedrigere oder andere datenschutzrechtliche Bedingungen gelten.

Zunächst gilt es zu prüfen, ob überhaupt die Nutzung von personenbezogenen Daten geeignet und erforderlich ist. Es gilt die Prüffolge:

1. Ist die Verarbeitung nicht-personenbezogener, anonymer Daten möglich?
2. Ist die Verarbeitung pseudonymer Daten möglich?
3. Ist die Verarbeitung personenbezogener Daten in unveränderter Form unbedingt erforderlich?

Verarbeitung nicht-personenbezogener Daten

Für Software-Entwicklung und -Tests sind Daten mit Personenbezug gewöhnlich vermeidbar, da festgestellt werden soll, ob unter bestimmten Bedingungen vorher festgelegte Anforderungen eingehalten werden. Die Software muss abstrakt mit allen möglichen Ausprägungen von Daten umgehen können. Deshalb ist der Einsatz von Daten mit Personenbezug in diesem Kontext in der Regel nicht erforderlich und damit vermeidbar.

Typische Testfälle, die ohne personenbeziehbare „Testdaten“ auskommen, sind „Grenzfälle“ („Edge-Cases“), die genutzt werden, um das Verhalten von Software bei verschiedenen Eingaben zu testen, zum Beispiel Personen mit einem Alter von unter 0 oder über 100 Jahren, besonders langen, kurzen oder vielen Namen oder gänzlich fehlenden Attributen. Diese Grenzfälle sollen von der Software so behandelt werden, dass keine unerwarteten Fehler oder Störungen auftreten. Andere Attribut- oder Parameterausprägungen werden durch Äquivalenzklassenbildung abgedeckt, um eine umfassende Prüfung der Software zu gewährleisten. Da hier die Eigenschaften des jeweiligen Testfalls maßgeblich sind, können die Testfälle entweder manuell erstellt werden oder entsprechende Testdatensätze voll synthetisch erzeugt werden ohne Personenbezug aufzuweisen. Die Testfälle ergeben sich aus den Anforderungen an die Software und dem Entwicklungsprozess, sodass hier keine personenbezogenen Daten aus konkreten Fällen erforderlich sind. Der erstellte (künstliche) Testdatenbestand kann dann für weitere Testzwecke, wie beispielsweise Last- oder Performancetest herangezogen werden.

Mögliche Fehlerquelle

Testfälle enthalten personenbezogene Daten: Beim Betrieb der Software wird festgestellt, dass bestimmte Sonderzeichen in mehreren Namen nicht korrekt dargestellt werden. Die Übernahme entsprechender Namen in die Testfälle würde dazu führen, dass personenbezogene Daten verarbeitet werden. Daher müssen zur Vermeidung des Personenbezugs Testfälle für die entsprechenden Zeichenklassen erstellt werden, ohne dass die betroffenen Namen übernommen werden.

Die Verarbeitung von nicht-personenbezogenen Daten fällt nicht in den Anwendungsbereich der DSGVO. Somit entfallen die datenschutzrechtlichen Pflichten.

Verarbeitung synthetischer oder generierter Daten

Kann nicht mit solchen Testfällen gearbeitet werden oder werden (umfangreiche) Testdatensätze benötigt, muss geprüft werden, ob anonyme Daten genutzt werden können. Anonyme Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse, die nicht mehr oder nur mit einem unverhältnismäßigen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können.

Eine Möglichkeit sind „voll synthetische“ Daten. Diese können ohne Einschränkungen für Entwicklungs- und Testzwecke genutzt werden. Solche voll synthetischen Daten werden ohne jeden Personenbezug erzeugt, zum Beispiel nach bestimmten Regeln oder (statistischen) Mustern. Eine Ableitung aus (vorhandenen) personenbezogenen Daten findet nicht statt (Fälle in denen aus personenbezogenen Daten zum Beispiel mittels KI, KI-Training oder anderen Technologien Testdaten abgeleitet werden sollen, werden hier nicht behandelt.). Auch manuell erstellte Testfälle können als synthetische Daten angesehen werden. Die so erzeugten Testdaten können dabei zielgerichtet sämtliche Anforderungen an die Software abdecken. Das genaue Vorgehen kann dabei beliebig aufwendig und ausführlich gestaltet werden: mit statistischen Modellen, die die reale Population realitätsgetreu abbilden, über generative Modelle, die die Daten möglichst vielseitig aussehen lassen, bis hin zu einfachen Blindtexten und „Dummy“-Objekten mit gleichlautenden Platzhaltern, wie „Mustermensch“ aus „Musterstadt“ passend zum Datenbankschema.

Mögliche Fehlerquelle

Indirekte oder unbemerkte Übernahme personenbezogener Daten: Der Prozess der Generierung und der erzeugte Testdatenbestand sind angemessen zu prüfen, insbesondere darauf, ob personenbezogene Daten (unbeabsichtigt) enthalten sind. Diese können zum Beispiel durch „Overfitting“ eines Modells, die Verarbeitung falscher oder fehlerhafter Eingangsdaten oder einen falschen oder falsch ausgeführten Prozess in die Ergebnismenge gelangen.

Verarbeitung anonymer Daten

Eine weitere Möglichkeit zur Erstellung eines Testdatenbestandes ist die Anonymisierung von personenbezogenen Daten. Typischerweise sollen vorhandene „Echtdaten“ aus einem Alt-, Kunden- oder Produktivsystem zu Testzwecken weiterverarbeitet werden. Die Weiterverarbeitung zur Anonymisierung selbst ist eine Verarbeitung personenbezogener Daten im Sinne der DSGVO und unterliegt den entsprechenden Anforderungen – insbesondere ist zu prüfen, ob eine Rechtsgrundlage und kompatible Zwecke vorliegen. Dies ist in der Regel aber nicht immer der Fall. Denn eine Anonymisierung beseitigt den Personenbezug und ermöglicht damit eine sehr risikoarme Datenverarbeitung, sodass die Anonymisierung selbst in der Regel – aber nicht stets – von den Vorgaben der DSGVO gedeckt ist.

Für die Anonymisierung gibt es keinen Algorithmus und kein Verfahren, das unabhängig von den konkreten Merkmalsausprägungen eine zuverlässige Umwandlung von personenbezogenen Daten zu anonymen Daten durchführt. Ein alleiniges Entfernen oder Ersetzen von Namen ist grundsätzlich nicht ausreichend. Es müssen auch spezifische Merkmalskombinationen in den Daten berücksichtigt werden, die eine Identifizierung ermöglichen können (sogenannte Quasi-Identifier). Mitunter ist die Anonymisierung von bestimmten Datensätzen, zum Beispiel im Gesundheitswesen oder der Forschung, nicht in geeigneter Weise möglich, da die enthaltenen Merkmalskombinationen so spezifisch sind, dass damit eine natürliche Person identifiziert werden kann. Deshalb ist zu prüfen, ob eine Anonymisierung erfolgreich war. Dabei sind nicht nur die Mittel des jeweiligen Datenempfängers zu berücksichtigen, sondern auch die Mittel von Anderen, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, um die natürliche Person direkt oder indirekt zu identifizieren – das beinhaltet grundsätzlich auch Informationen des Verantwortlichen bzw. des Datenabsenders sowie mögliche zukünftige Empfänger oder technische Entwicklungen. Der Prozess ist komplex und fehleranfällig, deshalb ist grundsätzlich von einem hohen Risiko für die Rechte und Freiheiten der betroffenen Personen auszugehen und eine Datenschutzfolgenabschätzung (DSFA) anzufertigen.

Zu Anonymisierungstechniken gibt es eine Stellungnahme der Artikel-29-Datenschutzgruppe, die hier weitere Orientierung geben kann. Des Weiteren sind Leitlinien des EDSA zu Pseudonymisierung kürzlich erschienen und zu Anonymisierung in Arbeit.

Verarbeitung pseudonymisierter Daten

Wird die Nutzung anonymer Daten nach Prüfung ausgeschlossen, soll also mit personenbezogenen Daten, zum Beispiel Bestandsdaten, gearbeitet werden, sind zunächst die Voraussetzungen der (Weiter-) Verarbeitung zu prüfen. Die Nutzung von personenbezogenen Daten aus bestehenden Verfahren in der Bundesverwaltung stellt in der Regel eine nicht zulässige Zweckänderung dar.

Falls die Verarbeitung zulässig ist, sind angemessene und geeignete technische und organisatorische Maßnahmen zur Risikoreduktion zu identifizieren und umzusetzen. Dazu gehören insbesondere die Aggregation, Maskierung und Pseudonymisierung, sowie die Reduktion von Art und Umfang der Daten auf den kleinstmöglichen Umfang. Auch bei der Pseudonymisierung sollten Quasi-Identifier soweit wie möglich entfernt oder ersetzt werden. Werden angemessen geschützte personenbezogene Daten verarbeitet, ist sicherzustellen, dass die etwaigen Pflichten aus der DSGVO erfüllt werden – insbesondere die Transparenz- und Informationspflichten.

Verarbeitung personenbezogener Daten in unveränderter Form „Echtdaten“

Die Verarbeitung personenbezogener Daten in unveränderter Form, auch „Echtdaten“ genannt, für Tests lässt sich in engen Grenzen rechtfertigen. Sie darf erst erfolgen, wenn für den konkreten Test die Verwendung von (synthetischen) Testdaten ohne Personenbezug nicht in Frage kommt, die Verwendung von anonymisierten Testdaten nicht möglich ist und auch eine pseudonymisierte Verwendung ausgeschlossen wurde. Wie zuvor ist sicherzustellen, dass die Verarbeitung nach DSGVO zulässig ist und alle etwaigen Pflichten erfüllt werden – insbesondere geeignete technische und organisatorische Maßnahmen getroffen werden.

Typische Anwendungsszenarien

Szenario 1: Für eine neue Komponente einer Software soll geprüft werden, ob sie dem angegebenen Umfang entspricht und Anfragen unter „hoher Last“ ausreichend schnell beantwortet.

Die Verwendung personenbezogener Daten für Szenario 1 ist nicht erforderlich und nicht zu rechtfertigen. Hier ist der Einsatz von „voll synthetischen“ oder simplen „Dummy-“Daten mit geeigneten Testfällen angezeigt. Durch entsprechende Testfälle können der Umfang und die Kompatibilität mit den vorgesehenen Einsatzszenarien gezielt überprüft werden. Ein Test muss immer gegen ein konkretes Set von Anforderungen erfolgen sonst sind die Ergebnisse nicht aussagekräftig. Soll das Verhalten bei unbekannten Ereignissen geprüft werden, eignen sich andere Ansätze, wie zum Beispiel Fuzzing.

Szenario 2: Es soll eine Software zur Simulation des Blutzuckerspiegels bei Diabetes während der Nacht entwickelt werden.

Soweit für Szenario 2 noch kein geeignetes Modell vorliegt, können keine synthetischen Daten erzeugt werden. Die Zusammenhänge müssen aus vorliegenden Daten extrahiert werden. Es ist zu prüfen, ob die Daten anonymisiert werden können. Ist nicht eindeutig festzustellen, ob die Daten anonym sind, ist davon auszugehen, dass die Daten personenbezogen sind. Das (Wieder-) Herstellen des Personenbezugs kann durch die Anwendung von geeigneten Maßnahmen wesentlich erschwert werden. Mit den so bereits ergriffenen Schutzmaßnahmen sind in der Regel weniger zusätzliche technische und organisatorische Schutzmaßnahmen zu treffen als für die ursprünglichen Daten, weil die Risiken für die Rechte und Freiheiten der betroffenen Personen erheblich reduziert wurden.

Szenario 3: Eine neue Software soll beschafft werden. Dafür stehen mehrere Systeme in der engeren Auswahl. Um auszuprobieren, ob die in der engeren Auswahl stehenden Systeme mit den eigenen Daten funktionieren, soll vor der Beschaffung der personenbezogene Echtdatensatz ohne Schutzmaßnahmen in die Systeme eingespielt werden.

Die Nutzung von ungeschützten Echtdaten wie in Szenario 3 dargestellt, ist unzulässig und ungeeignet. 1. Ein Test muss überprüfen, ob unter bestimmten Bedingungen vorher festgelegte Anforderungen eingehalten werden. Weder die Bedingung noch die Anforderung sind in diesem Szenario in geeigneter Weise definiert, sodass in diesem Szenario der Zweck mit keinem Datensatz erfüllt werden könnte. 2. Weiterhin wäre der Echtdatensatz für einen solchen Test nicht geeignet. Er deckt bspw. nicht zuverlässig alle möglichen oder zulässigen Merkmalskombinationen ab – insbesondere nicht die Grenzfälle. Deshalb wäre ein anforderungsspezifischer Datensatz wie in Szenario 1 besser geeignet. 3. Zudem fehlen hier jegliche Schutzmaßnahmen. Tatsächliche Hinderungsgründe für den Einsatz von Schutzmaßnahmen liegen nicht vor. Im Einzelfall müssen, wie zuvor dargestellt, u.a. Eingriffstiefe, Erforderlichkeit und getroffene Schutzmaßnahmen gegeneinander abgewogen werden, um die Zulässigkeit und Eignung bewerten zu können. Bei solchen Tests sollten alle entscheidungsrelevanten Gründe und Umstände dokumentiert werden.

Szenario 4: Für ein bestehendes System steht eine dringende Aktualisierung bereit. Die Test- und Produktivumgebung sind gleichwertig geschützt. Die aktualisierte Testumgebung wird parallel zur Produktivumgebung betrieben und mit den Echtdaten beladen.

Szenario 4 stellt den Übergang von der Verarbeitungstätigkeit „Entwicklung“ zur Verarbeitungstätigkeit „Betrieb“ dar. Es geht nicht mehr um die Überprüfung von Anforderungen, sondern Zweck ist es, den produktiven Betrieb sicherzustellen. Dafür kann eine solche Verarbeitung von Echtdaten zulässig sein. Durch den gleichwertigen technischen und organisatorischen Schutz der Verarbeitung, sowie dem Verbleib der Daten bei der verantwortlichen Stelle wird den bestehenden Risiken genauso angemessen begegnet, wie bei der ursprünglichen Verarbeitung. Eine ähnliche Konstellation kann sich bei der Fehlerbehebung ergeben, bei der die Spiegelung einer Umgebung erforderlich ist – jedoch ist darauf zu achten, dass die getroffenen technischen und organisatorischen Maßnahmen aufrechterhalten oder mindestens gleichwertig kompensiert werden, insbesondere bei der Weitergabe von Fehlerprotokollen und sonstigen Daten oder der Einbeziehung externer Stellen. Wie bei jeder Verarbeitung müssen die daraus resultierenden Pflichten, wie die Wahrung der Betroffenenrechte, das Löschen gemäß Löschkonzept oder die Protokollierung gemäß Protokollierungskonzept etc. beachtet werden.

Fazit

Aus datenschutzrechtlicher Perspektive ist entscheidend, wie den Risiken für betroffene Personen angemessen begegnet werden kann. Zur Auswahl geeigneter Maßnahmen sollte ein Verantwortlicher diese Stufen berücksichtigen und die wesentlichen Entscheidungsgründe nachvollziehbar dokumentieren.