GDPR and your website: forms, cookies, data

If your website has a contact form, you are processing personal data. If Google Analytics is installed, you are processing personal data. Collecting newsletter signups? Same. GDPR website compliance is not a "big company problem" — it applies to anyone with a form. That is the bad news. The good news: what the GDPR actually asks of a typical website is far less complicated than the compliance industry makes it look. For most sites, it comes down to three things: forms, cookies, and where the data ends up.

Let's be upfront: we are a software studio, not a law firm, and this is not legal advice. But after years of building websites, we have a clear view of which technical measures matter and which ones are theatre.

When does the GDPR apply to your website?

The General Data Protection Regulation has applied since 2018, and its scope boils down to one question: does any information passing through your site identify a person, or make them identifiable? Name, email, phone number — obviously. But IP addresses and cookie identifiers also count as personal data, which is the part most site owners miss.

So the sentence "we're just a brochure site, we don't collect data" is usually wrong. An analytics snippet alone puts you in scope.

Two more things people underestimate. First, reach: the GDPR applies to businesses outside the EU if they offer goods or services to people in the EU or monitor their behaviour — an ecommerce site in Istanbul or Austin serving European customers is in scope. Second, the UK has its own near-identical version, so "we left that market" rarely gets you out. If your situation is genuinely ambiguous, that is a question for a lawyer, not a blog post.

Forms: a privacy notice is an obligation, not a link

The common reflex is to bolt an "I have read the privacy policy" checkbox under the contact form. But what the regulation requires is not a checkbox — it is transparency: telling people, at the moment you collect their data, who is processing it, for what purpose, on what legal basis, and who it may be shared with.

In practice, a compliant form needs:

A visible link to a real privacy notice — reachable before the form is submitted, not buried in the footer of a page nobody visits.
Only the data the purpose requires. Don't ask for a date of birth on a quote request form. This is the regulation's data minimisation principle, and it happens to be good form design too: shorter forms get filled in more often.
Consent only where consent is the right basis. This is the most widespread confusion. To reply to someone who wrote to you through your contact form, you generally do not need consent — you have a legitimate reason to process their message because they asked you something. Consent is what you need when you want to do something extra, like send that person marketing emails. And then it must be a separate, unticked, freely given opt-in. Sprinkling consent checkboxes on everything does not make you more compliant; it often puts your processing on the wrong legal basis, which is worse.

Cookies: having a banner and being compliant are different things

Most websites have a cookie banner. Very few have one that works. The rule — coming from the ePrivacy rules working alongside the GDPR — is simple to state: non-essential cookies must not be set until the visitor consents.

What counts as essential? Session cookies, shopping cart cookies, a language preference — the site breaks without them, no consent needed. Analytics, ad pixels, heatmap tools — not essential, consent required first.

The failure patterns are depressingly consistent:

The banner is there, but the analytics script fires the moment the page loads, before anyone has clicked anything. The banner is decoration.
"Accept" is a big friendly button; "Reject" doesn't exist or hides three clicks deep. European regulators have been explicit about this: rejecting must be as easy as accepting.
Closing the banner is treated as acceptance. It isn't.

The technical fix is genuinely simple: don't load third-party scripts until consent arrives. On a modern site that is a consent-mode setup or a few lines gating script injection. The hard part is not the code — it is the inventory. Most site owners cannot list the cookies their own site sets, because every marketing tool added over the years brought three cookies along with it.

There is an architectural truth hiding here too. A statically generated site with few third-party scripts has a cookie inventory you can count on one hand. A WordPress installation with thirty plugins requires an archaeology project to find out which plugin sets which cookie. Fewer dependencies, fewer cookies, less risk — one of the invisible benefits of a lean architecture.

Where does the data live? What happens after submit

Compliance does not end at the banner; the real questions start behind the form:

Where do submissions go? Your own database, or a SaaS form tool's servers in another jurisdiction? International data transfers are separately regulated under the GDPR, with their own conditions. Every third-party tool in your stack raises a transfer question.
Who can access it? "Form emails land in the info@ inbox and five people check it" is not an access control policy.
How long is it kept? When the purpose is gone, the data should go too. If there is no reason to keep quote requests from 2019, there is no legal basis for keeping them either.
Is the site on HTTPS? It feels strange to write this in 2026, but sites still exist that send form data unencrypted. This is the floor, not the ceiling.

People also have enforceable rights: to access their data, correct it, and have it erased — and you normally have a month to respond to such a request. In a setup where data is scattered across five tools, an erasure request costs you an afternoon. On a site managed from a single panel, it takes minutes.

What non-compliance actually costs

The headline fines — up to 20 million euros or 4% of global annual turnover — were designed for large companies, and the record-setting penalties have indeed gone to big tech. A small business is unlikely to face a fine of that order, and we won't pretend otherwise. But two things are worth knowing. Anyone can lodge a complaint with a supervisory authority, and even an investigation that ends without a fine costs you correspondence, stress and legal fees. And increasingly, the pressure comes from customers rather than regulators: enterprise clients now ask about GDPR compliance in vendor assessments. "Why doesn't your cookie banner actually work?" is a bad question to hear in a sales meeting.

Where to start: a realistic order of operations

Don't try to do everything at once. This sequence works for most sites:

Take inventory. Which forms exist, what data do they collect, which third-party scripts load? Checking cookies in your browser's developer tools is a half-hour job.
Delete the unnecessary. Unused pixels, forgotten form fields, stale records. The cheapest compliance is data you never collect.
Write a privacy notice that matches reality. A template copied off the internet describes processing your site doesn't do — and won't protect you. This is the step where paying a lawyer makes sense.
Wire consent into your scripts. Fix the loading order, not just the banner.
Set a retention rule. Keep it simple, but write it down.

None of this is one-and-done: the inventory changes every time a new tool lands on the site. Which is why the most sustainable strategy is a lean architecture with as few tools as possible — your compliance burden grows in direct proportion to your site's complexity.

At Vucod, the sites we build have this designed in from day one: where form data lives, which script loads when, how the consent flow works. No banner gets glued on afterwards. If your site's data handling is due for an overhaul, write to us at vucod.com — we respond to every enquiry within 48 hours.