GDPR on a business website has grown myths in both directions: some believe a "this site uses cookies" banner is enough, others that a small business needs a lawyer on staff. The truth is duller: a typical small-business site processes personal data in two, maybe three places, and they can be put in order within an hour. Below is the checklist I run through on every launch. A caveat: this is a web developer's experience, not legal advice - for edge cases the sources are gdpr.eu and your national data protection authority.
What the GDPR actually requires
The GDPR does not forbid collecting data - it requires that you know what data you collect, why, on what legal basis and for how long, and that you can tell this to the person the data concerns. On a typical business site personal data appears in: the contact form (name, e-mail, phone), analytics and ad pixels (identifiers, behaviour) and server logs (IP addresses). That is all. If you run no store and no newsletter, your entire "GDPR documentation" concerns those three places.
The checklist, point by point
- A privacy policy - written for your site, not copied from someone else's. It must name: the controller with contact details, what data you collect and why, the legal bases, whom you entrust data to (hosting, e-mail, analytics), how long you keep it and what rights the data subject has.
- An information notice at the form - a short note on who processes the form data and why, linking to the full policy. It need not be a checkbox: answering an enquiry is covered by legitimate interest / pre-contract steps.
- Consent where consent is due - a newsletter and marketing require a separate, freely given consent. One consent "for everything" is invalid.
- HTTPS - sending form data unencrypted breaches the security-of-processing principle. The certificate is free; its absence is forgiven less and less.
- Processing agreements - hosting, external e-mail and analytics tools process data on your behalf. With the big providers the agreement is part of the terms - you just need to know where yours is.
- A procedure for deletion requests - you must be able to find and delete a specific person's data: from the mailbox, the database, and backups under defined rules. On my sites this is described on a dedicated "where your data is from" page.
Cookies and analytics
This is where the most theatre meets the least understanding. The rule is simple: cookies essential for the site to work need no consent; analytics and advertising cookies need consent before they are set. Two practical paths follow. First: a site with no analytics, or with cookieless analytics - then no banner is needed at all, which is both faster and more honest. Second: Google Analytics or ad pixels behind a genuine consent banner that by default stores nothing beyond the essentials - a banner with a huge "accept" and a refusal hidden three clicks deep fails the test of valid consent. Details in this overview of the cookie requirements. Bonus: every analytics script slows the page down - I wrote about that separately.
The most common mistakes
- A policy copied from another site - with the other company's name still in the text. I see it regularly; worse than nothing, because it proves nobody read it.
- A cookie banner that blocks nothing - scripts load before anything is clicked. Consent theatre instead of consent.
- A form served over http, or one sending data to a gmail inbox shared with private correspondence.
- Old plugins with known holes - a data leak from an unpatched WordPress is a GDPR incident too, with a 72-hour notification duty. Updates are not cosmetics.
If you want these points handled as standard rather than as an extra project - that is how I build websites: no unnecessary scripts, with a policy written for the specific business. Questions about your case - feel free to write.