Building a GDPR-Compliant Website: The 2026 Checklist

A website in Germany is quick to put online — but that doesn't make it legally sound. Between the duty to publish a legal notice, cookie consent and the new accessibility law, there are a handful of points you can't afford to forget if you want to avoid a warning letter. This checklist works through them one by one: what the law requires, what matters, and how BlenSite takes the work off your hands.

This article explains the requirements in plain terms but is not legal advice. For special cases — such as processing health data or tracking across several services — it's worth having an IT-law specialist take a look.

1. Legal notice: mandatory details per § 5 DDG

The legal notice (Impressum) is the best-known obligation — and since 14 May 2024 it lives in a new law. The Telemedia Act (TMG) was replaced by the Digital Services Act (DDG). Little has changed in substance, but a legal notice that still cites the "TMG" is outdated and vulnerable. The provider identification is now found in § 5 DDG.

A complete legal notice usually contains:

Full name and a physical address (not a P.O. box)
For companies: legal form and authorised representatives (e.g. managing director)
Contact: an email address and a second fast contact channel (e.g. phone)
Commercial register and registration number, if applicable
VAT identification number, if applicable
For licensed professions: the responsible supervisory authority
For regulated professions (doctors, lawyers, tax advisers): chamber, statutory job title and professional rules
A statement on consumer dispute resolution under § 36 VSBG — the once-common reference to the EU online dispute resolution platform is obsolete since the platform was shut down on 20 July 2025, and a leftover link is itself grounds for a warning letter

The legal notice must be reachable in one click from every page and clearly labelled as such.

2. Privacy policy per Art. 13 GDPR

As soon as your website processes personal data — and it almost always does, at the latest via server logs on page load — you need a privacy policy. It transparently informs users, per Art. 13 GDPR, which data you process for which purpose and on which legal basis.

Typical points that belong in it:

The controller and, if applicable, the data protection officer
Server log files and their legal basis (usually legitimate interest, Art. 6(1)(f) GDPR)
Contact form and email contact
Cookies and the tools you use (analytics, maps, fonts, videos)
Data subject rights (access, erasure, objection) and the right to complain to a supervisory authority
Retention period or the criteria for deletion

Important: name the appropriate legal basis for each individual processing operation. A generic phrase isn't enough.

3. Cookie consent per § 25 TDDDG

The cookie banner is where most sites stumble. The legal basis today is the TDDDG (Telecommunications Digital Services Data Protection Act), which replaced the earlier TTDSG in May 2024. If your privacy policy still says "TTDSG", that's outdated too.

Under § 25 TDDDG: for all cookies and technologies that are not strictly necessary, you need active, prior consent. That means:

No setting of non-essential cookies before consent
"Reject" must be as easy as "Accept" — equivalent buttons on the first layer
No pre-ticked boxes, no forced consent
Consent must be revocable and documented

Strictly necessary cookies (session, shopping cart) are exempt. Fines under § 28 TDDDG can reach 300,000 euros — a pure "accept all" button is not a good idea.

4. SSL/TLS encryption (HTTPS)

Every website that receives data through forms must transmit it encrypted — Art. 32 GDPR (security of processing) already requires this. In practice: a valid TLS certificate, the site runs over HTTPS, and HTTP requests are redirected automatically. Without the padlock, browsers actively warn visitors — bad for trust and for visibility on Google.

5. Data processing agreement (DPA) per Art. 28 GDPR

As soon as a service provider processes personal data on your behalf — your host, a newsletter tool, a form service — you need a data processing agreement (DPA) with them per Art. 28 GDPR. Make sure the provider processes in the EU or guarantees an adequate level of protection. A provider with servers and a legal seat in Germany makes this point much simpler than a transfer to third countries.

6. Design contact forms with data minimisation

Forms are the most common way a website collects data — and the place where the principle of data minimisation (Art. 5 GDPR) is broken fastest. Ask only for what you truly need: for an appointment request, a name, contact and message are enough. Mark required fields clearly, obtain consent to processing and explain in the privacy policy what happens with the data. An email address left visible in the source code is not only a spam magnet but also less clean from a data-protection view than a proper form.

7. Fonts and external resources: Google Fonts & CDNs

An underrated classic: externally embedded fonts. If your site loads Google Fonts directly from Google's servers, the visitor's IP address is transmitted to Google on every page load — without consent. In 2022 the Munich Regional Court treated exactly this as a GDPR violation and awarded damages. The consequence: self-host your fonts, don't load them dynamically from third-party servers. The same goes for scripts, icons and maps served from external CDNs.

8. Accessibility per BFSG

The newest item on the list: the Accessibility Reinforcement Act (BFSG), in force since 28 June 2025. It requires certain digital services to be accessible — in particular websites with electronic business functions such as online shops, bookings or customer accounts. The benchmark is essentially WCAG 2.1 at level AA.

For micro-enterprises (fewer than 10 employees and at most 2 million euros in annual turnover or balance sheet total) there is an exemption for services — but not if products are sold. Don't rely on it blindly: accessibility is good for all users and for SEO, and violations can be penalised with up to 100,000 euros. If you're building new, build accessible from the start.

The short checklist

Legal notice with all mandatory details per § 5 DDG, reachable from every page
Privacy policy per Art. 13 GDPR with a legal basis for each processing operation
Cookie consent per § 25 TDDDG — equivalent "reject", nothing before consent
HTTPS with a valid TLS certificate, HTTP redirect active
DPA per Art. 28 GDPR with all providers, EU processing where possible
Contact forms with data minimisation, with consent, no open email in the source
Fonts and external resources self-hosted (no dynamic Google Fonts)
Accessibility per WCAG 2.1 AA — check the BFSG obligation in force since 28 June 2025

How BlenSite automates this

The good news: you don't have to do almost any of this by hand. From your details, BlenSite generates a legal notice per the DDG and a privacy policy with a legal basis for each processing operation, embeds a cookie-consent banner per the TDDDG and serves every page over HTTPS. Hosting is exclusively in Frankfurt — your data stays in the EU, and a DPA is available. Fonts are self-hosted instead of loaded from third-party servers, and every generated page is automatically checked for accessibility to WCAG 2.1 AA.

That covers the mandatory points without needing a lawyer appointment for the standard texts. If your details change, you update the legal texts any time, free of charge, by chat.

If you want to start for your sector, you'll find fitting examples under industries — for a medical practice or a restaurant, say. And if you want to know what that costs compared to an agency or a builder, we do the maths in What does a website cost?. Your first website is free.