GDPR compliance starts with the system.
A GDPR-compliant CMS isn't a cookie banner question. It's a question of platform choice, hosting and the data processing behind it. TYPO3 on German hosting — with a data processing agreement, record of processing activities and a clean deletion concept.
Cookie banners are the last 5%.
The solution with TYPO3
- Open-source CMS on dedicated hosting in Germany — no third-country transfer by default
- Full control over every data process, every interface, every third party
- Cookie solutions that really only fire after consent — not the industry-standard "fires anyway"
- Auditable deletion concept for content, logs, and backups
- Processing register and DPA in German, aligned with your role as data controller
The problem
- WordPress plug-ins shovelling data uncontrolled into US clouds
- SaaS CMSes whose DPA is written in English and points to California
- Tracking scripts that pull data before the cookie banner has even been clicked
- No documented deletion concept — "it gets deleted in the DAM" isn't enough
- No processing register that would survive an audit
Four criteria where GDPR compliance is actually decided.
These four points separate a GDPR-compliant CMS from one that only claims compliance on its website. Without them, every audit collapses.
4. Processing register & DPA ready to use
You get the processing register for your data activities as a German-language template that your data protection officer can adopt directly. Plus a DPA with us as data processor, aligned with what we actually do — not generic.
3. Deletion concept that reaches into backups
Deletion in the CMS also deletes in the DAM, in the search index, in the caches, and through the backup rotations — verifiably. Data processing agreements with clearly defined deletion deadlines, automatically triggered.
2. Consent-first implementation
All third-party scripts (analytics, maps, video, fonts, chat) only fire after explicit consent. The default is: nothing loaded. Server-side tagging where possible. Cookieless analytics as a standard option.
1. Data residency in the EU — with no back door
Hosting in Germany, backups in Germany, logs in Germany. No sub-processors in the US, no "just this once" data flow via CDN providers, no edge compute in third countries without a Schrems II review. With us: AWS Frankfurt + EU sub-processors, clearly documented.
What GDPR actually means in operation.
Four posts from our blog that show GDPR as a consequence of architecture and operations — not as a marketing claim.
Why we use AWS
How we deliver GDPR requirements on AWS Frankfurt — including the points where we deliberately add other building blocks.
Your CI pipeline is the biggest entry point
GDPR doesn't end at the web server — every pipeline that ships code into your platform is GDPR-relevant.
Bitwarden CLI incident from 22 April 2026
Why supply-chain risks are also relevant for GDPR — every sub-processor is your responsibility.
The 3-layer model
How we draw clear responsibility boundaries in operations — the precondition for a deletion concept that also reaches into caches and backups.
Hosted in Germany, open source, DPA in German and a ready-to-use processing register.
Häufig zusammen eingesetzt.
External IT department
IT that operationally carries data protection — even when no internal team has the time.
GDPR check on your current platform?
In 30 minutes we look at your current CMS situation: where does the data sit? Who are your sub-processors? How does your deletion concept reach? You get a list of concrete risks — with no consulting package attached. Free of charge, no obligation.
Oder direkt schreiben: kontakt@moselwal.de