Privacy by Design

Privacy by Design in der Softwareentwicklung

Was bedeutet es, wenn eine Software nicht im Sinne von Privacy by Design (Art 25 DSGVO) entwickelt wurde? Welche konkreten Aspekte müssen im Bereich der Softwareentwicklung berücksichtigt werden, um diesem zentralen Prinzip der DSGVO gerecht zu werden? Mehr dazu in diesem Artikel:

Problemstellung

Im Zuge der Anschaffung von Software, Software Due Diligence Prüfungen und Datenschutz-Folgenabschätzungen gelangt immer wieder eines zum Tageslicht: Die geprüfte Software wurde nicht im Sinne des Prinzipes von Privacy by Design entwickelt und programmiert. Die Konsequenzen daraus sind schwerwiegend: Interessenten nehmen von einem Kauf (respektive Miete) der Software Abstand, Investoren suchen das Weite, der betriebswirtschaftliche Wert der Software sinkt drastisch. Hinzu kommt, dass eine Software, die nicht im Sinne von Privacy by Design entwickelt wurde, mangelhaft im Sinne des Gewährleistungsrechts sein kann.

Was bedeutet Privacy by Design konkret?

Was heißt es konkret, eine Software im Sinne von Privacy by Design zu entwickeln? Wer zu dieser Frage eine klare Antwort in Gesetzestexten sucht, wird enttäuscht. Vielmehr bedarf es einer Gesamtschau aus verschiedenen Dokumenten im Bereich des “Soft-Laws” (zB ISO 27001, ISO 27701, ISO 25000, Leitlinienvorschlag des Europäischen Datenschutzausschusses), um konkrete Handlungsanweisungen ableiten zu können.

Hands on: Praktische Empfehlungen

Aus all diesen Dokumenten kann folgende zentrale Erkenntnis für die Softwareentwicklung gewonnen werden: Datenschutz und Datensicherheit muss durch ein entsprechendes Qualitätsmanagement während des gesamten Lebenszyklus der Software nachweisbar respektiert werden. Konkret bedeutet das, dass bereits in der Entwicklungsphase bei der Erreichung der einzelnen Quality Gates Datenschutz und Datensicherheit zu prüfen ist. Dieser Prozess sollte von einer entsprechenden Compliance-Richtlinie begleitet werden. Diese Compliance-Richtlinie wiederum sollte jedenfalls auch die Aspekte: Urheberrecht, Open Source Lizenzen und Geschäfts- und Betriebsgeheimnisse abdecken. Schließlich ist sicherzustellen, dass diese Compliance-Richtlinie den involvierte Projektbeteiligten – allen voran den Entwicklern – durch Awarenessschulungen zur Kenntnis gebracht wird.

Fazit und Handlungsempfehlung

Zeit, Kosten und Qualität bilden das “magische Dreieck” im Projektmanagement. Eine Komponente beeinflusst die andere. Vor diesem Hintergrund wäre es unökonomisch, sämtliche Ressourcen in den Bereich “Compliance” zu investieren. ABER, es ist sehr kurzfristig gedacht, die Faktoren Datenschutz und Datensicherheit erst in einem späten Entwicklungsstadium zu beachten. Eine Software, die nicht nach den Grundsätzen von Privacy by Design programmiert wurde, wird nämlichen keinen vernünftigen Abnehmer finden. Und wenn doch, handelt es sich bei einer solch sorglos entwickelten Software um eine tickende Haftungsfalle.

Möglicherweise interessant: Know-How-Schutz in der IT-Branche

Autor: Tobias Tretzmüller