The WordPress GDPR Compliance Checklist

Most WordPress site owners we talk to think GDPR is something that happens to other people — big companies with data warehouses and a compliance department. Then we ask a simple question: where does a comment on your blog get stored, and what exactly gets stored with it? The answer is the commenter’s name, email address, IP address and browser user agent, kept in your database forever, by default, out of the box. That is personal data. You are processing it. And you almost certainly never decided to.

This is a practical, site-wide checklist you can work through in an afternoon. It’s deliberately broader than the forms-specific advice we’ve written before — forms are one of maybe eight places a normal WordPress site quietly accumulates personal data.

This is practical guidance from people who build WordPress sites, not legal advice. GDPR is a law, it is interpreted by regulators and courts, and the details depend on what you do, where you are, and who your users are. If you process sensitive categories of data — health, biometrics, political or religious views, sexual orientation, children’s data — or you operate at any real scale, get proper legal advice from someone qualified. Use this checklist to get your house in order and to have a much better-informed conversation with that person.

Step 1: Find the personal data you didn’t know you had

You cannot comply with rules about data you haven’t inventoried. Before touching a setting, walk your site the way a regulator would and write down every place a real person’s details land. Here’s what a typical WordPress site collects, in rough order of how often people forget it:

That last row quietly undoes people’s best efforts: you can delete a customer’s account and still hold their data in thirty nightly backups.

The embeds row deserves a second look too. A YouTube video, a Google Map, or a webfont from a third-party CDN makes the visitor’s browser call that third party — handing over an IP and full request headers — the instant the page renders. No click required. If your cookie banner loads after the embed has fired, the banner is decoration. Self-host fonts, and use click-to-load facades for video and maps.

Step 2: Write down your lawful basis, in plain language

For every processing activity in your inventory, you need a lawful basis. In practice, small sites use three of the six:

• Consent — the person actively agreed, for a specific purpose. Marketing email is the classic case.
• Contract — you need the data to deliver what they bought. Shipping an order needs an address; that’s not consent, it’s contract.
• Legitimate interest — you have a genuine business reason, and it doesn’t override the person’s rights and expectations.

Legitimate interest is where most people go wrong, because it reads like a loophole. It isn’t. It requires you to do and record a balancing test: what’s your interest, is the processing necessary for it, and would a reasonable person be surprised or harmed? Security logging of failed login IPs usually passes. Silently profiling visitors to retarget them with ads usually does not. It also carries a right to object — if someone tells you to stop, you generally stop.

Write one line per activity: “Comment IP addresses — legitimate interest, spam prevention, kept 6 months.” That sentence is more compliance work than most sites have ever done.

Step 3: Make your consent actually count

Consent under GDPR has to be freely given, specific, informed and unambiguous. Translated into things you can check on your own site:

• No pre-ticked boxes. Ever. A checkbox that arrives already ticked is not consent, and this has been settled law since Planet49 in 2019.
• No bundling. “I agree to the terms and to receive marketing” is one checkbox doing two jobs. Split it.
• No cookie walls that only offer “Accept”. If rejecting is harder than accepting — buried two menus deep, or simply absent — the consent isn’t freely given. “Reject all” should be as prominent and as few clicks as “Accept all”.
• No consent-by-scrolling. Continuing to browse is not an unambiguous affirmative action.
• Nothing fires before the choice. Analytics, pixels and third-party embeds stay dormant until consent is given. Test it in your browser’s network tab: load the page, refuse everything, see what still called out.
• Consent must be withdrawable as easily as it was given. A persistent link or a small floating control is fine; an email to support is not.
• Keep a record. Who consented, to what wording, when. If you can’t evidence it, you don’t have it.

For form-specific consent wording and how to store the record alongside the submission, we went into much more depth in our guide to GDPR and WordPress forms.

Step 4: Use the tools already in WordPress core

Since 4.9.6, WordPress core ships privacy tooling, and most site owners have never opened it:

• Tools → Export Personal Data. Enter an email address, WordPress sends a confirmation link, and on confirmation assembles a downloadable archive of what it holds. Core covers users, comments and media; well-behaved plugins hook in and add their own.
• Tools → Erase Personal Data. Same confirmation flow, but it anonymises or deletes instead. Again, plugin coverage depends on the plugin implementing the eraser hook.
• Settings → Privacy. Nominates a privacy policy page and generates a draft policy with suggested text — including sections contributed by plugins describing what they collect. It is a starting skeleton, not a finished policy, but reading the plugin-contributed sections is a fast, free audit of what’s on your site.

Run an export against your own email address today. The gap between that archive and your Step 1 inventory is your real problem list.

Step 5: Set retention periods and actually enforce them

This is where nearly every site fails, silently. GDPR’s storage limitation principle says you keep personal data no longer than necessary. Almost no WordPress site has any deletion process — form entries from 2019 still sit in wp_options or a plugin table, and years of backups contain data for people who asked to be forgotten eighteen months ago.

Decide a number for each category and write it down:

1. Contact form entries — 12 to 24 months is a common, defensible choice for a general enquiry form.
2. Comment IPs — 6 months is plenty for spam defence; the comment itself can stay.
3. Security and firewall logs — 30 to 90 days.
4. Analytics — set the retention control in your analytics tool; most default to far longer than you need.
5. Orders and invoices — usually driven by tax law rather than your preference; keep them, but keep them minimal and locked down.
6. Backups — define a rolling window (say 30 days) so deletions genuinely age out instead of living forever.

Backups get a concession in practice: regulators generally accept that you can’t surgically edit an encrypted archive, provided you have a documented rolling window and re-apply the erasure if you ever restore. What is not acceptable is keeping every backup indefinitely and calling it a technical limitation.

Enforcement matters more than the policy. If deletion is a manual chore nobody does, you don’t have a retention policy — you have a document. The practical requirement is that entries live in one predictable place you can search, export and purge on a schedule, which is why storing form entries properly in the first place makes every later obligation cheaper.

Full disclosure: our own free plugin, EntryVault, exists partly for this reason — it stores form submissions in one place in your own database, so when someone asks what you hold about them, you search one screen instead of an inbox and three plugin tables. It does not make you GDPR compliant; nothing does. It just makes find-and-delete tractable, which is the part that otherwise never gets done.

Step 6: Sort out processors and DPAs

Every third party that touches personal data on your behalf is a processor, and you’re supposed to have a data processing agreement with them. For a typical site that means your host, backup destination, email service (SES, Mailchimp), payment provider (Stripe, PayPal), CDN and analytics vendor.

The good news: reputable providers publish a standard DPA you accept in account settings or which is incorporated by reference in their terms. The work isn’t negotiating them — it’s knowing your list. Make a table: provider, what data they see, DPA accepted, where they process it. Thirty minutes, once.

Watch for accidental processors: a marketing tool with a tracking script, an AI chat widget, a heatmap recorder that captures form keystrokes. Those get added by whoever ran a campaign last spring and never audited. A periodic sweep of what’s actually loading on your pages — the same habit as a regular WordPress content audit — catches them.

Step 7: Know what happens in the first 72 hours after a breach

A breach isn’t only hackers. A misdirected export, a public backup file, a plugin bug exposing entries, a stolen laptop with a database dump — all breaches. Have a plan before you need it:

• Hour 0–4: Contain. Take the exposure offline, rotate credentials and API keys, preserve logs before anything overwrites them.
• Hour 4–24: Assess. What data, how many people, what’s the realistic harm? Write it down as you go — this becomes your record.
• Within 72 hours: Notify your supervisory authority if there’s a risk to people’s rights and freedoms. The clock starts when you become aware, not when you finish investigating; a partial report on time beats a perfect one late.
• Without undue delay: Notify affected individuals directly if the risk to them is high.
• Always: Log the incident internally even if it doesn’t meet the notification threshold. You must keep a record of all breaches.

Step 8: Be honest about what plugins can and can’t do

Search “WordPress GDPR plugin” and you’ll find tools promising compliance in one click. No plugin makes you compliant, and any that claims to is selling a false sense of security. A plugin can render a consent banner, block scripts until consent, help fulfil export and erasure requests, and automate retention purges. It cannot decide your lawful bases, write an accurate privacy policy, know which processors you use, run a breach response, or take responsibility.

Use plugins for the mechanical parts. Do the thinking yourself — or pay a lawyer to do it with you. The checklist above is that thinking, in the order that makes it manageable.

Frequently asked questions

Does GDPR apply to my small WordPress site if I’m not in the EU?

Possibly. GDPR applies based on whose data you process, not where your server is. If you offer goods or services to people in the EU or UK, or monitor their behaviour (which includes analytics on EU visitors), it can apply regardless of your own location. Size is not an exemption either — there are lighter record-keeping obligations for organisations under 250 people, but the core principles still apply. Most small sites are in scope for at least comments, forms and analytics.

Do I need a cookie banner on a WordPress site with no analytics?

If you genuinely load nothing beyond strictly necessary cookies — session and security cookies, and WordPress’s own logged-in and comment-author cookies — then no consent banner is required for those. The catch is that most sites do load more than they think: an embedded YouTube video, a Google Map, a webfont from a third-party CDN, or a chat widget will all set cookies or transmit data before you’ve asked. Load your homepage in a private window, check the network and storage tabs, and let the evidence decide rather than the assumption.

How long should I keep contact form entries?

There’s no fixed number in the law — you keep them only as long as you need them for the stated purpose. For a general enquiry form, 12 to 24 months is a common and defensible choice; for a quote request that might become a contract, longer may be justified. What matters far more than the exact figure is that you pick one, publish it in your privacy policy, and actually enforce it with a scheduled purge rather than letting entries accumulate indefinitely.