On 21 October, when PHP2Shell went public, Amazon's threat intelligence team published one line every incident responder should have read twice: investigate from at least 17 October. Four days before disclosure.
So here's a question for your team. Do you still have your web server logs from 17 October?
If they rotate every seven days, the honest answer to "were we hit before anyone knew about this?" is "we'll never find out".
Now ask your DPO how long you should keep those logs. Different answer. They're full of IP addresses, user IDs, session data, sometimes whole request bodies. Personal data, kept for a security purpose nobody wrote down, for a period nobody chose.
Same logs, two people, two fears. Both legitimate.
Two dogmas at the same table
The security dogma: log everything, keep it forever, storage is cheap and you never know. It comes from a real wound. Every incident responder has hit the dead end where the trail stops because the logs rolled over the week before.
The privacy dogma: log as little as possible, for as short as possible. Also a real wound. A log store that keeps everything about everyone indefinitely becomes a surveillance database, and one of the most attractive targets in the company. The CNIL named that exact risk in its own guidance: volumes of log data large enough to be attacked or used for purposes nobody intended.
Each side is right about its own risk. Neither works as a default. "Forever" isn't a retention period, and "as short as possible" isn't one either.
Anecdote: In practice, there's rarely a second person at that table. In the ISO 27001 audits I run, the DPO is almost never consulted on logging. It surprises me every time, and it's one of the minor nonconformities I raise most often. The security team picks a retention period, the tool applies it, and the person whose job is to ask "why do we keep this?" finds out during the audit. GDPR Article 38 already requires the DPO to be involved, properly and in good time, in every issue relating to personal data. Logs are one of them.
What the texts actually say
Here's what breaks the deadlock. No regulation gives you a universal number. And they all ask you for the same thing.
GDPR asks for data minimisation and storage limitation. It also requires appropriate security under Article 32, and Recital 49 recognises processing that's strictly necessary and proportionate for network and information security as a legitimate interest. So logging is lawful. Logging without a defined reason is where you get into trouble.
The CNIL's 2021 recommendation, one of the most detailed pieces of regulator guidance on the subject, gives six months to a year for application logs that trace who accessed and changed what. Longer is possible with a justification, up to three years in the common cases. Where the underlying data lives for less than six months, the logs shouldn't carry that personal data at all. And it explicitly leaves perimeter logs, from firewalls and network equipment, outside its scope. Almost everyone quoting "six months" misses that part.
NIS2's Implementing Regulation 2024/2690, for the digital infrastructure and service providers it covers, requires a risk-based list of assets to log, regular review, protection against tampering, and retention for a predefined period. No minimum. ENISA's implementation guidance then adds two lines: delete when the retention period ends, and don't keep data in the logs whose own retention has expired.
Read that again. The security regulator is saying what the privacy regulator says.
The AI Act sets a floor instead of a ceiling. Deployers of high-risk systems will have to keep the logs those systems generate for at least six months.
PCI DSS wants twelve months of history, three of them immediately available. A contractual number, not a legal one.
Five sources, five answers, one common demand: a defined period, tied to a purpose, written down.
Decide by purpose
The usual mistake is setting retention per tool. "The SIEM keeps 90 days" is a licence decision dressed up as a security one.
Set it per purpose.
Detection needs recent, searchable data. Weeks, kept hot.
Investigation needs enough history to cover how long it realistically takes you to discover a compromise, plus the pre-disclosure window PHP2Shell just demonstrated. Slow detection means long retention. That's the honest trade.
Accountability for privileged access needs a longer trail, because "who did this, and were they allowed to?" usually comes up months later.
Legal and contractual obligations set their own floor. You follow them.
One log can serve several purposes. Its retention is set by the most demanding purpose you can actually justify, rather than the one you'd like to have.
Three levers that dissolve most of the conflict
Retention is one dial. Most of the fight disappears once you use the other two.
Content. Log the event, leave the data out. Who, what action, when, which record reference. Skip the record itself, the request body, the form field someone typed a password into by mistake. Verbose and debug logs are where personal data leaks into places nobody governs, so give them a life measured in days.
Tiers. A short hot tier for detection. A longer cold tier for investigation, encrypted and harder to reach. A narrow archive for the trails you've justified keeping for years. Every step down, fewer people can read it.
Access. Your log store may well be the most complete record of personal activity in the company. Treat it that way. Named roles, logged access to the logs themselves, and administrators who can't quietly edit their own trail.
And one guardrail. A security log is collected for security. The day it gets pulled into an HR dispute without a separate legal basis and proper transparency, you've changed its purpose, and in several countries you've also brought the works council into the room.
An example retention table
Adapt it to your risk assessment and your national law. It's a starting point, and it shows the reasoning you'll need to document.
| Log type | Purpose | Example retention | Justification |
|---|---|---|---|
| Firewall, proxy, DNS, VPN | Detection, investigation | 12 months, 90 days hot | Covers late detection and pre-disclosure exploitation windows |
| Authentication (SSO, directory, MFA) | Detection, compromise investigation | 12 months | Account compromise rarely announces itself on day one |
| Privileged and admin actions | Accountability, internal control | Up to 3 years, restricted access | Documented internal control need, within the CNIL's upper bound |
| Application access to personal data | Traceability | 6 to 12 months | CNIL reference range |
| Applications holding short-lived data | Traceability | 6 to 12 months, without the personal data itself | Logs must not outlive the data they describe |
| Debug and verbose application logs | Troubleshooting | Days to weeks | No purpose beyond fixing the bug |
| Payment card environment | PCI DSS | 12 months, 3 online | Contractual requirement |
Write the decision down
On A.8.15, the auditor will ask how long you keep your logs. The better ones then ask why.
The answer has to exist before the question. A logging policy with the retention table and its justification. A legitimate interest assessment for the logging itself. The logging listed in your record of processing activities, because it is a processing activity. The DPO's opinion on file. A named owner. A review date.
That set of documents is what turns a dogma into a decision. Security gets the trail it needs. Privacy gets a purpose, a limit and a deletion date. And when someone challenges either side, there's a signature at the bottom.
Final Thought
The fight between "keep everything" and "keep nothing" usually ends with whoever argues loudest, and the retention period ends up being whatever the tool shipped with.
Neither regime lets you off that easily. Both want to see that someone looked at the purpose, picked a number, and wrote down why.
It takes an afternoon. It spares you two conversations: explaining to an incident response firm that the logs you needed were deleted by default, and explaining to a data protection authority why you kept seven years of everything.
Both sides of this sit in two of our courses. ISO 27001 Lead Implementer covers logging and monitoring as controls you can evidence in audit. ISO 27701 Lead Implementer covers the privacy side: purpose, retention, and the records that justify them.