GDPR and IP Addresses: What a Small Website Actually Has to Do

This is a plain-English orientation for small site owners, not legal advice. If you process personal data at scale, handle special-category data, or operate in a regulated sector, take proper advice.

If you run a small website — a shop, a portfolio, a blog with analytics — you are almost certainly logging IP addresses. Your web server does it by default. Your analytics does it. Any link or QR tracking you use does it.

That makes you a processor of personal data under the GDPR, which sounds alarming and mostly isn’t. The obligations for ordinary web analytics are modest and largely a matter of writing things down and deleting things on time. Here’s what actually applies.

Yes, an IP address is personal data

This is settled enough to plan around. In Breyer v Germany (C-582/14, 2016) the Court of Justice of the EU held that a dynamic IP address held by a website operator is personal data where the operator has legal means reasonably likely to be used to identify the individual — for instance, by asking an ISP through a legal process.

You will find people online insisting IPs are anonymous because they identify a connection rather than a person. Regulators do not accept this. Treat IP addresses as personal data and the rest follows straightforwardly.

Consent is probably not what you need

The most common confusion in this area is collapsing two separate laws into one.

The ePrivacy Directive (the "cookie law") governs storing or accessing information on a user's terminal equipment. Cookies, localStorage, device fingerprinting. That is what triggers a consent banner, and consent must be freely given, specific, informed and unambiguous.

The GDPR governs the processing of personal data generally, and offers six lawful bases, of which consent is only one.

An IP address arrives inside the HTTP request. Nothing is stored on or read from the visitor's device to obtain it. So server-side IP logging does not by itself trigger the ePrivacy consent requirement — but it does still need a GDPR lawful basis.

For ordinary analytics and security logging, that basis is normally legitimate interests (Art. 6(1)(f)): you have a genuine interest in understanding and protecting your site, the processing is necessary for it, and it doesn't override the visitor's rights. To rely on it properly you should be able to articulate that balance — a few paragraphs in a file is enough for a small site.

Two things push you back towards needing consent regardless:

• Advertising and cross-site tracking. Serving personalised ads through a network that sets cookies is squarely in ePrivacy territory. In the EEA, UK and Switzerland this is what a certified consent platform handles.
• Precise device location. A different order of intrusiveness. The browser's permission prompt is the consent mechanism, and it must not be obtained by misleading the visitor about what they're agreeing to.

The practical checklist

1. Publish a privacy notice that's actually true

The most common failure isn't having no policy — it's having a downloaded template describing a site that doesn't exist. Yours should say, specifically:

• Who you are and how to reach you
• What you collect — name IP addresses, approximate location, device and browser explicitly
• Why, and on what lawful basis
• Who else sees it — analytics, ad networks, hosting, any tracking tool
• How long you keep it
• The visitor's rights and how to exercise them

2. Decide a retention period and enforce it

"Necessary for the purpose" is the standard. If you look at analytics monthly, you don't need raw request logs from three years ago. Pick something defensible — 12 months for analytics is common, shorter for raw logs — write it down, and put a scheduled job behind it. An unenforced policy is worse than none, because it's a documented promise you're visibly breaking.

3. Know who your processors are

Anyone handling personal data on your behalf is a processor and needs a data processing agreement. For a small site that typically means your host, your analytics provider, your email platform, and any tracking tool. Most reputable vendors publish a standard DPA you accept by using the service — find them and keep copies.

Note where the data physically goes. Transfers outside the EEA/UK need a transfer mechanism, usually Standard Contractual Clauses, which reputable providers include in their DPA.

4. Be able to answer a request

People can ask what you hold, ask for a copy, ask for correction, and ask for deletion — generally within one month. For a small site this is rarely burdensome, but you need to know how you'd do it. If someone emails saying "delete everything about me", could you find it? Being able to search your visit data by IP is usually the practical answer.

5. Collect less

The most effective compliance measure, and the one people skip. Every field you don't collect is one you don't have to justify, secure, retain, disclose or delete. If you only ever look at country-level traffic, you don't need to store full IP addresses at all — many analytics tools can truncate or hash them, and truncation meaningfully reduces your exposure.

If you use tracking links or QR codes

This is where small site owners most often step over a line without noticing, because the data isn't about visitors to your site — it's about people you sent a link to.

• You are the controller for that data. You chose to create the link, decided who received it, and decided why. The tool is your processor. Its terms should say so — ours do.
• You need a lawful basis for those people too. Measuring which channel drove clicks is a reasonable legitimate interest. Using a link to work out where a specific named individual is, is not — and no lawful basis will rescue it.
• Purpose matters more than mechanism. The same redirect is ordinary analytics in a marketing campaign and potentially unlawful surveillance when aimed at one person you have a personal interest in. The technology is identical; the lawfulness is not.
• Don't disguise what a link is. Deception undermines any legitimate-interests argument, because the balancing test weighs the reasonable expectations of the person whose data you're processing.
• Precise location needs real consent. The browser prompt should be genuinely optional, and the visitor should not be misled about who is asking or why.

What about the UK, and elsewhere?

The UK GDPR is materially the same regime; the practical steps above don't differ. Switzerland's revised FADP is broadly aligned. If you have visitors from California, the CCPA/CPRA works differently — it leans on disclosure and opt-out of "sale" or "sharing" rather than a consent-first model — but a site that has done the GDPR work honestly is usually most of the way there.

The realistic version

For a small site doing ordinary analytics, this is a short list: publish an accurate privacy notice, rely on legitimate interests for server-side logging and document why, get consent for ad cookies and precise location, set a retention period and enforce it, keep your processors' DPAs on file, and be able to find and delete one person's data if asked.

That's a morning's work, not a project. The risk for a small site isn't a surprise regulatory raid — it's having no notice, keeping everything forever, and being unable to answer when somebody asks a reasonable question.

If you use tracking links, our privacy policy sets out what we store and for how long, and our terms spell out the controller/processor split. Our guide to what an IP logger can and can't see covers the technical limits — which are narrower than most people assume.