DSGVO-Konformität fängt schon beim System an.
Ein DSGVO-konformes CMS ist keine Cookie-Banner-Frage. Es ist eine Frage der Plattformwahl, des Hostings und der Datenverarbeitung dahinter. TYPO3 auf deutschem Hosting — mit AVV, Verfahrensverzeichnis und sauberem Löschkonzept.
Cookie-Banner sind das letzte 5%.
Die Lösung mit TYPO3
- Open-Source-CMS auf eigenem Hosting in Deutschland — keine Drittlandübermittlung als Default
- Volle Kontrolle über jede Datenverarbeitung, jede Schnittstelle, jeden Drittanbieter
- Cookie-lösungen, die wirklich erst nach Consent feuern — nicht der Industriestandard „feuert trotzdem“
- Auditierbares Löschkonzept für Inhalte, Logs und Backups
- Verfahrensverzeichnis und AVV in deutscher Sprache, abgestimmt auf Ihre Rolle als Verantwortlicher
Das Problem
- WordPress-Plugins, die unkontrolliert Daten in US-Clouds spielen
- SaaS-CMS, deren AVV im Englischen formuliert ist und nach Kalifornien verweist
- Tracking-Skripte, die schon vor Cookie-Banner-Klick Daten ziehen
- Kein dokumentiertes Löschkonzept — „wird im DAM gelöscht“ reicht nicht
- Kein Verfahrensverzeichnis, das einer Prüfung standhalten würde
Vier Kriterien, an denen sich DSGVO-Konformität wirklich entscheidet.
Diese vier Punkte trennen ein DSGVO-konformes CMS von einem CMS, das DSGVO-Konformität nur auf der Webseite behauptet. Ohne sie fällt jede Prüfung in sich zusammen.
4. Verfahrensverzeichnis & AVV ready-to-use
Sie bekommen das Verfahrensverzeichnis Ihrer Datenverarbeitung als Vorlage in deutscher Sprache, die Ihr Datenschutzbeauftragter direkt übernehmen kann. Plus AVV mit uns als Auftragsverarbeiter, abgestimmt auf das, was wir tatsächlich tun — nicht generisch.
3. Löschkonzept, das durch Backups durchgreift
Löschung im CMS löscht auch im DAM, im Suchindex, in den Caches und in den Backup-Rotationen — nachweisbar. Auftragsverarbeitungsverträge mit klar definierten Löschfristen, automatisiert ausgelöst.
2. Consent-First-Implementierung
Alle Drittanbieter-Skripte (Analytics, Maps, Video, Schriften, Chat) feuern erst nach explizitem Consent. Default ist: nichts geladen. Server-Side-Tagging, wo möglich. Cookieless Analytics als Standardoption.
1. Datenresidenz in der EU — ohne Hintertür
Hosting in Deutschland, Backups in Deutschland, Logs in Deutschland. Keine Subprozessoren in den USA, kein „Ausnahmsweise“-Datenfluss über CDN-Anbieter, kein Edge-Compute in Drittländern ohne Schrems-II-Prüfung. Bei uns: AWS Frankfurt + EU-Subprozessoren, klar dokumentiert.
Was DSGVO im Betrieb konkret bedeutet.
Vier Beiträge aus unserem Blog, in denen DSGVO als Konsequenz aus Architektur und Betrieb — nicht als Marketing-Behauptung — sichtbar wird.
Warum wir auf AWS setzen
Wie wir die DSGVO-Anforderungen mit AWS in Frankfurt umsetzen — inklusive der Punkte, an denen wir bewusst andere Bausteine ergänzen.
Ihre CI-Pipeline ist das größte Einfallstor
DSGVO endet nicht beim Webserver — jede Pipeline, die Code in Ihre Plattform schiebt, ist DSGVO-relevant.
Bitwarden-CLI-Vorfall vom 22. April 2026
Warum Lieferketten-Risiken auch für DSGVO relevant sind — jeder Subprozessor ist Ihre Verantwortung.
Das 3-Schichten-Modell
Wie wir Verantwortung im Betrieb klar trennen — die Voraussetzung für ein Löschkonzept, das auch durch Caches und Backups greift.
Standort Deutschland, Open Source, AVV auf Deutsch und Verfahrensverzeichnis als Vorlage.
DSGVO-Check Ihrer aktuellen Plattform?
In 30 Minuten schauen wir auf Ihre aktuelle CMS-Situation: Wo liegen die Daten? Wer sind Ihre Subprozessoren? Wie greift Ihr Löschkonzept? Sie bekommen eine Liste konkreter Risiken — ohne Beratungspaket im Anhang. Kostenfrei, unverbindlich.
Oder direkt schreiben: kontakt@moselwal.de