GDPR Checklist: What Your Business Website Actually Needs

What a GDPR Checklist for a Business Website Actually Covers

Most guidance on GDPR compliance splits into two unhelpful extremes: content written for large enterprises with a dedicated data protection officer and cross-border transfer agreements, or a vague instruction to "be GDPR compliant" with no list of what that actually requires. Neither helps a business owner who knows the regulation applies to their website but has never checked whether it's actually met.

A GDPR-compliant business website needs five things in place: a privacy policy that describes what the site genuinely does, a cookie consent mechanism that blocks non-essential cookies until visitors agree to them, a documented lawful basis for handling contact form enquiries, a defined data retention period, and a clear record of every data processor the site uses.

The five items below don't require legal advice to get right — they're the practical, checkable state a website needs to be in. The honest starting point: many business websites fail at least one of these right now, usually without the owner knowing, because compliance was treated as a one-off task rather than something to keep matching.

A Privacy Policy That Reflects What Your Site Actually Does

A privacy policy copied from a template and never updated is the most common gap. It might reference cookie categories the site no longer uses, omit a contact form added years later, or describe a retention approach that was never implemented. A privacy policy is a factual document — it must describe what the site does, not what a generic template assumes.

Getting this right means walking through the site as it exists today: what forms collect data, what analytics and marketing tools are installed, and how long data is kept — then rewriting the policy to match those facts. A stale privacy policy is worse than no policy, because it's a written claim that doesn't match reality.

Cookie Consent That Actually Blocks Non-Essential Cookies

A cookie banner that displays a message but does nothing to stop cookies firing is not consent — it's decoration. Tools like Google Tag Manager, Google Analytics, and advertising pixels are non-essential under GDPR, meaning they can't load until a visitor actively agrees. A banner that appears while those tools fire regardless of what's clicked is functionally no different from having no consent mechanism at all.

The correct pattern blocks those scripts by default and only triggers them once consent is recorded, with an equally easy way to withdraw it afterwards. This is a technical question as much as a policy one — it depends on how tags are actually configured to fire, not just what the banner says. Checking this directly, rather than assuming a visible banner means it's handled, is one of the fastest ways to find a real gap.

A Documented Lawful Basis for Contact Form Enquiries

Every piece of personal data a website collects needs a lawful basis for processing under GDPR, and a contact form is the most universal example on a business website. In most cases the basis is legitimate interest — responding to an enquiry someone has voluntarily submitted. That basis has to be documented, not assumed; "we've always done it that way" isn't an answer if a regulator or visitor asks.

Documenting this isn't complicated — a short internal record of what data the form collects, why it's needed, and how long it's kept afterwards covers most contact forms. The gap exists because businesses never wrote this down, usually because a previous developer or agency added the form without flagging it as a live obligation.

A Retention Period, Not Indefinite Storage

Keeping every enquiry and form submission indefinitely is one of the most common, and most avoidable, GDPR gaps. Personal data can only be kept for as long as it's needed for the purpose it was collected for — an enquiry resolved two years ago with no ongoing customer relationship has no business reason to still be sitting in a database.

Fixing this means setting an actual retention period for each category of data and putting a process in place to delete or anonymise it once that period passes, rather than letting it accumulate by default. It's one of the simplest items here to act on, and one of the easiest to check: if nothing has ever been deleted, the retention period isn't being enforced.

Knowing Who Your Data Processors Are

Every third party that touches visitor data on your behalf — the hosting provider, the email sending service, the analytics platform, the CRM a contact form feeds into — is a data processor under GDPR, and the business is required to know who they are and have an agreement in place with each one. Most site owners have never compiled this list, because it isn't visible from looking at the site itself.

A sub-processor register — a simple list of every third party involved, what they process, and confirmation a data processing agreement is on file — is standard, checkable evidence, and something most business websites are missing entirely. Assuming "the developer set it all up" covered this is rarely true.

Getting the Whole List Actually in Place

None of these five items needs a legal team to fix, but together they need someone to actually go through the site, check what's true today, and correct what isn't — the kind of task that gets deprioritised once a site is live and "working." A site compliant at launch drifts out of compliance as tools get added and nobody revisits the policy to match.

This is part of what a managed website service is for — not a one-off build that's compliant on day one and never checked again, but ongoing responsibility for keeping cookie consent, the privacy policy, and processor documentation matching what the site actually does as it changes. If you're not confident all five items are genuinely true for your site right now, that's the gap worth closing first.