# GDPR for marketing websites: cookies and forms > GDPR website compliance for marketing sites: when you need a cookie banner, how to run analytics and forms lawfully, and what to check before launch. Canonical page: https://kyvrel.com/blog/gdpr-website-compliance Published: 2025-12-03 · 6 min read · Kyvrel GDPR website compliance for a marketing site comes down to three things: what you store in the visitor's browser, what you collect through forms, and which third parties receive data. Get consent before non-essential cookies and tags load. Collect only what a form needs and say why. Know every vendor your pages call. The rest is careful build work. This post is the practical version for founders and marketing leads. It is not legal advice. Your privacy policy and data processing terms deserve a lawyer. The build decisions below deserve a developer who knows them, and that is where most sites go wrong. ## What GDPR website compliance means for a marketing site The [General Data Protection Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) has applied since May 2018. It covers personal data of people in the EU, and it reaches businesses outside the EU that offer them services or track their behavior. A US SaaS company with European prospects is in scope. On a typical marketing site, personal data shows up in more places than people expect: - **Identifiers.** Cookie IDs, device IDs and, in many cases, IP addresses. - **Form fields.** Names, work emails, phone numbers, free-text messages. - **Behavior.** Page views and clicks tied to an identifier. - **Third-party requests.** Every script, font or video loaded from another server sees the visitor's IP. Fines under Article 83 can reach €20 million or 4% of global annual turnover. Most small sites will never see that. The more common cost is a complaint, a deal that stalls in a security review, or a rebuild because consent was bolted on late. ![Diagram of a marketing site with data flowing to analytics, forms and third-party embeds, each passing through a consent check](https://kyvrel.com/blog/inline/gdpr-website-compliance-1.png) ## Do you need a cookie banner? Not always. The rule on cookies comes from the [ePrivacy Directive](https://eur-lex.europa.eu/eli/dir/2002/58/oj), Article 5(3), as implemented by each EU country. Storing or reading anything on a visitor's device needs consent, unless it is strictly necessary for a service the visitor asked for. GDPR then defines what valid consent looks like. Strictly necessary covers things like a shopping cart, a login session or a load balancer cookie. It does not cover analytics, ad pixels, heatmaps or chat widgets that track across visits. If your site uses only strictly necessary storage, you do not need a consent banner. You still need a clear cookie notice in your policy. If you use anything else, the banner has to meet the consent standard: 1. **Opt-in, not opt-out.** The Court of Justice of the EU ruled in [Planet49](https://curia.europa.eu/juris/liste.jsf?num=C-673/17) (2019) that a pre-ticked box is not consent. 2. **Before the tag fires.** Scripts that set cookies must not load until the visitor agrees. 3. **Reject as easy as accept.** A "Reject all" button at the same level as "Accept all". 4. **Granular.** Separate choices for analytics and marketing. 5. **Easy to withdraw.** Article 7(3) requires withdrawal to be as easy as giving consent. A "Cookie settings" link in the footer does this. 6. **Recorded.** Keep a record of what the visitor chose and when. A banner that sets tracking cookies on page load and then asks politely is a common failure, and an easy one to spot. ## Analytics without the guesswork You have two workable patterns. **Consent-gated analytics.** Google Analytics or similar loads only after the visitor opts in. You lose data from people who decline, but you keep the full tool. This is the right choice if your team depends on GA4 reports or ad attribution. **Cookieless first-party analytics.** Count page views and key events on your own server, without cookies or persistent identifiers. Many teams find this answers their real questions: which pages get traffic, which forms convert, which campaigns bring visits. On the sites we build, we often run this kind of internal event tracking by default and keep third-party tags switched off until consent. Whichever you choose, check where the data goes. Transfers to US vendors rely on the EU-US Data Privacy Framework, adopted in July 2023, or on standard contractual clauses. Your processor list should name each vendor and the basis for each transfer. ## Contact forms: collect less, explain more Forms are where marketing sites collect the most personal data, and where the fixes are simplest. - **Ask only for what you use.** A sales enquiry rarely needs a phone number. Make extra fields optional, or drop them. - **Say why, at the point of collection.** Article 13 requires you to tell people who you are, why you collect the data and how long you keep it. A one-line note under the button with a link to the [privacy and cookie details](https://kyvrel.com/cookies) covers the form itself. - **Separate consents.** Answering an enquiry and sending a newsletter are two purposes. Never bundle them into one checkbox. - **Record consent properly.** Store a timestamp of the consent with the submission. - **Protect the data in transit and at rest.** HTTPS, a database with access control, and no form data in plain email to shared inboxes if you can avoid it. - **Set a retention period.** Delete leads that went nowhere after a fixed time. Spam protection also touches personal data. Rate limiting by IP is fine if you hash the address with a secret and never store the raw value. A hidden honeypot field catches most bots without any third-party captcha. ## Third parties: embeds, fonts and processors Every external request is a data transfer. Make an inventory of what each page loads, then decide case by case. - **Fonts.** In 2022 a Munich court found that loading Google Fonts from Google's servers, without consent, breached GDPR. Self-host your fonts. It is also faster. - **Video.** Use a click-to-load preview for YouTube or Vimeo, so nothing loads until the visitor presses play. - **Maps, chat and scheduling widgets.** Treat them like video: load on interaction, or after consent. - **Processors.** Your hosting provider, email service, CRM and analytics tool all process data for you. Article 28 requires a data processing agreement with each one. Most vendors publish theirs. ![Flow diagram showing a page request where fonts and images load from your own domain and third-party embeds wait for a click](https://kyvrel.com/blog/inline/gdpr-website-compliance-2.png) ## A pre-launch checklist This is the short list we run through before a site goes live. It sits next to the technical checks in our [website security checklist](https://kyvrel.com/blog/website-security-checklist), since privacy and security share most of the same weak points. 1. Load the site in a clean browser profile. Confirm no non-essential cookies or third-party requests before consent. 2. Click "Reject all". Confirm nothing changes in storage or network calls. 3. Click "Accept all". Confirm only the vendors in your policy load. 4. Open "Cookie settings" from the footer and withdraw consent. Confirm tags stop. 5. Submit each form. Check the stored record, the consent timestamp and the notification email. 6. List every processor with its agreement and transfer basis. 7. Check that the privacy policy matches what the site actually does. ## Next step: build it in from the first sprint Consent and data handling are much cheaper when they shape the build than when they are patched on top. Our [corporate website development](https://kyvrel.com/products/corporate-website) projects plan the consent layer, form handling and the pre-launch check above from the first sprint. You can see what each product covers, and what is never charged extra, on our [pricing page](https://kyvrel.com/pricing). If your current site fails the first item on the checklist, that is a good place to start the conversation.