Almost always, yes. A typical application or access log carries IP addresses, user identifiers, session tokens, email addresses surfaced in error messages and whatever your request payloads happen to include. That makes logging a processing activity in its own right, requiring a lawful basis, a retention period, access controls and an entry in your records of processing. Most teams treat logs as infrastructure rather than as a personal data store, and that single category error explains nearly every logging failure that follows.
This article covers what logs actually contain, the lawful basis for keeping them, how long to keep which kind, why logs are usually the least-governed personal data in a company, and what happens when a subject access or erasure request reaches them.
What Is Actually In Your Logs
You do not need to resolve any hard legal question to answer this. Read a day of production logs.
The predictable contents are IP addresses, user or account identifiers, timestamps, user-agent strings, request paths and referrers. Those alone identify people, and vendors say so plainly in their own contracts: Cloudflare's data processing addendum names personal data in customer logs "such as IP addresses" among the categories it processes, which we covered in our piece on Cloudflare's DPA. When a major infrastructure provider writes it into its Annex, the question is settled for practical purposes.
The unpredictable contents are the problem. Stack traces embed the variables that were in scope when something failed, which routinely means email addresses, names and identifiers. Verbose request logging captures full bodies, including whatever a user typed. Integration debugging captures third-party payloads. And special category data arrives here the way it arrives everywhere — nobody decided to collect it, someone just typed a health detail into a support field and the field got logged.
Two related points. First, logs are usually written by many services with no shared policy, so what ends up in them is an emergent property rather than a decision. Second, the volume makes them opaque: nobody reads all of it, so nobody knows what is in there. "We do not log personal data" is a claim almost no team can support, and it is worth checking before anyone writes it into a questionnaire response.
The Lawful Basis For Logging
Logging needs a basis like any other processing, and for most of it the answer is legitimate interests under Article 6(1)(f): keeping a service running, investigating faults, detecting abuse, and maintaining security.
That is a strong interest and the balancing test usually goes your way, because people reasonably expect a service to record technical events. What weakens it is scope. Logging what is necessary to operate and secure the service is proportionate. Logging everything by default because it might be useful later is the pattern that fails, and it fails on data minimisation under Article 5(1)(c) before it fails on the balancing test.
Some logging sits on a different footing. Audit logs you are required to keep by law rest on legal obligation. Logs that exist to deliver the product feature the customer bought — an activity feed, an audit trail you sell — sit under contract. It is worth knowing which of your log types sit where, because the basis determines the retention argument and, incidentally, whether portability applies.
Where you are a processor rather than a controller, the position shifts again: logs you generate about your customers' end users are processed on your customer's instructions, and your DPA should cover them. Many do not mention logs at all.
Retention: Set It Per Log Type
There is no prescribed period. Article 5(1)(e) requires you to keep personal data no longer than necessary, and "necessary" varies sharply across log types, which is why one global setting is usually wrong in both directions.
Debug and verbose application logs have a short useful life — days, sometimes hours. They are also the logs most likely to contain unexpected personal data, so keeping them long is the worst combination of high risk and low value.
Access and security logs justify longer. Incident investigation frequently needs to look back weeks or months, and an intrusion discovered in March may need logs from January. Months rather than days is defensible here, and you should be able to say why you picked the number. For a concrete anchor, the CNIL's published guidance on setting retention periods gives log data six months as an indicative figure — not a binding rule, and not applicable outside France, but a useful sanity check if your logging platform is currently keeping everything for two years because nobody changed the default.
Audit logs tied to a legal or contractual obligation last as long as the obligation, and no longer once it lapses.
The practical failure is a single retention setting inherited from whatever the logging platform defaulted to, applied to everything. Splitting retention by log type costs one configuration exercise and materially reduces how much personal data you are holding at any moment.
Governance: Records, Access, And Rights
Three obligations reach logs and are routinely missed.
Article 30 records. Logging is a processing activity and belongs in your records of processing, with its purpose, the categories of data involved, the retention period and any processors. It is one of the most commonly absent entries, because whoever compiled the record listed the customer-facing systems and stopped.
Access control. Production log access is frequently granted broadly — to everyone on call, to the whole engineering team, sometimes to anyone with a dashboard login. That makes logs the least-restricted store of personal data in many companies, and it is the gap most likely to be found in a security review rather than by a regulator. Restrict, and log the access to the logs.
Third-party log processors. If logs leave your infrastructure for a hosted platform, that provider processes personal data on your behalf. It needs an Article 28 contract, it belongs on your subprocessor list, and it should go through your normal subprocessor notification process. Log platforms are among the most commonly omitted entries.
When A Request Reaches Your Logs
Logs fall within the scope of an access request under Article 15, so you need to be able to find one person's log lines — which is easy if you index by user ID and hard if you do not. Erasure is harder still, because log stores are frequently append-only, and the practical answer mirrors backups: reduce the retention window, suppress on any restore, and be honest about the timeline. Our piece on deleting personal data from backups sets out that approach.
The cheapest structural fix is upstream. Logging a stable pseudonymous identifier rather than an email address reduces exposure, makes per-user search feasible, and shortens redaction work — while leaving the data firmly in scope, as our guide to anonymisation versus pseudonymisation explains.
Common Mistakes With Logging Under GDPR
Leaving logging out of the records of processing. It is a processing activity with a purpose, categories of data, a retention period and processors. Its absence is the tell that nobody assessed it.
One retention period for every log type. Debug logs and security audit logs have completely different justifications. A single inherited default keeps the risky ones far too long.
Logging full request bodies by default. Verbose capture pulls in credentials, tokens and whatever users typed. Scrub at the point of writing, not by deleting later.
Broad production log access. If most of engineering can read raw logs, you have a large, unrestricted personal data store with no meaningful access control.
Forgetting the log platform is a subprocessor. A hosted logging service receives your users' personal data. It needs a DPA and a place on the subprocessor list.
FAQ
Do server logs count as personal data?
In almost all cases, yes. Logs routinely contain IP addresses, user identifiers and personal data captured incidentally in error messages and request payloads — and vendors say as much in their own processing agreements. Rather than reasoning about it abstractly, read a day of your own logs and see what is in them.
How long can we keep logs under GDPR?
There is no set period, and one period for all logs is the wrong answer. Verbose and debug logs have a short useful life and the highest chance of containing unexpected personal data. Security and access logs justify months because investigations look backwards. Set each type separately and record the reasoning.
Do logs need to be in our records of processing?
Yes. Article 30 requires records of your processing activities, and logging is one — with its own purpose, data categories, retention period and processors. It is among the most commonly omitted entries, usually because the person compiling the record listed only customer-facing systems.
Do we have to include logs in a subject access request?
Yes, where they contain the person's personal data. The practical question is whether you can retrieve one individual's entries, which depends on whether you log a searchable identifier. Teams that log a stable user ID can answer in minutes; teams that rely on free-text matching often cannot answer at all.
Closing Thought
Logs occupy a strange position. They are written by engineers for engineers, retained by default, rarely reviewed, and almost never appear on the data map — yet they frequently hold more personal data, about more people, than the database everyone worries about.
The reason is structural rather than careless: logging is the one system where the data is a by-product rather than the point. Nobody chose to collect it, so nobody owns it, so nobody governs it. Which makes "who is responsible for what we log" a more useful question than any of the legal ones in this article.
ComplyDog keeps the records this depends on — records of processing activities where logging belongs as a named activity with its retention period, subprocessor tracking that should include your logging platform, and a portal on your own domain for handling the requests that reach into these systems. You can try it free for 14 days, no credit card required.
