Source: https://www.datenschutz-wiki.de/Softwaretest_mit_Echtdaten
Timestamp: 2018-12-16 19:31:45
Document Index: 21686541

Matched Legal Cases: ['§ 11', '§ 3', '§ 3', '§ 3', '§ 11', '§ 11', '§ 4', '§ 9', '§ 4', '§ 3', '§ 28', '§ 9', '§ 28', '§ 14', '§ 14', '§ 4', '§28', '§ 16', '§ 3', '§ 9', '§ 11']

Softwaretest mit Echtdaten – Datenschutz-Wiki
Die Software-Entwicklung und das Testen mit Echtdaten
1 Auftragsdatenverarbeitung (ADV) - ein Beispielszenario
1.1 Handelt es sich hier um Auftragsdatenverarbeitung?
1.2 Muss ein Vertrag nach § 11 BDSG geschlossen werden?
2 Software-Entwicklung und das Testen mit Echtdaten
2.1 Allgemeine Praxis
2.2 Datenschutzrechtliche Risiken
2.3 Datenschutzrechtliche Zulässigkeit
2.3.1 Zweckgebundenheit und Zweckänderung
2.3.2 Ist tatsächlich eine Zweckänderung gegeben?
2.3.3 Zweckbindung und -änderung in öffentlichen Bereichen
2.3.4 Die zulässige Übermittlung der Daten
2.3.5 Besondere Arten personenbezogener Daten
2.4 Lösungsvorschlag und Maßnahmen
2.4.1 Schutzmaßnahmen
Auftragsdatenverarbeitung (ADV) - ein Beispielszenario
Ein Unternehmen entwickelt Software für einen Kunden. Der Kunde stellt zum Testen Echtdaten zur Verfügung, in denen sich Adressen von dessen Kunden befinden.
Handelt es sich hier um Auftragsdatenverarbeitung?
Das ist abhängig davon, welche Daten erhoben, verarbeitet oder genutzt werden sollen.
"...in denen sich Adressen von dessen Kunden befinden."
Privatkunden sind im Sinne § 3 Abs. 1 BDSG Betroffene, weil sie natürliche Personen sind. Firmenkunden hingegen sind juristische Personen und demnach nicht Betroffene im Sinne des BDSG. Für eine Betrachtung der Thematik unter dem Aspekt BDSG wird darum von Privatkunden ausgegangen. Unter diesem Aspekt handelt sich bei den Daten um Adressen der Kunden, also um personenbezogene Daten im Sinne von § 3 Abs. 1 BDSG.
Das Unternehmen entwickelt Software, die Kundendaten verwaltet und zum Testen sollen Kundenadressen verwendet werden. Das bedeutet, dass mithilfe dieser Software Tätigkeiten im Sinne § 3 Abs. 3 bis Abs.5 BDSG durchgeführt werden.
Das Unternehmen entwickelt diese Software nicht für die Verwaltung seiner eigenen Kunden, sondern im Auftrag eines seiner Kunden. Dieser stellt ihm seine Kundendaten zur Nutzung und Verarbeitung bereit.
Diese beiden Punkte erfüllen den Sachverhalt Auftragsdatenverarbeitung im Sinne von § 11 Abs. 1 und 5 BDSG.
Muss ein Vertrag nach § 11 BDSG geschlossen werden?
Aus den vorgenannten Punkten wird ersichtlich, dass es sich im Beispielszenario um ADV handelt. Dementsprechend muss ein ADV-Vertrag bzw. eine ADV-Vereinbarung zwischen dem Unternehmen (Auftragnehmer), das die Software entwickelt, und dem Kunden (Auftraggeber), der seine Kundendaten zur Verfügung stellt, geschlossen werden. Der Auftragnehmer ist im Rahmen der ADV verpflichtet, den Schutz der Daten mit entsprechenden technischen und organisatorischen Maßnahmen zu gewährleisten. Der Auftraggeber ist verpflichtet, diese Maßnahmen regelmäßig zu kontrollieren.
Software-Entwicklung und das Testen mit Echtdaten
Leider ist es in der heutigen IT-Praxis noch nicht möglich, die strikte Trennung der Datenverarbeitung einzuhalten. Das Auftreten von Fehlern bei der Integration der Software und der Daten oder bei der Aufnahme des Produktionsbetriebes kann nicht immer vermieden werden. Ein Grund dafür ist u.a., dass Testdaten die Echtdaten nicht immer in Gänze abbilden können, sei es bei seltenen Namen oder bei Adresskonventionen. Die Verwendung von Echtdaten beim Testen der Software nicht nur in der Integrationsphase sondern auch in der Testphase ist deshalb oftmals gängige Praxis.
Da es keine Rechtsvorschrift für die nicht zweckgebundene Verwendung der Daten gibt (z.B. zu Testzwecken), müsste der Betroffene in die Verwendung seiner Daten zu Testzwecken einwilligen. Der Auftraggeber ist nach § 4 BDSG verpflichtet, von seine Kunden diese Einwilligung einzuholen. Dies ist durchaus möglich, findet in der Praxis jedoch kaum Anwendung.
Aus der gängigen Praxis ergeben sich damit verschiedene datenschutzrechtliche Risiken, die mit den technischen und organisatorischen Maßnahmen verhindert werden sollen.
Im Allgemeinen haben wesentlich mehr Personen Zugriff auf Testsysteme, da dort verschiedenste Tests, auch mit anderer Software und anderen Daten, durchgeführt werden. Der Zugriff von nicht Berechtigten kann somit nicht ausgeschlossen werden und birgt dementsprechende Missbrauchsgefahren.
Die Datensicherheit kann durch die Verwendung unterschiedlicher Softwarestände gefährdet werden, da durch die Anzahl der Testversionen auch die Anzahl eventueller Fehlerquellen steigt. Es ist außerdem davon auszugehen, dass Backups nicht im erforderlichen Maße durchgeführt werden und somit versehentlich veränderte Daten nicht rekonstruiert werden können.
Die Verfahren der Weitergabe von Testergebnissen, die u.a. personenbezogene Daten enthalten können, entsprechen oftmals nicht den Bestimmungen nach der Anlage zu § 9 BDSG. Dies beinhaltet ebenfalls ein Missbrauchsrisiko, da die Daten z.B. zur Fehleranalyse an Dritte versendet werden.
Die Überprüfung einer Änderung der Daten während der Tests wird selten protokolliert und demnach kann nicht nachvollzogen werden, von wem welche Daten zu welchem Zweck geändert wurden.
Aus datenschutzrechtlicher Sicht ist die beschriebene gängige Praxis nicht zulässig.
Zunächst stellt § 4 BDSG die Zulässigkeit der Datenerhebung, -verarbeitung und -nutzung fest. Die ergibt sich aus Rechtsvorschriften oder der Einwilligung des Betroffen. Des weiteren erfordert § 3a BDSG die Anonymisierung und Pseudonymisierung von personenbezogenen Daten, die erhoben, verarbeitet und genutzt werden sollen. Oberstes Gebot ist außerdem die Datenvermeidung und Datensparsamkeit.
Was bedeutet das? Wofür werden die Daten benötigt?
Echtdaten werden in der fertiggestellten Software (im Produktionsbetrieb) benötigt, z.B. zur Verwaltung der Kunden
Testdaten werden im Testbetrieb benötigt, während der Erstellung der Software Daraus ergibt sich die grundsätzliche Zweckgebundenheit der Daten und die erforderliche Anonymisierung und Pseudonymisierung der Echtdaten zu anderen Zwecken als dem Produktionsbetrieb.
Demnach ist eine andere Verwendung der Echtdaten, beispielsweise zu Testzwecken, unzulässig.
Zweckgebundenheit und Zweckänderung
Der Verwendungszweck von Echtdaten zu Testzwecken wird mit der sicheren Inbetriebnahme der Software und der Vermeidung von Fehlern im Produktionsbetrieb begründet. Im Falle des Auftretens von Fehlern kann beispielsweise die Datensicherheit gefährdet sein.
Die Verwaltung und Pflege der Daten (z.B. Kundendaten) ist Teil des Geschäftes der verantwortlichen Stelle. Dementsprechend groß ist das Interesse, die Datensicherheit zu bewahren - allein zur Durchführung des Vertragsverhältnisses und für die Vermeidung wirtschaftlicher Einbußen. Somit ist sich nach § 28 BDSG und der Zulässigkeit der Erhebung und Speicherung von Daten für die Erfüllung eigener Geschäftszwecke zu richten. Der Zweck der Datenverarbeitung ist konkret festzulegen und eine Zweckänderung zur Erfüllung eigener Geschäftszwecke wird durch Absatz 2 geregelt:
Für die Durchführung oder Beendigung eines rechtsgeschäftlichen oder rechtsgeschäftsähnlichen Schuldverhältnisses mit dem Betroffenen - dies beinhaltet z.B. die Erhaltung der Kundendaten, ohne die eine Fortführung des Vertragsverhältnisses nicht möglich wäre.
Für die Wahrung berechtigter Interessen der verantwortlichen Stelle - welche in der Vermeidung von wirtschaftlichen Einbußen gesehen werden kann.
Für die Annahme, dass der Betroffene kein schutzwürdiges Interesse an dem Ausschluss der Übermittlung oder Nutzung hat.
Es wird ersichtlich, dass dem berechtigten Interesse der verantwortlichen Stelle (im Beispiel der Auftraggeber) das schutzwürdige Interesse des Betroffenen (im Beispiel der Kunde) entgegensteht. Allgemein kann davon ausgegangen werden, dass der Kunde der Verwendung seiner Daten zu Testzwecken nicht zugestimmt hat. Dem Kunden zu vermitteln, dass ein sicherer Betrieb ohne die Verwendung von Echtdaten für Testzwecke nicht möglich ist, wäre demnach nicht ganz einfach. Es kann jedoch ebenso davon ausgegangen werden, dass es auch im Interesse des Kunden liegt, dass die geforderte Datensicherheit nach § 9 BDSG bei der Verwaltung seiner Daten gegeben ist.
Das ergibt eine Abwägung der substanziellen Interessen des Auftraggebers und der schutzwürdigen Interessen des Kunden, bei dem jedoch ein gleichartiges Interesse an der Datensicherheit vorausgesetzt werden kann. Aus dieser Sicht wäre eine Zweckänderung für die Nutzung von Echtdaten im Test- oder Integrationsbetrieb nach § 28 Abs. 2 BDSG begründet. Der Auftraggeber muss in diesem Fall jedoch sicherstellen, dass technisch-organisatorischen Umstände keine Beeinträchtigung der Interessen der Betroffenen zulassen.
Ist tatsächlich eine Zweckänderung gegeben?
§ 14 Abs. 3 BDSG gewährt u.a. eine Zweckänderung für Ausbildungs- und Prüfungszwecke durch die verantwortliche Stelle, soweit nicht überwiegende schutzwürdige Interessen des Betroffenen entgegenstehen.
Es stellt sich die Frage, ob bei der Verwendung der Echtdaten zu Testzwecken ein anderer Zweck vorliegt. Ebenso kann es als eine betriebliche Querschnittsfunktion angesehen werden, dass die Daten für Zwecke der Prüfung genutzt werden können. Diese Nutzung kann als eine allgemeine Aussage zum Thema gleiche und andere Zwecke angesehen werden und durch den Rechtsgedanken ist es daher auch im nichtöffentlichen Bereich anwendbar. Eine Zweckbindungszusage dürfte deshalb im Allgemeinen einem notwendigen Programmtest mit Echtdaten nicht entgegenstehen.
Zusammengefasst bedeutet das die grundsätzliche Geltung:
Solange die Software noch nicht für den Einsatz mit Echtdaten freigegeben ist, sollten Tests möglichst nur mit Testdaten durchgeführt werden[1]. Ein gemeinsames Interesse der verantwortlichen Stelle und dessen Betroffenen besteht in einem ordnungsgemäßen und fehlerfreien Betrieb der für Vertragsdurchführung verwendeten Software. Dies rechtfertigt in Einzelfällen den Testbetrieb zu Prüfungszwecken mit Echtdaten unter der Wahrung der Zweckgebundenheit - dem Test der Software.
Der Test mit Echtdaten muss aber aus Datensparsamkeits- und Erforderlichkeitsgründen die Ausnahme bleiben. Dabei ist zu beachten, dass nur von der verantwortlichen Stelle - also dem Auftraggeber - die Echtdaten zu Prüfungszwecken verwendet werden dürfen.
Zweckbindung und -änderung in öffentlichen Bereichen
Die Grundlage des o.e. Rechtsgedanken ist die Datenverarbeitung der öffentlichen Stellen und deren Bindung an § 14 BDSG. In Absatz 2 werden die Anforderungen an eine Zweckänderung klar formuliert. Auch hier wird u.a. die Einwilligung des Betroffenen vorausgesetzt, die (gleich der nicht-öffentlichen Stellen) im seltensten Fall eingeholt werden kann. Doch kann auch hier von einem Interesse seitens des Betroffenen an der ordnungsgemäßen Verarbeitung seiner Daten ausgegangen werden kann. Dieser Annahme würde Absatz 2 Punkt 3 entsprechen:
"offensichtlich ist, dass es im Interesse des Betroffenen liegt, und kein Grund zu der Annahme besteht, dass er in Kenntnis des anderen Zwecks seine Einwilligung verweigern würde".
Damit kann eine eine Zweckänderung begründet werden.
Absatz 3 gewährt, wie bereits erwähnt, u.a. eine Zweckänderung für Ausbildungs- und Prüfungszwecke durch die verantwortliche Stelle, soweit nicht überwiegende schutzwürdige Interessen des Betroffenen entgegenstehen. Dies gewährt die Möglichkeit der Verwendung von Daten für Zwecke der Wahrnehmung von Aufsichts- und Kontrollbefugnissen, der Rechnungsprüfung oder der Durchführung von Organisationsuntersuchungen sowie zu Ausbildungs- und Prüfungszwecken genutzt werden können.
Die zulässige Übermittlung der Daten
Im o.g. Beispiel programmiert die verantwortliche Stelle die Software für die Verwaltung der Kundendaten nicht selbst - sie beauftragt Dritte damit. Für die ordnungsgemäße Fertigstellung und Inbetriebnahme gibt sie außerdem die Kundendaten weiter; es findet somit eine Übermittlung der Daten statt.
Nach § 4 BDSG muss der Betroffene über die Übermittlung informiert werden, wenn er nicht damit rechnet, dass seine Daten z.B. zur Erfüllung des Vertragsverhältnisses an Dritte weitergegeben werden. Im Beispiel kann man davon ausgehen, dass dem Kunden dies nicht bekannt ist - er also nicht damit rechnet. Ebenso ist eine Übermittlung der Daten nach §28 Abs.2 BDSG unzulässig, da die alleinige Übermittlung der Daten dem schutzwürdigen Interesse des Betroffenen entgegensteht. Unter diesen Aspekten ist eine Übermittlung der Daten unzulässig.
Öffentlichen Stellen ist eine Übermittlung der Daten nach § 16 BDSG unter bestimmten Voraussetzungen zulässig, soweit dies zur Erfüllung der in der Zuständigkeit der übermittelnden Stelle liegenden Aufgaben erforderlich ist. Jedoch werden die Daten an den Software-Entwickler nicht zum Zweck der Übermittlung weitergegeben sondern für die Erfüllung der eigenen Geschäftszwecke - der Kundenverwaltung. Eine Übermittlung der Daten im Sinne einer Funktionsübertragung findet nicht statt, da der Software-Entwickler nicht die Kunden verwalten soll. Die daraus folgende Aufgabe des Software-Entwicklers ist eindeutig festgestellt und entspricht einer Auftragsdatenverarbeitung.
Die Weitergabe der Daten an den Software-Entwickler zur Erfüllung der eigenen Geschäftszwecke ist unter den o.g. Bedingungen der Zweckgebundenheit und -änderung im begrenzten Umfang zulässig.
Einen wichtigen Schwerpunkt stellt der Schutz von personenbezogenen Daten der besonderen Art nach § 3 Abs. 9 BDSG dar. Die o.g. Interessenabwägung kann nicht bei diesen Daten angewendet werden und damit ist eine Verwendung der Daten z.B. in Testdatenbanken nicht zu rechtfertigen. Dies bedeutet, dass auch eine Übermittlung dieser Daten nicht zulässig ist. Die verantwortliche Stelle (der Auftraggeber) sollte also in der Lage sein, die beauftragte Software im eigenen Haus mit diesen Daten frühestens in der Integrationsphase zu verwenden.
Lösungsvorschlag und Maßnahmen
Sollte es im Einzelfall unumgänglich sein, Echtdaten zu Testzwecken zu verwenden sind die nachfolgenden Punkte unbedingt einzuhalten[2]. Als Hilfestellung kann hierfür der Baustein Datenschutz des BSI IT-Grundschutz-Kataloges herangezogen werden.
Die zu testende Software muss im Vorfeld mit Testdaten in ihrer Gesamtheit getestet wurden sein (Programmverzweigungen, Fehlerrobustheit, Zusammenspiel aller Komponenten und Schnittstellen)
Es ist eine detaillierte Dokumentation mit der Begründung der Verwendung der Echtdaten zu hinterlegen.
Der Test ist zeitlich auf das notwendige Minimum zu beschränken.
Unmittelbar vor den Tests sind Sicherungskopien der Daten und evtl. beteiligter Software anzulegen.
Die Schutzmaßnahmen sind analog dem Produktionsbetrieb nach § 9 Anlage BDSG einzuhalten.
Die Schutzmaßnahmen dürfen nicht über das Erforderliche ausgeweitet werden.
Die Tests müssen ausführlich dokumentiert werden.
Nach Testende müssen alle eingesetzten personenbezogenen Daten gelöscht und der ursprüngliche Zustand wieder hergestellt werden.
Der Schutz der Daten wird einerseits durch die technischen und organisatorischen Maßnahmen gefordert und sollte entsprechend gewährleistet werden. Um den Anforderungen der besonderen Situation Echtdaten im Testbetrieb außerdem gerecht zu werden, sollten
zusätzliche Absprachen in Form von Auflagen für den Einsatz der Software und den expliziten Verwendungszweck der Daten schriftlich festgehalten werden
zeitliche Fristen für eine Verwendung der Daten an die verschieden Softwareversionen gebunden werden
die Sicherung der Daten und Softwarestände gewährleistet werden
Erfolgt die Verarbeitung der Daten im Rahmen einer Auftragsverarbeitung ist außerdem den Pflichten nach § 11 BDSG nachzukommen[3].
BSI ITGrundschutz-Baustein Datenschutz
^ Hinweise des Landesbeauftragten für den Datenschutz Baden-Württemberg zur Datensicherheit beim Einsatz von PC und lokalen Netzwerken: 3.25 Tests mit Testdaten
^ 3. Tätigkeitsbericht des Landesbeauftragten für den Datenschutz Mecklenburg-Vorpommern 1996/1997 Test mit Echtdaten im Einzelfall
^ Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein (ULD) - Systemdatenschutz: Kontrollpflichten des Auftraggebers bei Outsourcing / Auftragsdatenverarbeitung
Abgerufen von „https://www.datenschutz-wiki.de/index.php?title=Softwaretest_mit_Echtdaten&oldid=2794“
Diese Seite wurde zuletzt am 28. April 2016 um 23:42 Uhr bearbeitet.