GDPR for Small Websites: What to Do

GDPR has a reputation problem. Written for a world that includes ad-tech giants and hospital networks, it lands on the desk of someone running a bakery website and reads like a threat. The famous "4% of global turnover" fine gets quoted at people whose global turnover is a market stall. The result is either panic-buying of compliance services or — more commonly — total avoidance.

Both reactions are wrong. For a small website, GDPR compliance is often a finite list of concrete tasks, many of which take an afternoon. This post is that list, with reasoning, so you understand not just what to do but why — and can stop when you've done enough. Usual caveat: practical guidance, not legal advice; if you handle health data, children's data, or large-scale profiling, get a professional.

First, establish whether GDPR applies to you

GDPR may apply if either of these is true:

  • You're established in the EU/EEA (or UK, under UK GDPR — functionally identical for our purposes), regardless of where your visitors are; or
  • You're established elsewhere but offer goods or services to people in the EU or monitor their behavior.

"Offering goods or services" means intent, not accidents. An EU resident merely being able to load your Ohio landscaping site doesn't trigger GDPR. Shipping to EU countries, pricing in euros, or marketing in EU languages does. "Monitoring behavior" mostly means tracking and profiling — which is why analytics choices matter to jurisdiction.

One myth to kill immediately: GDPR generally has no blanket small-business exemption. There is a limited exemption from one specific obligation (written records of processing, for organizations under 250 employees, with caveats), but the core rules can apply from employee number one. The good news is that the core rules scale naturally: less data, less obligation.

Understand what "personal data" means on your site

Personal data is any information relating to an identifiable person. On a typical small website, that's:

  • Contact form submissions — names, emails, message contents
  • Newsletter signups — emails, plus open/click tracking if your email tool does that (it does)
  • Customer accounts and orders — names, addresses, order history
  • Comments — name, email, IP address (WordPress stores the IP by default)
  • Server and security logs — IP addresses count as personal data
  • Analytics data — device identifiers, IPs, behavioral trails
  • Payment data — usually held by your payment processor, but order metadata sits with you

The exercise of writing this list for your own site is itself half of compliance. GDPR's real demand is not paperwork; it's knowing what you collect and being able to justify it.

The six lawful bases, and the only three you'll use

Every use of personal data generally needs a lawful basis. GDPR offers six; a small website realistically uses three:

  1. Contract — you need the data to deliver what the person asked for. Shipping address for an order. Email address to answer a contact form inquiry. This covers most of a small site's actual operations, no consent box required.
  2. Legitimate interest — you have a genuine business need, it's proportionate, and it doesn't override the person's rights. Security logging and fraud prevention live here comfortably. Some minimal analytics arguably does. Aggressive marketing does not.
  3. Consent — freely given, specific, informed, revocable. Needed for newsletter marketing, tracking cookies, and anything the person wouldn't reasonably expect. Consent is the weakest basis to rely on when another fits, because it can be withdrawn at any time — don't use it as a default.

Common mistake worth naming: adding an "I consent to my data being processed" checkbox to a contact form. You may not need it — answering the inquiry is often covered by contract/legitimate interest — and it trains everyone to treat consent as ritual noise. Save consent for where it's real: "Also subscribe me to the newsletter" as a separate, unticked box.

The data-minimization habit

GDPR's most practically useful principle is minimization: collect only what you need, keep it only as long as you need it. For a small site this converts into pleasantly concrete rules:

  • If your contact form asks for a phone number "just in case," delete the field.
  • Set a retention habit: old form entries stored in a database plugin, completed order details past your accounting requirements, inactive newsletter subscribers who haven't opened anything in two years — schedule deletion, quarterly is fine.
  • Stop logging what you don't use. WordPress comment IPs can be disabled with a one-line filter or a plugin if you don't moderate by IP.
  • Fewer plugins that store personal data means fewer places to secure, document, and clean.

Minimization is the compliance strategy that also improves your site: shorter forms convert better, smaller databases run faster, and there's less to lose in a breach.

The documents you may need

1. A privacy policy that tells the truth

This is generally the one public document you are expected to have. It doesn't need legalese; it needs accuracy. Cover, in plain language:

  • Who you are and how to contact you
  • What data you collect and why (map each item to its lawful basis)
  • Who you share it with — name your actual processors: hosting company, email provider, payment processor, analytics tool
  • Whether data leaves the EU/UK and under what safeguards (your US-based tools' standard contractual clauses / Data Privacy Framework participation)
  • How long you keep things
  • The person's rights (access, correction, deletion, objection, portability, complaint to a supervisory authority) and how to exercise them — an email address suffices

A generated template is a fine starting skeleton, but every clause must match reality. A policy describing data practices you don't have is worse than a short accurate one: it's documented evidence you didn't look.

2. A record of processing activities (lightweight version)

Even where the formal Article 30 record isn't strictly required, keep a simple spreadsheet: each processing activity (contact form, newsletter, orders, logs), the data involved, the lawful basis, where it's stored, who it's shared with, and retention period. Ten rows, one hour, and it becomes the source of truth your privacy policy summarizes. If a regulator ever calls, this spreadsheet is the difference between "organized small operator" and "deer in headlights."

3. Data processing agreements — mostly already done for you

Anyone who processes personal data on your behalf (host, email service, form service) generally needs to be bound by a data processing agreement. Here's the relief: every mainstream provider has a standard DPA baked into their terms or available with one click in their dashboard. Your job is to check the box, download or note the DPA, and record it in your spreadsheet — not to negotiate contracts.

Handling rights requests without drama

People can ask what data you hold about them, ask you to correct it, or ask you to delete it. For a small site these requests are rare — many owners never receive one — but you may need to respond within a month. The realistic playbook:

  1. Know your locations. Your spreadsheet already lists where personal data lives: WordPress database (users, comments, form entries), email marketing tool, payment processor, backups.
  2. Use the built-in tools. WordPress has native "Export Personal Data" and "Erase Personal Data" tools under the Tools menu — they handle comments, user profiles, and data from cooperating plugins by email address.
  3. Verify identity proportionately. Replying to the email address on record is usually sufficient verification for that address's data.
  4. Know the limits. Deletion isn't absolute — you may keep invoice data your tax law requires, and records needed to defend legal claims. Say so politely.

Security: the part regulators tend to focus on

When small organizations face penalties, it is often about breaches enabled by negligence rather than an imperfect privacy policy. GDPR requires "appropriate technical and organizational measures," and for a small website, appropriate means:

  • HTTPS everywhere — free via Let's Encrypt; no excuse today.
  • Updates applied promptly — many WordPress compromises exploit known, patched vulnerabilities in plugins and themes.
  • Strong, unique admin passwords and two-factor authentication on WordPress, hosting, and email accounts.
  • Least privilege — contributors don't need administrator roles.
  • Backups that exist and restore — availability of data is part of GDPR security, not just confidentiality.
  • A host that patches its stack — managed hosting outsources a meaningful chunk of your GDPR security obligation to people who do it professionally.

And know the breach rule: if personal data is breached and it risks harm to people, you may have to notify your supervisory authority within 72 hours of becoming aware (Article 33); ask a qualified advisor what applies to you. Write down, today, which authority that is and where the report form lives. A note in your spreadsheet costs one minute now and preserves sanity in a bad week.

What you can almost certainly skip

Compliance vendors profit from your uncertainty, so let's be specific about what a typical small website does not need:

  • A Data Protection Officer. Generally required only for public authorities or organizations whose core activities involve large-scale monitoring or large-scale special-category data. A shop, blog, or agency site doesn't come close.
  • A Data Protection Impact Assessment. Generally reserved for high-risk processing — systematic large-scale profiling, biometrics, that class of thing. Not contact forms.
  • An EU representative — non-EU businesses with only occasional, low-risk EU processing are typically exempt; this one is worth a real check if you're non-EU but actively selling into the EU.
  • Consent checkboxes on everything. As covered above: contract and legitimate interest do most of the work.
  • Expensive compliance subscriptions. The spreadsheet, the honest policy, the DPA checkboxes, and the security basics above are the actual substance.

The one-afternoon compliance sprint

Pulling it together, in order:

  1. List every place your site collects or stores personal data (30 min).
  2. Delete collection you don't need; set retention reminders (30 min).
  3. Build the ten-row processing spreadsheet with lawful bases (1 hour).
  4. Accept/record DPAs with your host, email tool, form tool, payment processor (30 min).
  5. Write or rewrite the privacy policy to match the spreadsheet (1–2 hours).
  6. Security pass: HTTPS, updates, 2FA, backup restore test (1 hour, ongoing habit).
  7. Sort out cookie consent if you run non-essential tracking — or drop the tracking (see our cookie consent guide).
  8. Note your supervisory authority and the 72-hour rule (5 min).

Conclusion

GDPR asks a small website owner to do what a decent one would want to do anyway: know what you collect, collect less of it, tell people the truth about it, protect it competently, and give it back or delete it when asked. The regulation's scariest numbers were aimed at organizations whose business model is other people's data. Yours isn't. Do the afternoon of work, keep the spreadsheet honest, and move on with running your business — compliant, and calmer than the headlines suggested you'd be. This is general guidance, not legal advice: check with a qualified advisor about what applies to your site.

Photo: Anete Lusina on Pexels