A practical example was telecoms being required to retain traffic and location data for a set period so authorities could request it later. In practice, teams used retention schedules, secure storage and deletion controls, while ensuring only data needed for lawful purposes was kept. The directive has since been invalidated.
One practical example was telecoms being required to retain traffic and location data for a set period so authorities could request it later. In practice, teams used retention schedules, secure storage and deletion controls, while ensuring only data needed for lawful purposes was kept. The directive has since been invalidated.
How the directive worked in day-to-day operations
The practical effect was not just “keep data longer”, but “keep the right data, for the right reason, in a controlled state”. Organisations had to define which records fell into scope, how long each category stayed available, who could access them, and when deletion should happen. That meant legal, security, privacy and operations teams had to work from the same retention rule set.
In a telecoms environment, that usually translated into logging and customer-data systems being configured around retention periods, with separate handling for records needed for billing, fraud handling, troubleshooting and lawful disclosure. The directive was therefore as much an information-governance exercise as it was a legal obligation, because retention only works when classification, storage and disposal are all enforceable.
For practitioners, the important point is that retention directives become operational only when they are translated into a data inventory and a retention schedule. The same approach is reflected in NHIMG’s Data Mapping and ROPA Guide, which shows how inventories, flows and records of processing make retention rules manageable in practice.
What makes a retention directive hard to implement safely
The biggest challenge is scope control. If an organisation keeps too much, retention becomes over-collection by another name. If it keeps too little, it may fail the legal purpose that justified retention in the first place. The directive therefore pushes teams to be precise about data categories, retention windows and deletion triggers, rather than relying on broad “keep everything” defaults.
Another practical issue is storage hygiene. Retained data still needs access controls, logging and deletion enforcement, because long retention periods increase the chance that stale records, misconfigured archives or poorly governed exports expose data beyond the original purpose. This is why retention should be paired with classification and handling rules, not treated as a standalone records policy. NHIMG’s Data Classification Guide is useful here because retention decisions depend on knowing which data is sensitive, routine or restricted.
When retention is tied to regulatory or investigative use, teams also need to preserve evidential integrity. That means being able to show when the data was created, when it became eligible for deletion, who approved any exception, and whether destruction happened as scheduled. Without that evidence chain, a retention programme can look compliant on paper while remaining weak in practice.
Why these directives were controversial and why they changed
data retention directive create a built-in tension between public-interest access and privacy expectations. The security argument is straightforward: certain communications data can support investigations. The privacy argument is equally straightforward: keeping large volumes of data longer increases exposure, especially if the data is centrally stored, broadly accessible or reused for secondary purposes.
That tension is why retention rules tend to attract scrutiny over proportionality, purpose limitation and necessity. A directive can be operationally clear and still be legally fragile if it requires broad retention without tight safeguards. In practice, the more expansive the retention obligation, the more important deletion controls, access limitation and lawful-purpose boundaries become. The practical lesson is reinforced by EU General Data Protection Regulation (GDPR), especially the principles around minimisation, storage limitation and security of processing.
One related operational pattern is that organisations often overestimate the safety of keeping data “just in case”. Retained data can become a liability if it is no longer needed, if the legal basis has expired, or if the environment holding it is less protected than production systems. Retention should therefore be justified record by record, not assumed to be harmless because it is passive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Article 5 — Principles relating to processing of personal data | Retention, minimisation and storage limitation are central to the example. |
| Recommendation — Apply storage-limitation and minimisation rules to each retained data category. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Retention depends on classifying data and applying different handling periods. |
| A.8.10 — Information deletion | The example depends on scheduled deletion after the lawful retention period ends. | |
| Recommendation — Classify retained records so retention and deletion rules match sensitivity. Implement deletion controls that remove data when retention expires. | ||
| CIS Controls v8 | CIS-3 — Data Protection | The scenario requires protecting retained data in storage and during disposal. |
| Recommendation — Protect retained records with encryption, access control and secure disposal. | ||
Practitioner Guidance
What to verify: Confirm that each retained category has a specific legal purpose, a defined expiry date and a documented deletion trigger. If you cannot map a dataset to one of those three things, the retention rule is too vague to trust.
Decision rule: If the data is retained for lawful-request or investigative purposes, isolate it from general analytics and operational reuse, and restrict access to the smallest group that genuinely needs it. If a category has no continuing legal purpose, schedule deletion rather than extending the retention window by default.
What practitioners underestimate: Retention is not just a storage problem. It is a governance problem that only works when legal, privacy, security and operations teams share the same inventory and the same deletion evidence.
Practitioner takeaway: A retention directive is safe only when the organisation can prove both necessity and disposal, otherwise “keeping it available” quietly turns into unnecessary exposure.
Related resources from NHI Mgmt Group
- Why is it important to integrate identity and data governance?
- Why does data minimization fail in practice even when organisations have a retention policy?
- What are the signs that GDPR data retention controls are failing in practice?
- What are the signs that data archiving and retention processes are failing in practice?