7. Juni 2018

Der agile Entwickler und die DSGVO: Alles nicht mein Bier?

Susanne Walter

Betrifft die DSGVO nur Marketingexperten, Webseiteninhaber und Rechtsanwälte? Haben wir Entwickler jetzt Zeit, die Füße hochzulegen? Leider nein. Warum? Lest ihr hier.

 

Wir alle haben in den letzten Wochen hunderte Nachrichten mit neuen Datenschutzbestimmungen und Mails mit mehr oder minder dringenden Bitten auf einen Button zu klicken bekommen. Aber soll man deswegen in Hektik verfallen? Oder  ergänzt nicht ein bisschen ist-mir-egal eine gemeinhin optimistische Einstellung und lockere Start-Up-Mentalität ganz gut?

Wir wiegen uns in einer Sicherheit, die nicht DSGVO-kompatibel ist. Denn sie betrifft nicht nur eine hübsche, seitenlange Datenschutzerklärung auf unserer Website, sondern – oha! – unseren alltäglichen Umgang mit Daten. Wenn wir also nicht nur statischen Content ohne jegliche Interaktion programmieren (wollen), betrifft es auch uns.

Na gut, was ist denn das?

Die neue DSGVO (Datenschutzgrundverordnung) ist eigentlich das alte BDSG (Bundesdatenschutzgesetz) – nur europäisch und etwas verändert. Zum Beispiel umfasst die Definition, was denn nun eine Verarbeitung personenbezogener Daten genau ist, einen ganzen Absatz. Verarbeitung ist nämlich im Grunde schon das reine anzeigen oder auch speichern. Und personenbezogene Daten? Eigentlich jeder Datensatz, mit dem man ein Datum einer natürlichen Person zuordnen kann. Und das beinhaltet ja nun mal auch die IP-Adresse. Aber nicht nur!

Genau da wachen wir Entwickler gemeinhin wieder auf. Umgang mit Datensätzen und IP-Adressen – muss also doch etwas mit uns zu tun haben! Die DSGVO fordert Privacy by Design und Privacy by Default. Und das müssen wir als Entwickler ja gleich beim Entwickeln der Software mit beachten – spart am Ende aufwändige und teure Nachbesserungen und macht beim Kunden mehr Eindruck. Denn wer möchte schon eine Software übergeben, die den imaginären Stempel trägt „Kannste so nicht (datenschutzkonform) verwenden“. Also wohl doch keine Zeit zum Füße hochlegen. Schauen wir uns das mal in einem imaginären agilen Projekt genauer an:

Vor Beginn

…kommen die Verträge. Während des Vertragsabschlusses kann man schon mal vorfühlen, wer denn der Datenschutzbeauftragte des Kunden ist. So kann im Falle einer Bedenklichkeit ein Austausch unter den Datenschutzbeauftragten beider Beteiligten stattfinden.

Auch ein Auftragsverarbeitungsvertrag müsste geschlossen werden, sobald wir mit Daten unseres Kunden arbeiten. Den am Besten ins firmeninterne wiki ablegen, so kann jeder aus dem Team, vor allem aber PO oder Scrum Master die Produktwünsche des Kunden besser einschätzen und sich mit der Materie mal beschäftigen. Ist übrigens im Sinne der agilen Transparenz auch für Projektverträge gut.

Vielleicht wäre es auch hilfreich ein Berechtigungskonzept fürs Team zu erarbeiten: Wer hat Zugriff auf Produktivdaten und wo liegen die? Gibt es innerhalb des Teams ein gemeinsames Verständnis? Wenn ihr also Daten beim Kunden ändern könnt, achtet auf ein Logging für die Nachvollziehbarkeit.

Am Anfang war die User Story.

Aber dann geht es los! Der PO bespricht mit den Stakeholdern den Funktionsumfang und die Anforderungen an das spätere Produkt. Ob hier also datenschutzrelevante Funktionen eine Rolle spielen, sollte schnell klar sein: Woran? Zum Beispiel an der User Story: sind hier personenbezogene Daten erwähnt, wie z.B. die Eingabe von Name, Geburtsdatum o.ä. in einem Buchungsdialog, sollte auch der PO hellhörig werden und die User Story um die datenschutzrechtlichen Belange erweitern. Dazu kann gehören:

  • Datenschutzfreundliche Voreinstellungen
  • Datenverschlüsselung
  • Festlegung von Speicherfristen
  • Protokollierung von Zustimmungen

Die Umsetzung

Bei der Umsetzung müssen wir immer wieder darauf achten, Userdaten zu anonymisieren. Vielmehr noch sollten wir ebenfalls ein Auge darauf haben, wie Daten überhaupt in unser System gelangen: Gerne nehmen wir nämlich einfach Produktivdaten für das Testing – keine gute Idee. Zudem müssen Daten verschlüsselt und vor unberechtigtem Zugriff geschützt werden. Aber ist nun jegliche Verarbeitung personenbezogener Daten verboten? Generell gesehen ja. (Und das war übrigens schon vor der DSGVO so!) Aber es gibt zwei Ausnahmen:

  1. Die Einwilligung des Users.
    Wichtig ist hierbei, dass VOR der Einwilligung klar sein muss, welche Daten dann erhoben werden. Das ist beispielsweise bei Cookies von Belang. Bevor der User nicht „ich stimme zu“ geklickt hat, dürfen keine Cookies gesetzt werden.
  2. Die gesetzliche Erlaubnis.
    Dazu gehört zum Beispiel die Notwendigkeit zur Vertragserfüllung. Das ist zum Beispiel der Fall, wenn ich eine Anfrage stelle und der Adressat schließlich meine Mailadresse zum Antworten braucht. Oder die Bank deine Bankdaten.

Die Einwilligung muss freiwillig erfolgen. So darf die Funktion einer Software nicht in Abhängigkeit von z.B. Social Media Accounts funktionieren. Eine Software muss so entwickelt werden, dass sie auch bei Nicht-Einwilligung der Datenverarbeitung grundsätzlich funktioniert. Denn das Kopplungsverbot schreibt auch vor, dass wir den User nicht mit einem quasi „Serviceentzug“ in seiner Einwilligung „bestechen“. Also Privacy by Default: Datenschutz durch datenschutzfreundliche Voreinstellungen. Auch das gilt es in der Softwareentwicklung zu beachten.

Die Verarbeitung, wenn sie nun also erlaubt ist, muss dann zweckgebunden sein, transparent gemacht werden – also verständlich sein (das ist auch der Grund für die Hunderten Mails) – und es dürfen nur so wenig Daten wie möglich erhoben werden. Die Daten dürfen auch nur so lange gespeichert werden, wie es für die Vertragserfüllung notwendig ist.

Diese und weitere Punkte sollten sich also nicht erst bei einem Auskunftsersuchen panisch in unseren Gesichtern widerspiegeln, sondern von vorn herein bedacht sein. Privacy by Design liefert hier gute Ansätze. Datenschutz funktioniert eben am Besten, wenn er bereits bei der Entwicklung und Programmierung des Datenverarbeitungsvorgangs technisch mit eingebaut wurde.

Daran gedacht?

Auch wenn wir keine Fans von plötzlichem (und viel zu häufig blindem) Aktivismus sind, gilt es ein paar Punkte in unserem Alltag zu beachten.

So müssen wir unsere Ticketsysteme im Auge behalten: wer kennt nicht, dass dort plötzlich die ein oder andere Telefonnummer landet. Oder der Kollege hat eine E-Mail geschickt, in deren Anhang sich sensible Daten befinden. Und das Backup der letzten Datenmigration befindet sich auch noch auf unserem Rechner?

Oder eine aktivierte Fernwartung der Firmware zum Beispiel. Also diese vielleicht lieber deaktivieren. Wir müssen nicht übereifrig werden, aber im Hinterkopf einfach unseren (möglichen!) Datenfluss behalten. Auch eine Festplattenverschlüsselung kann nicht schaden. Und im selben Zug daran denken, dass eben auch das Backup dann nicht ungesichert irgendwo herum liegt. Lieber verschlüsseln und offsite bereithalten. Ach und nicht vergessen, alle Mitarbeiter mit ein paar Denkanstößen zu schulen, in welchen Ecken der Datenschutz so zu finden ist.

Und später?

Im laufenden Betrieb der Software muss dann der Kunde und Betreiber darauf achten, dass alles datenschutzkonform läuft. Und vielleicht Tests dafür schreiben, ob alles richtig funktioniert sowie mal einen Datenexport testen, falls morgen ein Auskunftsersuchen eingeht.

Wir sehen, dass in allen Phasen der Softwareentwicklung Datenschutz eine Rolle spielt – und somit auch für alle Beteiligten eines agilen Softwareentwicklungsteams.

Lean Softwaredevelopment unterstützt im Grunde die datenschutzkonforme Entwicklung. Denn Daten, die nicht gebraucht werden, sollten nicht erhoben werden. Das ist in der Praxis nicht immer ganz einfach. Gerade bei bestehenden Infrastrukturen. Doch gerade bei Projekten, die neu beginnen, sind wir (eigentlich schon seit Einführung des BDSG) dazu verpflichtet, auch diesen Aspekt im Hinterkopf zu haben.

Und warum agil?

Agile Methoden und Vorgehensweisen eignen sich gut, um mit der DSGVO umzugehen. Allen voran: Pragmatismus. Also ran an die Website, muss erstmal nicht schön sein, sondern funktionieren. Das Feilen folgt als zweiter Schritt. Und nicht vergessen: Transparenz: Nach außen hin werden wir gerade dazu gezwungen, nach innen hin hilft es, wenn auch die Kollegen wissen, warum einige Entwickler gerade etwas ermattet aussehen oder brüsk auf „lustige“ GDPR-Posts reagieren. Im Sinne der Crossfunktionalität sollten auch alle im Bilde sein, was genau die Verordnung verlangt und auch wozu wir nun verpflichtet sind.

Also ganz im agilen Sinne: Anfangen und machen und dann ansehen und daraus lernen. Von uns aus auch mit Bier. Moment noch: Rechner sperren, bevor ihr in die wohlverdiente Pause geht!

 

Susanne Walter
Organisationscounselor | Veränderungsbegleiterin

Rufen Sie uns an: 030 – 555 74 70 0

Made with 
in Berlin. 
© leanovate 2025