Data retention why deleting old data is the cheapest security win

[Jenny]

TL;DR

• Data you no longer hold cannot be stolen, leaked, ransomed or decrypted later, so deleting unnecessary data is one of the cheapest and most effective security controls
• Privacy law requires it: the UK GDPR and EU GDPR storage limitation principle says personal data should be kept no longer than necessary
• Breaches are expensive: IBM's 2026 Cost of a Data Breach report put the global average at US$4.99 million, a record high
• Old data is especially risky for Q-Day, because anything encrypted with classical algorithms and stored or captured today could be decrypted in future
• A good retention programme needs an inventory, a schedule, automation, legal hold processes, attention to backups and verified deletion

The overlooked control

Security teams spend enormous effort protecting data: firewalls, encryption, access controls, monitoring and incident response. Far less attention goes to a simpler question. Do we need this data at all? Every record kept beyond its useful life adds risk without adding value

The logic is straightforward. Data that has been securely deleted cannot be exfiltrated in a breach, encrypted by ransomware, exposed by a misconfigured cloud bucket or surfaced by an over permissive AI search tool. It cannot be subpoenaed unexpectedly or decrypted by a future quantum computer. Deletion removes whole categories of risk at once

Despite this, many organisations keep data indefinitely by default. Storage is cheap, nobody wants to delete something that might be useful one day, and ownership is often unclear. The result is vast stores of old customer records, emails, logs and files that nobody uses. This thread explains why that habit is costly and how to change it

What the law says

Data protection law has long required organisations to limit how long they keep personal data. Article 5(1)(e) of the EU General Data Protection Regulation, mirrored in the UK GDPR, sets out the storage limitation principle: personal data should be kept in a form that identifies individuals for no longer than necessary for the purposes for which it is processed. Organisations should be able to justify their retention periods and review them. Regulators can and do take action when data is kept without good reason

Other rules push in the same direction. In the United States, the Federal Trade Commission has included data minimisation and retention requirements in enforcement orders, such as its 2022 order against the alcohol delivery platform Drizly, which required the company to destroy unnecessary data and publish a retention schedule. Sector rules in finance, healthcare and government add specific retention minimums and maximums. A retention programme must balance all of these

There is a tension worth acknowledging. Some laws require certain records to be kept for set periods, such as tax records, employment records or financial transaction data. Retention is therefore not about deleting everything quickly. It is about keeping what you must and need, for as long as you must and need, and deleting the rest

The security case in numbers

Breaches are costly. IBM's Cost of a Data Breach Report 2026 put the global average cost of a breach at US$4.99 million, a record high and up 12 percent on the previous year, with the US average at US$11.5 million. The average breach took 247 days to identify and contain. Every unnecessary record increases what is at stake in those incidents

Old data is frequently at the heart of major breaches. When the hotel group Marriott disclosed in 2018 that attackers had accessed the guest reservation database of Starwood, a company it had acquired, investigators found the intrusion dated back to 2014. The UK Information Commissioner's Office later fined Marriott 18.4 million pounds. Legacy systems and inherited data often receive less protection than core systems, making them attractive targets

Ransomware groups increasingly steal data before encrypting systems, then threaten to publish it. The more sensitive historical data an organisation holds, the more leverage attackers gain. Reducing that data reduces both the damage and the pressure to pay. Retention is therefore part of ransomware resilience

The Q-Day connection

For readers of this forum, there is a specific reason to care. Harvest now, decrypt later attacks involve recording encrypted data today and decrypting it once quantum computers can break classical public key cryptography. Data that is transmitted under classical key exchange, or stored with keys protected by RSA or elliptic curve cryptography, could become readable in future. The longer sensitive data exists, the more chances attackers have to capture it

Deleting data you no longer need is the simplest possible mitigation. It requires no new algorithms, no hardware upgrades and no vendor roadmaps. Combined with migrating to post quantum key exchange for data in transit, it shrinks the window of exposure significantly. Mosca's inequality, which compares data lifetime plus migration time with the time until a quantum threat, becomes much more comfortable when data lifetimes are shorter

Why organisations keep too much

Fear of losing something useful is the most common reason. Teams worry that deleting data might hamper future analysis, litigation defence or customer service. In practice, most old data is never accessed again, and the rare cases where it would help rarely outweigh the risk of keeping everything. Clear retention rules backed by legal and business owners address this fear directly

Unclear ownership is another reason. Data often lives in systems where nobody feels responsible for deciding when it should go. Shared drives, email archives and old databases accumulate for years. Assigning owners for each data category is essential

Technical complexity plays a part too. Data may be copied across many systems, backups, analytics platforms and test environments. Deleting it everywhere requires knowing where all the copies are. That is why an inventory comes first

Artificial intelligence has added a new twist. Organisations are indexing old documents for AI assistants and retrieval systems, sometimes resurrecting data that should have been deleted. Old files can then surface in answers to people who should not see them. Applying retention rules before feeding data into AI systems prevents this

Building a retention programme

Start with an inventory of data categories: what types of data you hold, where they are stored, why you hold them and who owns them. You do not need to catalogue every file. Focus on categories such as customer records, employee data, financial records, emails, logs, backups and analytics datasets. This mapping often overlaps with privacy records required under data protection law

Next, agree a retention schedule. For each category, set how long it should be kept, based on legal requirements, business needs and risk. Document the reasoning, since regulators may ask. Involve legal, compliance, security and business owners so the schedule has authority

Then automate. Manual deletion rarely happens consistently. Use retention policies built into email systems, document platforms, cloud storage and databases to delete or archive data automatically when its period ends. Automated lifecycle rules in cloud storage are particularly effective for logs and backups

Plan for legal holds. When litigation or investigations are expected, relevant data must be preserved regardless of the normal schedule. A clear process for applying and releasing legal holds protects the organisation and lets routine deletion continue for everything else. Without such a process, people tend to keep everything just in case

Do not forget backups and copies

Backups are often where deleted data lives on. A record removed from a production database may persist for years in backup archives. Retention policies should cover backups, with sensible rotation and expiry. Immutable backups for ransomware protection should still have defined lifetimes

Test environments, analytics platforms and data exports deserve attention as well. Copies of production data made for testing or analysis are easily forgotten. Using synthetic or masked data for testing reduces this risk. Regular reviews of where copies exist keep the programme honest

Verify deletion

Deletion should be real. For storage media being retired, follow recognised sanitisation guidance such as NIST SP 800-88, which describes methods for clearing, purging and destroying data on different types of media. For cloud services, understand the provider's deletion process and timelines. Crypto shredding, where data is encrypted and the keys are destroyed, can make deletion fast and verifiable at scale

Keep records of deletion activities. Logs showing that retention policies ran and data was removed help demonstrate compliance to regulators and auditors. They also reveal when automated processes fail. A retention programme that cannot show evidence is hard to trust

Quick wins

• Set automatic deletion for old logs beyond their security and legal usefulness
• Apply mailbox retention policies so emails are not kept forever by default
• Delete or archive inactive customer accounts after a defined period, with notice where appropriate
• Remove old exports, spreadsheets and test datasets from shared drives
• Review backup retention and expire old archives
• Exclude out of date documents from AI search and retrieval indexes
• Decommission legacy systems properly, including their data

Closing thoughts

Data retention is rarely glamorous, but it may be the best return on investment in security. Every unnecessary record deleted reduces breach impact, ransomware leverage, regulatory exposure and future quantum risk at once. The tools are already built into most platforms, and the main barriers are ownership and habit. A clear schedule, automation and verified deletion overcome both

Please share your retention successes and struggles in the replies. Examples of policies that worked, or data you were surprised to find, would help others make the case internally. Remember to keep details general where they relate to your organisation


Key references for citation

• EU GDPR and UK GDPR, Article 5(1)(e), storage limitation principle
• IBM, Cost of a Data Breach Report 2026
• UK Information Commissioner's Office, penalty notice to Marriott International, 2020
• US Federal Trade Commission, order against Drizly, 2022
• NIST SP 800-88, Guidelines for Media Sanitization