GDPR: what your site collects without you knowing

“Our site collects nothing, it is just a brochure.” The sentence is sincere and almost always wrong — not through ill will, but because collection happens through mechanisms nobody explicitly installed.

This article starts from what your site already does, rather than from the regulation. A useful clarification up front: we are not lawyers. What follows describes technical mechanisms and their consequences; validating your documents is a legal professional's job, and it is better to consult one on an already clean basis.

What a site that “collects nothing” collects

Server logs. Every visit leaves an IP address, a date, a requested page and a browser identifier. An IP address is personal data under the European regulation. These logs are necessary for operation and security — so they are legitimate — but they must be mentioned and have a retention period.

The contact form. Name, address, message, often a phone number. It is the most obvious collection, and yet the one whose purpose is most rarely stated: what the message will be used for, how long it will be kept, and who will have access.

Analytics. Depending on the tool and its configuration, it sets trackers and transmits browsing data to a third party, sometimes outside the European Union. This is where most of the obligations concentrate.

Remotely loaded fonts. A font loaded from an external server transmits the visitor's IP address to that server, on every page. Few people know this, and the fix is simple: host the font files with the site.

Share buttons and embedded content. A social button, an embedded video, a map: each loads third-party code, which may set trackers before any click.

Live chat and marketing tools. Often installed by the sales team without going through anyone else, and often the most talkative.

Consent, or not

The dividing line is simpler than the subject's reputation suggests: it runs between what is necessary for the service requested and everything else.

No consent needed: the cookie keeping a session open, the one holding a basket's contents, the one remembering the chosen language, the one storing the banner's own answer, and security measures against abuse.

Prior consent needed, collected before anything is set: non-exempt analytics, advertising and retargeting, social network trackers, and any third-party content that sets something.

The important word is before. A tracker set on page load and then removed if you decline does not meet the rule: it has already been set.

The cookie banner

Four characteristics make one acceptable, and the absence of any single one disqualifies it.

• Refusing must be as easy as accepting. An “Accept all” button opposite a buried “Settings” link is not a free choice.
• Nothing is set before the choice, apart from what is strictly necessary.
• The choice is withdrawn as easily as it is given. That requires a permanent way back to it — a footer link is enough.
• Refusal is respected and remembered. A banner reappearing on every page until you give in is not compliant.

The formula “by continuing to browse, you accept” no longer holds: browsing is not an act of consent, since it expresses no choice. It is the most widespread error on sites not reviewed for a few years.

The privacy policy

A template copied without review is often worse than nothing: it describes processing you do not perform, omits processing you do, and constitutes a written commitment to practices that are not yours. Six sections are indispensable:

1. Who is responsible for the processing — legal name, address, an effective means of contact.
2. What data is collected, and by what means.
3. Why — the purpose, in comprehensible language, and the legal basis.
4. How long it is retained.
5. Who it is shared with: host, email tool, analytics, payment provider. The list must be real.
6. What rights the person has, and how to exercise them concretely — an address to write to, not a general formula.

Retention periods

This is the point most often missing from existing policies, and the most revealing: writing it forces you to decide what you keep and why.

The principle is that data is kept for as long as the stated purpose requires, and no longer. A contact message received six years ago, a prospect file never updated, a newsletter database nobody looks after: each is data retained without a purpose, and a risk in the event of an incident. What you no longer hold cannot leak.

Writing down your retention periods is the only exercise on this list that genuinely improves security, not only compliance.

Common mistakes

• The pre-ticked box. Consent must be a positive act; an already-ticked box is not one.
• The form with no stated purpose. “I agree to receive information” says neither what information, nor how often, nor from whom.
• Newsletter sign-up bundled with the contact form. Two distinct purposes require two distinct consents.
• No way to withdraw. An unsubscribe that requires writing to an address and waiting is not as easy as signing up.
• The policy never updated. It describes a site from four years ago, and three tools have been added since.

A note on scope

The European regulation applies not according to where your company is, but according to whose data you process. An organisation established outside the Union that addresses European residents — or monitors their behaviour — falls within its scope. Many exporting companies discover this late, when it is settled upstream without particular difficulty.

Likewise, several countries outside the Union have adopted comparable texts. If you operate across several markets, the exercise described here — knowing what you collect, why, and for how long — serves as a common basis for all those obligations.

Where to start

Open your site in a private browsing window, turn on the browser's developer tools, and look at the list of domains contacted and trackers set before any interaction. The list is almost always longer than expected, and it constitutes your starting inventory. The rest — decisions, wording, retention periods — requires no engineering.

Our Cybersecurity and Web & Mobile Development pages cover the technical implementation. For legal validation of your documents, go to a lawyer: it is their job, and it costs little against the risk.