This website is also available in your language.

Go
Ein schwarz gekleideter Mann mit Regenschirm und Handy in der Hand vor einer roten Wand, valantic Case Study E-Plus Telefonica

E-Plus (Telefónica) - Datenschutzkonforme Löschung obsoleter Kundendaten

Entwicklung und Integration einer Enterprise Application mit Web-UI, Workflow-gesteuerten Java-Prozessen und Message-Queuing

E-Plus (Telefónica) hat sich an das wichtige Thema “Datenlöschung” gewagt und verwaltet nun als einer der ersten Telefonanbieter seinen Kundendatenbestand strukturiert und zentralisiert datenschutzkonform.

Bisher wurden die Löschungen manuell nach einem dezentralen Analyseverfahren durch die Mitarbeiter vorgenommen. Das führte zu unterschiedlichen Auslegungen des Regelwerks und war kompliziert in der Abstimmung mit anderen Abteilungen.

Präzise Löschung

Sichere und zuverlässige Lösch­ung durch präzises, zen­trales Regelwerk

Automatisierung

Effizienter Betrieb und Repro­duzier­bar­keit durch hohen Auto­mati­sierungs­grad

Agilität

Ressourcenschonender Pro­zess durch asyn­chro­ne Lösch­ung und individuelle Pake­tierung

Gesetzeskonformität

Vermeidung von Buß­gel­dern und straf­recht­lichen Konse­quenzen

Kundenbindung

Ein hoher Daten­schutz­stan­dard fes­tigt das Ver­trau­en der Kunden

Funktionsweise von cDROP

Grafik valantic Case Study Telefonica

Die Herausforderung

Um zu verstehen, wie komplex dieses Thema ist, muss man sich vorstellen, wie viele Systeme an der Bereitstellung, Verwaltung und Betreuung der Telekommunikationsdienste beteiligt sind. Betrachten wir dazu einen fiktiven Kunden: Nennen wir ihn Frank.

Frank hat einen Mobilfunkvertrag für sich selber. Für seine Frau Andrea hat Frank eine zweite SIM-Karte unter seinem Vertrag laufen. Dann hat er vor einiger Zeit für seine Tochter Lisa einen Prepaid-Tarif bestellt. Lisa ist nun volljährig und hat selber einen Mobilfunkvertrag. Die Prepaid-Karte hat zwar noch ein Restguthaben, ruht jedoch. Für seinen Sohn Luke hat er auch einen Prepaid-Tarif gewählt. Lukes Handy wurde samt Karte gestohlen. Die Karte ist zwar gesperrt, wurde aber zwischenzeitlich von Dritten genutzt – hier ist noch offen, ob Franks Versicherung oder die des Telefonanbieters den Schaden trägt.

Jetzt hat sich Frank dazu entschlossen, den Mobilfunkanbieter zu wechseln und kündigt seinen Vertrag. Für den Mobilfunkanbieter hat er nun den Status eines „deaktiven Kunden“ und der Anbieter steht vor der Herausforderung, Franks Daten in Hinblick auf Datenschutz, buchhalterische und rechtliche Vorgänge korrekt zu verwalten.

Grafik valantic Case Study Telefonica
Grafik valantic Case Study Telefonica

Was das Thema so komplex macht

Was an dem Beispiel deutlich werden sollte: Franks personenbezogene Daten sind in vielen verschiedenen Systemen hinterlegt und werden dort auch benötigt:

  • Kundenbetreuung
  • Tarifberatung
  • Technischer Support
  • Rechnungsstellung
  • Einzelverbindungsnachweise
  • Verwaltung der Vertragsdaten
  • Verwaltung von Guthaben
  • Verwaltung von Prepaid-Karten

Fristen und Zuordnung der Daten

Für verschiedene Abläufe gelten unterschiedliche Aufbewahrungsfristen. Rechnungen müssen beispielsweise 10 Jahre lang aufbewahrt werden. Verbindungsdaten hingegen müssen bereits nach kurzer Zeit gelöscht werden – es sei denn, sie sind wiederum rechnungsrelevant.

Eine weitere Herausforderung liegt darin, dass nicht jedes System dieselben Daten speichert. Manche Systeme verwenden und kennen nur die SIM-Nummer der stillgelegten Prepaid-Karte, andere nur die Mobilfunknummer der zweiten SIM-Karte. Alle diese Daten sind jedoch personenbezogen, da sie auf die Person Frank zurückzuführen sind.

In dieser Ausgangssituation ist unser Kunde zu uns gekommen. Unsere Aufgabe war es, ein System zu entwickeln, welches die Löschung obsoleter Kundendaten steuert und kontrolliert. Nur Daten zu löschen, wäre einfach. Unser System soll natürlich nur die Daten zur Löschung freigeben, die nach gewissen Vorgaben entfernt werden müssen. Und zwar überall dort, wo Daten hinterlegt sind, die auf irgendeine Weise Rückschlüsse auf die Person Frank zulassen. Im weiteren Verlauf nennen wir diese Löschkandidaten „deaktive Kunden“.

Aus der Beschreibung oben wurde sicherlich klar, dass diese Aufgabe ganz schön komplex ist.

Die Lösung

Ein System für die saubere und automatisierte Löschung personenbezogenener Kundendaten

Wer ist mein Kunde? Zusammenführen loser Datenstränge

Zunächst mussten wir herausfinden, in welchen Systemen personenbezogene Daten erfasst werden – denn in diesen müssen die Daten gelöscht werden.
Dabei gibt es:

  • Systeme, die nicht wissen, ob ein Kunde deaktiv ist, jedoch personenbezogene Daten verwalten
  • Systeme, die wissen, ob ein Kunde deaktiv ist
  • Systeme, die nicht wissen, ob ein Kunde deaktiv ist, jedoch Informationen verwalten, die relevant sind, für die Entscheidung, ob ein Kunde gelöscht werden darf

Systeme der zweiten und dritten Kategorie nennen wir Quellsysteme, da sie uns helfen, die Löschkandidaten zu identifizieren. Systeme in denen Daten gelöscht werden müssen, nennen wir Zielsysteme.

Das Kniffelige ist, dass keines der Quellsysteme alle Identifikationsmerkmale darüber enthält, ob ein Kunde gelöscht werden darf und auch nicht alle zu löschenden Datenarten enthält. Jedes System verwaltet seine Daten an Hand seiner eigenen Verwaltungsstruktur.

Welche Daten darf ich zum jetzigen Zeitpunkt löschen? Das fachliche Regelwerk

Wie jedoch eingangs schon beschrieben, gibt es Daten, die länger aufbewahrt werden müssen als andere. Und unter gewissen Umständen dürfen auch Daten, deren ursächliche Aufbewahrungsfrist schon verstrichen ist, noch nicht gelöscht werden.

Diese (wirklich sehr verschachtelten) fachlichen Zusammenhänge wurden von uns in ein programmatisches Regelwerk übersetzt. Das klingt jetzt irgendwie simpel – war es aber nicht. Die vielen Wenn-Dann-Fälle sauber in ein logisches Regelwerk zu packen, war ein zentraler Meilenstein des Projekts.

Zusammenfassung: Nach der Konsolidierung durchlaufen die Daten in DROP ein Löschregelwerk. Dabei wird für jeden Kunden entschieden, ob und nach welchen Regeln er gelöscht werden muss.

Erst jetzt ist das Bild vollständig: DROP kennt alle Kunden, weiß ob und warum sie gelöscht werden müssen und kann sie in jedem Zielsystem eindeutig zuordnen.

Sie denken, wir können jetzt endlich mit dem Löschen beginnen? Nun ja – nachdem die vorangegangenen Schritte so komplex waren, liegt auf der Hand, dass die Übertragung der Löschbefehle nicht weniger komplex ist.

Grafik valantic Case Study Telefonica

Es kann gelöscht werden. Aber wie?

Um die Löschung anzustoßen, erstellt DROP eine Liste mit Löschbefehlen. Diese Liste wird den Zielsystemen (Sie erinnern sich? Das sind die Systeme in denen Daten entfernt werden müssen.) zur Verfügung gestellt. Jedes Zielsystem kann dieser Liste entnehmen, ob und welche Daten es zu löschen hat.

So viel zur Theorie. In der Praxis bedeutet dieser Vorgang: Es muss eine enorme Datenmenge verschoben und verarbeitet werden. Diese Rechenleistung wird den unterschiedlichsten, teilweise sehr alten Systemen abverlangt. Nicht jedes System kann mit solch großen Datenmengen gleichermaßen umgehen. Um den Betriebsablauf nicht zu stören, galt zu berücksichtigen, dass die Systeme durch die Löschvorgänge nicht verlangsamt werden dürfen.

Unsere Lösung: Damit hier so schnell wie möglich aber so langsam wie nötig vorgegangen werden kann, bekommt jedes System die Löschbefehle individuell in genau den Paketmengen, die das jeweilige System verarbeiten kann. Die Löschpakete werden also asynchron zugestellt. 

Manche Systeme bekommen nur Daten in der Nacht – also zu betriebsarmen Stunden – andere können pro Stunde maximal eine Hand voll Datensätze verarbeiten und andere Systeme sind leistungsstärker und kommen zügiger voran.

Grafik valantic Case Study Telefonica

Die unwiderrufliche Löschung

Jetzt wird es wieder etwas einfacher. Die Löschlisten werden in regelmäßigen Abständen den Zielsystemen zur Verfügung gestellt. Kunden, welche auf der Liste stehen, werden aus den Systemen entfernt.

Der Gesetzgeber verlangt einen Beleg über die Löschung der Daten. Um dieser Forderung nachzukommen, wird in einem separaten Report dokumentiert, welche Daten erfolgreich gelöscht wurden. Da dieser Report wiederum personenbezogene Daten enthält, wird dieser nach eine Schutzdauer ebenfalls vernichtet. Ist dieser Prozess abgeschlossen, sind die Kundendaten unwiderruflich und somit datenschutzkonform gelöscht.

Herausforderungen im Projekt

Dass die ganze Nummer recht kompliziert wird, war uns klar. Im Laufe des Projekts gab es jedoch noch ein paar unvorhergesehene Herausforderungen zu meistern.

  1. Datenqualität

    Eine der Herausforderungen war die teilweise schlechte Datenqualität. Viele Datenbestände waren so alt, wie das Unternehmen – viele Daten, Systeme und Prozesse sind 10 bis 20 Jahre alt – im digitalen Zeitalter sind das regelrechte Fossilien.

    Damit nichts Falsches gelöscht wird, haben wir so eine Art Reißleine eingebaut: Stößt DROP auf ein widersinniges oder unverständliches Datum, wird es nicht gelöscht, sondern es wird eine Warnung zurück gespielt. Diese Daten müssen dann individuell, händisch abgeglichen und korrigiert werden. Nach der Korrektur kann der Datensatz beim nächsten Durchlauf von DROP erneut erfasst werden.

  2. Testing

    Das Löschen von Kundendaten ist ein unternehmenskritischer Vorgang. Fehler sind hier nicht verzeihlich. Daher gab es eine intensive Testphase und eine mehrstufige Einführung des Systems.

    Im Laufe der Integrationstests wurde jedoch schnell klar, dass die Testdaten nicht „echt“ genug waren. Die Komplexität der Vorgänge erforderte ein realitätsnäheres Testfeld als die bisherigen Systeme.

    Wir haben die Live-Daten ausführlich analysiert und konnten für das Testing so ein passgenaues Testfeld aufstellen.

Technische Besonderheiten in der Umsetzung

Die ganze Anwendung DROP ist geprägt von Asynchronität und Parallelität. Damit DROP sauber läuft, mussten wir jede Menge komplexe Abläufe und Datenbeziehungen formulieren, Prozesse steuern und externe Schnittstellen bedienen. Für die Ablaufsteuerung haben wir Activiti eingesetzt – eine BPMN-konforme Workflow Engine. Das hat den Vorteil, dass Workflows grafisch dargestellt werden und sich so auch den Fachverantwortlichen (die Code nicht so sehr lieben wir wir) erschließen. Das erleichterte die Kommunikation zwischen Technikern und Fachbereichen enorm. So konnten wir gemeinsam die technische Umsetzung der Anforderungen begutachten.

Um die Prozesse zeitlich voneinander zu entkoppeln, kommunizieren diese über einen Message-Bus (Active MQ) miteinander. Bei der Implementierung der Schnittstellen nach Außen haben wir auf bewährte Enterprise Integration Patterns gesetzt. Dabei kam Apache Camel zum Einsatz.

Einbettung in das Projekt

Wir betreuen Unternehmen der Telekommunikationsbranche in den Bereichen Fraud-Management und Compliance bereits seit vielen Jahren. Für dieses Projekt wurden wir explizit angefragt, da wir als versierter, unkomplizierter und flexibler Partner bekannt sind.

Insgesamt haben wir gemeinsam von der Konzeption über das Testing bis zum Livegang sehr eng zusammengearbeitet. Wir waren stets über die Status der Aufgaben der anderen informiert.

Seit April 2015 ist das System live und obsolete Kundendaten werden datenschutzkonform gelöscht.

Eingesetzte Technologien

Spring Framework | ORM (Objekt Relationales Mapping ) – Hibernate |Message Queuing – Active MQ | Web-Framework – Apache Wicket | BPMN Workflow Engine – Activiti | Enterprise Integration – Apache CAMEL

Unser Fazit

DROP war sicherlich eines der anspruchsvollsten Projekte, die wir bisher machen durften. Gerade deswegen sind wir stolz auf das Ergebnis und haben selber sehr viel dabei gelernt. Es ist immer wieder schön, Herausforderungen zu meistern und davon hat uns dieses Projekt jede Menge geboten. Unser Kunde hat die Wichtigkeit des Themas erkannt und mit diesem System einen wahren Meilenstein in Sachen Datenschutz gelegt. Aus Sicht der Verbraucher ist zu hoffen, dass andere Unternehmen diesem Vorbild folgen und ebenfalls zügig einen datenschutzkonformen Umgang mit ihren Kundendaten etablieren.

Ihr Ansprechpartner

Bild von Stefan Michaelis, Business Executive, valantic Telco Solutions & Services

Stefan Michaelis

Prokurist, Business Unit Executive
valantic Telco Solutions & Services