To make a website GDPR compliant, you need a lawful reason for every piece of personal data it collects, cookie consent before any non-essential tracking runs, a clear privacy notice, secure handling, written agreements with the companies that process data for you, and a way for people to see or delete their data.
- If your site has a contact form, analytics or a newsletter, GDPR applies — whatever your size.
- A cookie banner is only one part of it. Most non-compliant sites fail on the things behind the banner.
- The most common failure: analytics or ad pixels that load before the visitor has said yes.
- You have one month to answer a request from someone asking for their data.
- Compliance is far cheaper to build in than to fix afterwards.
Does my website need to be GDPR compliant?
Almost certainly. GDPR applies whenever you process personal data — any information that can identify a living person. On a website that includes names and emails from forms, but also IP addresses and the identifiers set by analytics and advertising cookies. If your site has any of these, the rules apply:
- A contact or quote form
- A newsletter or mailing-list signup
- Google Analytics, a Meta Pixel, or any other tracking
- User accounts, logins or a members' area
- An online shop or payments
- Embedded third-party content that sets cookies, such as YouTube videos or maps
Which law applies to you?
| If your business is in… | Data protection | Cookies & marketing | Regulator |
|---|---|---|---|
| United Kingdom | UK GDPR + Data Protection Act 2018 | PECR | ICO |
| Ireland | EU GDPR + Data Protection Act 2018 (Ireland) | ePrivacy Regulations | Data Protection Commission |
| Rest of the EU | EU GDPR | National ePrivacy law | National authority |
UK GDPR and EU GDPR are almost identical in what they require of a website. If you serve customers in both, build to the stricter reading and you will satisfy both.
The GDPR website checklist
Work down this table. Each row is something a regulator, or an unhappy customer, can actually check.
| # | Requirement | What "done" looks like |
|---|---|---|
| 1 | Lawful basis | For every purpose (replying to enquiries, sending newsletters, analytics) you can name which of the six lawful bases applies. |
| 2 | Cookie consent | No non-essential cookie is set until the visitor opts in. Rejecting is as easy as accepting. Choices can be changed later. |
| 3 | Privacy notice | A readable page saying who you are, what you collect, why, how long you keep it, who you share it with, and how to complain. |
| 4 | Forms | Only the fields you use. Marketing consent is a separate, unticked box. A link to the privacy notice where data is collected. |
| 5 | Security | HTTPS everywhere, software kept patched, strong access control, and encrypted backups. |
| 6 | Processors | A data processing agreement with your host, email provider, CRM, analytics and any other tool that handles personal data. |
| 7 | International transfers | You know which tools send data outside the UK/EU, and each one has a valid safeguard for it. |
| 8 | Data rights | A way for people to ask for, correct or delete their data, and a process to reply within one month. |
| 9 | Retention | A stated period for each kind of data, and old enquiries and records actually get deleted. |
| 10 | Breach plan | You know who to call, and that serious breaches must be reported to the regulator within 72 hours. |
1. Lawful basis
GDPR lists six lawful bases: consent, contract, legal obligation, vital interests, public task and legitimate interests. Most websites use three of them. You need contract to process an order, legitimate interests to reply to an enquiry someone sent you, and consent for marketing emails and non-essential cookies. Write down which basis covers each thing you do. That record is what you point to if anyone ever asks.
2. Cookie consent, done properly
This is where most websites fail, and the failure is visible to anyone who opens their browser's developer tools.
- Analytics, advertising pixels and embedded videos must not load until the visitor has consented.
- "Reject all" must be as easy to find and use as "Accept all". The ICO treats a hidden reject option as non-compliant.
- No pre-ticked boxes, and scrolling or continuing to browse does not count as consent.
- Visitors need a way to change their mind later, usually a link in the footer.
- Strictly necessary cookies, such as the one that keeps a shopping basket or a login working, need no consent.
_ga, _fbp
or similar before you have agreed to anything, your analytics are running without consent.
3. Privacy notice
Your privacy notice has to describe what your website actually does. Copying one from a template and never updating it is a common problem. If you have added a live chat tool, a new analytics platform or a booking system since the notice was written, it is probably out of date. It should cover:
- Who you are and how to contact you
- What data you collect and why, with the lawful basis for each
- How long you keep it
- Who you share it with, including the tools you use
- Whether it leaves the UK or EU
- People's rights, and how to complain to the regulator
4. Forms
Every field on a form is data you are responsible for. Before adding a phone number, company size or date of birth field, ask whether you actually use the answer. If you don't, remove the field: data minimisation is a legal requirement, not only good practice. Consent to marketing must be a separate, unticked checkbox, never bundled into "I agree to the terms".
5. Security
GDPR requires "appropriate" security, and for a website that means HTTPS on every page, keeping the CMS, framework and plugins patched, strong unique admin passwords with two-factor sign-in, and encrypted backups that you have actually tested restoring. Most small-business data breaches come from an outdated plugin, not a sophisticated attack.
6. Processors and data processing agreements
Any company that handles personal data on your behalf is a processor, and you need a written agreement with each one. Your web host, email provider, CRM, form tool, analytics and payment provider all count. The larger providers include one in their terms, so this is usually a matter of finding it and keeping a record, not negotiating a new contract.
7. International transfers
Many common tools store data in the United States. That is allowed, but it needs a valid safeguard. Check whether each provider is certified under the EU–US Data Privacy Framework (and its UK Extension), or relies on standard contractual clauses. Where you have a choice, hosting in the UK or EU avoids the question altogether.
8. Data subject rights
People can ask to see, correct or delete the data you hold about them, or object to marketing. You have one month to respond. Practically, this means knowing everywhere a person's data might live — your inbox, CRM, mailing list and backups — so you can find it all when asked.
9. Retention
Decide how long you keep each kind of data, and then actually delete it. An enquiry that never became a client doesn't need to sit in your database for five years. A website that can't delete old records has a GDPR problem built into it.
10. Breaches
If a breach is likely to put people at risk, you must report it to the regulator within 72 hours of becoming aware of it, and tell the affected people if the risk is high. Most small businesses have never thought about this. A one-page plan saying who does what saves panic later.
Is my website GDPR compliant? A 10-minute self-check
Answer each question honestly. Every "no" is a gap to fix.
- Do analytics and ad cookies stay off until someone clicks "Accept"?
- Is "Reject all" as prominent as "Accept all"?
- Does your privacy notice mention every tool your site uses today?
- Is marketing consent a separate, unticked box on your forms?
- Does every page load over HTTPS?
- Has your CMS or framework been updated in the last three months?
- Do you know which of your tools store data outside the UK/EU?
- Could you find and delete everything you hold on one person within a month?
- Do you delete old enquiries after a set period?
- Do you know who would report a breach, and to whom?
GDPR for web applications and developers
If you are building something more than a brochure site, such as a customer portal, a SaaS product or a booking system, GDPR asks for data protection by design and by default. In practice:
- Deletion paths from day one. Retrofitting "delete my account" into a database with foreign keys everywhere is painful. Design for it up front.
- No real personal data in test environments. Use generated or anonymised data for development and staging.
- Role-based access. Staff see only the records their job needs.
- Audit logs for who viewed or changed personal data, especially in health, finance and education systems.
- Pseudonymisation where analysis doesn't need to know who someone is.
- Privacy-safe defaults — optional sharing and tracking features start switched off.
Common mistakes we see
- A cookie banner that looks right, while Google Analytics loads anyway before anyone clicks.
- A privacy policy copied from another site that describes tools you don't use.
- "By submitting this form you agree to receive marketing" — bundled consent isn't valid.
- A "GDPR plugin" installed and never configured.
- Old contact-form submissions sitting in the website database for years.
How we handle this on our projects
Every website and app we build has consent-gated analytics, minimal forms, HTTPS, patched dependencies and a working deletion path from the start. It is far cheaper to get right during the build than to fix after launch. See our GDPR-compliant web development service, or our web development and custom software work.
Not sure where your current site stands? Send us the address and we'll tell you which of the ten points above it fails, free.