Often, yes. GDPR Recital 30 lists internet protocol addresses among the online identifiers that may leave traces and, combined with other information, identify a person. Treat IP addresses in logs as personal data by default, then keep them only as long as your security purpose needs.
This is a practical guide, not legal advice. Ask your counsel about edge cases.
What the text says
Recital 30 says natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as IP addresses and cookie identifiers. It adds that these may leave traces which, combined with unique identifiers and other information received by servers, may be used to create profiles and identify people.
A recital explains how the regulation should be read. It is not an article with its own obligations, but it shapes how regulators and courts interpret the term personal data. For engineers, the safe reading is that a log line with an IP and a timestamp can point to a person.
Why you still log them
Security teams need the source address. Investigating a credential attack, tracing abuse and blocking a hostile network all depend on it. The OWASP Logging Vocabulary even lists source IP as a standard attribute, while noting that fields should be weighed against privacy obligations because IP addresses can be personal data.
So the question is not whether to log them. It is how to log them responsibly.
Three principles from Article 5
Article 5 sets out principles that apply directly to log design:
| Principle | What it means for IP logging |
|---|---|
| Data minimisation, 5(1)(c) | Keep only what is necessary for the purpose, such as security monitoring |
| Storage limitation, 5(1)(e) | Keep identifiable data no longer than necessary |
| Integrity and confidentiality, 5(1)(f) | Protect logs with appropriate technical and organisational measures |
Steps to apply them
- Write down why you collect IPs, for example abuse detection and incident investigation. A stated purpose supports your retention choice.
- Log the IP only in the places that need it, such as authentication, access control and edge logs. Skip it in debug and business event logs.
- Restrict who can read raw IPs. Analysts can often work with a truncated or hashed value for trends.
- Set an expiry. Keep raw addresses for a short, defined window, then truncate or delete them, while keeping the detections and aggregates you need.
- Make sure you can find IP data when a person asks for access or erasure, or document why a retention exception applies.
- Mention IP logging in your privacy notice.
Hashing deserves a caution. A plain hash of an IPv4 address can be reversed by trying all possible addresses, because the space is small. Use a keyed hash with a secret if you pseudonymise, and keep the key separate.
Common mistakes
Keeping every log line forever "in case" is the usual one. Another is copying production logs, with real addresses, into test tools or third party analytics. A third is forgetting that a CDN or load balancer keeps its own copy under its own retention setting.
For the broader picture, see personal data in logs and setting retention by data class.
Quick check
Is a dynamic IP address personal data?
It can be. Recital 30 treats online identifiers as capable of identifying a person when combined with other information. Assume it counts unless counsel tells you otherwise.
Can I skip logging IPs to avoid the issue?
You can, but you lose a core security signal. Minimising, truncating and expiring is usually a better balance than not logging.
Safeguard's compliance and evidence automation helps teams keep policies and proof together, and you can check your dependencies with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
