Website GDPR Compliance: A Practical Checklist for Site Owners

Website GDPR compliance sounds like a legal project. In practice, it’s mostly an inventory problem. You need to know what your site collects, why it collects it, where that data goes, and whether you can explain all of it in plain language. Once you have those four answers written down, the rest is housekeeping.

I’ve walked through this on dozens of sites — my own, clients’, and a few I inherited in a mess. The pattern repeats: owners assume they’re non-compliant because of some scary article they read, or they assume they’re fine because they installed a cookie banner plugin. Both assumptions are usually wrong. So here’s the checklist I actually run, in the order I run it.

A quick note before we start: I’m a marketer, not a lawyer. This is a practical working checklist, not legal advice. For high-risk processing — health data, large-scale profiling, children’s data — talk to someone qualified.

Does GDPR Even Apply to Your Website?

Start here, because plenty of site owners skip it. The regulation applies if you’re established in the EU, and it also reaches organisations outside the EU when they offer goods or services to people in the EU or monitor their behaviour. That second trigger — Article 3(2) — is the one that catches most websites.

Here’s the part people miss: analytics counts as monitoring behaviour. Therefore, if you run any visitor tracking and you have EU readers, you’re in scope regardless of where your server sits. A US-based blog with a German audience is in scope. A Canadian shop that ships to France is in scope.

What doesn’t put you in scope? Simply being reachable from Europe. If your site is in Japanese, prices are in yen, and you don’t ship to the EU, an occasional European visitor doesn’t drag you in. Intent matters — language, currency, shipping options, and ad targeting are the signals regulators look at.

Step 1: Write Down What You Actually Collect

You cannot comply with rules about data you haven’t listed. So the first task is boring and unavoidable: open a spreadsheet and inventory every place your site touches personal data.

Walk the site as if you were a visitor. Then list:

• Analytics — what tool, what identifiers, what retention period
• Forms — contact, newsletter, checkout, comments, file downloads
• Embeds — YouTube, Maps, fonts, chat widgets, social buttons
• Server logs — IP addresses are personal data, and your host keeps them
• Third-party scripts — ad pixels, heatmaps, A/B testing, error trackers

Embeds are where the surprises live. A single embedded video or a webfont loaded from a third-party CDN can transmit visitor IP addresses to another company before anyone clicks anything. Moreover, these get added by themes and plugins without anyone deciding to add them.

To find them, open your browser’s network tab on a fresh visit and sort by domain. Every external domain in that list is a party receiving something about your visitor. I’ve never run this on an established site and found fewer than three surprises.

Formally, this inventory becomes your record of processing activities under Article 30. Organisations under 250 employees get a partial exemption, but it’s narrower than it sounds — it falls away when processing is regular rather than occasional, which describes any website running continuous analytics. Keep the record anyway. It takes an afternoon and it’s the first thing a regulator asks for.

Step 2: Give Every Purpose a Lawful Basis

Every processing purpose needs one of six lawful bases from Article 6. Most websites only ever use three.

Two rules keep this clean. First, one purpose gets one basis — you can’t claim consent and then fall back on legitimate interest when someone withdraws it. Second, if you pick legitimate interest, write down the balancing test: what your interest is, why the visitor’s rights don’t override it, and what you did to limit the impact. A short paragraph per purpose is enough, but it has to exist on paper.

Step 3: Handle Cookies Under the Right Rule

This is the step most owners get backwards. Cookie consent isn’t primarily a GDPR question — it comes from the ePrivacy Directive, whose Article 5(3) says you need consent before storing information on someone’s device or reading what’s already there. It applies to cookies, localStorage, and device fingerprinting alike, and it applies regardless of whether the data is personal.

The only carve-out is for storage that’s strictly necessary to deliver a service the user explicitly requested. A session cookie keeping a logged-in user logged in qualifies. A shopping cart qualifies. Analytics generally does not, because the visitor didn’t ask to be measured.

Consequently, valid consent has to be freely given, specific, informed and unambiguous — which rules out most of what I see in the wild:

• Banners with only an “Accept” button and no equally easy refusal
• Pre-ticked boxes or sliders defaulted to on
• Scripts that fire before the visitor chooses anything
• “By continuing to browse you agree” notices — scrolling isn’t consent
• No way to withdraw consent later, as easily as it was given

That last one catches almost everyone. If your banner has no persistent “change preferences” link, withdrawal isn’t as easy as giving consent, and the consent isn’t valid. I wrote more about when a banner is genuinely required in this breakdown of consent banners.

There is a way out of this loop, and it’s the reason this site exists: if your analytics doesn’t store or read anything on the device, Article 5(3) isn’t triggered. Several privacy-first tools are built exactly this way. France’s data protection authority, the CNIL, has published conditions under which certain audience-measurement setups can be exempt from consent — strictly limited scope, no cross-site tracking, aggregated results only. Other national regulators take somewhat different lines, so the exemption isn’t automatic across every market. Still, cookieless measurement moves you from “needs valid consent” to “arguably needs none,” which is a much better place to stand.

Step 4: Follow the Data Out of the Building

Anyone processing personal data on your behalf is a processor, and you need a data processing agreement with each one. That covers your host, your email service, your analytics provider, your CRM, your backup service. Most reputable vendors publish a standard DPA you can accept in their dashboard — go and actually accept it, because it usually isn’t automatic.

Then check where those processors sit. Transfers outside the EEA need a legal mechanism under Chapter V: an adequacy decision, standard contractual clauses, or one of the narrow derogations. For US vendors, the EU-US Data Privacy Framework, adopted in July 2023, provides adequacy — but only for companies that have actively self-certified under it. Check the vendor’s name on the official Data Privacy Framework list rather than trusting a badge on their marketing page.

Treat that one as live, though. The Framework has been contested since it was adopted: the EU General Court upheld it in September 2025, that ruling was appealed to the Court of Justice, and a June 2026 US Supreme Court decision on the independence of federal agencies has raised fresh questions about the enforcement structure the adequacy finding rests on. Nothing has been struck down, and certified transfers remain lawful today.

The practical lesson isn’t to panic — it’s to avoid building a stack that only works while one adequacy decision survives. If a US transfer is load-bearing for you, keep standard contractual clauses as a documented fallback. Better still, prefer processors inside the EEA where the choice is genuinely equivalent, which for analytics it usually is.

Self-hosting sidesteps the question entirely. If the analytics runs on your own server in the EU, there’s no transfer to justify. That trade-off — a bit of maintenance in exchange for a much shorter compliance story — is one I unpack in the rundown of privacy-first alternatives.

Step 5: Write a Privacy Notice Someone Can Read

Article 13 lists what you must tell people when you collect their data. The legal minimum is a fixed list; the practical goal is that a normal visitor understands it in two minutes.

Your notice needs to cover who you are and how to reach you, what you collect, why, the lawful basis for each purpose, who receives the data, whether it leaves the EEA and under what safeguard, how long you keep it, the visitor’s rights, the right to complain to a supervisory authority, and — if you rely on consent — the right to withdraw it.

The most common failure here isn’t a missing section. It’s a generated template that describes a business you don’t run, listing processors you’ve never used. If your notice mentions a CRM you dropped two years ago, it’s evidence you aren’t managing this. Therefore, delete what doesn’t apply and add what does.

Retention periods deserve a special mention. “As long as necessary” is not a retention period. Give real numbers: analytics data 14 months, contact form submissions 12 months after the conversation ends, invoices as long as tax law requires. Then configure your tools to actually enforce those numbers.

Step 6: Make Data Rights Work in Practice

Visitors can ask for access, correction, deletion, portability, restriction, and they can object to processing. You generally have one month to respond. That deadline is the thing that catches unprepared sites — the request arrives, nobody knows which systems hold the data, and the clock runs out.

So run a dry run. Pick a real email address from your own database and try to answer these questions:

1. Which systems hold data about this person?
2. Can I export all of it in a readable format?
3. Can I delete it everywhere, including backups and the email tool?
4. Who in the team knows how to do this if I’m away?

If the dry run takes you three hours, a real request will take three days you don’t have. Write the steps down while they’re fresh. Meanwhile, add a working contact route for these requests — a dedicated address that someone monitors beats a form that dumps into an inbox nobody opens.

One more thing worth building before you need it: a short breach procedure. Serious breaches must be reported to the supervisory authority within 72 hours of becoming aware, so you want the decision path written down in advance rather than improvised during a bad week.

The Website GDPR Compliance Checklist

Here’s the whole thing in one place. I keep a copy of this per site and date each review.

The Mistakes I See Most Often

Treating the banner as the whole project. A consent banner is one control among fourteen. Installing it while analytics still fires on page load makes things worse, not better — now you’ve documented that you knew consent was required.

Copying a competitor’s privacy notice. Their processors aren’t yours. Their retention periods aren’t yours. It reads as compliant and functions as a liability.

Collecting fields “just in case.” Data minimisation isn’t a suggestion. Every optional field on a form is data you must secure, disclose, retain, and delete on request. If you haven’t used a field in six months, remove it.

Forgetting the exports. The spreadsheet of newsletter subscribers on someone’s laptop is processing too. So is the CSV in a shared drive from last year’s campaign.

Assuming anonymised means exempt. Truly anonymous data falls outside GDPR, but the bar is high — it must be impossible to re-identify anyone, by anyone, including by combining datasets. Hashed IPs and pseudonymised IDs are pseudonymous, not anonymous, and they stay in scope. Tools that never collect the identifier in the first place are a different matter, which is the distinction I drew in this guide to GDPR and website analytics.

For the difference between European and Californian rules — which trips up anyone selling into both markets — see CCPA vs GDPR.

Bottom Line

Website GDPR compliance is achievable for a small site in about a day of focused work, and most of that day is inventory rather than law. List what you collect, justify each purpose, block non-essential scripts until someone agrees, sign your DPAs, write a notice that matches reality, and test that you can honour a deletion request.

The shortcut worth taking is upstream: the less you collect, the less there is to defend. Every site I’ve moved to a cookieless, EU-hosted measurement setup got shorter on all fourteen checks at once — no banner to maintain, no transfer mechanism to verify, no retention policy to enforce on data that was never stored. Compliance stopped being a project and became a property of the setup. For most websites, that’s the whole answer.

Regulators update their guidance regularly, and national authorities differ on the details. So date your checklist, review it once a year, and check your own supervisory authority’s current position before making a call on the edge cases. Official sources are worth reading directly: the European Data Protection Board’s guidelines and the ICO’s organisation guidance are both written for practitioners rather than lawyers.