Hintergrund

08. Oktober 2021

Das bedeutet Privacy by Design / by Default im Unternehmensalltag

Gratis

Um die Digitalisierung des Wertschöpfungsprozesses datenschutzkonform zu gestalten, muss „Privacy by Design/Default“ als Unterstützungsprozess etabliert und müssen die Mitarbeitenden angemessen qualifiziert sein

Bild: iStock.com / SeventyFour

4,00 (1)

drucken

Inhalte in diesem Beitrag

Datenschutz von Anfang an

Stellen Sie sicher, dass Softwareentwickler oder die Mitarbeiter von Webagenturen richtig geschult und wirksam in die Organisation eingebunden sind. Denn nur so lässt sich Privacy by Design bzw. by Default umsetzen.

Kennen Sie das auch? Sie als Datenschutzbeauftragter (DSB) sollen beurteilen, ob die neue Unternehmens-App den Datenschutz ausreichend berücksichtigt. Sie sollen den Kunden bestätigen, dass Ihr Unternehmen das neue digitale Produkt datenschutzkonform entwickelt hat. Sie sollen Ihrer Entwicklungs- oder Marketing-Abteilung erklären, wie sie Datenschutz im neuen Internetauftritt umsetzen.

Die Antwort auf all diese Herausforderungen ist eigentlich ganz einfach: Ihr Unternehmen muss „Privacy-by-Design“- bzw. „Privacy-by-Default“-Prinzipien in den betrieblichen Alltag integrieren! Das Wissen hierzu benötigen v.a. diejenigen Mitarbeiterinnen und Mitarbeiter, die daran beteiligt sind, die Applikationen zu entwickeln und zu betreiben.

Genau an dieser Stelle kommen Sie als DSB ins Spiel: Nach Art. 39 Datenschutz-Grundverordnung (DSGVO) obliegt Ihnen die Aufgabe, die Sensibilisierung und Schulung der an der Softwareentwicklung Beteiligten zu überprüfen. Dazu gehören Mitarbeiter in Ihrem eigenen Unternehmen, aber auch solche in den Webagenturen und Softwareentwicklungshäusern, die für Ihr Unternehmen als Zulieferer arbeiten.

Was heißt „Privacy by Design“?

„Privacy by Design bzw. by Default“ ist ein Prinzip, das sicherstellt, dass die beteiligten Rollen relevante Datenschutzanforderungen bereits von Beginn an systematisch ermitteln und während des ganzen Software-Lifecycles berücksichtigen. Schon die Beauftragung der Software muss die Datenschutzanforderungen festschreiben, etwa in Pflichtenheften, User Stories etc., damit sie in die Budgetierung von Zeit und Geld einfließen können.

Datenschutz von Anfang an mitdenken: der Software-Lifecycle

Wichtig für Sie als DSB ist es, dass Sie die Grundprinzipien des sicheren und datenschutzkonformen Software-Lifecycles kennen, um so die Unternehmensstrukturen, die daran beteiligt sind, auditieren zu können. Der Software-Lifecycle gliedert sich grundsätzlich in drei Phasen:

Entstehungsphase – Begin of Life (BoL)

Die Entstehungsphase einer Software durchläuft verschiedene Reifegrade: Ausgehend von der ersten Idee entsteht über die Konzeption, das Festlegen der Softwarearchitektur und die Entwicklung eines Prototyps schließlich eine marktreife Anwendung.

Das „Privacy-by-Design/Default“-Konzept begleitet bereits diese Entstehungsphase und unterstützt bei wichtigen Entscheidungen, um so die zukünftige datenschutzkonforme Nutzung der Anwendung zu ermöglichen. Das gilt etwa hinsichtlich der folgenden Punkte:

Zweck der Anwendung / des Business Case
Umsetzung der Anforderungen aus Art. 12–23 DSGVO (Rechte der betroffenen Person)
Datenmanagement / Data-Lifecycle
Einbindung von Fremdkomponenten
Konzeption technischer und organisatorischer Schutzmaßnahmen („Security by Design“)

Nutzungs- und Service-Phase – Middle of Life (MoL)

Mit der „Middle-of-Life“-Phase beginnt der Einsatz der Anwendung durch den Nutzer. Für gewöhnlich geht damit auch die Verantwortung im Unternehmen von der Entwicklungsabteilung in die Zielorganisation (Vertrieb, Marketing, Service etc.) über. Auch hierbei müssen „Privacy-by-Design/Default“-Aspekte gewährleistet sein, wie beispielsweise

Rechte der betroffenen Person sicherstellen,
Datenpannen erkennen und behandeln (Incident-Management) und
Fehlerbehebung und Patchmanagement für Sicherheitsupdates („Security by Design“).

Nutzungsende – End of Life (EoL) und End of Support (EoS)

Das Nutzungsende kann der Nutzer selbst auslösen (EoL) oder das Softwareunternehmen, indem es den Support für die Anwendung beendet (EoS). Für beide Fälle muss bereits das Design der Anwendung die datenschutzrechtlichen Anforderungen umfassen, etwa:

Rechte der betroffenen Person sicherstellen
Prozess zur datenschutzkonformen Löschung / Archivierung von personenbezogenen Daten vorsehen
Umgang mit personenbezogenen Daten (z.B. digitalen Identitäten und Profilen) bei Deinstallation von Anwendungen sowie ein Konzept zur datenschutzkonformen Entsorgung von Geräten festlegen

Datenschutz als Ingenieursleistung: Was Softwarearchitekten und Produktmanager wissen müssen

Es wäre unrealistisch, aus jedem, der irgendwie an der Anwendungsentwicklung beteiligt ist, einen Datenschutzexperten machen zu wollen, aus jedem Produktmanager, jeder Softwarearchitektin, jedem Entwickler, jeder Testerin. Das ist auch absolut nicht notwendig.

Entscheidend ist vielmehr, immer einen Ansprechpartner zu etablieren, der speziell dafür ausgebildet ist, datenschutzrechtliche Fragestellungen zu erkennen, auf Handlungsbedarf hinzuweisen und praxistaugliche Umsetzungsvorschläge zu unterbreiten. Ein solcher Data Privacy Software Engineer (DPSE) muss über die reine Datenschutz-Grundschulung hinaus weitere spezifische Kenntnisse besitzen und Qualifizierungsmaßnahmen durchlaufen.

Qualifizierung von Data Privacy Software Engineers (DPSE) überprüfen: In diesen Bereichen muss ein(e) Data Privacy Software Engineer (DPSE) ausgebildet werden

Grundsätze des Datenschutzes (Art. 4–11 DSGVO) aus Sicht der Softwareentwicklung
Rechte der betroffenen Person (Art. 12–23 DSGVO)
„Privacy-by-Design“-Grundsätze
DPSE kennen die „7 Grundprinzipien von Privacy by Design“ nach Ann Cavoukian, die „8 Privacy Design Strategien“ nach Jaap-Henk Hoepman und die „Privacy-by-Design“-Empfehlungen der Europäischen Agentur für Netz- und Informationssicherheit (ENISA) und können sie bei der täglichen Arbeit anwenden.
„Security-by-Design“-Grundsätze
DPSE müssen in der Lage sein, Security-Maßnahmen entsprechend dem Stand der Technik in der Anwendung zu implementieren. Hierzu gehört z.B. die richtige Auswahl und Implementierung von Lösch- und Verschlüsselungsroutinen, aber auch Kenntnisse über bekannte Schwachstellen und deren Beseitigung.
Überblick über Methoden und Werkzeuge im Bereich „Privacy und Security by Design“
DPSE kennen erprobte und international anerkannte Vorgehensweisen wie z.B. Attack-Trees, STRIDE oder LINDDUN und können sie in der Unternehmenspraxis anwenden.
„Privacy-by-Design / Default“-Anforderungen aus der Perspektive unterschiedlicher Stakeholder
DPSE müssen die Sichtweisen unterschiedlicher Stakeholder (Datenschutzbeauftragte, B2B-Kunden, Betreiber, betroffene Personen) und ihre Anforderungen an den Datenschutz kennen. DPSE sind in der Lage, diese Anforderungen effizient und praxistauglich in Softwarelösungen umzusetzen. DPSE wissen, welche Inhalte aus Sicht des Datenschutzes für die Dokumentation relevant sind, und können die Datenschutzkonformität einer Anwendung belegen.
Schutzbedarfsanalyse
DPSE kennen Methoden, um den datenschutzrechtlichen Schutzbedarf für eine Softwarelösung aus der Sicht der betroffenen Personen zu ermitteln und zu dokumentieren. Diese Schutzbedarfsanalyse ist der erste Schritt, um Maßnahmen zum Datenschutz risikoorientiert definieren zu können.
Verfahren zur Bedrohungsmodellierung
DPSE sind in der Lage, relevante Bedrohungen für eine Softwarelösung systematisch zu ermitteln und zu dokumentieren,
um konkrete Schutzmaßnahmen spezifizieren zu können.
Datenschutz-Folgenabschätzung (Art. 35 DSGVO)
Datenpannen (Art. 33 DSGVO)
DPSE sind in der Lage, datenschutzkonforme Maßnahmen zum Erkennen und Behandeln von Datenpannen zu entwickeln, insbesondere mithilfe des Log Managements (Definieren, Empfangen, Auswerten, Speichern und Löschen von Protokolldaten).
Technische und organisatorische Maßnahmen
DPSE können technische und organisatorische Maßnahmen definieren, abhängig vom Risiko für die betroffene Person und von technischen Rahmenbedingungen. Dabei können sie klar abgrenzen, welche Maßnahmen sich direkt in der Software implementieren lassen und welche der Betreiber treffen muss. Diese Maßnahmen dokumentieren sie im Betreiberkonzept.
Praktische Anwendung der Privacy-Konzepte, Methoden und Werkzeuge im Entwickleralltag

Praxis-Tipp

Softwarearchitekten und Produktmanager, die qualifiziert sind, „Privacy-by-Design / Default“-Prinzipien umzusetzen, können nicht nur Anwendungen datenschutzkonform entwickeln. Sie verfügen auch über das notwendige Fachwissen, um Produkte auf eine EU-weite Zertifizierung nach den Vorgaben der DSGVO vorzubereiten.

Das bedeutet: Sobald die Deutsche Akkreditierungsstelle (DAkkS) zusammen mit der deutschen Datenschutzkonferenz die Freigabe für die ersten Zertifizierungsverfahren erteilt, haben die Lösungen, die nach Maßgaben von „Privacy- by-Design / Default“ entwickelt wurden, eine ideale Ausgangsposition für ein „Privacy-Siegel“. Das kann ein echter Wettbewerbsvorteil für Unternehmen sein – nicht nur europaweit, sondern weltweit.

Prozesse prüfen

Zu den Kernaufgaben von Datenschutzbeauftragten gehört – neben der fachlichen Beratung und Unterstützung –, Organisationsstrukturen, Unternehmensprozesse sowie die Qualifizierung der daran beteiligten Mitarbeiter und Lieferanten regelmäßig zu prüfen. Mit zunehmender Digitalisierung der Prozesse und Produkte müssen DSB bei der Auditierung ein besonderes Augenmerk auf die Umsetzung der „Privacy-by-Design- / Default“-Prinzipien legen.

Betrachten Sie dafür die klassischen Wertschöpfungsprozesse Entwicklung, Beschaffung sowie Betrieb/Service, die ein unterstützender Prozess „Privacy by Design / Default“ flankiert. Damit sich dieser Prozess praxistauglich und wirksam umsetzen lässt, ist ein Data Privacy Software Engineer (DPSE) nötig. Er oder sie begleitet die Wertschöpfungsprozesse operativ. Die Qualifizierung und Einbindung von DPSE in die Organisationsstruktur müssen DSB im Sinne von Art. 39 DSGVO überprüfen.

Um den „Privacy-by-Design / Default“-Prozess vorausschauend, nachhaltig und effizient in einer Organisation zu implementieren, ist ein entsprechendes Managementsystem unerlässlich. Es überprüft die Wirksamkeit des „Privacy-by-Design / Default“-Prozesses und stellt sicher, dass eine Anpassung an geänderte Anforderungen stattfindet. Um einen solchen Prozess zu überprüfen, sind die folgenden Fragestellungen auf hilfreich.

Privacy by Design und by Default: Auditfragen für Datenschutzbeauftragte

Fazit: DSB sollten sich auf ihre Kernaufgaben konzentrieren

Was bedeutet das konkret?

Vorgaben zur Qualifizierung überprüfen: DSB müssen überwachen, dass Webdesignerinnen, Softwareentwickler, Softwarearchitekten und Produktmanagerinnen, die im Kontext von personenbezogenen Daten entwickeln, eine für ihre Bedürfnisse maßgeschneiderte Qualifizierung durch Schulung und Weiterbildung bekommen haben.
Vorgaben zur Organisationsstruktur auditieren: DSB müssen überwachen, dass Unternehmen klare Zuständigkeiten im Bereich der Software, Web- und App-Entwicklung nach Maßgaben von „Privacy by Design / Default“ aufbauen.
Wirksamkeit überprüfen: DSB müssen in Stichproben überprüfen, ob die Unternehmenspraxis die Organisationsstrukturen und die Qualifizierungen umsetzt und lebt.

Monika Egle, Andreas Zeller, Peter Schmidt

Monika Egle Andreas Zeller Peter Schmidt

Wie nützlich war dieser Beitrag für Sie?

drucken

Verfasst von

Monika Egle

Monika Egle ist Informatikerin und Leiterin des Bereichs Datenschutz und Informationssicherheit bei ditis Systeme in Ulm. Sie gehört dem Ausschuss Berufsbild des Berufsverbands der Datenschutzbeauftragten Deutschlands (BvD) e.V. an.

Andreas Zeller

Andreas Zeller ist Volljurist und Datenschutzberater bei ditis Systeme in Ulm. Er begleitet Softwareentwicklungsprojekte und trainiert Entwicklungsabteilungen. Er ist EuroPriSe-Experte im Bereich Recht.

Peter Schmidt

Peter Schmidt verantwortet den Bereich Digitale Produktsicherheit bei ditis System in Ulm und hat langjährige Berufserfahrung als Softwareentwicklungsleiter. Er bereitet Unternehmen u.a. auf die Zertifizierung nach IEC 62443 vor.

zu den Kommentaren