DSGVO im Alltag der Architekten und Entwickler von Software

DSGVO im Alltag der Architekten und Entwickler von Software

Die DSGVO hat die Herangehensweise in Softwareprojekten grundlegend verändert – sollte man zumindest meinen, nachdem man sich einen ersten Überblick über die Vorgaben verschafft hat. Vor allem die Cookie-Meldungen auf Webseiten erinnern uns ständig daran, dass Unternehmen und Behörden an ihren IT-Lösungen gearbeitet haben. Doch der Geist der DSGVO wollte mehr erreichen: ein grundsätzliches Bewusstsein um den Umgang mit personenbezogenen Daten. Und das sollte sich auf (fast) jedes Softwareprojekt auswirken.

Aber hat es das auch? Sind die Grundsätze bei Softwarearchitekten, Datenanalysten und Softwareentwicklern angekommen? Ist es bereits zu einer Gewohnheit geworden, Verfahrensverzeichnisse zu pflegen und die Lebensdauer eines Datensatzes zu definieren, der personenbezogene Informationen enthält?

Dieser Artikel richtet sich an alle Experten, die Software erstellen, pflegen und betreiben. Darüber hinaus versuche ich den Artikel auch für Nicht-ITler verständlich zu halten, denn gerade auch die Kollegen aus dem Marketing oder aus HR/Personal stellen an die IT regelmäßig Anforderungen, die die Verwendung von personenbezogenen Daten einschließen. Der Artikel soll helfen, sich und das eigene Team zu sensibilisieren und den Geist der Verordnung zu verstehen. So ist es möglich, die Verordnung in der täglichen Arbeit einzuhalten. Dann kann man bei der Umsetzung des Datenschutzes agieren – anstatt gezwungen zu werden, kurzfristig zu reagieren.

Das Auskunftsbegehren

Früher oder später wird der Zeitpunkt kommen, wo ein Unternehmen zu reagieren hat. Da kommt eine E-Mail dem Sinne nach:

„Sehr geehrte Damen und Herren,

 

auf Grundlage des Artikel 15 der DSGVO bitte ich um Auskunft, welche Daten zu meiner Person bei Ihnen gespeichert sind, zu welchen Zwecken Sie diese speichern und verarbeiten, wann Sie diese löschen werden und an wen meine Daten weitergegeben wurden.“

Eine andere Variante könnte lauten:

„Auf der Grundlage des Artikel 15 Abs. 3 bitte ich um Kopien der Daten, die sich auf meine Person beziehen.“

Noch spannender wird es, wenn bezugnehmend auf Artikel 17 eine Person die Einwilligung zur Verarbeitung der Daten widerruft oder die unverzügliche Löschung bestimmter oder aller auf sie bezogenen Daten fordert.

Der Hintergrund des Auskunftsrechts

Das Auskunftsrecht ist nicht dazu da, Rechtsabteilungen mit der Abwehr zu beschäftigen oder damit enttäuschte Kunden Unternehmen schikanieren können. Tatsächlich stehen nachvollziehbare Gründe hinter diesem Recht. Zur DSGVO existieren zahlreiche „Erwägungsgründe“, die helfen, Regelungen zu verstehen und diese umzusetzen. So lautet der Erwägungsgrund 63 auszugsweise:

„Eine betroffene Person sollte ein Auskunftsrecht hinsichtlich der sie betreffenden personenbezogenen Daten, die erhoben worden sind, besitzen und dieses Recht problemlos und in angemessenen Abständen wahrnehmen können, um sich der Verarbeitung bewusst zu sein und deren Rechtmäßigkeit überprüfen zu können. … Jede betroffene Person sollte daher ein Anrecht darauf haben zu wissen und zu erfahren, insbesondere zu welchen Zwecken die personenbezogenen Daten verarbeitet werden und, wenn möglich, wie lange sie gespeichert werden, wer die Empfänger der personenbezogenen Daten sind, nach welcher Logik die automatische Verarbeitung personenbezogener Daten erfolgt und welche Folgen eine solche Verarbeitung haben kann, zumindest in Fällen, in denen die Verarbeitung auf Profiling beruht. Nach Möglichkeit sollte der Verantwortliche den Fernzugang zu einem sicheren System bereitstellen können, der der betroffenen Person direkten Zugang zu ihren personenbezogenen Daten ermöglichen würde. Dieses Recht sollte die Rechte und Freiheiten anderer Personen, etwa Geschäftsgeheimnisse oder Rechte des geistigen Eigentums und insbesondere das Urheberrecht an Software, nicht beeinträchtigen. Dies darf jedoch nicht dazu führen, dass der betroffenen Person jegliche Auskunft verweigert wird. Verarbeitet der Verantwortliche eine große Menge von Informationen über die betroffene Person, so sollte er verlangen können, dass die betroffene Person präzisiert, auf welche Information oder welche Verarbeitungsvorgänge sich ihr Auskunftsersuchen bezieht, bevor er ihr Auskunft erteilt.“

Die Erwartung von Datenschutzbehörden

Wie die Antwort auf ein Auskunftsbegehren aussehen sollte, haben Datenschutzbehörden inzwischen konkretisiert. Das Bayerische Landesamt für Datenschutzaufsicht hat beispielsweise ein Musterantwortschreiben veröffentlicht.

Das Verzeichnis von Verarbeitungstätigkeiten

Um ein Auskunftsbegehren beantworten zu können, muss ein Unternehmen zunächst einmal wissen, in welchen IT-Lösungen und Datenbanken potentiell personenbezogene Daten gespeichert sein können. Das war früher, als es eine zentrale Unternehmenssoftware gab, schon nicht gerade leicht zu beantworten. Heute, wo die Vorteile der Microservice-Architektur dieser zu einem Siegeszug verholfen hat, können Daten zu einer Person von mehreren Programmen (Services) verarbeitet und gespeichert werden. Was in vielen Fällen Vorteile mit sich bringt, wird hier zu einem Nachteil: dass Prinzip der Microservices, dass jeder Service seinen eigenen Datenspeicher bzw. seine eigene Datenbank haben sollte, statt auf eine einzige zentrale Datenbank zuzugreifen.

Doch genau dabei, nämlich bei der Suche nach potentiellen Speicherorten, sollte eine weitere Vorschrift helfen: das Verzeichnis von Verarbeitungstätigkeiten. Es wird in Artikel 30 beschrieben. Dieses Verzeichnis zu haben und es aktuell zu halten, ist nicht nur hilfreich; Aufsichtsbehörden, wie das bereits zitierte Bayrische Landesamt für Datenschutzaufsicht, können Einsicht in das Verzeichnis eines Unternehmens fordern. Dass die Behörden das auch zunehmend tun, verrät ein Blick auf deren Internetseiten.

Den Teufel nicht an die Wand malen

Dann ist da noch das gestiegene Risiko, dass vertrauliche Daten an die Öffentlichkeit oder an Unbefugte gelangen. Man spricht dann von einem „data breach“, einer Datenpanne oder einem Datenleck. Wer seine öffentlichen IP-Adressen überwacht, dürfte bestätigen: die Anzahl der Eindringversuche durch Hacker hat 2019 massiv zugenommen. Doch das Risiko, dass Daten des Unternehmens in unbefugte Hände gelangen, lässt sich nicht alleine an der Firewall eliminieren: immer häufiger gelangen Daten von innen nach außen, weil Mitarbeiter E-Mail-Anhänge oder Webseiten geöffnet haben, durch die auf Rechnern im Unternehmen – hinter der Firewall – Schadsoftware installiert wurde, die dann fleißig Daten sammelt und nach draußen weiterleitet.

Dann ist da noch das Risiko, dass Mitarbeiter Daten nach außen geben, entweder aufgrund von menschlichem Versagen oder Sabotage. In der englischen Wikipedia existiert der Artikel „List of data breaches“, der sicher nur die Spitze des Eisberges auflistet. Interessant ist dabei die Spalte „Method“. Es überrascht, wie häufig „accidentally published“ oder „inside job“ zu finden sind.

Auffällig ist ebenfalls, dass für 2019 kaum Unternehmen mit Sitz in der EU zu finden sind. Dabei schreibt Artikel 33 vor, dass eine Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden an die Aufsichtsbehörde zu melden ist – was natürlich nicht bedeutet, dass eine Verletzung auch öffentlich bekannt wird. Der Artikel definiert außerdem, welche Angaben die Meldung zu enthalten hat. Darüber hinaus sind gemäß Artikel 34 von einem Datenleck betroffene Personen zu verständigen, sofern von einem hohen Risiko für die persönlichen Rechte und Freiheiten auszugehen ist.

Damit eine Meldung frist- und formgerecht erfolgen kann und ggf. auch Betroffene informiert werden, sollten unternehmensinterne Prozesse existieren. Auch muss bekannt sein, welche Art von Daten in welchem IT-System verarbeitet werden, um im Fall eines Schadens auch handeln zu können. Auch dabei hilft ein aktuelles Verzeichnis von Verarbeitungstätigkeiten.

DSGVO in Fleisch und Blut

Für erfahrene Architekten und Entwickler ist es in Fleisch und Blut übergegangen, auf Wartbarkeit, Einfachheit, Kompaktheit und Robustheit/Qualität von Code zu achten. DRY ist nur eines der Konzepte, Unit Tests ein Weiteres. Auch wenn es zunächst einmal zusätzliche Zeit kostet, Unit Tests zu entwerfen und zu schreiben, so hat sich die Erkenntnis durchgesetzt, dass man letztendlich Zeit und Kosten spart. Zeit und Kosten, vor allem auch empfindliche Strafen, kann man auch sparen, wenn Architekten und Entwickler noch ein weiteres Prinzip verinnerlichen: das Bewusstsein um die besondere „Empfindlichkeit“ von personenbezogenen Daten. Um dieses Bewusstsein aufzubauen, sollte man sich mindestens diese drei Artikel der DSGVO zu verinnerlichen:

• Artikel 5
  Hier werden 6 Grundsätze genannt, die bei der Verarbeitung personenbezogener Daten einzuhalten sind. Diese sind:

   

  • Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz
  • Zweckbindung
  • Datenminimierung, also Datensparsamkeit
  • Richtigkeit
  • Speicherbegrenzung, was bedeutet, jede gespeicherte Information mit einem Löschdatum zu versehen
  • Integrität und Vertraulichkeit

Der Artikel erinnert auch daran, dass ein Unternehmen, bzw. um genau zu sein, die dort verantwortliche Person, rechenschaftspflichtig ist.

• Artikel 6
  Zählt 6 Umstände auf, unter denen die Verarbeitung und Speicherung personenbezogener Daten überhaupt legal ist. Artikel 8 erweitert diese noch um besondere Bedingungen für die Daten von Kindern.
• Artikel 32
  beschreibt Grundsätze, Verfahren und Verhaltensregeln, um die Sicherheit der Daten sicherzustellen. Dazu gehören Pseudonymisierung, Verschlüsselung aber auch Konzepte, zur Wiederherstellung der Daten bei einem physischen oder technischen Zwischenfall.

DSGVO in der täglichen Routine

Zusammengefasst sollte ein Architekt oder ein Entwickler folgendes bedenken, wenn ein Stück Software entsteht, das personenbezogene Daten verarbeitet oder speichert:

• Diese Information kann durch eine Person durch ein Auskunftsbegehren abgefragt werden und muss dann in der Auskunft aufgeführt werden.
• Die Person oder eine Aufsichtsbehörde können einen Nachweis verlangen, dass die Verarbeitung einer Information rechtens war.
• Die Person kann die Löschung einzelner oder aller Daten verlangen, wobei Ausnahmen bestehen und gewisse Daten aufgrund anderer regulatorischer Vorgaben erst nach Ablauf einer Aufbewahrungsfrist gelöscht werden dürfen.
• Die Information muss nach einer gewissen Zeit automatisch gelöscht werden.
• Die Information kann unberechtigt offengelegt werden. Dann sind Melde- und ggf. Informationspflichten einzuhalten.
• Personenbezogene Daten sind zu pseudonymisieren und zu verschlüsseln.
• Eine Wiederherstellung der Daten ist bei einem physischen oder technischen Zwischenfall sicherzustellen.

Wie lassen sich diese Anforderungen erfüllen? Auch hier führen viele Wege nach Rom. Besonders spannend wird es, wenn individuelle Softwarelösungen nach einer Microservice-Architektur entworfen wurden und/oder diese in der Cloud betrieben werden.

Sie wollen auf meine Erfahrung zurückgreifen?

Dann freue ich mich auf Ihren Kontakt.

Disclaimer 

Der Artikel schöpft aus meinen Erfahrungen aus unterschiedlichen Projekten bei verschiedenen Kunden aus 20 Monaten in Vorbereitung auf die DSGVO und in deren Umsetzung. Ich bin kein Jurist und kann daher auch keine verbindlichen Aussagen treffen. Dieser Artikel ist keine Rechtsberatung und ersetzt auch keine. Entsprechend muss ich eine Haftung aufgrund meiner Aussagen ausschließen.