Location data and GDPR: handling personal data the compliant way

Most geolocation tutorials show you how to turn an IP address into a city and then stop. The part they skip is the part your legal team cares about: under the GDPR, an IP address is personal data. Processing one — even just to infer a visitor's country — pulls you into the same framework that governs names and email addresses. The reassuring news is that the compliant design and the well-engineered design turn out to be nearly identical.

One caveat up front: this is engineering guidance from a team that builds a location API, not legal advice. It will help you ask better questions and ship defensible defaults, but your Data Protection Officer or counsel owns the final call for your jurisdiction and specific use case.

Why an IP address is personal data

The reference point here is the Court of Justice of the EU's decision in Breyer (C-582/14). In plain terms: the court held that a dynamic IP address can be personal data in the hands of anyone who has a realistic, lawful route to combining it with other information to identify the person behind it. For a typical website operator that route runs through the visitor's internet provider, which holds the subscriber records. GDPR Recital 26 frames the same test — data is personal if someone can be identified by “means reasonably likely to be used” — and an IP address usually clears that bar.

Once you accept that, three obligations attach the moment your code touches an IP:

• Lawful basis — you need a valid reason to process it under Article 6, chosen *before* you collect it, not rationalized afterward.
• Data minimization — Article 5(1)(c) says keep only what the purpose actually requires; a country code is far less than a raw address.
• Storage limitation — Article 5(1)(e) says hold it no longer than you need; for most geo lookups that is milliseconds, not months.

None of this forbids geolocation. It just decides how you build it — and, as we'll see, the constraints push you toward a cleaner architecture anyway.

Pick a lawful basis before you write the code

GDPR Article 6 lists six lawful bases, but for IP-driven geolocation two do the real work: legitimate interest and consent. Choosing the wrong one is the most common way a reasonable feature turns into a compliance problem, so decide per purpose rather than once for the whole app.

• Legitimate interest (Art 6(1)(f)) — fits fraud prevention, rate limiting, network security, and coarse localization such as currency, language, or VAT rules. Recital 49 explicitly names network and information security as a legitimate interest. It requires a documented balancing test — purpose, necessity, and the user's rights — but not a consent banner.
• Consent (Art 6(1)(a)) — required once you move into marketing, ad targeting, behavioral profiling, or precise and continuous location tracking. Consent must be freely given, specific, informed, and as easy to withdraw as it was to give.

Rule of thumb: if the geo lookup protects the service or makes it work, legitimate interest is usually defensible. If it feeds advertising or tracks individuals, you are in consent territory — and precise device geolocation often triggers ePrivacy consent rules on top of the GDPR.

Data minimization is just good engineering

This is where compliance and clean code converge. The instinct to log the raw IP “just in case” is exactly what turns a stateless lookup into a data-retention liability. The disciplined pattern is resolve, use, discard: take the IP, derive only the field you need, and never persist the address itself. Store the country, not the identifier.

// Resolve → use → discard. The raw IP never reaches your database.
async function localize(ip: string) {
  const geo = await fetch(
    `https://api.locabium.com/v1/geoip?ip=${ip}`,
    { headers: { Authorization: `Bearer ${process.env.LOCABIUM_KEY}` } },
  ).then((r) => r.json())

  // Keep only the derived country; drop the address itself.
  return { country: geo.country_code } // "DE" — not 203.0.113.7
}

// Downstream code only ever sees the country, never the IP.
const { country } = await localize(req.ip)
setCurrency(country)
// `ip` is out of scope now: nothing logged it, nothing stored it.

Two things make this both leaner and safer. First, your logs and analytics never accumulate a pile of IP addresses you would later have to secure, justify, and delete on request. Second, if your provider processes the lookup in memory and retains nothing, the address exists only for the milliseconds of the request — on their side and yours. That is the default Locabium ships: requests are processed in-memory, and validation and geo payloads are not retained after the response is returned.

You're the controller, your API is the processor

The GDPR splits responsibility into two roles. You — the company deciding why and how the data is used — are the controller. A geolocation or validation API you call is a processor, acting on your instructions. That distinction is not paperwork trivia; it decides who owes what. As controller you are accountable for the whole chain, which means your processor's practices become your exposure.

So when you evaluate a location API, you are really vetting a processor of your users' data. Ask for three things:

• A Data Processing Agreement — Article 28 requires a written DPA before a processor may touch personal data; it should bind them to your instructions, to security duties, and to deletion.
• Sub-processor transparency — your vendor's own vendors (hosting, CDN) process the data too. A published, current sub-processor list lets you meet your own disclosure duties instead of guessing.
• A retention commitment in writing — “we don't store the IPs you send” is only worth what the DPA and the docs actually commit to.

Locabium publishes its DPA, its sub-processor list, and its privacy terms for exactly this reason: a controller should not have to file a support ticket to learn how a processor handles the data flowing through it.

International transfers and EU residency

One more layer applies the moment data leaves the European Economic Area. Chapter V of the GDPR (Articles 44–50) restricts transfers to countries without an adequacy decision, and after Schrems II the usual fix — Standard Contractual Clauses — comes with a transfer impact assessment you are expected to actually perform. The pragmatic shortcut is to not transfer at all: if your provider offers EU data residency and processes the request inside the EEA, the hardest transfer questions never arise. Where a US leg is unavoidable, confirm the recipient is covered by a current adequacy route — such as the EU–US Data Privacy Framework — rather than assuming it. Locabium offers EU data residency so that, for EU traffic, the request never leaves the bloc in the first place.

The engineering checklist

Translated into things you can put in a pull request and a runbook:

• Never log raw IPs by default — derive the field you actually need (country, timezone) and drop the address before it reaches storage.
• Pin a lawful basis per feature — write down “fraud check → legitimate interest”, “ad geo → consent”, and keep the balancing test on file.
• Set retention to near-zero — treat the IP as request-scoped; if you must keep anything, keep the derived value with a short TTL.
• Prefer in-memory, non-retaining providers — a processor that keeps nothing is a processor you barely have to audit.
• Sign the DPA and read the sub-processor list — before go-live, not during an incident.
• Choose EU residency where you can — it removes an entire class of transfer paperwork.
• Say it in your privacy notice — one plain sentence on what you infer from an IP and why goes a long way toward the transparency the GDPR asks for.

Compliant geolocation and good geolocation converge on the same design: collect the minimum, keep it for the shortest possible time, and be honest about it. The privacy-safe architecture is also the leaner one.