GDPR website compliance and cookies: what to check on your banner, forms, policies and third-party tools

This article is informational and does not replace advice from a lawyer or a data protection officer (DPO). The rules apply differently from one business to another, depending on the data being processed. EU-level rules and guidance on cookies and data protection are being reviewed, so check the current position before relying on any article, this one included.

Which rules apply, in short

For a website aimed at audiences in Romania and the European Union, two sets of rules meet. The first is the General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, which applies to any processing of personal data: names, emails, phone numbers, IP addresses, online identifiers. The second is the electronic communications privacy legislation (the ePrivacy Directive, implemented in Romania by Law 506/2004), which governs storing and accessing information on a user’s device, in other words cookies.

In essence the rule is this: if a cookie is not strictly necessary for the service the visitor asked for, you need their consent before placing it. And if you process personal data, you need a legal basis, you must inform the person and you must let them exercise their rights.

The Romanian supervisory authority is ANSPDCP, and official information is available at dataprotection.ro, while the text of the regulation is on EUR-Lex. If you want a quick overview of your pages before a deeper review, you can start with our landing page audit for the visible side of forms and trust messages.

Types of cookies, and when you need consent

A cookie is a small text file saved in the browser. Similar technologies, such as localStorage or tracking pixels, work in the same way. What matters is the purpose, not the name of the technology.

There are nuances: some authorities accept certain anonymised measurements without consent, under strict conditions, but do not assume you are in that position just because you switched on an anonymisation setting. The safest practice is to treat analytics and advertising as requiring prior consent.

What a compliant cookie banner looks like

The banner is not an aesthetic formality; it is the mechanism by which you obtain consent. To be valid, consent must be freely given, specific, informed and unambiguous.

1. Genuine blocking. Non-essential scripts (analytics, advertising, embedded video) do not load before consent. A banner that merely informs while the tags are already running solves nothing.
2. Rejecting is as easy as accepting. A “Reject” or “Essential only” button at the same visual level as “Accept”, not buried in a menu.
3. No pre-ticked boxes. The user actively ticks what they accept.
4. Choices by category. The option to accept analytics but not advertising, for example.
5. Clear information. Purposes, providers and duration, with a link to the cookie policy.
6. Easy withdrawal. A permanent “Cookie settings” link in the footer, through which the decision can be changed at any time.
7. A consent log. The consent platform should keep proof of the choice, in case of checks.

Avoid manipulative patterns: a brightly coloured “Accept” button next to grey text for “Reject”, confusing wording, or windows that block the site until you accept everything. Data protection authorities have criticised such practices. We also discuss the link with measurement in our conversion tracking guide.

Privacy policy and cookie policy

The two documents are different and do not replace each other. The cookie policy lists the technologies you use. The privacy policy explains what you do with personal data in general.

What a privacy policy should contain

• the identity and contact details of the controller (your company);
• what data you collect and from which sources;
• the purposes of processing and the legal basis for each (contract, legitimate interest, consent, legal obligation);
• how long you keep the data;
• who you share it with (hosting, email, accounting and analytics providers) and whether it leaves the European Economic Area;
• the individual’s rights: access, rectification, erasure, restriction, portability, objection, withdrawal of consent;
• the right to complain to the supervisory authority (ANSPDCP);
• the DPO’s details, if you have appointed one.

The text must be written in plain language and reflect what really happens on the site. A policy copied from another company that mentions services you do not use is a problem in itself.

Contact forms, newsletters and orders

Forms are where you collect personal data most visibly. A few practical principles:

• Ask only for what you need. For a quote request, a name, email and message are usually enough. The phone number can be optional.
• Inform at the point of collection. A short text under the form with a link to the privacy policy.
• Do not mix purposes. Replying to a quote request can rest on pre-contractual steps or legitimate interest; signing up to a newsletter generally requires separate consent.
• An unticked box for marketing. Consent to commercial emails is not hidden inside acceptance of general terms.
• Keep data only as long as needed. Set a period for enquiries that lead nowhere rather than keeping them indefinitely.
• Watch who receives the notifications. Emails containing customer data should not end up in the personal inboxes of former colleagues.

For subscriber lists, proof of consent and unsubscribing, we have a dedicated article: how to build a GDPR-compliant email list.

Third-party tools: maps, fonts, video, chat, analytics

Many problems come from resources loaded from other companies’ servers. When a visitor’s browser requests a font, a map or a video from an external domain, the visitor’s IP address reaches that provider, sometimes together with cookies.

• Fonts (for example Google Fonts): the simplest solution is to host them locally on your own server, to avoid transfers to third parties. There have been court cases on this subject in Europe.
• Embedded maps: load the map only after consent, or replace it with an image and a link to the map.
• Embedded video: “privacy-enhanced” modes reduce tracking but do not always eliminate it; blocking until consent is safer.
• Chat and social widgets: load them after consent.
• reCAPTCHA and other anti-spam checks: check which data they send and mention them in your policy.
• Analytics and advertising: run them only after consent and configure retention settings properly.

Make a real inventory of every external request your site makes, using the browser’s developer tools or a cookie scanner. What you do not know you have, you cannot document.

Suppliers, security and individuals’ rights

If a supplier processes data on your behalf (hosting, an email platform, a CRM), it is a processor, and the relationship should be governed by a data processing agreement. Most serious suppliers provide one in your account or on their website.

Technical security is part of your obligations: updates, good passwords, backups, limited access. The practical details are in our WordPress security guide.

Finally, prepare a simple process for individuals’ requests: who receives the message, how soon you reply (the GDPR generally provides for one month, with extensions possible in specific circumstances) and how you verify the requester’s identity. A dedicated email address, for example for data protection, is enough for a small company.

Common mistakes

• A banner appears, but the marketing tags load anyway.
• A hidden or missing reject button.
• Policies that are copied, outdated or do not match the real site.
• A marketing consent box that is ticked automatically.
• Pixels and scripts left behind after a redesign or a finished campaign.
• Embedded content (maps, video) that sets cookies before consent.
• Forms that ask for unnecessary data, such as a national ID number or date of birth, for no clear reason.
• No internal owner: nobody knows who answers an erasure request.

How we approach it

When we build a site, we include the compliance basics from the start: a banner that genuinely blocks scripts, locally hosted fonts, minimal forms with an information notice, and policy pages prepared for review by the client’s lawyer. We do not draft legal documents in place of a lawyer; we prepare the technical structure, and the texts are validated by someone qualified to do so.

If you need a site that starts out right in this respect, see how we work on WordPress website development. For the final check before publication we also use our website launch checklist.

In short

• Non-essential cookies need prior consent, and refusing must be as easy as accepting.
• The banner must actually block scripts until consent is given.
• You need a real, up-to-date privacy policy and cookie policy.
• Forms ask only for necessary data and inform at the point of collection.
• External fonts, maps and video are frequent sources of problems.
• For specific legal decisions, consult a lawyer or a DPO.