DSGVO: Rechtssicherheit im Testdatenmanagement
Am 25. Mai 2018 tritt die neue EU Datenschutz-Grundverordnung (DSGVO) in Kraft. Mit ihr erhöhen sich die datenschutzrechtlichen Anforderungen auch für den Test von IT-Systemen. Und mit einem erheblich erhöhten Sanktionsrahmen von bis zu vier Prozent des Vorjahresumsatzes gibt es für Firmen dringend Veranlassung, zum Stichtag alle Vorkehrungen getroffen zu haben. Dies gilt vor allem für solche Unternehmen, die bislang – oft unwissentlich – nicht entsprechend den geltenden Gesetzgebungen agieren. Denn auch auf Grundlage des Bundesdatenschutzgesetzes (BDSG) ist es nicht erlaubt, personenbezogene Echtdaten ohne Weiteres zu Testzwecken zu verwenden. Trotzdem ist die Verwendung von Echtdaten beim Softwaretest nicht nur in der Integrations-, sondern auch in der Testphase oftmals gängige, aber gefährliche und rechtswidrige Praxis.
Risiken erkennen
Auf Testsysteme haben oftmals wesentlich mehr Personen Zugriff als das im regulären Betrieb der Fall ist, da dort verschiedenste Tests, auch mit anderer Software und anderen Daten, durchgeführt werden. Den Zugriff auf die genutzten Daten durch unberechtigte Dritte auszuschließen wird so schnell zur Herausforderung – vor allem wenn Daten zur Fehleranalyse an Dritte weiterfließen. Auch kann die Datensicherheit durch die Verwendung unterschiedlicher Zwischenversionen der Software gefährdet werden, da durch die Anzahl der Testversionen auch die Anzahl eventueller Fehlerquellen steigt. So können beispielsweise versehentlich im Test veränderte Daten nicht mehr rekonstruiert werden, falls Backups nicht im erforderlichen Maße durchgeführt werden.
Gemäß BDSG ist die Nutzung personenbezogener Daten grundsätzlich nur zweckgebunden erlaubt, also nur für den Zweck, für den sie erhoben wurden. Und nur sehr selten erheben Unternehmen personenbezogene Daten mit entsprechender Einwilligung der Personen zur Nutzung in Testumgebungen. Sind sie dafür nicht erhoben worden, so stellt die Nutzung von Echtdaten für Testzwecke also zunächst eine Zweckänderung dar. Und diese ist nach der Vorgabe des BDSG nur dann zulässig, wenn dies zur Wahrung berechtigter Interessen der verantwortlichen Stelle erforderlich ist. Außerdem darf kein Grund zu der Annahme bestehen, dass das schutzwürdige Interesse des Betroffenen an dem Ausschluss der Nutzung überwiegt. Das heißt auf Deutsch: es bedarf einer Begründung, dass man wirklich und unbedingt personenbezogene Daten nutzen muss.
Im Rahmen dieser Interessensabwägung ist bereits zweifelhaft, ob die Nutzung von personenbezogenen Echtdaten zu Testzwecken überhaupt erforderlich (und damit rechtens) ist. Denn mit entsprechender Anonymisierung und Pseudonymisierung kann eine Testabteilung auch ohne Echtdaten in geeigneter und rechtssicherer Weise testen. Und auch die DSGVO, die die Zweckänderung von Daten strengen Voraussetzungen unterwirft, setzt ausdrücklich auf diesen Weg. So fordert sie für die Nutzung von personenbezogenen Daten für Testzwecke in Artikel 6 Absatz 4 das "Vorhandensein geeigneter Garantien, wozu Verschlüsselung oder Pseudonymisierung gehören kann". Eine Nutzung von Echtdaten für Testzwecke, insbesondere im Projektbetrieb, ist danach nicht zulässig. Eine weitere Alternative könnte der Einsatz sogenannter synthetischer Datensätze sein, also künstlich geschaffene Datensätze ohne reelle Datenbasis.
Vermeiden, sparen und minimieren
Als grundlegendes Prinzip des Datenschutzes fordert schon das BDSG die sogenannte Datenvermeidung sowie die Datensparsamkeit. Das bedeutet in der Praxis: Die Verarbeitung personenbezogener Daten und die Gestaltung und Auswahl von Datenverarbeitungssystemen haben sich – so der Wortlaut des BDSG – an dem Ziel auszurichten, keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen. Das heißt, dass im Grunde schon heute der Gesetzgeber wo immer möglich eine Anonymisierung beziehungsweise Pseudonymisierung verlangt, etwa in Funktions- und Programmtests.
Sollte nach BDSG noch vermieden und gespart werden, geht es bei der DSGVO um minimieren. So fordert Artikel 25, Absatz 1 geeignete technische und organisatorische Maßnahmen, wie die Pseudonymisierung, um den Datenschutzgrundsatz der Datenminimierung umzusetzen (Data protection by design). Hierbei handelt es sich übrigens um eine bußgeldrelevante Regelung. An geeigneten Softwarelösungen, mit der sich die Nutzung von entsprechenden Testdaten vermeiden lässt, kommt ab Frühjahr 2018 also kein Unternehmen mehr vorbei.
Sicherheit garantieren
Schon heute unterliegen Testdaten restriktiven Vorgaben zum technischen und organisatorischen Datenschutz seitens des BDSG, die auch das Testen von Software und Systemen betreffen. So haben Unternehmen unter anderem zu gewährleisten, dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskontrolle). Ferner müssen sie personenbezogene Daten gegen zufällige Zerstörung oder Verlust schützen (Verfügbarkeitskontrolle). Der Gesetzgeber fordert damit auch eine Trennung von Produktiv- und Testsystem. Das Testen im Livebetrieb ist also keine Option! Und der Einsatz von personenbezogenen Echtdaten im Testbetrieb muss auch unter dem Gesichtspunkt der Datensicherheit als grundsätzlich unzulässig beurteilt werden. Denn er stellt nicht nur eine Zweckdurchbrechung dar, sondern gefährdet auch die Integrität und die Vertraulichkeit der Daten.
Natürlich gibt es auch Ausnahmen dieser Regel, etwa wenn ein System eine solche Komplexität aufweist, dass es ohne Echtdaten nicht aussagekräftig getestet werden kann. Allerdings sind auch hier wieder die Möglichkeiten moderner Softwarelösungen zur Anonymisierung oder Pseudonymisierung zu berücksichtigen, denn die Nachfolgereglung in Artikel 32 DSGVO verlangt ein risikoadäquates Sicherheitskonzept entsprechend dem aktuellen "Stand der Technik". Dieses fordert unter anderem die Pseudonymisierung und Verschlüsselung als Bestandteil des Sicherheitskonzepts. Zudem muss es die Fähigkeit haben, die Vertraulichkeit zu gewährleisten. Und auch für diesen Artikel gilt: Diese Ziele sind bußgeldrelevant beim Test von IT-Systemen zu berücksichtigen.
Informationspflichten und Folgenabschätzungen
Je nach Art der Testumgebung und des Testverfahrens kann das Risiko bestehen, dass durch Systemfehler beim Testen mit Echtdaten ungeplant personenbezogene Daten an Dritte übermittelt werden. Sind diese Daten besonders sensibel oder handelt es sich um Bank- oder Kreditkartendaten, müssen nach dem BDSG die Datenschutzaufsichtsbehörde sowie die Betroffenen selbst über diesen Datenverlust informiert werden. Dies kann mit Imageverlusten für das Unternehmen verbunden sein. Nach Geltung der DSGVO muss sogar ungeachtet der Sensibilität innerhalb von 72 Stunden jeder Datenverlust der Aufsichtsbehörde gemeldet werden. Dieses Risiko lässt sich nach dem Wortlaut der DSGVO vermeiden, wenn ein Sicherheitskonzept die Verschlüsselung von Daten vorsieht.
Ein neues Instrument der Datenschutzorganisation eines Unternehmens ist die Datenschutz-Folgenabschätzung. Bei Verwendung neuer Technologien, die besondere Risiken für die Betroffenen aufweisen, hat das Unternehmen gemäß Artikel 35 DSGVO eine Abschätzung der Folgen vorzunehmen. Insbesondere wenn besonders sensible Daten verarbeitet werden sollen, bedarf es bei der Planung der Tests von IT-Systemen einer Analyse der Risiken auf technologischer Ebene, die gegebenenfalls mittels Pseudonymisierung oder dem Einsatz synthetischer Datensätze minimiert oder ausgeschlossen werden kann.
Orientierungshilfe der Behörde
Die Datenschutz-Aufsichtsbehörden fordern im Hinblick auf das Inkrafttreten der DSGVO im Mai 2018 in der Orientierungshilfe "Datenschutz und Datensicherheit in Projekten" eine Differenzierung zwischen Projekt- und Produktivbetrieb. Für den Projektbetrieb sollen Unternehmen bei Funktions- und Integrationstests grundsätzlich keine personenbezogenen Echtdaten mehr nutzen dürfen. Zudem bedarf es einer Kurzfassung eines IT-Konzepts sowie eines auf die Testbedingungen angepassten Sicherheitskonzepts. Auch für den Produktivbetrieb wird ein Sicherheitskonzept gefordert. Notwendige Tests mit Echtdaten sollten sich auf Daten von Personen beschränken, die für das Verfahren verantwortlich oder Mitarbeiter des Projekts sind und diesen Tests zugestimmt haben. Zudem wird die Freigabe für den Produktivbetrieb durch die Unternehmensleitung gefordert, wohl um die datenschutzrechtliche Verantwortlichkeit zu unterstreichen.
Konsequenzen bei Verstößen
Verstöße gegen die oben genannten Regelungen oder natürlich auch andere im Gesetzestext können ein Einschreiten der Datenschutz-Aufsichtsbehörden zur Folge haben. Diese können Bußgelder bis zu 300.000 Euro verhängen sowie Auflagen für die System- und Programmtests erteilen. Die DSGVO bringt nun einen erheblich verschärften Bußgeldrahmen mit. Danach können Bußgelder bis zu 20 Millionen Euro oder bis zu vier Prozent des weltweiten (Konzern-)Jahresumsatzes, je nachdem welcher der Beträge höher ist, verhängt werden. Dabei müssen die verhängten Bußgelder "wirksam, verhältnismäßig und abschreckend sein". Datenverluste können zudem den Tatbestand der Strafbewährungen erfüllen, wie die Verletzung von Amts-, Berufs- und Privatgeheimnissen, die Verletzung des Post- oder Fernmeldegeheimnisses oder Verrat von Geschäfts- und Betriebsgeheimnissen. Bei Verlusten von sensiblen Daten oder Daten zu Kredit- und Bankkonten auf Grund sicherheitstechnisch unzulänglicher System- und Programmtests sind nach einer Risikobeurteilung zudem auch die Aufsichtsbehörden und die Betroffenen hiervon zu informieren. Der Imageverlust des Unternehmens ist dabei sicherlich der größte Schaden.
Prozesse kennenlernen und definieren
Mit der DSGVO verschärfen sich also auf verschiedenen Ebenen die regulatorischen Vorschriften. Mit ihnen nehmen auch die fachlichen und technischen Anforderungen an Unternehmen sowie die Bedeutung der Themen Datenhoheit und der Schutz externer Quellen zu. Um diesen Anforderungen Herr zu werden, müssen Unternehmen im Hinblick auf die Gesetzes-Novellierung sicherstellen, dass die Implikationen, die sich aus den Regularien ergeben, fest im Prozessgefüge verankert sind. Zudem müssen sie auch die entsprechenden Kompetenzen, Werkzeuge und Ressourcen definieren und nachhalten. In der Konsequenz ergeben sich klar definierte Prozesse, die eine Einhaltung der gesetzlichen Rahmenbedingungen garantieren.
Um dies jedoch zu erreichen, ist es für die Verantwortlichen im Unternehmen zunächst unerlässlich, die zugrundeliegende Datenverlaufsarchitektur End-to-End zu kennen, Quell- und Zielsysteme zu analysieren und Serviceschnittstellen zu lokalisieren. Nur so lassen sich die Testdatenanforderungen schnell ableiten und beteiligte Systeme und ihre Owner identifizieren und einbinden. Konsequenterweise schließt sich hieran ein Kennenlernen und detailliertes Auseinandersetzen der Verantwortlichen mit den Testprozessen und -vorgehen an. Eine entsprechende Visualisierung der Datenreservierung – also der besetzten Datenketten – und der Verarbeitungsprozesse erleichtert Unternehmen das Kennenlernen der eigenen Prozesse. Kennt man die einzelnen Schritte genau, erübrigt sich auch die oftmals vorherrschende Massendatenvorhaltung, da die Daten dann nur für die einzelnen Testfälle zur Verfügung gestellt werden können. Auch kann so identifiziert werden, welche Datensätze sich für ein Synthetisieren beziehungsweise welche Testsysteme sich für eine Virtualisierung eignen.
Haben die Firmen den Überblick über die Prozesskette gewonnen, können sie auch die Auswahl der richtigen Werkzeuge für den rechtssicheren Umgang mit Testdaten eingrenzen. Dafür müssen sie, abgeleitet aus der Prozessvisualisierung, den Anforderungsbedarf je Einzelschritt erfassen. So lässt sich eine Toolmatrix erstellen und mit ihr der richtige Hersteller finden.
Rollenverteilung erzeugt Klarheit
Es wird schnell klar, dass es für eine Person im Unternehmen schwierig sein kann, hier den Überblick zu behalten. Es bietet sich daher an, verschiedene Rollen zu definieren, um Klarheit im Testdatenmanagement zu erzeugen – insbesondere sind hier der Projektverantwortliche, der Testdatenmanager und der Testdatenanalyst zu nennen. In der Projektverantwortung liegt auch die technische Verantwortung für das Testprojekt. Hier werden die fachlichen und regulatorischen Anforderungen geklärt und deren Einhaltung unter Bereitstellung der entsprechenden Ressourcen sichergestellt. Der Testdatenmanager zeichnet die fachlichen Anforderungen an das Projekt und ihre technische Umsetzung verantwortlich. Er behält auch die Liefer- und Betriebsfähigkeit zusammen mit dem ausführenden Testdatenanalysten im Auge. In der Verantwortung des Analysten liegt außerdem die technische Umsetzung sowie die fortlaufende Kontrolle der eingesetzten Werkzeuge und Umgebungen.
Mit der DSGVO kommen auf alle Unternehmensbereiche Veränderungen und eine Sensibilisierung im Umgang mit Daten zu. Auch das Testing ist davon nicht ausgeschlossen. Dabei sollten viele der neuen Anforderungen bereits unter dem BDSG zumindest in Ansätzen verankert worden sein. Ist dies nicht der Fall, gilt es schnell nachzubessern. Dadurch wird nicht nur Rechtssicherheit sichergestellt. Am Ende kann ein Unternehmen auch Zeit und Geld sparen, da oftmals klar wird, dass das Testing gerade im Umgang und Umfang der Datennutzung einen gehörigen Overhead produziert.
Quick Check Datenschutz
Nutzt Ihr Unternehmen Echtdaten im Softwaretest, ohne diese zu anonymisieren oder pseudonymisieren? Falls ja, dann hilft Ihnen die folgende Checkliste dabei, festzustellen, ob Sie dabei auch den Datenschutz einhalten. Bei ein bis zwei "Nein"-Antworten sollten Sie dies mit einem Datenschutzexperten abklären. Sollten Sie mehrere Anforderungen nicht erfüllen, besteht akuter Handlungsbedarf.
- Wurden im Vorfeld ausgiebige Tests ohne Echtdaten durchgeführt?
- Werden die Echtdaten nur im Rahmen zusätzlicher, minimierter Tests verwendet und finden diese nur in einer definierten und kontrollierten Umgebung statt?
- Es existiert keine bereichsspezifische Rechtsvorschrift, die den Test mit Echtdaten ausdrücklich untersagt?
- Liegen Fehler aus dem Produktionsbetrieb vor, die sich ohne Echtdaten nicht aufklären lassen?
- Wäre die Anonymisierung der Echtdaten mit unvertretbar hohem Aufwand verbunden?
- Hat die verantwortliche Stelle dem Test mit Echtdaten schriftlich zugestimmt (Geschäftsleitung)?
- Wurde vorab der betriebliche oder behördliche Datenschutzbeauftragte informiert?
- Werden bei der Durchführung und Auswertung der Tests die schutzwürdigen Belange der Betroffenen und die Datensicherheit berücksichtigt?
- Haben nur solche Personen auf die Echtdaten Zugriff, die auch für die Fehlerbehebung und Durchführung der Tests erforderlich sind?
- Unterliegen diese Personen den jeweils maßgebenden Vertraulichkeitsgrundsätzen und insbesondere datenschutzrechtlichen Vorschriften?
- Wurde der Zugriff auf die Echtdaten protokolliert und die Verwendung mit Anlass, Begründung, Umfang und Dauer, die getroffenen Sicherheitsmaßnahmen sowie die vorangegangen Tests mit Testdaten revisionssicher dokumentiert?
- Ist eine Kurzfassung des IT-Konzeptes sowie ein auf die Testbedingungen angepasstes Sicherheitskonzept vorhanden?
