Warum die DSGVO eine neue Quelle für technische Schulden ist

Die EU-Datenschutzgrundverordnung (EU-DSGVO) stellt digitale Unternehmen und deren IT vor große Herausforderungen. Es braucht neue Prozesse, in der Regel auch neue Software und natürlich die dazu jeweils passende Dokumentation. Diese Komplexität birgt ein besonders großes Risiko, mit „Quick and Dirty“-Designs technische Schulden aufzubauen. In diesem Artikel erfahren Sie, nach welchen Prinzipien eine softwaretechnische Architektur gestaltet werden muss, sodass Sie diese Risiken umgehen.

Technische Schulden sind eine „Metapher für die Folgen unzureichender Entwicklung eines Pro­dukts, um kurzfristige Nutzen zu erreichen, die aber spätere Arbeiten verteuern“ (Ebert 2014). Sie entstehen insbesondere dann, wenn ein Projekt mal wieder den zeitlichen oder finanziellen Rahmen sprengt und die Entscheidungsträger – meist ohne viel technischem Verständnis – auf eine sogenannte „Quick-and-Dirty“-Lösung drängen. Jede dieser Entscheidungen verlagern Aufwände indirekt aus dem Projekt in die Linie, zum Beispiel indem der Betrieb oder die Wartung des Prozesses bzw. der Software teurer wird (Lilienthal 2017).

Hatte sich ein Unternehmen etwas zu spät mit der Umsetzung der DSGVO befasst, mussten in kürzester Zeit nicht nur Datenschutzbeauftragte qualifiziert, installiert und bekannt gemacht werden oder die AGBs aktualisiert werden. Es mussten auch alle Geschäftsprozesse hinsichtlich ihrer Informationsflüsse durchleuchtet werden, die personenbezogene Daten direkt oder indirekt (z. B. durch Verknüpfung) verarbeiten oder speichern. Die daraus gewonnenen Erkenntnisse zahlen auf die Rechenschaftspflicht ein und münden unmittelbar in Anpassungen zur Erfüllung von Vorgaben wie Transparenz, Zweckbindung und Datenminimierung.

Es gab also eine Menge zu tun und insbesondere für digitale Unternehmen ist dieser Prozess offenbar noch lange nicht abgeschlossen – das können Sie selbst schnell herausfinden: Fragen Sie einfach mal bei Gelegenheit ein paar willkürlich ausgewählte Online-Vertragspartner nach Ihren personenbezogenen Daten. Sie werden erstaunt sein, wie unterschiedlich qualitativ die Antworten sind, sofern Sie überhaupt eine Antwort in der gesetzlichen Frist erhalten.

Auch hier führten in einigen Unternehmen der zeitliche Druck und die Komplexität der Aufgabe sicherlich zu einer Menge schlechter Entscheidungen, die den Berg an technischen Schulden wachsen ließen. Doch jeder eingeführte Prozess und jede in Betrieb genommene Software, der bzw. die nicht von Beginn an hinsichtlich der Speicherung und Verarbeitung personenbezogener Daten gestaltet wurde, führt später an anderer Stelle zu enormen Aufwänden, zum Beispiel wenn Kunden, Lieferanten oder Mitarbeiter ihre Auskunfts- oder Löschrechte in Anspruch nehmen.

Dabei gibt es bereits seit vielen Jahren eine Menge guter Konzepte, mit denen vermieden werden kann, dass die Inanspruchnahme von Datenschutzrechten eine Organisation oder einen Prozess sprengt. Dazu zählt zum Beispiel der Ansatz Privacy-By-Design, dessen Prinzipien dabei helfen, Software-Architekturen von Beginn an unter der Berücksichtigung aktueller Datenschutzrechte technisch zu gestalten (Langheinrich 2001). Sie lauten wie folgt:

1. Transparenz über Art und Umfang der Speicherung und Verarbeitung personenbezogener Daten herstellen, z. B. durch die Implementierung technischer Protokolle wie P3P, EPAL, XACML oder APPEL (Nigusse 2009).
2. Zustimmung einholen über die transparent gemachte Speicherung und Verarbeitung, z. B. über einen (digital signierten) Mini-Vertrag, der vor der Benutzung der Software auf einer Portalseite vereinbart wird – idealerweise mit verschiedenen Auswahlmöglichkeiten, die es der Person erlauben, in verschiedenen Abstufungen zwischen Datenschutz und Funktionalität zu wählen.
3. Anonymisieren und Pseudonymisieren von personenbezogenen Daten, um den strengen gesetzlichen Rahmenbedingungen für die Datenverarbeitung zu entkommen, z.B. durch Entfernen bzw. Austauschen von Identifikationsmerkmalen wie Kundennummern. Diese Daten können auch abgespalten werden, müssen dann aber getrennt aufbewahrt werden.
4. Lokalitätsprinzip wahren, indem Daten nur dann gesammelt oder preisgegeben werden, wenn die betroffene Person in unmittelbarer Nähe oder eingeloggt ist. Ein Smart Home-Lautsprecher würde beispielsweise nur dann „lauschen“, wenn der Besitzer in unmittelbarer Reichweite ist (darstellbar etwa dadurch, dass sein Smartphone unter der Liste erreichbarer Bluetooth-Geräte aufgeführt wird).
5. Angemessene Datensicherheit zum Beispiel durch – dem aktuellen Stand der Technik angemessene – Verschlüsselungsmechanismen sicherstellen. Hier eignen sich auch Hosting-Angebote, bei denen selbst der Provider keinen Zugriff auf die Daten hat („Sealed Cloud“).

Kurzum: Der Weg zu einer DSGVO-konformen, langlebigen Softwarearchitektur ohne (viel) technische Schulden führt immer auch an einem im Designprozess fest verankerten Privacy-Konzept vorbei, das den Architekten die wesentlichen Prinzipien – und idealerweise auch die passenden unternehmensinternen Lösungsbausteine – vor Augen hält. Auf diese Weise können aufwändige und fehleranfällige manuelle Recherchen in den Prozessen und Datenbeständen vermieden werden, sollten die Kunden oder Lieferanten mal ihre Rechte tatsächlich in Anspruch nehmen.

Literatur

• Ebert, C. (2014): Systematisches Requirements Engineering. 5. Auflage, dpunkt, Heidelberg
• Langheinrich, M. (2001): Privacy by Design – Principles of Privacy-Aware Ubiquitous Systems. In: Gregory D. Abowd/Barry Brumitt/Steven Shafer (Hg.), Ubicomp 2001, Springer, Berlin.
• Lilienthal, C. (2017): Langlebige Software-Architekturen. 2. Auflage, dpunkt, Heidelberg
• Nigusse, G (2009): Capabilities and Limitations of P3P. Report CW 539, Dep. of Computer Science, Universität Leuven.