DSGVO Artikel 25 in der Praxis. Was Privacy by Design rechtlich verlangt, wenn man es ernst meint.

Wer mit einer kleinen App in Deutschland startet und sich an den geltenden Datenschutz halten will, trifft früh auf die Formel „Privacy by Design“. Sie taucht in Datenschutzerklärungen auf, in Marketing-Texten, in Produkt-Beschreibungen. Sie ist auch ein Begriff aus Artikel 25 der DSGVO, und in dieser Eigenschaft ist sie nicht optional, sondern verpflichtend. Die Frage ist, was die Pflicht praktisch heißt.

Was Artikel 25 wörtlich sagt

Artikel 25 Absatz 1 verlangt vom Verantwortlichen, unter Berücksichtigung des Stands der Technik, der Implementierungskosten, der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere der Risiken sowohl zum Zeitpunkt der Festlegung der Mittel als auch zum Zeitpunkt der Verarbeitung selbst geeignete technische und organisatorische Maßnahmen zu treffen, die dazu bestimmt sind, die Datenschutzgrundsätze wirksam umzusetzen und die notwendigen Garantien in die Verarbeitung aufzunehmen, um den Anforderungen der Verordnung zu genügen und die Rechte der betroffenen Personen zu schützen.

Absatz 2 ergänzt eine zweite Pflicht: Die Voreinstellungen müssen so beschaffen sein, dass per Default nur die personenbezogenen Daten verarbeitet werden, die für den konkreten Zweck nötig sind. Das betrifft die Menge der erhobenen Daten, die Tiefe der Verarbeitung, die Speicherdauer und die Zugänglichkeit. Eine App, die per Default Telemetrie an einen Cloud-Dienst sendet, erfüllt diese Pflicht nicht, auch wenn sie sich abschalten lässt.

Beide Pflichten richten sich an den Verantwortlichen, also typischerweise die Betreiberin der App oder des Dienstes. Die EDPB-Guideline 4/2019 betont, dass Artikel 25 die gesamte Lebensphase der Verarbeitung umfasst, von der Anforderungsdefinition über die Implementierung bis zum Betrieb und der späteren Anpassung.

Was „Stand der Technik“ bedeutet

Die Verordnung verlangt geeignete Maßnahmen unter Berücksichtigung des Stands der Technik. Das ist keine Pflicht zur teuersten verfügbaren Lösung, sondern eine Pflicht, die etablierten Verfahren zu kennen und begründen zu können, warum man sich für eine bestimmte Variante entschieden hat. Pseudonymisierung, Verschlüsselung, getrennte Datenhaltung, Zugriffskontrollen, automatische Löschfristen, lokale Datenhaltung sind alle Beispiele für Maßnahmen, die in einschlägigen Empfehlungen, etwa von BSI und ENISA, beschrieben sind.

Eine kleine Praxis kann nicht alles umsetzen, was theoretisch möglich wäre. Sie muss aber dokumentieren, was sie geprüft und warum sie sich für oder gegen eine Maßnahme entschieden hat. Die Risiko-Abwägung ist Teil der Konformität.

Voreinstellungen sind das praktische Herzstück

Artikel 25 Absatz 2 ist in der Praxis oft die wirksamste Bestimmung, weil sie sich in konkreten UI- und Architektur-Entscheidungen niederschlägt. Ein Newsletter-Formular, bei dem die Tracking-Cookies per Default abgeschaltet sind, erfüllt sie. Eine App, die Standort nur fragt, wenn die Funktion ihn wirklich braucht, erfüllt sie. Eine Patientendokumentation, die per Default nur die Felder anzeigt, die für die aktuelle Sitzung nötig sind, erfüllt sie.

Die Pflicht ist damit eine Pflicht zur Sparsamkeit ab Werk. Sie kehrt das übliche Muster um, bei dem die Nutzerin alles Mögliche ausschalten muss, was sie nicht will. Stattdessen muss die Anbieterin alles aktivieren müssen, was sie verarbeiten will.

Privacy by Default ist die einzige Stelle in der DSGVO, an der die Verordnung dem Anbieter eine konkrete UI-Pflicht auferlegt. Die Voreinstellung selbst ist die Maßnahme.

Lokale Datenhaltung als technische Maßnahme

Eine der wirksamsten Maßnahmen unter Artikel 25 ist die lokale Datenhaltung, also Speicherung und Verarbeitung auf dem Gerät der Nutzerin, ohne Übermittlung an Server der Anbieterin. Wenn personenbezogene Daten den Geräte-Speicher nie verlassen, sind sie für Dritte nicht erreichbar. Keine Cloud-Sync-Risiken, keine Datenlecks beim Anbieter, keine behördlichen Auskunftsersuchen, keine Schrems-II-Probleme bei Drittlandstransfer.

Lokale Datenhaltung passt nicht für jede Anwendung. Wenn der Wert der Anwendung in der Synchronisation zwischen Geräten oder in serverseitiger Analyse liegt, ist sie nicht möglich. Für viele Anwendungen, vor allem im Gesundheits- und Sozial-Bereich, ist sie aber sinnvoll und realistisch. Eine ergänzende Perspektive zur Architektur-Seite findet sich in Privacy by Design in Gesundheits-Apps.

Wichtig: Lokale Datenhaltung allein erfüllt Artikel 25 nicht automatisch. Sie muss dokumentiert sein, mit klarer Auflistung, welche Daten lokal bleiben, welche Telemetrie (falls überhaupt) den Server erreicht, wie Backups gehandhabt werden (wenn lokal, dann lokal verschlüsselt; wenn Cloud-Backup, dann ist das eine Übermittlung), und wie das mit den Datenschutzgrundsätzen aus Artikel 5 zusammenhängt.

Was Aufsichtsbehörden konkret prüfen

Die deutschen Datenschutzbehörden orientieren sich am Standard-Datenschutzmodell (SDM), das die Datenschutzgrundsätze in sieben Schutzziele übersetzt: Verfügbarkeit, Integrität, Vertraulichkeit, Transparenz, Intervenierbarkeit, Nichtverkettung, Datenminimierung. Jedes dieser Ziele ist mit konkreten Prüfmaßstäben hinterlegt.

Bei einer Prüfung sehen Aufsichtsbehörden typischerweise nach:

• der Dokumentation der Verarbeitungstätigkeiten nach Artikel 30,
• der Begründung, warum bestimmte Daten erhoben werden und nicht andere,
• den Voreinstellungen der Anwendung,
• dem Konzept für Speicherdauer und Löschung,
• den technischen Maßnahmen für Vertraulichkeit und Integrität (Verschlüsselung, Zugriffskontrolle),
• der dokumentierten Risiko-Abwägung,
• der Datenschutz-Folgenabschätzung, falls Artikel 35 sie verlangt.

Das Wichtigste ist die Konsistenz zwischen Dokumentation und Praxis. Eine sauber geschriebene Verarbeitungs-Dokumentation, die nicht der Realität entspricht, ist schlechter als eine knappe Dokumentation, die genau das beschreibt, was die Anwendung tut.

Was für eine kleine Praxis bleibt

Für ein kleines Studio läuft Artikel 25 auf wenige praktische Punkte hinaus. Bevor codiert wird: Welche Daten brauchen wir wirklich, und welche nicht? Welche Voreinstellungen wählen wir? Wo bleiben die Daten? Während entwickelt wird: Werden diese Entscheidungen versionskontrolliert dokumentiert? Werden sie überprüft, wenn sich Anforderungen ändern? Nach dem Release: Gibt es einen Prozess, der die Verarbeitungs-Dokumentation aktuell hält?

Nichts davon ist mit einer Compliance-Abteilung verbunden. Es ist sorgfältiges Produkt-Engineering, das mit dem Recht zusammenfällt. Die Verordnung verlangt nicht mehr, aber auch nicht weniger.

Häufige Fragen

Was verlangt Artikel 25 DSGVO konkret?

Artikel 25 Absatz 1 verlangt, dass Verantwortliche unter Berücksichtigung des Stands der Technik, der Kosten und der Risiken der Verarbeitung geeignete technische und organisatorische Maßnahmen treffen, die die Datenschutzgrundsätze umsetzen. Absatz 2 fordert datenschutzfreundliche Voreinstellungen: per Default werden nur die personenbezogenen Daten verarbeitet, die für den konkreten Zweck nötig sind. Beide Pflichten sind nicht optional, ihre Verletzung kann mit bis zu 10 Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes geahndet werden.

Reicht es, in der Datenschutzerklärung 'Privacy by Design' zu erwähnen?

Nein. Artikel 25 verlangt umgesetzte Maßnahmen, nicht eine Erklärung. Aufsichtsbehörden, etwa die EDPB-Guideline 4/2019, machen deutlich, dass die Pflicht eine kontinuierliche ist: bereits in der Planung, dann während der Verarbeitung selbst. Eine reine Textstelle in der Datenschutzerklärung ohne dokumentierte Entscheidungen erfüllt sie nicht.

Hilft lokale Datenhaltung bei Artikel 25?

Lokale Datenhaltung ist eine der wirksamsten technischen Maßnahmen unter Artikel 25, weil sie das Risiko der Verarbeitung an der Quelle reduziert. Wenn keine personenbezogenen Daten den Geräte-Speicher der Nutzer:innen verlassen, sind sie für Dritte nicht erreichbar, weder durch Datenlecks beim Anbieter noch durch behördliche Anfragen. Die Maßnahme muss aber dokumentiert sein, mit klarer Beschreibung, welche Daten lokal bleiben und welche (falls überhaupt) den Server erreichen.

Was prüfen Aufsichtsbehörden bei Artikel 25?

Die deutschen Datenschutzbehörden orientieren sich am Standard-Datenschutzmodell (SDM) der Datenschutzkonferenz, das die Datenschutzziele (Verfügbarkeit, Integrität, Vertraulichkeit, Transparenz, Intervenierbarkeit, Nichtverkettung, Datenminimierung) in praktische Prüfmaßstäbe übersetzt. Geprüft werden typischerweise: dokumentierte Entscheidungen über Datenminimierung, Voreinstellungen, Speicherdauer-Konzept, Architekturentscheidungen mit Datenschutzbezug, und ob die Umsetzung den dokumentierten Maßnahmen entspricht.