GDPR Compliance Checklist for European Websites

The most consistent finding from our GDPR compliance reviews isn't the obvious stuff. It's not missing privacy policies or unsigned DPAs. It's sites that installed a cookie consent tool, saw the banner appear, and concluded they were compliant, without ever checking whether analytics and marketing scripts were actually blocked before consent. Cookiebot on your site and Google Analytics loading before consent are not mutually exclusive. We've seen both coexist on audited sites more times than we'd like to admit. This checklist covers what actually fails in practice, not just what the regulation says in theory.

Cookie Consent: The Banner Isn't Enough

A compliant consent mechanism must block all non-essential cookies before consent is given. That means analytics, marketing pixels, and social media scripts must not fire on page load, or after a 3-second delay, or unless someone scrolls past a banner. Before consent means before consent.

Users must also be able to accept or reject cookies by category (necessary, analytics, marketing, preferences separately), and the "Reject All" button must be as prominent as "Accept All." Burying the reject option in a sub-menu or making it grey while the accept button is bright green is a dark pattern that regulators have started enforcing specifically. You must store consent records, including timestamp, user identifier, and which categories were accepted, and allow users to change their preferences at any time.

Tools like Cookiebot or Complianz handle the consent UI, but correct configuration is what makes them work. Many out-of-the-box setups still load Google Analytics or Facebook Pixel before consent because the tag manager configuration wasn't updated after the consent tool was installed. If you're running GA4, our GA4 setup guide covers how to implement consent mode correctly so Analytics only fires when permitted.

Privacy Policy Requirements

Your privacy policy must be in clear, plain language, not legal jargon copied from a template. It needs to name you as the data controller with contact details, and list the types of personal data you collect alongside the purpose and legal basis for each processing activity (consent, legitimate interest, contractual necessity, or legal obligation). Third parties who receive data must be named: your hosting provider, analytics service, payment processor, email marketing platform. Retention periods for each data category must be stated. And users must understand how to exercise their rights: access, rectification, erasure, portability, and objection.

A cookie policy and a privacy policy are separate documents. A lot of sites have one without the other, and some have neither, just a vague "we respect your privacy" footer line.

Data Processing Agreements

Any third-party service that processes personal data on your behalf requires a Data Processing Agreement (DPA). This includes your hosting provider, analytics service, email marketing platform, and CRM. Most major providers (AWS, Google, Mailchimp, HubSpot) offer standard DPAs you sign electronically. The obligation is on you to ensure they're in place, not on the provider to ask. Smaller EU hosting companies often don't surface this proactively, which is why we find missing DPAs on almost every site that uses a regional host.

Right to Erasure

Users can request deletion of their personal data. You need a documented process for receiving those requests, verifying the requester's identity, and deleting data from all systems within 30 days, including backups where technically feasible. Any third parties who received the data must be notified, and the request and your response must be documented.

For e-commerce sites, this is complicated by the fact that you may have a legal obligation to retain certain transaction data (invoices, tax records) for 5-10 years under national accounting law. The legal basis for retaining that data overrides the erasure request, but you still need to delete everything else. Getting this balance right requires a documented data retention policy, not just a delete button.

SSL/HTTPS and Data Security

GDPR requires "appropriate technical and organisational measures" to protect personal data. In practice, all pages must be served over HTTPS with a valid certificate. Passwords must be hashed using bcrypt or Argon2 (MD5 and SHA-1 are still found on older sites and are not acceptable). Sensitive personal data fields should be encrypted at rest in the database. Access to personal data must be restricted to authorized personnel with access logging in place. And security audits should happen on a regular cadence, particularly after major software updates.

Where the Real Compliance Gaps Hide

Pre-ticked consent checkboxes on contact forms and newsletter sign-ups come up constantly. Consent must be an affirmative action, so a pre-ticked box is invalid regardless of what your terms say. Bundled consent is the related problem: combining marketing email opt-in with acceptance of terms of service in a single checkbox. Those two must be separate opt-ins under GDPR, and many e-commerce checkouts still bundle them.

Contact form submissions not being treated as personal data is surprisingly common. They are personal data, full stop, and that means documenting how long you retain them and why. The retention question catches a lot of sites: "forever" is not a valid retention period, but it's effectively what many sites practice because nobody configured automatic deletion or ever thought about it.

Not logging consent records is the one that creates the most exposure with regulators. "We displayed a banner" isn't documentation. You need to be able to demonstrate when and how each specific consent was obtained, which requires storing a timestamped record per user, per session.

From a Recent GDPR Review Before a Market Expansion

A Latvian fashion retailer asked us to review their GDPR posture before a planned expansion into Germany and Sweden. We found five issues. Google Analytics and Facebook Pixel were both firing before consent despite a Cookiebot installation, because the GTM container hadn't been configured with consent mode variables. There was no DPA in place with their Lithuanian hosting provider. Their privacy policy hadn't been updated since 2019 and still referenced Universal Analytics. Contact form submissions were being stored indefinitely with no retention policy. And checkout email captures were automatically adding customers to a marketing list without a separate opt-in.

We addressed all five over three weeks. The DPA was the easiest fix, a 20-minute email exchange. The consent configuration took the most time because their GTM setup had to be rebuilt from scratch with consent mode variables controlling when each tag fires. The privacy policy update took a full day of drafting with their management team.

The hard part of GDPR compliance isn't usually the technical fixes. It's documenting your data flows well enough to know what you're collecting, where it goes, and why, before you can decide what to protect or delete. Start with that inventory and the technical implementation follows naturally. Our IT Consulting service includes GDPR compliance reviews covering the technical implementation side. If you're evaluating which e-commerce platform handles EU compliance better, our comparison of PrestaShop vs WooCommerce covers the consent and data handling features each platform ships with.