Privacy by Design nach Art. 25 DSGVO: Datenschutz technisch und organisatorisch von Anfang an verankern

Privacy by Design bezeichnet den Grundsatz, Datenschutz nicht nachträglich an ein fertiges System anzuflanschen, sondern bereits bei der Konzeption von Verfahren, Software und Prozessen zu berücksichtigen. In der Datenschutz-Grundverordnung ist dieser Gedanke in Art. 25 verankert und gilt für jeden Verantwortlichen, unabhängig von Branche und Unternehmensgröße. In der Praxis wird die Vorschrift dennoch häufig unterschätzt: Neue Systeme werden beschafft, eingeführt und erst danach datenschutzrechtlich geprüft, wenn die Konfiguration längst festgelegt und die Schulung der Beschäftigten abgeschlossen ist. Nachträgliche Korrekturen sind dann teuer, technisch aufwendig und bleiben oft Stückwerk. Dieser Beitrag erläutert, was Art. 25 DSGVO konkret verlangt, wie sich Privacy by Design und Privacy by Default voneinander abgrenzen und welche technischen und organisatorischen Maßnahmen sich im Mittelstand bewährt haben. Ergänzend werden ein Praxisbeispiel, typische Stolperfallen, ein Vorgehen in sieben Schritten und eine Checkliste vorgestellt, mit denen Geschäftsführung, IT und Datenschutzverantwortliche das Thema strukturiert angehen können. Der Beitrag richtet sich an Fachverantwortliche, die Datenschutz als festen Bestandteil der Systemgestaltung und nicht als nachgelagerte Pflichtübung verstehen wollen.

Hinweis: Dieser Beitrag gibt ausschließlich die redaktionellen Ansichten der Redaktion von cyberschutzbetrieb.de wieder. Er stellt keine Rechts- oder Steuerberatung dar und ersetzt nicht die Beratung durch qualifizierte Fachleute. Für verbindliche Auskünfte zu Ihrem konkreten Fall wenden Sie sich bitte an eine zugelassene Beratung.

Titelbild: Foto von FlyD auf Unsplash.

Was Privacy by Design bedeutet und was Art. 25 DSGVO verlangt

Art. 25 Abs. 1 DSGVO verpflichtet den Verantwortlichen, sowohl zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der Verarbeitung selbst geeignete technische und organisatorische Maßnahmen zu treffen. Diese Maßnahmen sollen die Datenschutzgrundsätze wirksam umsetzen, etwa die Datenminimierung, und die notwendigen Garantien in die Verarbeitung aufnehmen. Die Vorschrift nennt dabei ausdrücklich die Pseudonymisierung als Beispiel.

Maßgeblich ist ein risikobasierter Ansatz. Der Verantwortliche muss den Stand der Technik, die Implementierungskosten sowie Art, Umfang, Umstände und Zwecke der Verarbeitung berücksichtigen. Ebenso zählen die Eintrittswahrscheinlichkeit und die Schwere der Risiken für die Rechte und Freiheiten natürlicher Personen. Je sensibler die Daten und je größer die Auswirkungen auf Betroffene, desto strenger fallen die Anforderungen aus.

Die Pflicht trifft den Verantwortlichen, also das Unternehmen, nicht den Softwarehersteller. Hersteller werden in Erwägungsgrund 78 lediglich ermutigt, Datenschutz bei der Entwicklung zu berücksichtigen. Wer eine Software einsetzt, bleibt dennoch selbst verantwortlich und muss prüfen, ob das Produkt die Anforderungen erfüllt oder sich entsprechend konfigurieren lässt.

Datenschutz, der erst nach der Einführung eines Systems geprüft wird, ist keine Gestaltung, sondern eine Reparatur.

Privacy by Design und Privacy by Default im Vergleich

Beide Begriffe stehen in derselben Vorschrift, adressieren aber unterschiedliche Fragen. Privacy by Design betrifft die Architektur und die Prozessgestaltung, Privacy by Default die Ausgangseinstellungen, mit denen ein System ausgeliefert oder in Betrieb genommen wird.

Aspekt	Privacy by Design (Art. 25 Abs. 1)	Privacy by Default (Art. 25 Abs. 2)
Kernfrage	Wie ist das Verfahren grundsätzlich aufgebaut?	Welche Einstellungen gelten ohne Zutun der Nutzenden?
Zeitpunkt	Konzeption und laufender Betrieb	Inbetriebnahme und jede Neukonfiguration
Typische Maßnahmen	Pseudonymisierung, Rollenmodell, Trennung von Datenbeständen, Löschroutinen	Minimale Pflichtfelder, kurze Speicherfristen, eingeschränkte Zugriffe, keine öffentliche Sichtbarkeit
Verantwortung	Verantwortlicher, unterstützt durch IT und Fachbereich	Verantwortlicher, umgesetzt in der Konfiguration
Nachweis	Konzept, Architekturentscheidungen, Risikobewertung	Konfigurationsdokumentation, Prüfprotokolle

Privacy by Default verlangt nach Art. 25 Abs. 2 DSGVO, dass standardmäßig nur diejenigen personenbezogenen Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind. Das gilt für die Menge der erhobenen Daten, den Umfang der Verarbeitung, die Speicherfrist und die Zugänglichkeit. Insbesondere dürfen personenbezogene Daten nicht ohne Eingreifen der betroffenen Person einer unbestimmten Zahl von Personen zugänglich gemacht werden.

Die Datenschutzgrundsätze als Gestaltungsmaßstab

Art. 25 DSGVO verweist auf die Grundsätze des Art. 5 DSGVO. Für die Gestaltung lassen sich daraus konkrete Leitfragen ableiten, die bei jedem neuen Verfahren gestellt werden sollten.

• Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz: Gibt es eine tragfähige Rechtsgrundlage, und wissen Betroffene verständlich, was mit ihren Daten geschieht?
• Zweckbindung: Ist der Zweck vor der Erhebung festgelegt und dokumentiert, und werden die Daten nur dafür genutzt?
• Datenminimierung: Werden nur die Daten erhoben, die für den Zweck erforderlich sind, oder werden Felder aus Gewohnheit abgefragt?
• Richtigkeit: Gibt es Wege, falsche Daten zu erkennen und zu berichtigen?
• Speicherbegrenzung: Sind Löschfristen festgelegt, und löscht das System automatisch oder erinnert es an die Löschung?
• Integrität und Vertraulichkeit: Sind Zugriffe, Verschlüsselung und Protokollierung dem Schutzbedarf angemessen?
• Rechenschaftspflicht: Lässt sich nachweisen, dass die Maßnahmen umgesetzt wurden?

Hilfreich ist ergänzend das Standard-Datenschutzmodell der deutschen Aufsichtsbehörden. Es übersetzt die rechtlichen Anforderungen in Gewährleistungsziele wie Datenminimierung, Vertraulichkeit, Integrität, Verfügbarkeit, Transparenz, Intervenierbarkeit und Nichtverkettung. Diese Ziele eignen sich gut als Raster für Konzepte, weil sie sowohl Juristen als auch Technikern vertraut gemacht werden können.

Technische Maßnahmen für Privacy by Design

Technische Maßnahmen setzen die Anforderungen in Systemen und Konfigurationen um. Sie sollten möglichst früh festgelegt werden, weil sich Architekturentscheidungen später nur mit hohem Aufwand ändern lassen. Die folgende Übersicht zeigt gängige Maßnahmen, die dazugehörigen Grundsätze und typische Einsatzfelder.

Maßnahme	Unterstützter Grundsatz	Typisches Einsatzfeld
Pseudonymisierung und Trennung von Identifikationsdaten	Datenminimierung, Vertraulichkeit	Auswertungen, Testdaten, Analysesysteme
Rollen- und Berechtigungskonzept nach dem Need-to-know-Prinzip	Vertraulichkeit, Integrität	ERP, CRM, Personalverwaltung
Verschlüsselung bei Speicherung und Übertragung	Vertraulichkeit	Laptops, Backups, Dateiablagen, E-Mail-Transport
Automatische Löschroutinen und Aufbewahrungsfristen	Speicherbegrenzung	Bewerbungsdaten, Protokolle, Kundenakten
Protokollierung von Zugriffen und Änderungen	Integrität, Rechenschaftspflicht	Verwaltungssysteme mit sensiblen Daten
Mandantentrennung und logische Datensilos	Zweckbindung, Nichtverkettung	Gemeinsam genutzte Plattformen
Datensparsame Formulare und optionale Felder	Datenminimierung	Webformulare, Onboarding, Kundenportale
Anonymisierung für Statistik und Berichte	Datenminimierung	Auswertungen für die Geschäftsleitung

Pseudonymisierung richtig einsetzen

Pseudonymisierte Daten bleiben personenbezogen, solange die Zuordnung mit zusätzlichen Informationen möglich ist. Der Gewinn liegt in der Risikoreduzierung: Wer Auswertungen mit Pseudonymen durchführt und die Zuordnungstabelle getrennt und zugriffsgeschützt aufbewahrt, begrenzt die Folgen eines Zugriffs auf den Analysebestand erheblich. Wichtig ist, dass die Trennung organisatorisch abgesichert ist, etwa durch unterschiedliche Berechtigungen für die Zuordnungstabelle.

Testdaten und Entwicklungsumgebungen

Ein häufig übersehener Punkt sind Testumgebungen. Werden Echtdaten aus dem Produktivsystem in Test- oder Entwicklungsumgebungen kopiert, fehlen dort oft Zugriffsbeschränkungen und Löschroutinen. Besser sind synthetische oder anonymisierte Testdaten. Lässt sich die Verwendung von Echtdaten nicht vermeiden, sollten dieselben Schutzmaßnahmen wie im Produktivbetrieb gelten.

Organisatorische Maßnahmen und Verantwortlichkeiten

Technik allein genügt nicht. Privacy by Design braucht klare Zuständigkeiten, feste Prüfpunkte im Projektablauf und geschulte Beteiligte. Die folgenden organisatorischen Bausteine haben sich in mittelständischen Unternehmen bewährt.

• Datenschutz im Projektablauf verankern: Bei jedem neuen Verfahren, jeder Softwarebeschaffung und jeder wesentlichen Änderung erfolgt eine Datenschutzprüfung vor der Entscheidung, nicht danach.
• Verantwortliche benennen: Der Fachbereich trägt die Verantwortung für das Verfahren, IT und Datenschutzbeauftragte beraten und prüfen.
• Anforderungskatalog für Beschaffung: Datenschutzanforderungen werden in Lastenheft und Auswahlkriterien aufgenommen und mit Anbietern verbindlich geklärt.
• Schulung: Entwickler, Administratoren und Fachbereiche kennen die Grundprinzipien und erkennen Situationen, in denen eine Prüfung erforderlich ist.
• Freigabeprozess: Ein Verfahren geht erst in den Produktivbetrieb, wenn die dokumentierten Datenschutzanforderungen erfüllt sind.
• Regelmäßige Überprüfung: Konfigurationen und Berechtigungen werden in festen Abständen und nach Änderungen kontrolliert.

Privacy by Design bei Beschaffung und Auswahl von Software

Im Mittelstand wird Software überwiegend eingekauft, nicht selbst entwickelt. Privacy by Design bedeutet hier, den Datenschutz zum Auswahlkriterium zu machen. Vor Vertragsschluss sollten folgende Punkte geklärt sein.

1. Welche personenbezogenen Daten verarbeitet das Produkt, und sind alle erhobenen Felder für den Zweck erforderlich?
2. Lassen sich Voreinstellungen datenschutzfreundlich konfigurieren, etwa Speicherfristen, Sichtbarkeit und Protokollumfang?
3. Gibt es ein Rollen- und Berechtigungskonzept mit ausreichender Granularität?
4. Wie werden Löschung, Auskunft und Berichtigung technisch unterstützt?
5. Wo werden Daten verarbeitet, und ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO vorgesehen?
6. Welche Unterauftragnehmer sind beteiligt, und wie ist die Verarbeitung außerhalb des Europäischen Wirtschaftsraums geregelt?
7. Welche Nachweise liefert der Anbieter, etwa Zertifizierungen oder Prüfberichte?

Art. 25 Abs. 3 DSGVO erlaubt, ein genehmigtes Zertifizierungsverfahren als Faktor zum Nachweis der Erfüllung heranzuziehen. Eine Zertifizierung ersetzt jedoch nicht die eigene Prüfung, ob das Produkt im konkreten Einsatz die Anforderungen erfüllt.

Praxisbeispiel: Kundenportal für einen Maschinenbauer

Ein mittelständischer Maschinenbauer plant ein Kundenportal, über das Servicekunden Wartungsaufträge anlegen, Dokumente abrufen und Ersatzteile bestellen. Im ersten Entwurf des Dienstleisters sollen bei der Registrierung Name, Telefonnummer, private Anschrift und Geburtsdatum erhoben werden, jeder Benutzer eines Kundenkontos soll alle Aufträge der Firma sehen können, und Protokolle sollen unbefristet gespeichert werden.

Eine Datenschutzprüfung vor Vertragsschluss führt zu mehreren Änderungen. Pflichtfelder werden auf geschäftliche Kontaktdaten reduziert, das Geburtsdatum entfällt, weil es für den Zweck nicht erforderlich ist. Ein Rollenmodell trennt Administratoren des Kunden von Sachbearbeitern, sodass nicht jeder alle Aufträge einsehen kann. Protokolle werden nach einer festgelegten Frist automatisch gelöscht, und Downloads personenbezogener Daten werden protokolliert.

Entscheidend ist der Zeitpunkt: Weil die Anforderungen im Lastenheft standen, entstanden keine Mehrkosten durch Nachprogrammierung. Hätte das Unternehmen erst nach dem Go-live geprüft, wäre dieselbe Anpassung als Änderungsauftrag angefallen, mit Verzögerung und zusätzlichem Aufwand.

Dokumentation und Nachweis

Die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO verlangt, dass der Verantwortliche die Einhaltung der Grundsätze nachweisen kann. Für Privacy by Design bedeutet das, Entscheidungen nachvollziehbar zu dokumentieren. Es genügt nicht, dass Maßnahmen existieren, sie müssen belegbar sein.

• Beschreibung des Verfahrens mit Zweck, Datenkategorien, Empfängern und Löschfristen im Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO
• Risikobewertung und gegebenenfalls Datenschutz-Folgenabschätzung nach Art. 35 DSGVO bei hohem Risiko
• Dokumentierte Architekturentscheidungen, etwa zur Trennung von Datenbeständen und zur Pseudonymisierung
• Konfigurationsstände der datenschutzrelevanten Einstellungen mit Datum und Verantwortlichem
• Prüfprotokolle, Freigaben und Nachweise zu Schulungen
• Verträge und Nachweise der Dienstleister, insbesondere Auftragsverarbeitungsverträge

Der Verstoß gegen Art. 25 DSGVO kann nach Art. 83 Abs. 4 DSGVO mit Bußgeldern von bis zu 10 Millionen Euro oder bis zu 2 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Die tatsächliche Höhe richtet sich nach den Umständen des Einzelfalls. Den vollständigen Verordnungstext stellt die EU im Portal EUR-Lex bereit.

Häufige Stolperfallen

• Datenschutz als Schlussabnahme: Die Prüfung erfolgt kurz vor dem Start, wenn Änderungen nur noch schwer möglich sind.
• Standardeinstellungen unverändert übernommen: Das System wird mit den Voreinstellungen des Herstellers betrieben, obwohl diese mehr Daten sammeln, als erforderlich ist.
• Pflichtfelder aus Gewohnheit: Formulare fragen Daten ab, die niemand auswertet.
• Fehlende Löschlogik: Daten werden erhoben, aber nie gelöscht, weil kein Verfahren dafür vorgesehen ist.
• Zu weite Berechtigungen: Aus Bequemlichkeit erhalten alle Beschäftigten Vollzugriff.
• Echtdaten in Testsystemen: Produktivdaten werden ungeschützt in Entwicklungsumgebungen kopiert.
• Keine Dokumentation: Maßnahmen existieren, lassen sich aber gegenüber Aufsichtsbehörden oder Kunden nicht belegen.
• Verantwortungslücke: Fachbereich, IT und Datenschutz schieben sich die Zuständigkeit gegenseitig zu.

Schritt für Schritt zur Umsetzung im Unternehmen

1. Bestandsaufnahme durchführen: Alle Verfahren mit personenbezogenen Daten erfassen, beginnend mit denen mit dem höchsten Risiko.
2. Prüfpunkt im Projektprozess festlegen: Für Neuentwicklung, Beschaffung und wesentliche Änderungen eine verbindliche Datenschutzprüfung vor der Entscheidung einführen.
3. Anforderungskatalog erstellen: Standardanforderungen zu Datenminimierung, Rollenkonzept, Löschung, Protokollierung und Verschlüsselung formulieren.
4. Voreinstellungen prüfen: Bestehende Systeme auf datensparsame Konfiguration kontrollieren und Abweichungen beheben.
5. Verantwortliche zuweisen: Je Verfahren eine fachlich verantwortliche Person benennen, IT und Datenschutz beratend einbinden.
6. Dokumentation aufbauen: Entscheidungen, Konfigurationen und Prüfungen strukturiert ablegen und mit dem Verarbeitungsverzeichnis verknüpfen.
7. Wirksamkeit überprüfen: In festen Abständen Stichproben ziehen und die Maßnahmen an veränderte Verfahren anpassen.

Privacy by Design in der Praxis kleiner Organisationen

Nicht jedes Unternehmen verfügt über eine eigene Entwicklungsabteilung oder ein Datenschutzteam. Der Grundsatz lässt sich dennoch pragmatisch umsetzen, weil das Gesetz ausdrücklich die Implementierungskosten und die Größe der Verarbeitung berücksichtigt. Kleine Unternehmen müssen nicht dieselben Maßnahmen ergreifen wie ein Konzern, sie müssen aber eine begründete, dokumentierte Abwägung treffen.

Ein einfacher Einstieg besteht in einer Kurzprüfung für jedes neue Verfahren mit fünf Fragen: Welche Daten werden benötigt, wer braucht Zugriff, wie lange werden die Daten gespeichert, wie sind sie geschützt und wie wird die Löschung sichergestellt? Die Antworten werden schriftlich festgehalten und bilden die Grundlage für Konfiguration und Vertragsgestaltung. Dieser Ansatz erzeugt wenig Aufwand und liefert zugleich den Nachweis, dass Datenschutz bei der Planung berücksichtigt wurde.

Checkliste für die Praxis

• Für jedes neue Verfahren ist eine Datenschutzprüfung vor der Entscheidung vorgesehen
• Zweck, Datenkategorien und Rechtsgrundlage sind dokumentiert
• Erhobene Daten sind auf das Erforderliche beschränkt
• Voreinstellungen sind datensparsam konfiguriert und dokumentiert
• Ein Rollen- und Berechtigungskonzept nach dem Need-to-know-Prinzip existiert
• Löschfristen sind festgelegt und technisch oder organisatorisch umgesetzt
• Verschlüsselung und Protokollierung entsprechen dem Schutzbedarf
• Testumgebungen verwenden keine ungeschützten Echtdaten
• Dienstleister sind geprüft, Auftragsverarbeitungsverträge liegen vor
• Verantwortlichkeiten sind benannt, Prüfungen finden regelmäßig statt

Fazit

Privacy by Design ist keine Zusatzaufgabe für Juristen, sondern ein Gestaltungsprinzip, das Technik, Organisation und Fachbereiche gemeinsam umsetzen. Wer Anforderungen früh festlegt, spart späteren Aufwand, reduziert Risiken und kann gegenüber Kunden, Aufsichtsbehörden und Geschäftspartnern belegen, dass Datenschutz ernst genommen wird. Der wirksamste Hebel liegt im Prozess: ein fester Prüfpunkt vor jeder Beschaffung und jeder wesentlichen Änderung, ein schlanker Anforderungskatalog und eine saubere Dokumentation. Perfektion ist dafür nicht erforderlich, wohl aber Konsequenz.

FAQ

Was ist der Unterschied zwischen Privacy by Design und Privacy by Default?
Privacy by Design betrifft die datenschutzfreundliche Gestaltung von Verfahren und Systemen insgesamt, Privacy by Default die datensparsamen Voreinstellungen. Beides ist in Art. 25 DSGVO geregelt und ergänzt sich.

Gilt Art. 25 DSGVO auch für kleine Unternehmen?
Ja, die Pflicht trifft jeden Verantwortlichen. Der Umfang der Maßnahmen richtet sich jedoch nach Risiko, Stand der Technik, Kosten und Art der Verarbeitung, sodass kleinere Unternehmen proportional angepasste Lösungen wählen können.

Wer ist für Privacy by Design verantwortlich, der Hersteller oder das Unternehmen?
Verantwortlich ist das Unternehmen, das die Daten verarbeitet. Hersteller sollen den Gedanken bei der Entwicklung berücksichtigen, tragen aber nach Art. 25 DSGVO keine unmittelbare Pflicht. Anwender müssen prüfen, ob eingesetzte Produkte die Anforderungen erfüllen.

Reicht eine Zertifizierung des Softwareanbieters als Nachweis?
Eine Zertifizierung kann nach Art. 25 Abs. 3 DSGVO als Faktor dienen, ersetzt aber nicht die eigene Prüfung. Das Unternehmen muss beurteilen, ob das Produkt im konkreten Einsatz und in der gewählten Konfiguration die Anforderungen erfüllt.

Wann ist eine Datenschutz-Folgenabschätzung erforderlich?
Nach Art. 35 DSGVO, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Sie ergänzt Privacy by Design, indem sie Risiken und Gegenmaßnahmen strukturiert bewertet.

Welche Folgen hat ein Verstoß gegen Art. 25 DSGVO?
Möglich sind Anordnungen der Aufsichtsbehörde und Bußgelder nach Art. 83 Abs. 4 DSGVO. Darüber hinaus drohen Reputationsschäden und höhere Folgekosten, wenn Systeme nachträglich umgebaut werden müssen.