Datenschutz kommt in Softwareprojekten oft zu spät zur Sprache: Die Anwendung ist gebaut, dann fragt jemand nach der Datenschutzerklärung. Das ist der teure Weg. Die Datenschutz-Grundverordnung stellt nämlich in erster Linie Anforderungen an die Architektur einer Anwendung — an das, was überhaupt gespeichert wird, wie lange, auf welcher Grundlage und wer es außer Ihnen noch sieht. Wer diese Fragen im Entwurf stellt, vermeidet Umbauten am fertigen System.
Eine Einordnung vorweg, die wir nicht verstecken: Dieser Beitrag beschreibt die technische Seite aus Entwicklersicht. Er ersetzt keine rechtliche Prüfung. Für die Bewertung Ihres konkreten Falls — insbesondere bei Gesundheits- oder Beschäftigtendaten — gehören Datenschutzbeauftragte oder eine Fachanwältin an den Tisch. Wir liefern dafür die technischen Grundlagen.
Privacy by Design ist eine Architekturfrage
Der Grundsatz „Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen“ (Art. 25 DSGVO) klingt abstrakt, hat aber sehr konkrete Folgen für den Bau einer Web-App. Drei davon fallen im Alltag am stärksten ins Gewicht.
Erstens die Datenminimierung: Jedes Formularfeld braucht einen Zweck. Das Geburtsdatum, das „vielleicht später nützlich“ wird, ist ein Risiko ohne Gegenwert. Zweitens die Voreinstellungen: Neue Nutzerkonten starten mit den restriktivsten sinnvollen Rechten, Benachrichtigungen und Sichtbarkeiten sind standardmäßig aus, nicht an. Drittens die Trennung: Wer welche Datensätze sehen darf, wird im Berechtigungsmodell abgebildet und serverseitig erzwungen, nicht durch ausgeblendete Schaltflächen.
Als Sammelaufgabe „Datenschutz umsetzen“ ans Ende der Roadmap geschoben, funktioniert das nicht: Es sind viele kleine Entscheidungen, verteilt über das ganze Projekt — sie gehören in die Anforderungsklärung, nicht in die Abnahme.
Zweck und Rechtsgrundlage gehören ins Datenmodell
Nützlich ist eine simple Übung vor der ersten Tabelle: Listen Sie alle Datenkategorien auf, die die Anwendung verarbeiten soll, und notieren Sie je Kategorie Zweck, Rechtsgrundlage, Herkunft, Empfänger und geplante Speicherdauer. Diese Tabelle ist gleichzeitig Entwurfswerkzeug und später die halbe Dokumentation.
Der Effekt auf das Datenmodell ist erheblich. Daten mit unterschiedlichem Zweck landen in unterschiedlichen Strukturen, statt in einer Nutzertabelle mit sechzig Spalten zusammenzuwachsen. Liegen Vertragsdaten, Marketing-Präferenzen und Nutzungsstatistiken getrennt, lässt sich später einzeln löschen, exportieren und sperren; in einem Sammeldatensatz ist jede dieser Operationen ein Eingriff mit Nebenwirkungen.
Ebenso lohnt die Frage, ob eine Auswertung den Personenbezug wirklich braucht. Statistiken über Nutzungsmuster funktionieren häufig auch mit Pseudonymen oder rein aggregierten Zählern. Was pseudonymisiert oder aggregiert vorliegt, senkt Ihr Risiko dauerhaft — und macht Berichte trotzdem möglich.
Löschkonzept: Fristen, die tatsächlich ablaufen
Der Grundsatz der Speicherbegrenzung ist die Anforderung, die in der Praxis am häufigsten scheitert. Fast jede gewachsene Anwendung hat Daten von 2017 in der Datenbank, weil nie jemand definiert hat, wann sie verschwinden. Ein Löschkonzept ist deshalb kein Dokument, sondern Code:
- Aufbewahrungsdauer je Datenkategorie, nicht pauschal je System
- ein automatischer Job, der abgelaufene Datensätze tatsächlich entfernt oder anonymisiert — messbar und protokolliert
- eine Entscheidung pro Tabelle: hartes Löschen, Anonymisieren oder Sperren, und was mit abhängigen Datensätzen passiert
- Umgang mit Backups, die eigene Aufbewahrungszyklen haben und nicht selektiv editierbar sind
- Testfälle, die belegen, dass Löschen wirklich löscht — auch in Suchindizes, Caches und Dateispeichern
Regelmäßig kollidieren Löschpflicht und Aufbewahrungspflicht: Rechnungen und Buchungsbelege unterliegen handels- und steuerrechtlichen Fristen und dürfen nicht mitgelöscht werden, wenn ein Kunde sein Konto beendet. Die technische Antwort ist meist ein reduzierter Restdatensatz — Belegdaten bleiben, das aktive Profil verschwindet. Welche Frist konkret gilt, lassen Sie sich von Steuerberatung oder Rechtsberatung bestätigen, statt sie im Projekt zu schätzen.
Betroffenenrechte als Funktion einplanen
Auskunft (Art. 15 DSGVO), Berichtigung, Löschung (Art. 17 DSGVO) und Datenübertragbarkeit sind für Sie als Betreiber Prozesse mit Fristen — und für die Anwendung Funktionen. Wenn eine Auskunftsanfrage eintrifft, muss jemand sämtliche Daten einer Person zusammentragen: aus der Hauptdatenbank, aus Protokollen, aus dem Ticketsystem, aus dem Newsletter-Werkzeug. Ohne vorbereitete Abfrage wird daraus jedes Mal ein Tagesprojekt.
Was sich lohnt, hängt von der Menge ab, und hier ist Ehrlichkeit angebracht. Bei zwei Anfragen im Jahr genügt ein dokumentierter manueller Ablauf mit vorbereiteten Abfragen und einem verantwortlichen Menschen — eine Selbstbedienungsoberfläche wäre Verschwendung. Bei einer Anwendung mit vielen tausend Endnutzern kippt die Rechnung: Dann sind ein Datenexport im Konto und eine gesteuerte Kontolöschung schlicht billiger als der wiederkehrende Aufwand. Planen Sie in beiden Fällen einen Schritt ein, der die Identität der anfragenden Person prüft, bevor Daten herausgehen.
Auftragsverarbeitung: Hosting, Mail, Analytics, KI-Dienste
Kaum eine Web-App verarbeitet Daten nur an einem Ort. Für jeden Dienst, der personenbezogene Daten in Ihrem Auftrag verarbeitet, brauchen Sie einen Vertrag zur Auftragsverarbeitung (Art. 28 DSGVO) und Klarheit über dessen Subdienstleister. Diese Kette ist meist länger als vermutet.
| Dienstkategorie | Was dort typischerweise anfällt | Worauf es ankommt |
|---|---|---|
| Hosting und Datenbank | alle Anwendungsdaten, Zugriffsprotokolle | Standort der Verarbeitung, Subdienstleister, Backup-Orte |
| Transaktionsmails | Adressen, Namen, Inhalte, Zustellstatus | Aufbewahrungsdauer beim Anbieter, Protokoll-Inhalte |
| Web-Analytics | IP-Adressen, Gerätekennungen, Verhalten | Notwendigkeit prüfen, Kürzung, Einwilligungspflicht |
| Fehler- und Betriebsüberwachung | Fehlermeldungen mit Nutzdaten, Sitzungsdetails | Filter für Nutzdaten, kurze Vorhaltezeiten |
| KI- und Sprachmodell-Schnittstellen | alles, was in die Anfrage geschrieben wird | Speicherung und Training beim Anbieter, Region, Filterung |
Zum Dauerstreitpunkt EU-Hosting gegen US-Anbieter eine nüchterne Einordnung: Ein europäischer Standort ist kein Konformitätsbeweis, und ein US-Anbieter ist nicht automatisch unzulässig. Für Übermittlungen in die USA existiert ein Angemessenheitsbeschluss der EU-Kommission, dessen Bestand politisch und juristisch umstritten bleibt. Wer das Risiko dieser Unsicherheit nicht tragen möchte, wählt für die Kerndatenhaltung einen Anbieter im EU-Raum — bei Gesundheits- und anderen besonders geschützten Daten ist das aus unserer Sicht die naheliegende Entscheidung. Wichtig ist die Austauschbarkeit: Dienste, die über eine klar abgegrenzte Schnittstelle angebunden sind, lassen sich wechseln, wenn sich die Rechtslage ändert.
Protokollierung gegen Datensparsamkeit
Hier stehen zwei berechtigte Anforderungen gegeneinander. Für den sicheren Betrieb brauchen Sie Protokolle: Wer hat sich angemeldet, welche Fehler traten auf, welche Datensätze wurden geändert. In sensiblen Bereichen ist die Nachvollziehbarkeit von Zugriffen sogar ausdrücklich gefordert. Gleichzeitig sind ausgerechnet Protokolle die Datenhalde, die niemand aufräumt — voller IP-Adressen, Formularinhalte und Klartext-Kennungen.
Bewährt hat sich eine bewusste Entscheidung je Protokollart: Was wird erfasst, wie lange bleibt es, wer darf es lesen, welche Felder werden geschwärzt. Fehlerberichte lassen sich so konfigurieren, dass Nutzdaten gefiltert werden; Zugriffsprotokolle können nach kurzer Zeit gekürzt werden, während fachliche Änderungsnachweise länger vorgehalten werden müssen. Die Schutzmaßnahmen selbst — Verschlüsselung, Zugriffskontrolle, Härtung nach Art. 32 DSGVO — sind ein eigenes Thema; sie entscheiden darüber, dass die Protokolle nicht selbst zum Vorfall werden.
Verwandt damit ist die Einwilligung, die häufig zu breit eingesetzt wird. Ein Einwilligungsbanner ist nicht das Universalwerkzeug: Was Sie zur Vertragserfüllung verarbeiten, braucht keine Einwilligung, und wo Sie eine erfragen, muss die Funktion auch ohne sie nutzbar bleiben. Eine Anwendung, die technisch notwendige Sitzungsmerkmale hinter einem Banner versteckt, während sie zugleich einwilligungspflichtige Fremddienste ungefragt lädt, hat das Thema genau falsch verstanden.
Was Sie am Ende in der Hand haben sollten
Verantwortlich sind Sie als Betreiber, nicht der Dienstleister. Umso wichtiger ist, dass ein Projekt die Unterlagen liefert, mit denen Sie Ihre Pflichten erfüllen können — etwa das Verzeichnis von Verarbeitungstätigkeiten oder, bei riskanteren Verarbeitungen, eine Datenschutz-Folgenabschätzung. Verlangen Sie zum Abschluss:
- eine aktuelle Datenfluss- und Datenkategorien-Übersicht samt Rechtsgrundlagen-Zuordnung
- die Liste aller eingebundenen Dienste inklusive Verarbeitungsstandort und Vertragsstand
- das Löschkonzept mit Fristen je Datenkategorie und dem Nachweis, dass es läuft
- eine Beschreibung der technischen und organisatorischen Maßnahmen im Klartext
- die Ablaufbeschreibung für Auskunfts-, Export- und Löschanfragen
Vereinbaren lassen sich diese Punkte in der Planungsphase; wie wir Projekte aufsetzen, zeigt unser Projektvorgehen. Nachträglich beschafft, kosten sie ein Mehrfaches.
Fazit: Konformität ist ein Zustand, kein Zertifikat
„DSGVO-konform“ ist keine Eigenschaft, die man mit einer Software einkauft. Eine Anwendung kann datenschutzfreundlich gebaut und dokumentiert sein, sodass Sie sie rechtskonform betreiben können — beurteilen lässt sich das nur zusammen mit Ihren Prozessen und im Einzelfall fachlich geprüft. Genau deshalb ist ehrlicherweise auch die Eigenentwicklung nicht immer die richtige Antwort: Deckt ein etabliertes Standardprodukt Ihren Prozess ab und bringt Auftragsverarbeitungsvertrag, EU-Verarbeitung und ein sauberes Löschkonzept mit, ist der Kauf der schnellere und risikoärmere Weg. Eigenbau lohnt dort, wo Ihr Prozess besonders ist oder wo Sie die Datenhaltung wirklich selbst kontrollieren müssen — was bei besonders geschützten Daten häufig den Ausschlag gibt.
Wenn Sie eine Anwendung mit personenbezogenen Daten planen, klären wir diese Punkte vor der ersten Zeile Code. Einen Überblick gibt die Leistungsseite, für eine Einschätzung genügt eine Nachricht über die Kontaktseite.
Häufige Fragen
Reicht eine gute Datenschutzerklärung für eine DSGVO-konforme Web-App?
Nein. Die Erklärung beschreibt nur, was die Anwendung tut. Die Anforderungen betreffen die Anwendung selbst: welche Daten erhoben werden, wie lange sie bleiben, wer sie sieht und wie Löschung und Auskunft funktionieren.
Muss die Anwendung zwingend in der EU gehostet werden?
Pauschal nein, es kommt auf die Datenarten und Ihre Risikobereitschaft an. Bei besonders geschützten Daten wie Gesundheitsdaten ist EU-Verarbeitung der naheliegende und in der Praxis am leichtesten begründbare Weg.
Wie teuer ist Datenschutz im Projekt?
Von Anfang an mitgedacht fällt der Aufwand meist wenig auf, weil es um Entwurfsentscheidungen geht. Teuer wird es beim Nachrüsten: Löschfähigkeit und Datentrennung in ein bestehendes Datenmodell einzubauen ist echter Umbau.
Dürfen wir KI-Dienste einsetzen, wenn personenbezogene Daten im Spiel sind?
Das ist eine Frage der Ausgestaltung, nicht ein grundsätzliches Verbot. Entscheidend sind Vertragslage, Verarbeitungsort, Speicher- und Trainingspraxis des Anbieters sowie die Frage, welche Daten überhaupt in die Anfrage gelangen. Bei sensiblen Daten gehört das rechtlich geprüft.
