Im letzten Blog dieser Serie ging es um die Vorteile der Pseudonymisierung von sensiblen oder identifizierenden Feldern anstatt diese im ERP-System (besonders in SAP) komplett zu löschen.
Jetzt möchte ich erklären, wie wir diesen Ansatz bei unserem Kunden MAPA GmbH umgesetzt haben. Dieser Fall ist vor allem deshalb interessant, weil er mehrere Facetten der DSGVO-Bestimmungen veranschaulicht: Privacy by Design, Datenreduzierung und die Rolle eines Datenverarbeiters im Vergleich mit der eines Datenverantwortlichen.
Reagieren auf neue (und bestehende, aber nicht bekannte) Rechte
Meine Zusammenarbeit mit MAPA hat bereits vor Inkrafttreten der DSGVO begonnen. Wir haben uns die Anforderungen von MAPA und einigen anderen Kunden in Bezug auf die DSGVO genau angehört, um unsere Lösungen auf die Bedürfnisse am Markt abzustimmen. Die Herausforderung besteht darin, dass die DSGVO keine eindeutigen Vorschriften enthält. Vielmehr gibt sie Leitprinzipien vor, keine festen, für ein IT-Team umsetzbaren Punkte. Deshalb wurden die Anforderungen an das SAP-System von unseren Kunden unterschiedlich interpretiert und wir beobachteten auch, dass sich diese Anforderungen im Laufe der Zeit änderten.
Das war für uns zunächst etwas nervenaufreibend, hat allerdings allen Beteiligten dabei geholfen zu verstehen, dass die DSGVO kein einmaliges Projekt sondern eine dauerhafte Aufgabe ist.
Im ersten Schritt lag der Fokus für alle unsere Kunden auf dem Umgang mit Anträgen auf Auskunftserteilung (Subject Access Request (SAR) bzw. Data Subject Access Request (DSAR), wenn die Daten als Präfix hinzugefügt werden) und was zu tun ist, wenn eine solche Anfrage zu einem Löschantrag entsprechend dem Recht auf Vergessenwerden führt. Für beide Fälle haben wir Technologien entwickelt, wobei für Letzteres die Verfremdung genutzt wird. Es war interessant zu sehen, dass schon beim Festlegen der Richtlinien zur Verfremdung an das Thema Aufbewahrungsfristen gedacht wurde. Viele unserer Kunden wollten die Anträge ehemaliger Mitarbeiter analysieren und anhand der vergangenen Jahre seit dem Unternehmensaustritt bestimmen, welche Daten des ehemaligen Mitarbeiters gelöscht oder verfremdet werden sollen.
In vielen Fällen wurde nicht die Identität gelöscht sondern nur bestimmte Daten, bei denen der Kunde keine rechtliche Grundlage mehr für eine Speicherung erkennen konnte.
Proaktive Aufbewahrungsregeln
Als die DSGVO in Kraft getreten ist, arbeiteten die meisten Organisationen, die unsere DSGVO-Software nutzen, noch immer reaktiv. Wenn jemand darum gebeten hat, seine Daten ganz oder teilweise zu löschen, wurde eine Pseudonymisierung vorgenommen. Doch die Voraussetzungen für die Umsetzung von Aufbewahrungsregeln waren gegeben. Das Unternehmen hatte sich an Diskussionen darüber beteiligt, welche Daten zu welchem Zeitpunkt entfernt werden sollten. Langsam aber sicher kam auch von Rechts- oder Auditteams der Anstoß, dass proaktiveres Handeln erforderlich ist. Ich habe schon 2017 darüber gebloggt, dass Aufbewahrungsregeln für ein IT-Team etwas anderes bedeuten als für eine Audit- oder Rechtsabteilung. Meiner Meinung nach hat diese Angleichung der Bedeutung oder des Bewusstseins über den tatsächlichen Status von Daten, deren Aufbewahrungsdauer überschritten ist, Organisationen wie MAPA dazu veranlasst, Aufbewahrungsregeln in ihre laufenden Prozesse zu integrieren.
Anfangs hatten wir an 18 Monate für Kundenauftragsdaten gedacht, die in SAP als Adressen sowie als Texteinträge vorhanden sind und sowohl sensibel als auch nicht sensibel sein können. Wir führten über das Wochenende eine Massenbereinigung von rund 400.000 historischen Bestellungen durch. In der Zeit, die wir für die Planung, den Test und die Durchführung der historischen Datenbereinigung brauchten, wurde die Vorgabe für die fortlaufende Aufbewahrung von 18 Monaten auf 12 Monate reduziert. Wir entwickelten einen Prozess, der monatlich ablaufen sollte und untersuchten, wie viel von diesem Prozess wir letztendlich automatisieren wollten. Ich bin der Überzeugung, dass Dinge erst manuell perfektioniert werden sollten, bevor sie automatisiert werden. Dieser Prozess war keine Ausnahme, dennoch haben wir angefangen, über Ausnahmefälle nachzudenken. Wie viele Bestellungen werden voraussichtlich im Monat getätigt? Ist eine Warnmeldung oder ein Abbruch nötig, wenn in einem bestimmten Monat mehr Bestellungen aufgegeben werden, oder wenn die Aufträge des Vormonats noch nicht verarbeitet worden sind? Während wir uns mit diesen Fragen befassten, änderte sich die Situation dramatisch.
Pflichten des Datenverarbeiters im Vergleich zum Datenverantwortlichen
Ein Teil der Daten für "einmalige Bestellungen" wurden über einen Partner-Marktplatz generiert und nicht über den eigenen Webshop von MAPA oder anderen Verkaufsplattformen. Bei der Vertragsverlängerung mit diesem Marktplatz, muss ein Fragebogen zum Datenschutz ausgefüllt werden. Die Optionen für die Dauer der Datenspeicherung reichen von sehr kurz bis zur maximalen Option „länger als 180 Tage“. Das bedeutete, dass die neue Aufbewahrungsstrategie unter derselben Dropdown-Option wie „für immer“ zu finden war! Für den eigenen Webshop und anderen Partner-Verkaufsseiten hatte MAPA die Rolle des „Datenverantwortlichen. MAPA war für die Beziehung zum Kunden verantwortlich und hat seine Richtlinien für den Datenschutz festgelegt. Für diesen anderen Marktplatz ist MAPA nach der DSGVO jedoch lediglich als Datenverarbeiter tätig.
Zwei kürzlich bekannt gewordene Datenschutzverletzungen und Bußgelder (British Airways und Marriott Hotels) waren beide auf Fehler eines Datenverarbeiters und nicht auf die Hauptorganisation zurückzuführen. Aber die Bußgelder und der Rufschaden fielen vor allem auf den Datenverantwortlichen zurück. Das erklärt, warum ein Partner, der als Datenverantwortlicher handelt, auf eine viel kürzere Aufbewahrungsfrist besteht. Von MAPA wurde demnach verlangt, Daten, die über den externen Marktplatz generiert wurden, nur 30 Tage lang zu speichern. Das bedeutete eine wesentliche Änderung für unser Projekt. Bei einer Aufbewahrungsdauer von nur 30 Tagen wurde uns schnell klar, dass der Prozess täglich hätte ablaufen müssen. Um eine wöchentliche Verarbeitung zu ermöglichen, hätte die Aufbewahrungsfrist auf 23 Tage sinken müssen und um die monatliche Verarbeitung fortzusetzen zu können, auf null Tage.
Zu diesem Zeitpunkt hat MAPA sich in weiser Voraussicht den Geschäftsprozess angesehen und erkannt, dass ein Teil des Prozesses so umgestaltet werden kann, dass die Daten niemals im SAP-System verbleiben. Die Notwendigkeit, den Kunden mit Namen und Adresse für den Versand zu identifizieren, besteht nur für eine sehr kurze Zeit und kann auch außerhalb von SAP erfüllt werden. Somit konnten wir wieder zu einem monatlichen Prozess zurückkehren, der besser zu managen ist. Die im Auftrag des Marktplatzes verarbeiteten Daten werden auf den Umfang minimiert, der für die Erfüllung der vertraglichen Pflichten notwendig ist.
Aus meiner Sicht zeigt MAPAs Weg durch diesen Geschäftsprozess, dass die DSGVO eigentlich unglaublich gut durchdacht ist und dass ihre Grundsätze zu einer Verbesserung des Datenschutzes für alle Kunden geführt haben.
Einen Kommentar schreiben