Architektur

Datenschutz by Design: DSGVO-konforme Softwarearchitektur

Datenschutz ist keine Funktion, die man am Ende ergänzt. Er ist eine Eigenschaft der Architektur — und wer ihn nachträglich einbaut, zahlt dafür in der Regel das Mehrfache.

Autor Julien MarschallVeröffentlicht 2026-07-12Lesezeit 6 Min.

In vielen Projekten taucht Datenschutz als Thema erst auf, wenn die Software bereits läuft: kurz vor dem Go-live, wenn jemand nach dem Löschkonzept fragt. Dann beginnt die teure Phase — nachträgliche Anonymisierung, nachgerüstete Zugriffskontrollen, ein Auskunftsprozess, der auf drei Datenbanken zugreifen muss, die nie dafür gebaut wurden. Datenschutz by Design bedeutet, diese Anforderungen als Architekturprinzip zu behandeln, nicht als Feature-Ticket.

Datenminimierung ist eine Design-Entscheidung

Der wirksamste Datenschutz besteht darin, Daten gar nicht erst zu erheben. Jedes Feld in einem Formular, jedes Attribut in einem Datenmodell, jedes Event im Tracking ist eine bewusste Entscheidung mit Konsequenzen. Die zentrale Frage lautet nicht „könnte das später nützlich sein?“, sondern „welchen konkreten Zweck erfüllt dieses Feld heute?“.

Daten, die nicht existieren, können nicht abfließen, nicht falsch verarbeitet und nicht Gegenstand einer Auskunftspflicht werden. Das ist der einzige Schutz, der zu hundert Prozent wirkt.

Trennung: personenbezogen und funktional

Eine der wirkungsvollsten Architekturentscheidungen ist die saubere Trennung personenbezogener Daten vom Rest des Systems. Statt Name, E-Mail und Adresse über alle Tabellen und Services zu verteilen, liegen sie in einem klar abgegrenzten Bereich; der Rest des Systems arbeitet mit einer internen ID.

  • Löschen wird zu einer Operation an einer Stelle, nicht zu einer Suche über zwölf Systeme
  • Auskunftsersuchen lassen sich technisch beantworten statt manuell zusammenzutragen
  • Analytics und Reporting arbeiten mit pseudonymisierten Daten, ohne Funktionsverlust
  • Der Kreis der Systeme mit Personenbezug bleibt überschaubar und prüfbar

Löschung braucht ein Konzept, kein Skript

Die Pflicht zur Löschung nach Zweckfortfall ist in der Praxis der härteste technische Test. Sie scheitert regelmäßig an drei Stellen: an Backups, an Log-Dateien und an Datenkopien in Data Warehouses oder Analyse-Tools. Ein tragfähiges Löschkonzept definiert für jede Datenkategorie eine Aufbewahrungsfrist, benennt jedes System, in dem die Daten liegen, und beschreibt, wie die Löschung dort erfolgt — inklusive der Frage, wie mit Backups umgegangen wird.

Zugriff: minimal, protokolliert, überprüfbar

Ein Rollen- und Rechtekonzept ist keine Verwaltungsübung. Es beantwortet die Frage, wer im Ernstfall an welche Daten gekommen sein könnte. Drei Prinzipien tragen den größten Teil der Last: Least Privilege — jeder erhält nur den minimal nötigen Zugriff. Zweckbindung — Zugriff wird an eine Aufgabe gekoppelt, nicht an eine Person. Protokollierung — lesende Zugriffe auf sensible Datensätze werden mitgeschrieben.

Verschlüsselung: differenziert statt pauschal

Transportverschlüsselung ist heute selbstverständlich. Interessanter ist die Frage der Verschlüsselung im Ruhezustand und, darüber hinaus, der feldbasierten Verschlüsselung besonders sensibler Attribute. Nicht jedes Feld braucht dasselbe Schutzniveau — eine Bestellnummer und eine Gesundheitsangabe sind unterschiedliche Risikoklassen und sollten es auch technisch sein.

Auftragsverarbeitung: die Kette ist so stark wie ihr schwächstes Glied

Jeder externe Dienst, der personenbezogene Daten verarbeitet — Hosting, E-Mail-Versand, Analytics, Support-Tool, KI-Schnittstelle — ist Teil der Verarbeitungskette. Architekturseitig heißt das: Der Datenfluss zu Dritten muss bewusst gestaltet, dokumentiert und technisch begrenzt sein. Ein Support-Tool braucht selten den vollständigen Datensatz eines Kunden; es braucht meist nur den Kontext des konkreten Vorfalls.

Was im Alltag wirklich hilft

  • Ein Datenmodell-Review vor jeder größeren Feature-Entwicklung — welche neuen Personenbezüge entstehen?
  • Testdaten, die synthetisch sind, nicht kopierte Produktionsdaten
  • Log-Filter, die personenbezogene Felder standardmäßig maskieren
  • Ein Verarbeitungsverzeichnis, das aus dem Code heraus gepflegt wird und nicht als Word-Datei existiert

Der wirtschaftliche Punkt

Datenschutz by Design ist nicht nur eine Compliance-Frage. Ein System mit klaren Datengrenzen ist einfacher zu warten, einfacher zu migrieren, einfacher zu prüfen und einfacher zu verkaufen — insbesondere im Mittelstand, wo Kunden zunehmend selbst nach Auftragsverarbeitungsverträgen und Löschkonzepten fragen. Wer diese Fragen technisch beantworten kann statt rhetorisch, hat im B2B-Vertrieb einen messbaren Vorteil.

Systeme, die Änderungen aushalten

Individualsoftware mit Testabdeckung, Monitoring und sauberer Pipeline — statt Blackbox.

Projekt anfragen →

Häufige Fragen

Was bedeutet Privacy by Design konkret?
Dass Datenschutzanforderungen bereits in Architektur- und Datenmodellentscheidungen einfließen — etwa durch Datenminimierung, Trennung personenbezogener Daten und ein von Anfang an mitgedachtes Löschkonzept.
Wie geht man mit Backups beim Löschen um?
Backups werden in der Praxis nicht selektiv bereinigt. Üblich ist, die Löschung in den Produktivsystemen umzusetzen und Backups mit einer definierten, begrenzten Aufbewahrungsfrist rotieren zu lassen.
Reicht Verschlüsselung als Datenschutzmaßnahme?
Nein. Verschlüsselung schützt gegen unbefugten Zugriff, ersetzt aber weder Datenminimierung noch Zweckbindung noch ein Löschkonzept.