When logs are kept longer than the policy says: what to do first
Stop guessing why the logs outlast the policy, and freeze deletion until you know why. The first task is provenance: which system produced the extra retention, on whose instruction, and since when. Only after that can you decide whether to purge the excess, preserve it for a stated reason, or report the gap upward. Everything that follows depends on getting the origin right before touching the data itself.
A retention gap rarely announces itself. It surfaces during an audit, a data subject request, or a routine system check, and by then the excess has usually existed for months. The instinct is to delete immediately and move on. That instinct is the wrong first move, because deleting evidence of how the gap arose can turn a configuration error into something harder to explain later.
Legal basis
Three positions can justify logs living past the date the policy sets, and each carries a different owner. Security incident handling under Directive (EU) 2022/2555 (NIS2) can require certain logs to survive the ordinary schedule while a matter is open, because deleting them mid-investigation removes the record the investigation needs. Automatic logging built into a high-risk AI system under Regulation (EU) 2024/1689 (AI Act) carries its own retention logic, separate from the general policy that governs everything else in the organisation. Outside those two positions, an extension has no basis of its own, and the written policy remains the only rule that applies to that log.
The three positions are not interchangeable, and confusing them is the most common way this situation goes wrong. A security team holding logs under an open NIS2 matter is not the same as an AI system logging by design, and neither is the same as a policy simply not being enforced. Establishing which one applies is the entire point of the provenance step.
What changes in practice
The practical effect depends on which of the three positions applies. If a NIS2 matter is still open, the extra logs are potential evidence, and deleting them on the ordinary schedule creates a second gap on top of the first. If the excess sits inside an AI system's own logging design under the AI Act, the operator answers to whichever structure governs that system, not to the general policy that covers everything else. If neither applies, every day past the stated date is itself the breach, and the volume of data held without a basis grows with each day of delay.
Deadlines drift for similar reasons across disciplines. Compare When a validation deadline was missed and the deadline — once a date is missed, it does not reset itself, and the same rule applies to a retention limit once it has passed without a documented exception.
There is a second, quieter effect. Every additional day of retention is a day the data could be requested, subpoenaed, or breached, and each of those events carries its own separate exposure. The retention gap does not sit still while the review is under way; it keeps accumulating risk in the background.
What to do first
- Locate the source of the extension. The IT lead pulls the current retention configuration and compares it against the written policy, line by line, rather than trusting a summary from memory.
- Freeze the setting. Nobody changes retention rules further, in either direction, until the review closes and the policy owner signs off on the next step.
- Check for an open exception. The compliance officer confirms whether a NIS2 matter or an AI system's own logging design explains the excess, before assuming the extension is simply an error.
- Record the dates. The compliance officer notes when the excess began, not when it was noticed — the two dates are rarely the same, and the gap between them matters.
- Decide disposal or preservation. The policy owner decides, in writing, whether to purge the excess now or preserve it for a stated and documented reason.
- Assess notification. The data protection lead decides whether anyone affected needs to be told, based on the nature of the data held past the stated date.
Who decides
Ownership of the retention policy decides the default outcome, and that ownership sits with whoever signed the policy, not with whoever configured the system that breached it. A security lead decides only while a NIS2 matter stays open, and only for the logs that matter covers. The operator of a high-risk AI system decides only for that system's own logs, on its own schedule, and cannot extend that authority to unrelated systems.
If the entity that wrote the policy has since merged or split, decision rights follow the corporate chain rather than the original signatory, much as in When a group restructuring moves the rights and its obligations pass to the successor. A policy does not dissolve because the entity that wrote it was absorbed into another one; someone in the new structure now owns it, whether or not that has been made explicit.
| Basis | What it covers | Who decides | Typical trigger |
|---|---|---|---|
| Directive (EU) 2022/2555 (NIS2) | Security logs held while an incident is open | Security lead, for the duration of the matter | An active investigation |
| Regulation (EU) 2024/1689 (AI Act) | Automatic logging built into a high-risk AI system | Operator of that AI system | System design, not a policy choice |
| Neither applies | General operational logs with no stated exception | Owner of the retention policy | Configuration drift or a missed clean-up |
If your situation is different
If the excess began on the date a hosting provider changed region, check the migration log before anything else. The pattern is close to When a hosting provider changes region in detail, and the usual fix is a configuration reset rather than a rewritten policy, since the retention setting often reverts to a provider default during migration.
If the system producing the logs also underpins a separate governance decision, such as When a token gives voting rights step by step, treat the retention question and the access-rights question as two separate files. Combining them tends to slow both down and obscure who is actually accountable for each.
If no exception applies and the excess is simply an error, treat it as a breach of the policy from the first day past the stated date, not from the day it was found. The organisation's own record of what should have happened is the baseline; the discovery date is only when the review started.
What this page does not cover
This page does not fix a specific retention configuration, draft a corrected policy, or represent an organisation before a supervisory authority. It does not decide whether the underlying data should have been collected in the first place, and it does not assess whether a separate breach notification is already overdue on other grounds. Those steps follow once provenance is established, not before, and each usually needs its own separate review.
Verified
Checked against Directive (EU) 2022/2555 (NIS2) and Regulation (EU) 2024/1689 (AI Act). The AI Act is tracked as at its stated application date of 2 August 2026, given the pace of change in that framework; treat any reference to it as provisional until closer to that date.
Related situations
A related question of shared responsibility for data is addressed in When a joint controller relationship is denied in practice.
FAQ
What is the first step when logs are kept longer than the policy says?
Freeze the retention setting and establish when the excess began, before deciding whether to delete or preserve anything. Deleting first destroys the record you need to explain what happened.
Which deadline is already running?
The date the policy set for deletion. Each day past that date adds to the period the organisation will eventually need to account for, whether to a regulator, an auditor, or an affected individual.
Who decides, and on what evidence?
The owner of the retention policy decides by default, on the dated configuration record. A security lead decides only within an open NIS2 matter, and an AI system operator decides only for that system's own logging design.