When a junior engineer first hears that IP addresses are personal data under GDPR, the reaction is usually disbelief. An IP doesn’t have a name attached. It can change. How is 192.0.2.1 personal data?

The answer is that GDPR’s definition of personal data is broader than most people’s intuition, and the regulation has been consistently interpreted to include IP addresses — both static and dynamic — by European courts. The German Federal Court of Justice settled this in 2016 (the Breyer case), and it’s been reaffirmed since.

What this means in practice for engineering teams is more nuanced than “you can’t log IPs.” This post walks through what’s actually required, what’s still allowed, and how to set up your IP-handling pipelines so you stay on the right side of compliance.

The Legal Reality (Quickly)

GDPR Article 4(1) defines personal data as anything relating to an identified or identifiable natural person. An IP address by itself doesn’t identify someone, but combined with other data (logs, accounts, device fingerprints) it often does. The CJEU’s Breyer ruling extended this to dynamic IPs: even though the website operator can’t directly identify the user from a dynamic IP, the ISP can — and that’s enough for the IP to count as personal data.

The practical implication: logging, storing, processing, or transmitting an IP address is processing personal data. You need a lawful basis (Article 6), you need to honor data-subject rights, you need to disclose what you’re doing in your privacy notice.

This applies whether you’re operating in the EU or processing the personal data of EU residents from anywhere. A US-only company with EU users is still in scope.

What This Actually Requires

Don’t panic. The requirements are reasonable, and most of them you’re probably already doing. The structured list:

1. Have a lawful basis for processing

You can process personal data — including IPs — under one of six bases in Article 6. The two most relevant to IP processing:

Legitimate interest (Article 6(1)(f)) — security, fraud prevention, analytics. Covers most IP logging.
Contract performance (Article 6(1)(b)) — anything the user signed up to receive.

Consent is not required for most legitimate IP usage. You do need to weigh your legitimate interest against the user’s rights and document the assessment (often called a “legitimate interest assessment” or LIA).

What’s not a valid basis:

Marketing-driven profiling without consent.
Sharing IPs with third parties beyond what’s needed for the service.
Long-term retention with no purpose.

2. Disclose it

Your privacy policy should mention:

That you collect IP addresses
Why (security, analytics, geo-routing, fraud prevention — name the purposes)
How long you keep them
Whether you share them with anyone (third-party services count — analytics providers, CDNs, IP geolocation APIs)
The legal basis you’re relying on (legitimate interest, etc.)

This is not optional. A vague “we collect data to improve our service” doesn’t cut it.

3. Apply data minimization

GDPR’s Article 5(1)(c) requires that you process only the data you actually need. Practically:

Don’t log full IPs for analytics if you only need country-level data. Geolocate the IP at the edge, store the country, drop the IP.
Don’t retain raw IPs for years. Most security/abuse use cases need IPs for days or weeks, not indefinitely.
Don’t share IPs with third parties beyond strict necessity. Your CDN sees the IP; that’s unavoidable. Sending it to a third-party analytics service might not be.

4. Apply retention limits

You need a defined retention period. “Forever” is not defensible. Industry-standard retention windows:

Security/abuse logs: 30–90 days. Long enough to investigate incidents, short enough to limit exposure.
Audit logs (regulated industries): 6 months to a few years, but only for legally required fields. IP can often be hashed or truncated after the initial response window.
Analytics: Country-level data can be kept long-term. Raw IP should not.
Fraud signals: Hashed IP fingerprints can be kept longer than raw IPs. Many fraud platforms work this way.

Document the retention policy. Implement it as a scheduled job (cron, scheduled function) that actually deletes the data when the window expires. Don’t just write a policy and never enforce it.

5. Honor data-subject rights

EU users can request:

Access (Article 15) — what data do you have about me?
Erasure (Article 17) — delete my data.
Rectification (Article 16) — correct mistakes.
Portability (Article 20) — give me my data in a portable format.

For IPs specifically, “erasure” means actually removing them from your logs, backups, and any downstream systems you’ve shared them with. Build a process. Don’t assume you’ll figure it out when the first request arrives — they have a 30-day deadline.

6. Document your processing

GDPR Article 30 requires a record of processing activities. For IP processing, this includes:

What categories of data (IP, ASN, country, etc.)
What you do with each (logging, geo lookup, analytics, security)
Who you share with (your IP geolocation API counts)
Retention periods

Smaller organizations have some exemptions, but having the documentation never hurts. A simple data-flow diagram + table is enough for most teams.

Common Mistakes

”We anonymize IPs by truncating the last octet.”

This was a popular Google Analytics-era pattern. The reality: truncating the last octet is not full anonymization under most modern interpretations. It reduces the precision but doesn’t fully de-identify. The remaining 24 bits still narrow the user down to a few hundred or thousand possibilities, often combined with other data.

Better: don’t keep the raw IP at all if you only need country-level data. Look up the geo at the edge, store the country code, drop the IP.

It does, if you offer services to EU users or monitor their behavior. The location of your company is not the determining factor; the location of your users is. Enforcement against US companies has been increasing.

”Our analytics doesn’t store IPs.”

Maybe. Check carefully. Many analytics products (especially the privacy-friendly ones) explicitly don’t collect IPs. Many others do, even if it’s not obvious from the UI. Look at the actual data they collect, not just the marketing pages.

”We use Cloudflare so we’re fine.”

Cloudflare sits between you and your users; they see and log IPs. Your CDN is a processor (in GDPR terms) and should be covered in your data processing agreements. Just because you’re behind a CDN doesn’t mean you don’t need to think about IPs — but the CDN handles a lot of the heavy lifting for short-term security IP logging.

Most reputable ones are, but you should still check. A few things to verify:

They have a data processing agreement (DPA) you can sign.
They don’t retain your queries beyond what’s needed to serve them.
They have EU-based infrastructure if that matters to your data-residency needs.

The Ip2Geo privacy policy covers our handling. For most IP enrichment use cases, the IP leaves your server, gets enriched, and the response comes back — no long-term storage by the API provider.

A Compliant Engineering Setup

Concretely, what does a compliant IP-handling pipeline look like? Here’s the pattern:

At the edge

Request arrives with IP.
Edge middleware looks up geo via an API or CDN headers.
Enriched data is attached to the request context (country, ASN, city, region).
Raw IP may be passed downstream for security/abuse use, but with awareness.

Logging

Application logs (request paths, performance metrics): don’t include raw IPs unless needed.
Security logs (auth failures, rate limit hits): include IPs, with a 30–90 day retention.
Audit logs (regulated actions): may include IPs per regulatory requirement, with the legally required retention.

Analytics

Use a privacy-friendly analytics provider that doesn’t collect IPs by default (Plausible, Fathom, PostHog with IP collection disabled).
Use country-level aggregation where the geo info is useful, not raw IPs.
If you must collect IPs, apply truncation or hashing at ingest.

Third-party services

Every third party that sees IPs needs to be in your privacy notice.
Sign DPAs with each.
Document your data flows for ROPA.

Retention enforcement

Scheduled job runs daily.
Deletes records older than the retention window.
Logs the deletion event (for audit).
Triggers an alarm if deletion fails.

Data-subject request handling

One pre-defined process from request to action.
Each request gets a ticket.
Standard timeline (30 days).
Verification step to confirm the requester’s identity before disclosing data.

This isn’t 50 hours of work. It’s mostly disciplined defaults: log less, geolocate at the edge, retain short, document what you’re doing.

When IPs Are Legitimately Necessary

A short list of cases where retaining IPs is clearly defensible under legitimate interest:

Security log retention. Investigating a brute-force attempt that surfaces three weeks later requires having the IP logs.
Fraud prevention. Real-time fraud detection looks at IP-based signals. Patterns require some history.
Rate limiting. Per-IP throttling is fundamentally based on the IP.
Compliance with explicit regulatory requirements (financial-services audit logs, etc.).
Geo-routing to keep services running.

For each of these, the rationale should be documented, the retention should be bounded, and the data shouldn’t be repurposed for marketing.

Quick Compliance Checklist

A pragmatic list:

Privacy notice mentions IP collection and what we do with it
We have a documented lawful basis (legitimate interest assessment)
Raw IPs aren’t kept beyond a defined retention window
Country-level data is stored separately from raw IPs (and kept longer)
Third-party processors (CDN, geo API, analytics) are in our DPA records
Data-subject requests have a defined response process
Article 30 documentation is updated when we change IP usage

If you can tick all those boxes, you’re substantially compliant. The IP question becomes much less scary once you’ve put the pipes in place.

The Bigger Picture

GDPR doesn’t make IP handling impossible — it makes IP handling deliberate. The shift is from “log everything forever and figure it out later” to “log what’s needed, for as long as needed, with the user told about it.” That’s a healthier engineering posture regardless of compliance.

If you want to ship a country-level personalization or geofencing layer without retaining raw IPs at all, the Ip2Geo API lets you geolocate at the edge, store only the country code (which is generally not personal data on its own), and drop the rest. That pattern keeps the data benefits without most of the GDPR baggage.

For the more nuanced cases — fraud detection, security retention, audit logs — the right answer is a clear policy, bounded retention, and proper documentation. The technology is the easy part.

This post is engineering guidance, not legal advice. If you’re handling significant volumes of EU user data, hire a privacy lawyer. The cost of getting it wrong is much higher than the cost of getting professional advice up front.

GDPR and IP Addresses: Compliance Without Breaking Things

The Legal Reality (Quickly)