| name | dach-compliance |
| description | Cover Germany, Austria, and Switzerland compliance requirements that have security implications. Covers Impressum content per TMG/MStV/ECG, Datenschutzerklärung per DSGVO/TTDSG/DSG, AGB and Widerrufsbelehrung, AVV/DPA for sub-processors, technical-organizational measures (TOMs), and cookie consent that satisfies all three jurisdictions. Invoke when launching a DACH-facing site, adding third-party services, or reviewing an inherited DACH site. |
DACH Compliance (DE / AT / CH)
DACH markets — Germany, Austria, Switzerland — have a stricter and more enforced compliance regime than most jurisdictions. The good news: a small set of pages plus a cookie banner satisfies the common case. The bad news: missing any one of them is a real risk, particularly in Germany where commercial cease-and-desist (Abmahnung) is a small industry.
This skill is about the technical implementation of these requirements. It is not legal advice. For non-trivial cases (especially regulated industries, B2B SaaS at scale, or anything cross-border), retain a DACH-qualified lawyer.
When to invoke
- Launching a website or web app to a DACH audience
- Adding new third-party services (analytics, ads, chat, AI, CRM, CDN)
- Reviewing an inherited DACH site for compliance gaps
- After an Abmahnung or Datenschutz inquiry
- Periodic review (annually is reasonable)
The four pages every DACH site needs
| Page | Slug convention | What it is |
|---|
| Impressum | /impressum | Legal identification of the operator. Required by §5 TMG (DE), §25 MedienG (AT), and §3 lit. s UWG (CH). |
| Datenschutzerklärung | /datenschutz or /datenschutzerklaerung | Privacy policy compliant with GDPR + national law (TTDSG / TKG 2021 / FADP). |
| AGB | /agb | General Terms and Conditions — required for online sale of goods/services in B2C, strongly recommended in B2B. |
| Cookie banner | site-wide overlay | Consent UI for non-essential cookies/tracking. |
The Impressum and Datenschutzerklärung must be reachable from every page with no more than two clicks and the link text must be unambiguous. Footer links named exactly "Impressum" and "Datenschutz" are the safe pattern.
Impressum — what must be in it
The legally required content varies slightly by jurisdiction. A safe combined Impressum for a site targeting all three:
Anbieter / Verantwortlich
[Vor- und Nachname / Firmenname mit Rechtsform]
[Straße Hausnummer]
[PLZ Ort]
[Land]
Kontakt
Telefon: +43 ...
E-Mail: info@example.com
[Optional: Kontaktformular-Link]
Vertretungsberechtigte
[Bei juristischen Personen: Geschäftsführer / Vorstand mit Vor- und Nachname]
Handelsregister / Firmenbuch
[Registergericht / Firmenbuchgericht]
[Registernummer / Firmenbuchnummer]
Umsatzsteuer-Identifikationsnummer
[UID / USt-IdNr.]
Aufsichtsbehörde
[Sofern Gewerbe mit Behördenaufsicht]
Berufsbezeichnung und Kammer
[Bei reglementierten Berufen — Ärzte, Anwälte, Steuerberater etc.]
Online-Streitbeilegung (EU)
Die EU-Kommission stellt eine Plattform zur Online-Streitbeilegung bereit:
https://ec.europa.eu/consumers/odr/
Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV (DE) bzw. § 25 MedienG (AT)
[Vor- und Nachname, Anschrift]
Implementation rules:
- Plaintext, not behind login. Search engines and regulators must reach it.
- No
noindex, no robots.txt block.
- No "click here for Impressum" — name the link "Impressum" literally.
- Email address must be reachable, not a contact form alone. Plaintext is fine — yes, scrapers will grab it, that's been the legal position for years.
- Updated when responsibilities change. Wrong Impressum is the same as no Impressum for liability purposes.
Datenschutzerklärung — must match what the site actually does
A static template copied from a generator is a finding, not compliance. The privacy policy must reflect every processing operation actually happening on the site.
Per processing activity, document:
- What data is collected (form fields, automatic data, cookies, fingerprinting)
- Why (legal basis: consent / contract / legitimate interest / legal obligation)
- Where it's stored (own systems, processors, location)
- Retention period specifically
- Recipients (every third-party processor named with link to their privacy policy)
- User rights (access, rectification, deletion, portability, objection, supervisory authority complaint)
Common DACH-site processing to enumerate:
- Web server logs (IP, user-agent, referrer, path, status, timestamp)
- Contact form / inquiry handling
- Newsletter / mailing list subscription with double opt-in
- Cookies & local storage (essential + optional)
- Analytics (Matomo, GA4 — needs consent in DACH)
- Maps (Google Maps, OpenStreetMap, Mapbox)
- Embedded videos (YouTube/Vimeo — pre-consent variants exist:
youtube-nocookie.com)
- Fonts (self-hosted vs Google Fonts — Google Fonts CDN was the subject of multiple AT/DE judgments; self-host is the safe path)
- Payment processors (Stripe, PayPal, Klarna)
- AI / LLM services that receive user content
Sync the privacy policy with the data inventory from gdpr-technical-controls — they should never disagree.
Cookie / consent banner — the requirement
Under TTDSG §25 (DE) / §165 TKG 2021 (AT) / DSG (CH, more permissive), you may only store or read information on the user's device with prior, informed, opt-in consent — except for strictly necessary cookies.
The banner must:
- Block non-essential cookies/scripts until consent. A banner that just says "by using this site you agree" while Google Analytics already loaded is non-compliant.
- Offer "Accept", "Reject all", and "Settings" with equal prominence. "Reject" cannot be a tiny grey link under a large green "Accept".
- Provide granular categories — typically "Essential", "Analytics", "Marketing", "Functional" — that users can toggle individually.
- Be revocable. A persistent re-open link (small "Cookie-Einstellungen" in the footer) is the standard pattern.
- Log consent with timestamp and what was consented to — you may need to prove it later.
Acceptable banner stacks:
- Self-hosted: Klaro!, Cookiebot (paid), Iubenda (paid)
- WordPress-hosted: Real Cookie Banner, Borlabs Cookie, Complianz
- DIY: a small implementation is fine if you cover the requirements above
Wire it to actual script-loading: scripts that depend on a category only run after the user opts in. A consent record without enforced gating is theater.
AGB — Terms of Service
Required for B2C e-commerce; strongly recommended for B2B and for SaaS. AGB must:
- Be accepted before purchase — typically a checkbox on the order page with a clear link to the AGB text
- Be persistently available at a stable URL (
/agb)
- Match the actual fulfillment process — delivery timelines, return windows (14-day right-of-withdrawal for B2C distance contracts under DE/AT law), warranty
- Not include surprise clauses — DE has aggressive jurisprudence against unfair contract terms (AGB-Kontrolle)
- Include a Widerrufsbelehrung (withdrawal notice) for B2C — there are statutory templates; deviating is risky
Templates are a starting point, not the finished product. Have a DACH e-commerce lawyer review the AGB before launch if you sell B2C.
AVV / DPA — for every processor
Every third party that processes personal data on your behalf needs an Auftragsverarbeitungsvertrag (AVV) under Art. 28 GDPR (in EN: Data Processing Agreement / DPA).
Engineering side:
- Sign before integration, not after launch. Most providers offer a standard AVV in their privacy/legal portal.
- Track which AVV covers which processor — when you onboard a new tool, the AVV is part of the onboarding checklist
- Some major providers' standard AVVs are good enough (AWS, Stripe, Cloudflare, Mailgun, HubSpot). Smaller vendors sometimes need an actual draft.
- Inform users in the Datenschutzerklärung that data goes to this processor and link their privacy policy
TOMs — Technical and Organizational Measures
Art. 32 GDPR requires you to implement appropriate TOMs. For an audit, you need a written document. For your security posture, you need the underlying controls to actually exist. The two should match.
Typical TOMs sections (with the skills in this repo that implement them):
| TOM area | Implementation |
|---|
| Zutrittskontrolle (physical access) | Office locks, server location (cloud DC ISO 27001 etc.) |
| Zugangskontrolle (system access) | Strong auth, MFA — see auth-hardening |
| Zugriffskontrolle (data access) | Role separation, RLS — see postgres-hardening |
| Weitergabekontrolle (transit) | TLS, encrypted backups — see site-server-audit, postgres-hardening |
| Eingabekontrolle (audit) | Audit logging — see log-strategy |
| Auftragskontrolle (processor) | DPAs/AVVs, processor vetting |
| Verfügbarkeitskontrolle (availability) | Backups, restore tests, monitoring |
| Trennungsgebot (purpose separation) | Tenant isolation, separate environments |
Write this document early — once your stack is set, generate the TOMs from what you've actually built.
CH-specific notes (FADP / DSG)
Switzerland's revised FADP (2023) is close to GDPR but not identical:
- Notification deadline differs — without undue delay rather than 72h
- Record of processing activities required for entities ≥250 staff or for high-risk processing
- Cross-border transfers to non-adequate countries need additional safeguards (similar to SCCs)
- Data Protection Impact Assessment (DPIA) required for high-risk processing
- Privacy Icon convention is recommended but not mandatory
For sites targeting EU + CH together, GDPR-compliant is generally CH-compliant; document the small deltas if you operate from Switzerland.
Common findings
When auditing a DACH site:
- Impressum missing the Vertretungsberechtigte (juristic person) or Handelsregister number
- Datenschutzerklärung references services that aren't actually integrated, or omits services that are
- Google Fonts loaded from
fonts.googleapis.com (instead of self-hosted) — Munich and Vienna courts have ruled against this
- YouTube embeds load before consent (use
youtube-nocookie.com and gate behind consent)
- "Accept" cookie button is large+colored; "Reject" is hidden in settings — non-compliant under TTDSG/TKG
- Newsletter signup without double opt-in
- Contact form transmits over HTTP, or stores submissions plaintext in a CMS that allows wide access
- Site has no
/agb despite selling to consumers
- The Datenschutz page links to outdated processor privacy policies
Quick checklist
Before launching or relaunching a DACH-facing site:
What this skill will not do
- Provide legal advice — talk to a DACH-qualified lawyer for borderline cases
- Generate Impressum / AGB content as a substitute for review
- Endorse dark-pattern cookie banners that bury the reject option
