Die DSGVO ist für die meisten Entwickler kein juristisches Problem, sondern ein Prioritäten-Problem: 90 Prozent des Risikos stecken in fünf technischen Punkten, die du in einem Nachmittag abräumen kannst. Der Rest ist Papierkram, den du einmal sauber aufsetzt und dann nur noch pflegst.
Ich baue seit Jahren Websites und Web-Apps für Kunden in Deutschland, und das Thema kommt in praktisch jedem Projekt auf den Tisch — meistens viel zu spät. Deshalb hier die Praxis-Sicht: was dich als Dev wirklich betrifft, was Kunden von dir erwarten dürfen und wo die typischen Abmahnfallen liegen.
Warum das Thema dich betrifft, auch wenn du “nur” entwickelst
Viele Devs winken ab: “Datenschutz ist Sache des Kunden.” Rechtlich ist der Betreiber der Website tatsächlich der Verantwortliche. Aber in der Praxis passiert Folgendes: Der Kunde bekommt eine Abmahnung wegen Google Fonts oder einem fehlenden Cookie-Banner, und die erste Frage lautet: “Warum hat mir mein Entwickler das nicht gesagt?”
Wenn du Kundenprojekte machst — egal ob als Freelancer oder Agentur — gehört ein datenschutz-sauberer Auslieferungszustand schlicht zur handwerklichen Qualität. Genauso wie du keine Seite ohne HTTPS auslieferst, lieferst du keine Seite aus, die beim ersten Aufruf ungefragt Daten an US-Server schickt. Das ist kein Jura, das ist Sorgfalt.
Und wenn du selbst ein SaaS oder eine Community betreibst, bist du sowieso direkt Verantwortlicher. Dann gibt es niemanden, auf den du zeigen kannst.
Die AVV: Der Vertrag, den fast jeder vergisst
Sobald du für einen Kunden personenbezogene Daten verarbeitest — und das tust du schon, wenn du Hosting betreust, Formulardaten weiterleitest oder Zugriff auf die Datenbank hast — brauchst du einen Auftragsverarbeitungsvertrag (AVV) mit dem Kunden. Umgekehrt brauchst du selbst AVVs mit deinen Dienstleistern: Hoster, Mail-Service, Analytics-Anbieter.
Die gute Nachricht: Das ist fast immer ein Standardprozess. Hetzner, IONOS, Resend, Brevo — praktisch jeder seriöse Anbieter hat einen fertigen AVV, den du online abschließt oder herunterlädst. Der Aufwand liegt bei zehn Minuten pro Dienstleister. Die schlechte Nachricht: Wenn du es nicht machst, ist es einer der Punkte, die bei einer Prüfung sofort auffallen, weil er dokumentenbasiert und damit leicht nachweisbar ist.
Mein Workflow: Bei jedem neuen Projekt lege ich eine kurze Liste aller eingesetzten Dienste an und hake ab, wo ein AVV existiert. Diese Liste ist gleichzeitig die Grundlage für die Datenschutzerklärung — zwei Fliegen, eine Klappe.
Hosting und Drittland-Transfers: Die Architektur-Entscheidung
Der einfachste DSGVO-Hebel ist eine Architektur-Entscheidung: Hoste in der EU. Ein VPS bei Hetzner oder ein deutscher Managed-Hoster erspart dir die komplette Diskussion über Drittland-Transfers beim Kern deiner Anwendung. Das Data Privacy Framework mit den USA existiert zwar, aber es ist politisch wackelig — wer sich erinnert, wie Privacy Shield gekippt wurde, baut nicht darauf.
Kritisch wird es bei den Diensten drumherum:
- CDNs und externe Skripte: Jedes
<script src="https://...">von einem US-Anbieter ist ein Datenabfluss beim Seitenaufruf — IP-Adresse inklusive. - Mail-Versand: Transaktionsmails über US-Anbieter gehen, brauchen aber AVV und Erwähnung in der Datenschutzerklärung.
- Analytics: Google Analytics ohne Consent ist keine Grauzone, sondern klar unzulässig. Selbstgehostete Alternativen wie Matomo oder Plausible (EU-Cloud) lösen das elegant.
Die Faustregel: Alles, was beim ersten Seitenaufruf ohne Nutzerinteraktion lädt, muss entweder aus der EU kommen oder von deinem eigenen Server.
Google Fonts, Cookies, Consent: Die Abmahnklassiker
Die Google-Fonts-Abmahnwelle hat gezeigt, wie billig Angreifbarkeit sein kann: Ein automatisierter Scan findet die Font-Einbindung vom Google-Server, ein Anwalt verschickt Serienbriefe. Die Lösung kostet dich fünfzehn Minuten: Fonts herunterladen, selbst hosten, fertig. Das gehört in jedes Projekt-Setup, ohne Ausnahme.
Beim Cookie-Banner gilt: Du brauchst keins, wenn du keine einwilligungspflichtigen Dienste einsetzt. Eine statische Website mit selbst gehosteten Fonts, ohne Tracking, ohne eingebettete YouTube-Videos braucht kein Banner — und ist damit schneller, schöner und rechtssicherer als die Konkurrenz mit ihrem dreistufigen Consent-Monster. Ich versuche in Kundenprojekten aktiv, die Zahl der einwilligungspflichtigen Dienste auf null zu drücken, statt ein Banner draufzuklatschen.
Wenn du um Consent nicht herumkommst: Das Banner muss echte Wahlfreiheit bieten. “Ablehnen” genauso prominent wie “Akzeptieren”, und vor der Einwilligung darf der Dienst nicht laden. Ein Banner, das nur dekorativ über bereits gesetzten Trackern schwebt, ist schlimmer als keins — es dokumentiert, dass du es wusstest.
Technische Maßnahmen: Was Prüfer sehen wollen
Die DSGVO verlangt “technische und organisatorische Maßnahmen” — klingt schwammig, ist aber für Devs das Heimspiel. In der Praxis reicht solides Handwerk:
- Verschlüsselung: TLS überall, Passwörter mit bcrypt/argon2, Backups verschlüsselt.
- Zugriffskontrolle: Wer hat Zugriff auf Produktivdaten? SSH-Keys statt Passwörter, keine geteilten Accounts, Offboarding-Prozess wenn jemand geht.
- Datenminimierung: Frag im Formular nur ab, was du brauchst. Jedes Feld, das du nicht erhebst, musst du nicht schützen.
- Löschkonzept: Logs rotieren, alte Nutzerdaten nach definierter Frist löschen. Ein Cronjob, der Accounts nach Inaktivität anonymisiert, ist ein Löschkonzept.
Dokumentiere das kurz — eine Markdown-Datei im Projekt-Repo reicht als Startpunkt. Es geht nicht um Perfektion, sondern darum, zeigen zu können, dass du dir Gedanken gemacht hast.
Was du getrost niedriger priorisieren kannst
Ehrlichkeit gehört dazu: Nicht alles, was DSGVO-Berater verkaufen, brauchst du sofort. Ein Verarbeitungsverzeichnis für einen Solo-Freelancer ist schnell erstellt und formal Pflicht, aber die reale Prüfwahrscheinlichkeit ist gering, solange sich niemand beschwert. Ein Datenschutzbeauftragter ist erst ab bestimmten Schwellen Pflicht, die du als kleiner Betrieb selten reißt.
Das Risiko ist asymmetrisch verteilt: Abmahnungen kommen über öffentlich sichtbare, automatisiert scanbare Fehler — Fonts, Tracker, fehlendes Impressum, kaputte Datenschutzerklärung. Behördenverfahren kommen fast immer über Beschwerden von Nutzern oder Ex-Mitarbeitern. Priorisiere entsprechend: erst die sichtbare Angriffsfläche schließen, dann den Papierkram nachziehen.
Fazit: Einmal sauber aufsetzen, dann wiederverwenden
DSGVO-Konformität ist für Entwickler vor allem ein Template-Problem. Bau dir einmal ein sauberes Projekt-Setup — selbst gehostete Fonts, EU-Hosting, AVV-Checkliste, Datenschutzerklärungs-Generator deines Vertrauens, Formulare mit Datenminimierung — und jedes weitere Projekt erbt diesen Stand automatisch. Der Aufwand für das erste Mal: ein Tag. Für jedes weitere Projekt: eine Stunde.
Falls du dich mit anderen Devs über solche Praxis-Themen austauschen willst — im Discord der Community diskutieren wir regelmäßig, wie wir Kundenprojekte sauber und pragmatisch aufsetzen.