GDPR for Small Websites: No-Legalese Checklist

If your website has visitors, a contact form, or even just Google Analytics, and any of them could be in the EU or UK, GDPR applies to you — no matter how small your business is or where you're based.

Who this is for: small business owners, indie SaaS founders, and agencies running a marketing site, online store, or app with a contact form, newsletter signup, or login. What you'll get: a plain-English rundown of the four things that actually matter — cookies, your privacy policy, how you handle form data, and the security duty (Article 32) almost nobody reads — plus a one-page checklist you can work through in an afternoon.

This isn't legal advice — enforcement depends on your specific data flows, and a lawyer should sign off on anything customer-facing. But most small sites get compliance wrong in the same handful of predictable ways, and those are fixable without a law degree.

Does GDPR actually apply to your website?

GDPR (General Data Protection Regulation) is EU law, but it reaches well outside the EU. It applies to you if either is true:

• You're based in the EU/UK, regardless of who visits your site, or
• You're based anywhere else, but you offer goods or services to people in the EU/UK, or you monitor their behavior (analytics, ad tracking, cookies) — even if you never make a sale there.

In practice: if your contact form, newsletter, or checkout could realistically be used by someone in Europe, GDPR applies. "We don't think we have EU visitors" stops being a defense the moment you check your analytics and find you do.

The UK runs a near-identical "UK GDPR" post-Brexit, enforced by the ICO — everything below applies to both. Source: ICO guidance for small organisations.

The cookie banner: what you actually need

The banner requirement technically comes from the ePrivacy Directive (the "cookie law"), not GDPR itself — but GDPR defines what counts as valid consent, so regulators enforce them together. The rule is simple once you split cookies into two buckets:

Valid consent means:

1. Opt-in, not opt-out. No pre-ticked boxes for analytics or marketing cookies.
2. Specific and easy to refuse. "Accept all" as the only button isn't compliant without an equally easy "reject" or "manage preferences" option.
3. Before the cookie fires, not after. If Analytics loads on page load before anyone clicks anything, that's tracking without consent.
4. As easy to withdraw as to give — a "manage cookies" link in the footer, not a support ticket.

If your site only uses strictly-necessary cookies, you don't need a consent banner at all — just disclose them in your privacy policy.

Privacy policy checklist

A privacy policy isn't a formality — it's the document that proves you thought about what you collect. Under GDPR Article 13, it needs to disclose, in plain language:

• Who you are and how to contact you (business name, email, physical address if you have one)
• What personal data you collect (form fields, cookies, server logs, payment details)
• Why you collect it and your legal basis (consent, contract, legitimate interest)
• How long you keep it — a real retention period, not "as long as necessary"
• Who you share it with — email provider, payment processor, host, analytics tools
• Whether data leaves the EU/UK and how that transfer is protected
• The visitor's rights: access, correction, deletion, restriction, objection, portability
• Where to complain if they're unhappy — their local data protection authority

A policy copy-pasted from another site and never updated when you add a new tool (a chatbot, a new email platform) is one of the most common gaps we find during audits.

Contact and signup forms: collect less, store safer

GDPR's data minimization principle (Article 5(1)(c)) says you may only collect what you actually need for the stated purpose. Source: official GDPR text, Article 5.

Practical fixes for most small-site forms:

• Drop fields you don't use. A contact form asking for phone number, company size, and job title when you only ever email people back is over-collecting.
• Separate marketing consent from the form submission itself — an unticked "send me updates" checkbox, not a bundled agreement.
• Never email form submissions containing sensitive data (ID numbers, health info) in plain text — route them to an encrypted CRM or ticketing system instead.
• Set a real deletion schedule for old leads and abandoned carts — most email and CRM tools let you auto-purge inactive contacts.
• Serve every form over HTTPS. A form on an unencrypted http:// page is both a GDPR problem and a basic security hole.

The clause almost every small business misses: Article 32

Most owners think GDPR is a paperwork exercise — write a policy, add a banner, done. But Article 32 ("Security of processing") is a legal obligation to actually secure the data you collect, and it's the part regulators focus on hardest after a breach. Source: GDPR Article 32, official text.

The regulation doesn't hand you a fixed checklist — it says measures must be "appropriate" to the risk. For a small business website, that translates to a concrete list:

• Encrypt data in transit. Every page over HTTPS/TLS, not just checkout — an expired or missing certificate anywhere is a gap.
• Keep software patched. Outdated CMS core, plugins, or themes are the most common way small sites get breached — see is my website hackable for how attackers actually find these.
• Use strong authentication on admin accounts. Unique passwords plus two-factor authentication (2FA) for anyone with CMS, hosting, or database access.
• Limit who has access. Not every staff member needs admin — use editor/contributor roles for people who don't manage plugins or settings.
• Back up regularly, and actually test the restore. Article 32 explicitly calls out "the ability to restore availability... in a timely manner" after an incident — a backup you've never restored isn't one you can rely on.
• Set basic security headers. Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options cut down common attack surface — check yours free with our security headers tool.
• Test it periodically. Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness" of these measures — the part a scanner alone can't fully judge, since it can't weigh context the way a person reviewing your actual site can.

This is what separates "we have a privacy policy" from actually meeting your GDPR security obligation — and it's the part a manual audit is built for, not a checkbox tool.

If you have a breach: the 72-hour clock

If personal data is exposed — a hacked database, a misconfigured form emailing submissions to the wrong place, a leaked backup — GDPR Article 33 gives you 72 hours from becoming aware of it to notify your supervisory authority, unless the breach is unlikely to risk people's rights and freedoms. If it's high-risk (passwords or financial data exposed), you may also need to tell the affected individuals directly.

Fines scale with severity: up to €10 million or 2% of global annual turnover for lesser infringements, and up to €20 million or 4% for the most serious ones — whichever is higher. Source: GDPR Article 83. For most small businesses, real enforcement is rare and usually follows a complaint or a breach, not a random audit — but "rare" isn't "never," and prevention is almost always cheaper than the incident.

One-page GDPR checklist

• [ ] Cookie banner blocks non-necessary cookies until opt-in consent
• [ ] "Reject" is as easy to click as "Accept"
• [ ] Privacy policy lists what you collect, why, how long, and who it's shared with
• [ ] Privacy policy names all third-party tools (analytics, email platform, payment processor)
• [ ] Contact/signup forms only ask for fields you actually use
• [ ] Marketing consent is a separate, unticked checkbox
• [ ] All forms and pages served over HTTPS
• [ ] CMS, plugins, and themes are up to date
• [ ] Admin accounts use unique passwords + 2FA
• [ ] Backups exist and have been test-restored in the last 6 months
• [ ] You know who to notify within 72 hours if data is exposed

Key takeaways

• GDPR applies based on your visitors' location, not your business's — check your analytics before assuming it doesn't apply to you.
• The cookie banner only needs to gate non-essential cookies (analytics, ads); strictly necessary ones just need disclosure.
• Your privacy policy should describe your actual current tools and data flows, not a copy-pasted template.
• Article 32's "appropriate technical measures" is a real security requirement — HTTPS, patching, 2FA, and tested backups — not just a legal sentence.
• A manual review catches the context-dependent gaps (over-collecting forms, unpatched plugins, missing headers) that automated scanners and legal templates both miss.

Where a manual audit fits in

None of this replaces legal advice on your specific data flows — but the security half of GDPR (Article 32) is exactly what a hands-on website review is built to check. Bug Circuit's Circuit audit is $49: a real person manually reviews your site and hands you a written report with fixes, including the headers, patching, and access issues that feed straight into your GDPR security obligations. Start with our free passive check if you just want a quick read on where you stand first.