BI-Systeme und die DSGVO: Prüfen und Dokumentieren bei jedem Prozess

Mit der EU-Datenschutzgrundverordnung (DSGVO) drohen dieses Jahr Unternehmen, die sich nicht daran halten, nicht nur erhebliche Bußgelder. Auch für Firmen, die die Regelungen einhalten wollen, entsteht erheblicher Aufwand. Denn sie müssen prüfen, ob die Vorgaben zu “Privacy by Design” und “Privacy by Default” durch die von ihnen verwendete Software und Dienste erfüllt sind, welche Daten der DSGVO der unterliegen und wie sie bei Anonymisierung und Analyse vorgehen müssen. Daraus resultieren entsprechende technische und organisatorische Maßnahmen. Sie wurden bereits in einem früheren Beitrag bei silicon.de ausführlich beschrieben.

In diesem Beitrag geht es nun vor allem darum, welche Aufgaben mit dem Ende der derzeit laufenden Übergangsfrist für die DSGVO am 25. Mai 2018 auf Business-Intelligence-Verantwortliche zukommen. Denn auch sie müssen bis dahin ihr BI-System prüfen und DSGVO-konform machen.

Personenbezogene Informationen und ihre Bearbeitung

Im ersten Schritt sollte ein Datenverarbeitungskatalog mit der Liste der zu verarbeitenden Daten und ihren Attributen erstellt werden. Diese Daten sollten kategorisiert werden anhand der Frage, ob sie als personenbezogene Daten verarbeitet werden oder nicht. Die Attribute sind daraufhin zu prüfen, ob es sich um personenbezogene Informationen handelt. Sollte es sich weder um personenbezogene Daten oder um personenbezogene Informationen handeln, ist keine weitere Bearbeitung nötig, da die DSGVO nicht greift.

Wenn doch, so sollte geprüft werden, ob die Nutzung der personenbezogenen Attribute der Daten zwingend nötig ist. Wenn nicht, werden sie aus dem Data Warehouse (DWH) entfernt. Andernfalls müssen Maßnahmen zu ihrem Schutz definiert werden. Dies können etwa Zugriffbeschränkungen sein, die Verschlüsslung sowie die Pseudonymisierung oder Anonymisierung.

Für den zukünftigen Datenfluss muss sichergestellt werden, dass die definierten Maßnahmen an der richtigen Stelle implementiert werden. Noch vor der Realisierung sollten die Maßnahmen aber auch rechtlich geprüft werden. Hier muss die Hilfe eines spezialisierten Juristen herangezogen werden. Erst dann sollten die definierten Schritte umgesetzt und danach die Systeme zertifiziert werden.

Wir geben im Folgenden eine Übersicht über die einzelnen Bereiche, die besondere Beachtung verdienen.

Self-Service-BI und Datenschutz

Datenanalysten gehen mehr und mehr dazu über, Quell-Systeme direkt anzusprechen und Daten direkt auszulesen. Dieses “Self-Service-BI” erlaubt schnellere und flexiblere Analysen als bisher möglich. Das Vorgehen kann aber aus Sicht des Datenschutzes unerwünschte Folgen haben. So kann es passieren, dass Benutzer von Self-Service-BI-Lösungen Rohdaten in eine eigene Datenbank einlesen. Selbst wenn sie in Folge verarbeitet und anonymisiert werden, sind die Rohdaten mitsamt den detaillierten personenbezogenen Daten in dieser Datenbank weiterhin vorhanden: Dies widerspricht den Vorschriften der DSGVO.

Self-Service-BI muss man deswegen aber nicht vollständig unterbinden. Den Analysten muss aber bewusst sein, was das “Anzapfen” von personenbezogenen Daten für Folgen haben kann. Dies kann mit einer entsprechenden Schulung vermittelt werden. Ein technischer Ausweg kann sein, die personenbezogenen Daten durch Berechtigungen oder mit anderen technischen Lösungen zu schützen.

Sie könnten etwa nur innerhalb der Quell-Applikation im Klartext zur Verfügung stehen und bei einem direkten Zugriff anonymisiert werden. Ein solcher Mechanismus muss vom Applikationsanbieter oder von der Datenbankplattform zur Verfügung gestellt und erzwungen werden. Dadurch kann sichergestellt werden, dass sensible personenbezogene Daten nicht außerhalb der kontrollierten Umgebung genutzt werden können.

Alternativ kann auch ein Export der Daten in einer anonymisierten Form aus dem CRM-System realisiert werden (zum Beispiel in einem Text- oder -CSV-File). Diese Daten können dann risikolos in das Self-Service-BI-Werkzeug eingelesen werden.

Daten im ETL Bereich

Der ETL-Bereich (Staging und Cleansing Area) ist der Bereich des BI-Systems, in dem die Daten aus den Quell-Systemen, zum Beispiel des CRM-Systems, zwischengespeichert werden. Diese werden dann für das Data Warehouse (DWH) aufbereitet und dort festgeschrieben. Üblicherweise werden diese Daten nur bis zum nächsten Ladelauf gespeichert.

Datenfragemtierung (Bild: Shutterstock)

Der Zeitraum zwischen den Ladeläufen kann von wenigen Minuten (Near-Realtime-DWH) bis zu mehreren Tagen oder Wochen dauern. In dieser Zeit sind poteziell vrtrauliche personenbezogene Daten hier gespeichert. Dies stellt gemäß der DSGVO ein unnötiges Risiko dar.

Aus dem ETL-Bereich werden die Daten in das DWH überführt. Dabei können die personenbezogenen Daten entfernt, pseudonymisiert oder in eine gröbere Detaillierungsstufe gebracht werden. Im DWH und den nachgelagerten Analyse-Systemen müssen Mechanismen für den Zugriffsschutz implementiert werden, falls doch die detaillierten Daten benötigt werden.

Zudem sollte der ETL-Bereich am Ende der Datenaufbereitung und der Überführung der Daten in das DWH in jedem Fall permanent gelöscht werden. Dieses Problem stellt sich nicht, wenn die Voraussetzungen zur Anonymisierung der Daten schon in den Quellsystemen etabliert sind.

Log- und technische Tabellen

Nicht zu vergessen sind auch Log-Files und ähnliche technische Tabellen, welche z.B. im Cleansing für eine Duplikatserkennung benötigt werden. Diese können ebenfalls personenbezogene Daten enthalten und müssen in den Prozessen entsprechend bereinigt oder entfernt werden.

Personenbezogene Daten im Legacy-DWH/BI-System

Vorhandene BI-Systeme müssen auf personenbezogene Daten überprüft werden. Falls solche Daten vorhanden sind, muss eine Risikoanalyse durchgeführt und entsprechende technische und organisatorische Maßnahmen (TOM) sind zu ergreifen, um zu verhindern, dass hier personenbezogene Daten ungeschützt gespeichert sind.

Daten in den Sicherungen

Ein möglicherweise übersehener Bereich beim Datenschutz ist die Datensicherung. In Abhängigkeit von der vorgesehenen Aufbewahrungszeit der Sicherungen, müssen diese überprüft und eventuell an die neuen Prozesse angepasst werden, welche die DSGVO mit sich bringt. Dies kann einen entsprechend großen Aufwand bedeuten, da nicht nur die Datenbanksicherung an sich, sondern eventuell auch die Sicherung der Transaktions- und Redo-Logs betroffen sind.

Bei kurzen Aufbewahrungszeiten (bis zwei Monate) kann man von einer Prüfung und Anpassung der Sicherungen absehen, da diese nach Ablauf dieser Zeit sowieso gelöscht werden. Die Löschung dieser Sicherungen nach Ablauf der Aufbewahrungszeit muss aber sichergestellt werden, um bei einem Audit oder bei einem Vorfall (zum Beispiel einer Beschwerde) abgesichert zu sein. Hier bietet sich eine automatisierte Protokollierung an.

Bei besonderen Monats- oder Jahres-Sicherungen muss eine Prüfung und, falls nötig, eine Anpassung der gesicherten Daten an die DSGVO durchgeführt werden. Hier sollte der Aufwand dieser Änderungen geprüft werden, sowie die Frage, ob die rechtlichen Rahmenbedingungen tatsächlich die langfristige Sicherung dieser Daten erzwingen. Dies kann zur Folge haben, dass ältere Sicherungen nicht angepasst werden müssen. Das bedingt aber eine entsprechende Prüfung und Dokumentation der Sicherungsprozesse.

Die Löschung einer kompletten Sicherung, nur um einen einzelnen Datensatz zu einer einzelnen Person zu löschen, ist unverhältnismäßig. In diesem Fall reicht es, den Benutzer darüber zu informieren, wann sein Datensatz überschrieben beziehungsweise nach Ablauf eventueller gesetzlicher Vorgaben endgültig gelöscht wird. Wichtig ist, dass die Dokumentation der entsprechenden Prozesse als Nachweis vorhanden sein muss.

Das “Recht auf Vergessenwerden” und Ausnahmen im Data Warehouse

Die DSGVO verlangt von Unternehmen umfassende Anpassungen bei der Behandlung von Daten. Überall, wo personenbezogene Daten verwendet werden, gilt es zu prüfen, inwieweit die DSGVO Anwendung findet. Zudem ist die Einhaltung zu dokumentieren.

Bisweilen bringt die Verordnung Unternehmen auch in eine rechtliche Zwickmühle. Sollten sie bilanzierungspflichtig sein und zu diesem Zwecke ein Data Warehouse als Datenquelle für die Erstellung der Bilanz verwenden, geraten sie möglicherweise in den Konflikt mit Art. 17 – dem sogenannten “Recht auf Vergessenwerden”. Hierin ist festgelegt, dass ein Kunde verlangen darf, dass seine Daten gelöscht werden.

Bilanzrechtlich ist aber eine nachträgliche Veränderung der Datenbasis, welche für die Erstellung der Bilanz oder dient, nicht erlaubt. Das vollständige und durchgehende Löschen von personenbezogenen Daten in einem Data Warehouse könnte also zur Folge haben, dass sich darauf basierende Berichte für das Firmenergebnis nachträglich verändern. Das widerspricht anderen gesetzlichen Vorgaben. Der Gesetzgeber beschreibt diesen Fall in Art. 17, Absatz 3. Dort sind Ausnahmen definiert, welche das Löschrecht aushebeln. Doch diese Punkte müssen geprüft, entsprechend nachgewiesen und dokumentiert werden. Einfacher kann es sein, wenn im DWH keine personenbezogenen Daten mehr enthalten sind, sondern nur anonymisierte Daten: Diese fallen nicht unter das Recht der DSGVO, womit Prüfung und Nachweis entfallen.

Fazit

Die Arbeit mit Business-Intelligence-Systemen als zentrale datenverarbeitende Instanz wird durch die DSGVO gründlich umgekrempelt. Keine Datenbank und kein Prozess, sei er technisch oder organisatorisch, der potenziell personenbezogene Angaben enthalten kann, ist von der Prüfung und Anpassung ausgenommen.

Doch in vielen Fällen sind kostspielige technische Projekte unnötig. Geringe Detailtiefen, Anonymisierung und Pseudonymisierung können genutzt werden, die in bestehenden BI-Prozessen verwendeten Daten aus dem Geltungsbereich der Verordnung heraus zu nehmen. Doch hierfür ist Fachwissen und Erfahrung bei Datenschutz-Projekten nötig. Hinsichtlich der empfindlichen Strafen, welche die DSGVO vorsieht, sollten Unternehmen darauf Wert legen, sich hier den bestmöglichen Rat einzuholen.

Weiterführende Informationen