DSGVO-Konformität für Websites: Was der Aufbau tatsächlich erfordert

Die meisten DSGVO-Ratgeber im Netz sind für Juristen geschrieben oder für Menschen, die einen Policy-Generator kaufen wollen. Sehr wenig davon ist für die Person geschrieben, die einen Editor öffnen und etwas ändern muss.

Dieser Leitfaden ist von der zweiten Sorte. Er geht durch, was die Datenschutz-Grundverordnung von einer Website und den dahinterliegenden Systemen verlangt, ausgedrückt als Dinge, die Sie bauen, konfigurieren oder löschen. Wir machen diese Arbeit für Unternehmen in der EU, seit die Verordnung 2018 anwendbar wurde, und das Muster dessen, was schiefgeht, hat sich in dieser Zeit kaum verändert.

Eines vorweg: Die DSGVO ist nicht einfacher geworden, weil neuere Verordnungen dazugekommen sind. Sie ist wichtiger geworden, weil praktisch alles in der aktuellen Welle der EU-Digitalregeln voraussetzt, dass Ihr Umgang mit personenbezogenen Daten bereits geordnet ist.

Beginnen Sie mit einer ehrlichen Dateninventur

Fast jedes gescheiterte DSGVO-Projekt, das wir übernommen haben, ist an derselben Stelle gescheitert. Das Team hat zuerst die Richtlinie geschrieben und die Daten später entdeckt.

Bevor Sie irgendetwas anderes tun, kartieren Sie, welche personenbezogenen Daten Ihre Website tatsächlich erhebt. Nicht, was die Produktspezifikation sagt. Was in der Datenbank steht, in den Logs, in der Analytics-Plattform, im CRM, im Support-Tool, im Marketing-Automation-Stack, im Error-Tracker, in den CDN-Logs und in den Drittanbieter-Skripten auf der Seite.

Praktisch heißt das:

• Durchsuchen Sie das Schema. Jede Spalte, die eine Person direkt oder in Kombination mit einer anderen Spalte identifizieren könnte.
• Lesen Sie den Netzwerk-Tab bei einem echten Seitenaufruf. Jede ausgehende Anfrage an eine Domain, die Ihnen nicht gehört, ist eine potenzielle Übermittlung personenbezogener Daten, denn eine IP-Adresse plus User-Agent ist ein Personenbezug.
• Prüfen Sie, was Ihr Error-Tracker erfasst. Stacktraces enthalten routinemäßig E-Mail-Adressen, Tokens und Request-Bodies.
• Prüfen Sie die Log-Aufbewahrung. Zugriffslogs mit IPs, die ewig liegen bleiben, sind einer der häufigsten Befunde und einer der am leichtesten behebbaren.

Schreiben Sie das als Verzeichnis von Verarbeitungstätigkeiten auf. Artikel 30 verlangt es für die meisten Organisationen ohnehin, und die für Entwickler nützliche Fassung ist eine Tabelle mit System, Daten, Zweck, Rechtsgrundlage, Aufbewahrungsfrist und Empfängern.

Wählen Sie eine Rechtsgrundlage pro Zweck, nicht pro System

Artikel 6 gibt Ihnen sechs Rechtsgrundlagen. Der häufigste Fehler ist, eine davon für das gesamte Produkt zu wählen.

Sie haben mit hoher Wahrscheinlichkeit mehrere Zwecke gleichzeitig laufen. Eine Bestellung zu erfüllen ist Vertrag. Betrugsprüfungen sind meist berechtigtes Interesse oder rechtliche Verpflichtung. Rechnungen für die gesetzliche Frist aufzubewahren ist rechtliche Verpflichtung. Werbe-E-Mails sind in den meisten Mitgliedstaaten Einwilligung. Nicht notwendige Analytik ist Einwilligung, wegen der ePrivacy-Regeln zum Zugriff auf Endeinrichtungen und nicht wegen der DSGVO selbst.

Die praktische Folge: Ihr Datenmodell muss wissen, welchem Zweck jeder Datensatz dient. Wenn Sie das Marketingprofil nicht vom Bestelldatensatz trennen können, können Sie einem Werbewiderspruch nicht nachkommen, ohne die Bestellhistorie zu zerstören. Diese Trennung ist eine Schemaentscheidung, und sie ist schmerzhaft nachzurüsten.

Einwilligung muss echt sein, und sie muss protokolliert werden

Wenn Sie sich auf Einwilligung stützen, muss sie freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich erfolgen, und Sie müssen sie später nachweisen können.

Konkret:

• Nichts Nicht-Notwendiges feuert, bevor der Nutzer handelt. Das schließt das Analytics-Snippet ein, das Werbepixel, das Chat-Widget, die von einem Drittanbieter-CDN geladene Schrift und das A/B-Testing-Skript.
• Ablehnen muss so einfach sein wie Annehmen. Gleiche Ebene, gleiche Prominenz, gleiche Klickzahl. Aufsichtsbehörden behandeln alles andere als Dark Pattern, und sie sind darin konsequent.
• Einwilligung ist zweckbezogen. Ein einziger Schalter für "Analyse und Marketing und Personalisierung" ist nicht spezifisch.
• Der Widerruf ist so einfach wie die Erteilung. Ein dauerhafter Link oder ein schwebender Button, keine E-Mail an den Support.
• Speichern Sie den Nachweis: Zeitstempel, den Consent-String oder den Zustand jeder Kategorie, die Bannerversion und den Text, der dem Nutzer angezeigt wurde. Ohne die Version können Sie einen zwei Jahre alten Einwilligungsnachweis nicht verteidigen.

Die Durchsetzung hier ist nicht theoretisch. Im September 2025 verhängte die französische Datenschutzbehörde am selben Tag Bußgelder von 325 Millionen Euro gegen Google und 150 Millionen Euro gegen Shein wegen Cookie-Praktiken. Beide Fälle drehten sich um Mechanik, nicht um Formulierungen: Cookies wurden vor jeder Interaktion gesetzt, und Ablehnen-Buttons lehnten nicht wirklich ab.

Auch die Regeln dazu sind in Bewegung. Der Digital-Omnibus-Vorschlag würde die Einwilligung für Endeinrichtungen in die DSGVO selbst verlagern und Browser-Signale bindend machen. Was das ändern würde, steht in Cookie-Einwilligung nach dem Digital Omnibus.

Bauen Sie die Maschinerie für Betroffenenrechte früh

Die Artikel 15 bis 22 geben Menschen das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung, Übertragbarkeit und Widerspruch. Sie haben einen Monat Zeit für die Antwort, in komplexen Fällen auf drei verlängerbar.

Teams bearbeiten die ersten Anfragen meist manuell, was genau so lange funktioniert, bis es das nicht mehr tut. Was Sie deutlich vor dem Volumen brauchen:

Einen Resolver, der eine Person systemübergreifend findet. Zu einer E-Mail-Adresse alles zurückgeben: Konto, Bestellungen, Support-Tickets, Marketingprofil, Analytics-Identifier, Logs. Wenn sich ein Mensch daran erinnern muss, dass es noch eine Drittanbieter-Bewertungsplattform mit Daten gibt, wird das irgendwann jemand vergessen.

Einen Löschpfad, der Aufbewahrungspflichten respektiert. Löschung ist nicht absolut. Rechnungen müssen aus steuerlichen Gründen meist überleben. Was Sie brauchen, ist Soft Delete mit zweckbezogener Hartlöschung, damit Sie das Marketingprofil entfernen und den Buchhaltungsdatensatz behalten können, und damit dieser Datensatz selbst planmäßig verfällt.

Einen portablen Export. Strukturiert, gängig, maschinenlesbar. JSON ist in Ordnung. Ein PDF einer gerenderten HTML-Seite nicht.

Ein Widerspruchs-Flag, das das gesamte System liest. Ein Widerspruch gegen Profiling muss das Profiling tatsächlich stoppen, auch im Batch-Job, der um drei Uhr morgens läuft und das Flag nicht prüft.

Aufbewahrung ist ein Job, keine Zeile in einer Richtlinie

Speicherbegrenzung ist der Grundsatz, gegen den ansonsten gut gebaute Systeme am häufigsten verstoßen, weil Löschen bedeutet, dass jemand einen Job schreiben und einplanen muss, nach dem niemand fragt.

Geben Sie jeder Datenkategorie eine definierte Lebensdauer und setzen Sie sie dann um. Zugriffslogs, Sitzungsdaten, abgebrochene Warenkörbe, nicht bestätigte Registrierungen, geschlossene Support-Tickets, alte Backups und Analytics-Rohdaten brauchen alle ein Verfallsdatum. Backups verdienen besondere Aufmerksamkeit: Wenn Ihr Restore-Prozess gelöschte personenbezogene Daten wiederbelebt, ist Ihre Löschung unvollständig. Die übliche Antwort ist eine dokumentierte Backup-Rotation mit Höchstalter plus erneute Anwendung der Löschungen nach jedem Restore.

Übermittlungen, Unterauftragsverarbeiter und wo Ihr Stack wirklich läuft

Übermittlungen außerhalb des EWR brauchen einen Rechtsmechanismus, meist das EU-US Data Privacy Framework für zertifizierte US-Empfänger oder Standardvertragsklauseln plus Transfer Impact Assessment.

Die technische Seite ist einfacher als die juristische: Wissen Sie, wo Ihre Daten physisch liegen. Das heißt die Cloud-Region jedes Dienstes, den Ort Ihrer Backups, die Region Ihrer verwalteten Datenbank, die CDN-Edge-Konfiguration und, besonders wichtig, das Support-Modell jedes SaaS-Tools, das Sie einsetzen. Ein Anbieter mit Hosting in Frankfurt, dessen Support-Team von außerhalb des EWR auf Produktion zugreift, ist trotzdem eine Übermittlung.

Wir empfehlen in der Regel, personenbezogene Daten in EU-Regionen zu halten, wenn nichts stark dagegen spricht. Das räumt eine ganze Kategorie von Diskussionen ab, und der Kostenunterschied ist meist Rauschen.

Pflegen Sie eine Liste der Unterauftragsverarbeiter und halten Sie sie aktuell. Artikel 28 verlangt einen schriftlichen Vertrag mit jedem, und die Liste ist auch das, wonach Ihre Kunden in der Due Diligence fragen.

Sicherheit als Voreinstellung, ausgedrückt in Konfiguration

Artikel 32 verlangt geeignete technische und organisatorische Maßnahmen. Das ist bewusst vage, aber die Grundlinie für eine Website im Jahr 2026 ist nicht verhandelbar:

• TLS überall, HSTS aktiviert, kein Mixed Content.
• Passwörter mit einer modernen, speicherharten Funktion gehasht, und Mehrfaktor-Authentifizierung verfügbar für Konten mit personenbezogenen Daten.
• Verschlüsselung im Ruhezustand für Datenbanken und Backups.
• Zugriff auf personenbezogene Produktionsdaten rollenbasiert beschränkt und protokolliert, mit Überprüfungen, die tatsächlich stattfinden.
• Pseudonymisierung, wo möglich: Identifier in der Analytik hashen, die Zuordnungstabelle getrennt und zugriffsbeschränkt halten.
• Ein getesteter Restore, nicht nur ein Backup.

Datenschutz durch Technikgestaltung und durch Voreinstellungen in Artikel 25 bedeutet, dass die datenschutzfreundliche Option diejenige ist, die man bekommt, ohne etwas zu tun. Newsletter-Häkchen nicht gesetzt. Profilsichtbarkeit privat. Optionale Felder optional.

Meldung von Verletzungen braucht ein Runbook

Zweiundsiebzig Stunden von der Kenntnis bis zur Meldung an die Aufsichtsbehörde sind nicht lang, besonders wenn die Verletzung an einem Freitagabend entdeckt wird. Der Digital-Omnibus-Vorschlag würde das auf sechsundneunzig Stunden verschieben, aber das ist noch kein Recht.

Bereiten Sie vor: Wer ruft einen Vorfall aus, wer bewertet, ob personenbezogene Daten betroffen sind, wer kontaktiert die Behörde, was steht in der Meldung, und wie informieren Sie Betroffene, wenn das Risiko hoch ist. Schreiben Sie es als Runbook mit benannten Rollen und üben Sie es einmal. Der erste Einsatz sollte nicht das erste Lesen sein.

Die Oberfläche der Website selbst

Ein Teil der DSGVO ist auf der Seite sichtbar, und diese Details lohnen sich, weil genau sie gemeldet werden.

Ihre Datenschutzerklärung muss Identität und Kontakt des Verantwortlichen nennen, Zwecke und Rechtsgrundlagen, Empfänger und Empfängerkategorien, Übermittlungsmechanismen, Aufbewahrungsfristen, die vollständige Liste der Rechte einschließlich des Beschwerderechts bei einer Aufsichtsbehörde und ob automatisierte Entscheidungsfindung stattfindet. Schreiben Sie in einer Sprache, der ein normaler Mensch folgen kann. Gestufte Hinweise, mit einer Kurzfassung, die auf Details verlinkt, funktionieren besser als eine Textwand.

Formulare sollten nur erheben, was Sie brauchen. Jedes Feld ist eine Rechtfertigung, die Sie eventuell liefern müssen. Wenn das Häkchen für Werbeeinwilligung im selben Absenden steckt wie die Bestellung, muss es separat nicht vorausgewählt und separat formuliert sein.

Eingebettete Drittinhalte sind der stille Fehler. YouTube im datenschutzfreundlichen Modus, Karten hinter einem Klick-zum-Laden-Platzhalter, Schriften selbst gehostet statt von einem Drittanbieter-CDN. Jede dieser Änderungen ist klein und beseitigt einen Befund.

Was wir am häufigsten schiefgehen sehen

Nach genug Audits taucht immer dieselbe kurze Liste auf:

1. Analytik, die vor der Einwilligung lädt, meist weil ein Tag-Manager vom Marketing konfiguriert und nie von der Entwicklung geprüft wurde.
2. Ablehnen-Buttons, die wegen des Standardverhaltens eines Drittanbieter-Skripts trotzdem Einwilligung auslösen.
3. Überhaupt keine Aufbewahrungsjobs, in keiner Tabelle.
4. Löschungen, die Backups, Logs und das CRM übersehen.
5. Eine Datenschutzerklärung, die einen Datenfluss beschreibt, der sich vor achtzehn Monaten geändert hat.
6. Listen von Unterauftragsverarbeitern, die bei den drei offensichtlichen Anbietern aufhören.
7. Einwilligungsnachweise ohne die Version des angezeigten Textes.

Nichts davon ist ein schweres Problem. Es ist nur Arbeit, die niemandem zugewiesen wurde.

Hilfe bekommen

Wenn Sie einen zweiten Blick auf eine bestehende Website wollen: Wir machen technische DSGVO-Audits, die ein priorisiertes Backlog liefern statt eines Berichts. Was zu beheben ist, in welcher Reihenfolge, mit einer Schätzung pro Punkt. Wenn Sie neu bauen, ist es erheblich billiger, Datenmodell und Consent-Architektur von Anfang an richtig zu machen.

Wir decken auch die breitere EU-Compliance-Oberfläche ab, darunter Barrierefreiheit und EU-Markteintritt. Erreichbar sind wir unter office@c9group.dev.

Wir bauen Software. Wir erteilen keine Rechtsauskünfte, und die Auslegung einer konkreten Anforderung gehört zu Ihren Juristen. Was wir tun können, ist dafür zu sorgen, dass das System das tut, was Ihre Juristen sagen.