- 1 Section
- 11 Lessons
- unbegrenzt
- DSGVO & Datenschutz11
- 1.1Entstehung und Ziele der DSGVO
- 1.2Grundprinzipien der DSGVO (Art. 5)
- 1.3Betroffenenrechte (Art. 15–22)
- 1.4TOMs – Technische und organisatorische Maßnahmen
- 1.5Auftragsverarbeitungsvertrag (AVV)
- 1.6Datenpanne: Meldepflichten und Fristen
- 1.7Datenschutzbeauftragter, VVT und DSFA
- 1.8DSGVO im Entwicklungskontext: Privacy by Design
- 1.9Beschäftigtendatenschutz: § 26 BDSG
- 1.10Bußgelder, Aufsichtsbehörden und Praxisfälle
- 1.11IHK-Aufgaben DSGVO
DSGVO im Entwicklungskontext: Privacy by Design
Datenschutz nachträglich in eine fertige Software einzubauen ist wie Sicherheitsgurte in ein bereits gebautes Auto einzuschrauben – es geht, aber es ist teuer, unbequem und nie so gut wie ab Werk. Privacy by Design (Datenschutz durch Technikgestaltung, Art. 25 DSGVO) fordert, dass Datenschutz von Anfang an in die Softwareentwicklung eingebaut wird – nicht als Zusatz, sondern als Grundprinzip. Zusammen mit Privacy by Default (datenschutzfreundliche Voreinstellungen) ist es die wichtigste Datenschutznorm für Entwickler.
1) Privacy by Design vs. Privacy by Default
Beide Konzepte stehen in Art. 25 DSGVO und ergänzen sich. Privacy by Design sagt: Baue Datenschutz in die Architektur ein. Privacy by Default sagt: Stelle Datenschutz als Standard ein, sodass Nutzer aktiv abwählen müssen – nicht aktiv anwählen. Das ist der Unterschied zwischen einem vorab angekreuzten Newsletter-Häkchen (verboten) und einem leeren Häkchen, das der Nutzer aktiv setzen muss (korrekt).
| Privacy by Design | Privacy by Default | |
|---|---|---|
| Was es bedeutet | Datenschutz als Grundlage der Systemarchitektur | Datenschutzfreundlichste Einstellung als Standard |
| Wann relevant | Bei der Entwicklung / Architekturentscheidung | Bei der Konfiguration / beim Produktlaunch |
| Beispiel gut | Passwörter werden nie im Klartext gespeichert | Newsletter ist ab Werk deaktiviert |
| Beispiel schlecht | Datenschutz als Plugin nachgerüstet | Alle Benachrichtigungen ab Werk aktiviert |
2) Die sieben Privacy-by-Design-Prinzipien (nach Cavoukian)
3) Konkrete Umsetzung in der Entwicklung
Privacy by Design lässt sich auf verschiedenen Ebenen umsetzen – von der Datenbankmodellierung bis zum API-Design.
| Bereich | Privacy-by-Design-Maßnahme |
|---|---|
| Datenerhebung | Nur erforderliche Felder im Formular. Pflichtfelder auf das Minimum reduzieren. Kein Geburtsdatum ohne Grund. |
| Datenbank | Pseudonymisierung: Nutzer-ID statt Name in Protokollen. Sensible Felder verschlüsselt speichern (z.B. bcrypt für Passwörter). |
| Zugriffskontrolle | RBAC von Anfang an: kein Admin-Zugriff by Default. Least Privilege: jede Rolle nur die nötigen Rechte. |
| Löschung | Soft-Delete mit geplanter Löschung statt dauerhafter Speicherung. Automatische Löschfristen implementieren. |
| Logging | Keine personenbezogenen Daten in Logdateien. IP-Adressen anonymisieren oder nur verschlüsselt loggen. |
| API-Design | Minimale Daten in API-Antworten – nicht jedes Feld mitschicken, das in der DB steht. HTTPS erzwingen. |
Zusammenfassung
Privacy by Design (Art. 25 DSGVO) verlangt, dass Datenschutz von Anfang an in die Softwarearchitektur eingebaut wird – nicht nachgerüstet. Privacy by Default verlangt datenschutzfreundliche Standardeinstellungen. Die sieben Prinzipien nach Cavoukian umfassen proaktiven Ansatz, Default Privacy, eingebauten Datenschutz, volle Funktionalität, End-to-End-Sicherheit, Transparenz und Nutzerkontrolle. In der Entwicklungspraxis bedeutet das: Datenminimierung, Pseudonymisierung, RBAC, automatische Löschfristen und keine sensiblen Daten in Logs. Zusammen mit den TOMs und den Betroffenenrechten ist es das Kernwerkzeug für datenschutzkonforme Softwareentwicklung.
