Technical compliance
GDPR website compliance checklist
A practical checklist for cookie consent, privacy copy, processors, forms, and access requests on Germany and EU business sites. Written for operators who need working controls on the live site.
TL;DR
- A GDPR-ready website needs working consent for non-essential cookies, an accurate privacy policy, processor contracts (DPAs), a real DSAR path, a processor inventory, and forms that collect only what you need.
- Germany/EU is the primary frame: Impressum and privacy links must be easy to find; consent must block marketing/analytics tags until accepted.
- US readers with EU visitors still need GDPR for that traffic. US state privacy laws (for example CCPA/CPRA) may apply in parallel for US residents.
- Checklist ≠ legal advice. Use it to find gaps, then confirm with counsel for your entity. For a technical pass, see our GDPR audit service.
Who this is for
Website operators in Germany and the EU who need a control list they can verify.
Most "GDPR compliant" claims on agency proposals mean a cookie banner was installed. That is not enough. Compliance on a live site is a set of controls you can point to: consent before tags fire, accurate notices, contracts with vendors, and a path when someone asks for their data.
This checklist targets marketing sites, lead-gen WordPress builds, and B2B product sites that run analytics, ads, chat, or CRM embeds. It is Germany/EU primary. If you are a US company with EU traffic or an EU subsidiary, treat the EU visitor path as in scope.
US-only sites without EU targeting still benefit from the hygiene (processor list, retention, form minimisation). Separately, check whether US state privacy laws apply to your residents. This page does not replace that review.
A cookie banner without blocked tags is decoration. Consent requires blocked tags until accept.
Checklist
Twelve website GDPR controls to verify on production.
01
Map processing on the website
List every place personal data is collected or loaded: forms, chat, booking, newsletter, analytics, ads, CDN logs, error trackers, and CRM embeds. If it is not on the map, it will not be in the privacy policy.
02
Cookie and similar tech inventory
Document cookies, localStorage, pixels, and SDKs by purpose (necessary, functional, analytics, marketing). Include who sets them and whether they fire before consent.
03
Consent before non-essential tags
Marketing and analytics must not load until the user accepts. Test in a fresh browser: reject all, then confirm GA, Meta, LinkedIn, Hotjar, and similar tools stay silent. Equal ease for reject and accept.
04
Privacy policy that matches reality
Purposes, legal bases, categories of data, retention, recipients, international transfers, and rights must match the live stack. Update the policy when you add a tool. Soft wording that ignores your actual pixels fails audits.
05
Impressum and easy legal links (DE/EU)
On German sites, Impressum and privacy must be reachable from every page in practice (footer is normal). Broken or buried links are a common fail in reviews.
06
Processor list and DPAs
Every vendor that processes personal data for you needs a data processing agreement (Art. 28). Hosting, email, CRM, analytics, chat, form backends, and error logging count. Keep signed copies.
07
International transfers documented
If data goes to the US or other third countries, record the transfer tool (adequacy, SCCs, plus transfer impact notes where required). "We use a US SaaS" without paperwork is a gap.
08
DSAR / data subject request path
Publish how people request access, deletion, or correction. Route inbox to a human owner with a deadline (usually one month). Test that you can actually export or erase website and CRM records.
09
Forms: minimisation and purpose
Collect only fields you use. State why you need them. Do not pre-tick marketing consent. Wire form data to a known system with retention. Avoid parking form data forever in a random inbox.
10
Security basics on the site path
HTTPS everywhere, admin access limited, secrets out of the repo, and vendors patched. GDPR expects appropriate security; a public wp-admin with weak passwords undermines the paperwork.
11
Records and retention
Know how long leads, tickets, and analytics identifiers are kept. Delete or anonymise on schedule. Orphaned CRM lists and everlasting form CSVs are frequent findings.
12
Retest after every marketing stack change
New pixel, new chatbot, new A/B tool: re-check consent blocking, privacy copy, and DPA status before launch. Compliance decays when growth tools ship without a review.
Quick evidence map
What "done" looks like for each control family.
| Control | Evidence on a live site | Common fail |
|---|---|---|
| Consent | Reject-all works; analytics network calls absent until accept | Tags fire on page load before any choice |
| Privacy policy | Lists actual tools, purposes, and rights contacts | Generic template missing chat, CRM, or US processors |
| DPA / processors | Signed Art. 28 agreements on file for each vendor | Only the host has a contract; pixels ignored |
| DSAR | Published email/form plus tested export/erase path | Privacy@ alias that nobody monitors |
| Forms | Minimal fields, purpose text, known retention | Optional fields treated as required; no unsubscribe path |
Germany / EU vs US readers
Build for EU visitors first if they can reach the site.
German sites should treat Impressum, privacy, and consent UX as table stakes. Supervisory attention and competitor complaints often start with a banner that does not block tags or a policy that ignores real processors.
US companies selling into Europe need the same website controls for EU personal data. Separately, US state privacy laws may require notice, opt-out of sale/share, and consumer request handling for US residents. Run both tracks if you have both audiences.
This checklist does not decide your legal bases or whether you need a DPO. It tells you whether the website implementation matches a serious GDPR posture.
One-hour smoke test
Run this in a private window before you call the site ready.
✓
Load homepage with reject all: no analytics/ads requests in the network panel.
✓
Accept analytics only: only those tags fire; marketing stays off if not accepted.
✓
Open privacy policy: every live tool you saw in the network panel appears in the policy.
✓
Submit a test lead: data lands in the expected system; confirmation email behaviour matches the notice.
✓
Send a test DSAR to the published address: someone acknowledges within your SLA.
✓
Confirm DPAs exist for host, email, CRM, and any tag that processes personal data.
Audit vs checklist
Use the checklist weekly. Use an audit when stakes are high.
Run the smoke test after every stack change. Commission a deeper pass before a funding round, enterprise security review, or after years of unmanaged pixels. Our technical GDPR audit focuses on what the site and vendors actually do. Pricing context sits in GDPR audit cost.
Pair website fixes with honest privacy copy and counsel review for entity-level questions. Engineering can block tags; it cannot invent a lawful basis.
Common questions
What people ask about GDPR on websites.
What is a GDPR website compliance checklist?
A practical list of controls: consent that blocks non-essential cookies, an accurate privacy policy, processor DPAs, a DSAR path, a processor inventory, secure HTTPS/admin hygiene, and forms that collect only needed data. It verifies the live site. A slide deck alone is incomplete.
Is a cookie banner enough for GDPR?
No. The banner must obtain valid consent before analytics and marketing tags load, offer a real reject option, and match what the privacy policy describes. A banner that decorates while tags fire immediately is incomplete. For Germany-specific rules, read cookie banner GDPR requirements. For analytics stacks, see Google Analytics and GDPR.
Do US companies need GDPR on their website?
If you process personal data of people in the EU/EEA (or UK GDPR where applicable) through the site, those rules apply to that processing. US state privacy laws may also apply to US residents. Scope both audiences explicitly.
What is a DPA and who needs one?
A data processing agreement (Art. 28 GDPR) is the contract between you (controller) and a vendor that processes personal data for you. Hosting, email, CRM, analytics, chat, and form backends typically need one.
How do I handle DSAR requests from the website?
Publish a contact path, assign an owner, acknowledge requests, and be able to find, export, correct, or erase personal data in the site stack and connected CRM within the legal time limit. Test the path before you need it.
How often should we recheck website GDPR controls?
After every new pixel, chatbot, or form tool, and at least quarterly for the smoke test. Marketing stacks change faster than legal pages, which is how most gaps appear.
Start here
Ready to talk.Send us the brief.
or book a 15-minute call →or email us directly →
Not sure where to start? Send the page, workflow, or backlog causing the problem. We will tell you whether it needs a scope call, a short diagnostic, or a different first step.