DSGVO-konforme Softwareentwicklung: Privacy by Design in der Praxis

Art. 25 DSGVO verlangt Datenschutz durch Technikgestaltung — Privacy by Design. Für Softwareentwickler bedeutet das: Datenschutz ist keine nachträgliche Compliance-Übung, sondern eine Architekturentscheidung. Wer eine Software von Grund auf datenschutzkonform plant, spart sich aufwändige Nachbesserungen und vermeidet Bußgeldrisiken. Dieser Leitfaden zeigt, wie DSGVO-konforme Softwareentwicklung in der Praxis funktioniert.
Wir sehen eine moderne KI-Grafik. Im Hintergrund angedeutet die DSGVO als Vertrag. Im Vordergrund symbolisiert ein IT-Sicherheitszeichen DSGVO-konforme Softwareentwicklung.
© javu

Was DSGVO-konforme Softwareentwicklung bedeutet

Die Datenschutz-Grundverordnung enthält zwei Artikel, die für Softwareentwicklung unmittelbar relevant sind. Art. 25 verlangt „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen” — im Fachjargon: Privacy by Design und Privacy by Default. Art. 32 fordert „geeignete technische und organisatorische Maßnahmen” (TOM) zum Schutz personenbezogener Daten.

Für Auftraggeber, die Software entwickeln lassen, bedeutet das: Die DSGVO-Konformität einer Anwendung beginnt nicht bei der Datenschutzerklärung auf der Website. Sie beginnt beim Datenmodell, bei der Zugriffsarchitektur und bei den Löschroutinen. Wer Software in Auftrag gibt, die personenbezogene Daten verarbeitet, trägt als Verantwortlicher die Pflicht, diese Anforderungen bereits in der Konzeptionsphase sicherzustellen — nicht erst beim Audit.

Privacy by Design fordert, dass Datenschutzmaßnahmen von Anfang an in die Software eingebaut werden. Das betrifft die Architektur, nicht die Oberfläche. Eine Anwendung, die Daten erst erhebt und dann fragt, ob sie das durfte, ist konzeptionell fehlerhaft — unabhängig davon, wie gut die nachträgliche Einwilligungsabfrage gestaltet ist.

Privacy by Default verlangt, dass die datenschutzfreundlichste Konfiguration die Standardeinstellung ist. Keine vorausgewählten Checkboxen, keine standardmäßig aktivierten Tracking-Funktionen, keine unnötig weiten Datenfreigaben. Der Nutzer muss aktiv entscheiden, mehr preiszugeben — nicht weniger.

Privacy by Design: Datenschutz als Architekturprinzip

Ann Cavoukian, die ehemalige Datenschutzbeauftragte der kanadischen Provinz Ontario, hat in den 1990er Jahren sieben Grundsätze für Privacy by Design formuliert. Sie sind abstrakt — aber für Softwarearchitekten lassen sie sich in konkrete Entwurfsentscheidungen übersetzen.

Datenminimierung als Designprinzip. Die Frage lautet nicht: Welche Daten können wir erheben? Sondern: Welche Daten brauchen wir für genau diesen Zweck? Ein Registrierungsformular, das den Geburtsnamen der Mutter abfragt, obwohl ein E-Mail-Konto angelegt wird, verstößt gegen dieses Prinzip. In der Architektur bedeutet das: Das Datenmodell spiegelt den Verarbeitungszweck — nicht mehr. Felder, die „vielleicht später nützlich” sein könnten, haben in einem datenschutzkonformen Entwurf nichts verloren.

Zweckbindung im Datenmodell. Personenbezogene Daten werden für einen definierten Zweck erhoben und nur für diesen verarbeitet. In der Software heißt das: Klare Trennung zwischen Datensätzen für unterschiedliche Verarbeitungszwecke. Eine Kundendatenbank für die Rechnungsstellung hat andere Zugriffsregeln als eine für das Marketing — auch wenn beide auf derselben Infrastruktur laufen.

Automatisierte Löschroutinen. Art. 17 DSGVO gewährt Betroffenen ein Recht auf Löschung. Art. 5 Abs. 1 lit. e begrenzt die Speicherdauer. In der Praxis bedeutet das: Software muss Löschroutinen nicht nur ermöglichen, sondern automatisieren. Wenn der Verarbeitungszweck entfällt, werden die Daten gelöscht — ohne manuelle Intervention. Speicherfristen werden im System konfiguriert, nicht in einem Word-Dokument festgehalten.

Transparenz durch Audit-Logs und Auskunftsfunktionen. Art. 15 DSGVO gibt Betroffenen das Recht auf Auskunft über ihre gespeicherten Daten. Software muss dieses Recht technisch unterstützen: Export-Funktionen, Protokollierung der Zugriffe, nachvollziehbare Verarbeitungshistorien. Audit-Logs dokumentieren, wer wann welche Daten eingesehen oder verändert hat — ein Pflichtbestandteil jeder datenschutzkonformen Architektur.

Technische und organisatorische Maßnahmen (TOM) in der Entwicklung

Art. 32 DSGVO verlangt TOM, die „unter Berücksichtigung des Stands der Technik” ein angemessenes Schutzniveau gewährleisten. Für Softwareentwickler bedeutet das konkrete Anforderungen an Architektur und Implementierung.

Verschlüsselung — at rest und in transit. Personenbezogene Daten werden verschlüsselt gespeichert (AES-256 oder vergleichbar) und verschlüsselt übertragen (TLS 1.3). Das gilt nicht nur für Passwörter, sondern für alle sensiblen Datenfelder: Gesundheitsdaten, Finanzdaten, Kontaktinformationen.

Rollenbasierte Zugriffskontrolle (RBAC). Nicht jeder Benutzer braucht Zugriff auf alle Daten. RBAC stellt sicher, dass Sachbearbeiter nur die Datensätze sehen, die sie für ihre Arbeit brauchen — nicht den gesamten Datenbestand. Die Rollen werden im System definiert, dokumentiert und regelmäßig überprüft.

Pseudonymisierung und Datenmaskierung. Wo immer möglich, werden personenbezogene Daten pseudonymisiert. In Test- und Entwicklungsumgebungen kommen ausschließlich maskierte Datensätze zum Einsatz — niemals echte Produktionsdaten. Bei TenMedia ist die strikte Trennung von Entwicklungs-, Test- und Produktionsumgebungen durch unsere ISO 27001 Zertifizierung verbindlich geregelt.

Logging und Monitoring. Sicherheitsrelevante Ereignisse — fehlerhafte Anmeldeversuche, Rechteänderungen, Datenexporte — werden protokolliert und überwacht. Das Logging selbst ist datenschutzkonform gestaltet: Es protokolliert Aktionen, ohne unnötige personenbezogene Daten zu speichern.

Backup und Wiederherstellung. Regelmäßige Sicherungen gewährleisten, dass Daten bei einem Vorfall wiederhergestellt werden können. Die Backup-Strategie berücksichtigt dabei die Löschpflichten: Wenn Daten im Produktivsystem gelöscht werden, müssen sie auch aus den Backups entfernt werden — spätestens nach dem nächsten Backup-Zyklus.

Auftragsverarbeitung: Was Auftraggeber beachten müssen

Wenn ein Unternehmen Software von einem externen Dienstleister entwickeln lässt und dabei personenbezogene Daten verarbeitet werden, entsteht ein Auftragsverarbeitungsverhältnis nach Art. 28 DSGVO. Das Unternehmen bleibt Verantwortlicher, der Dienstleister wird zum Auftragsverarbeiter.

Der Auftragsverarbeitungsvertrag (AVV) regelt die Pflichten beider Seiten: Zweck und Dauer der Verarbeitung, Art der personenbezogenen Daten, Kategorien betroffener Personen, Weisungsbindung des Auftragsverarbeiters, technische und organisatorische Maßnahmen, Unterauftragnehmer, Löschpflichten nach Vertragsende.

Prüfpflicht des Verantwortlichen. Art. 28 Abs. 1 DSGVO verlangt vom Auftraggeber, dass er sich „vergewissert”, dass der Auftragsverarbeiter „hinreichende Garantien” bietet. In der Praxis bedeutet das: Der Auftraggeber muss prüfen, ob der Dienstleister geeignete TOM implementiert hat. Eine ISO-27001-Zertifizierung liefert hier einen belastbaren Nachweis — sie dokumentiert, dass ein geprüftes Informationssicherheits-Managementsystem existiert.

Unterauftragnehmer. Nutzt der Dienstleister Cloud-Dienste, Hosting-Anbieter oder andere Unterauftragnehmer, müssen diese im AVV benannt und vom Auftraggeber genehmigt werden. Jeder Unterauftragnehmer unterliegt denselben vertraglichen Pflichten.

DSGVO und ISO 27001: Warum beides zusammengehört

Die DSGVO fordert technische und organisatorische Maßnahmen — definiert aber nicht im Detail, wie diese auszusehen haben. ISO 27001 füllt diese Lücke. Die Norm liefert ein Managementsystem, das genau die Strukturen schafft, die die DSGVO verlangt: systematische Risikoanalyse, dokumentierte Sicherheitsmaßnahmen, regelmäßige Überprüfung, kontinuierliche Verbesserung.

Risikoanalyse als gemeinsame Basis. Sowohl die DSGVO (Art. 32: Maßnahmen „unter Berücksichtigung des Risikos”) als auch ISO 27001 verlangen eine systematische Risikobewertung. Wer ein ISMS nach ISO 27001 betreibt, hat diese Analyse bereits strukturiert durchgeführt — und kann die Ergebnisse direkt für die DSGVO-Dokumentation nutzen.

Dokumentation und Nachweispflicht. Die DSGVO verlangt die Rechenschaftspflicht nach Art. 5 Abs. 2: Der Verantwortliche muss nachweisen können, dass er die Grundsätze einhält. ISO 27001 liefert genau diesen Dokumentationsrahmen — von der Sicherheitsleitlinie über Risikobewertungen bis zu Audit-Berichten.

Incident Response. Art. 33 DSGVO fordert die Meldung von Datenschutzverletzungen innerhalb von 72 Stunden. ISO 27001 verlangt einen dokumentierten Incident-Response-Prozess. Wer beide Anforderungen gemeinsam umsetzt, hat im Ernstfall eine funktionierende Meldekette — statt hektischer Improvisation.

Die Kombination aus DSGVO-Compliance und ISO 27001 Zertifizierung ist kein Doppelaufwand. Sie ist Effizienzgewinn: Ein System, zwei Compliance-Ziele. Für Unternehmen in KRITIS-Sektoren oder mit NIS-2-Pflichten kommt ein dritter Compliance-Rahmen hinzu, der ebenfalls auf denselben Grundstrukturen aufbaut.

Wie TenMedia datenschutzkonforme Software entwickelt

Datenschutz ist bei TenMedia kein separater Arbeitsschritt, der am Ende eines Projekts abgehakt wird. Er ist Teil des normalen Entwicklungsprozesses — verankert in unserer ISO 27001 Zertifizierung und konkretisiert durch die Annex-A-Controls für Softwareentwicklung.

Datenschutz in der Anforderungsanalyse. Bei jedem Projekt erheben wir die datenschutzrelevanten Anforderungen gemeinsam mit dem Auftraggeber: Welche personenbezogenen Daten werden verarbeitet? Welche Rechtsgrundlagen gelten? Welche Speicherfristen sind einzuhalten? Welche Betroffenenrechte muss die Software technisch unterstützen?

Privacy Impact Assessments bei Bedarf. Art. 35 DSGVO verlangt bei bestimmten Verarbeitungsarten eine Datenschutz-Folgenabschätzung. Wir unterstützen unsere Auftraggeber bei der Durchführung, indem wir die technischen Risiken identifizieren und Schutzmaßnahmen vorschlagen.

Code Reviews mit Datenschutz-Fokus. Unsere Code Reviews prüfen nicht nur Funktionalität und Sicherheit, sondern auch die Einhaltung der Datenschutzanforderungen: Werden Daten nur im vorgesehenen Umfang erhoben? Sind Löschroutinen implementiert? Sind Zugriffskontrollen korrekt?

Dokumentierte TOM. Die technischen und organisatorischen Maßnahmen, die wir für jedes Projekt umsetzen, sind dokumentiert und werden dem Auftraggeber für seinen AVV und für die eigene Rechenschaftspflicht bereitgestellt. Für Non-Profit-Unternehmen gelten dabei dieselben Standards wie für Konzerne — der Umfang skaliert mit dem Risiko, nicht mit der Unternehmensgröße.

Weiterführende Informationen

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.