When logs are kept longer than the policy says: what it costs to be wrong
Keeping logs beyond the period stated in your own retention policy is not a technical slip. It turns a documented control into an undocumented one, and the gap itself becomes the fact a regulator or claimant examines first. The fix starts with an honest audit, not a rewritten policy.
The basis
Data protection law rests on a storage limitation principle: personal data is kept only as long as the stated purpose requires, and the retention period is one of the facts a controller commits to and must follow. A national implementing act with its own article number is not part of the file behind this page, so no article number appears below. What is settled, and worth stating without a citation, is the mechanism itself: a retention period that an organisation publishes becomes a commitment, and any gap between that commitment and actual practice is the finding an inspection, or a subject access request, will surface.
Where an organisation also falls within the scope of Directive (EU) 2022/2555 (NIS2) as an essential or important entity, logging is not only a data protection question. Wait — the source is not a link on this page; the reference is stated by name only. Directive (EU) 2022/2555 (NIS2) expects the ability to detect and investigate incidents, which can pull retention in the opposite direction from a data minimisation instinct. The two obligations do not cancel each other. They have to be reconciled in one policy document, not treated as competing rules.
What changes
Three clocks start moving the moment the gap is found. The first is internal: how long the excess retention has existed, which sets the scope of what has to be reviewed and, if needed, deleted. The second is external: a subject access request made during the excess period pulls in data that should not still exist, and the response has to explain why it does. The third is a question of credibility within the file itself. A policy the organisation does not follow becomes evidence against it in any later dispute about data handling generally, not only about the retention point that triggered the review.
What to do
- Freeze further deletion of the disputed logs. Assign this to whoever holds operational access, and do it first, so evidence is not destroyed while the position is assessed.
- Compare the stated policy against the actual system configuration. Assign this to the IT lead or the data protection officer. The output is a list of every system where retention exceeds the published figure.
- Establish why the gap exists. A backup setting left unconfigured is a different problem to a deliberate decision never written into policy, and the record should say which one applies.
- Decide, with legal input, whether to delete the excess now or amend the policy going forward. Backdating a policy to match existing practice is not a fix; it layers a second problem on the first.
- Document the correction, the date it took effect, and who approved it. This document is what an inspection asks for first.
- Check hosting and processor contracts for retention defaults that do not match the controller's own policy. A processor's default setting is not a defence if the controller's own policy said otherwise.
If the mismatch traces back to infrastructure rather than internal practice, a provider change deserves its own review before the retention question is closed: When a hosting provider changes region in detail covers what a region change does to existing commitments.
Who decides
Internally, the decision to correct practice or amend the published policy sits with the controller's management, acting on the data protection officer's assessment. This is a governance decision, not a purely technical one. Externally, if a data subject or an inspection raises the point, the national supervisory authority for data protection in the relevant member state examines actual retention practice against the published policy. It decides whether the gap amounts to a breach of the storage limitation principle, and it looks closely at dates: when the excess period started, when it was found, and when it was corrected.
Which fork applies
| Your situation | What is already running | First move |
|---|---|---|
| Excess retention found during an internal audit, no external request yet | Internal correction window only | Freeze, map, document before touching the policy text |
| Excess retention found because a subject access request surfaced old logs | The response deadline for that request | Answer the request accurately first; correct the policy after |
| Excess retention traces to a hosting or processor default | Contract review, not a regulatory deadline | Check the processor agreement before assuming the controller alone is at fault |
| Organisation is also in scope of NIS2 | Incident-detection retention obligations running in parallel | Reconcile the two retention logics in one document, not two |
If the excess logs contain employee data rather than customer data, the storage limitation analysis stays the same, but the internal audience for the correction changes: employee representatives may need to be informed under separate workplace rules this page does not cover.
If the discovery coincides with a governance question elsewhere in the business, keep the files separate. A retention gap found during a review of When a token gives voting rights explained does not become evidence in that unrelated dispute merely because both surfaced in the same audit cycle. The same discipline applies if the review overlaps with a question closer to The same invention is granted to someone else patent — being first to log something establishes nothing about who holds a right.
If the retention policy itself used loose wording, the correction should tighten language as well as practice. The same drift that causes trouble in When exclusive and sole are used interchangeably explained is what allows a retention gap to reopen the following year: a term left undefined invites a different reading each time someone new applies it.
Related situations
Related pattern: When a joint controller relationship is denied: what it follows the same logic. A written position that does not match practice is what an inspection tests first, whichever obligation is at issue.
What this page does not cover
This page does not set a specific retention period for any category of data. That figure depends on the purpose, the sector, and the national implementing act, none of which is stated here in general terms. It does not cover employee representation rules that may attach to workplace monitoring logs. It does not replace an assessment of NIS2 obligations where retention needs to be extended rather than shortened. Where a number, a deadline, or a national provision matters to your case, get it confirmed in writing before acting on it.
Verified
Checked: 10 March 2025. Source referenced by name: Directive (EU) 2022/2555 (NIS2), current at the date above. No national implementing act is cited on this page because none is confirmed in the underlying file.
Frequently asked questions
What is the first step when logs are kept longer than the policy says?
Freeze deletion of the disputed logs and map the actual configuration against the published policy before deciding anything about the policy text. Assessing the gap correctly matters more than closing it quickly.
Which deadline is already running?
If a subject access request has surfaced the excess data, the response deadline for that request is running now and takes priority. If the gap was found internally, no external deadline has started, but the longer the correction is delayed, the harder it is to explain later.
Who decides, and on what evidence?
Internally, management decides on the data protection officer's recommendation. Externally, the national supervisory authority for the relevant member state decides, based on the dates the excess started, was discovered, and was corrected, set against the policy the organisation itself published.