Data Retention, Minimization & Deletion

A recap of the Pyxos masterclass with Anurag Sushant.

Keeping data because it might be useful one day is not a legal purpose, and treating it as one is where retention programs quietly go wrong. That was the practical spine of this masterclass on data retention, minimization, and deletion, led by Anurag Sushant, a DPO consultant at Salam. His emphasis throughout was that these are not theoretical principles but operational ones, and that the test of a program is whether the schedules actually run.

Sushant grounded the session in four ideas that shape everything else: data minimization, purpose limitation, storage limitation, and the legal-hold obligations that sit on top of them. Personal data should be kept only while the original purpose, or a documented secondary purpose such as audit or recordkeeping, still applies. The PDPL sets these as principles rather than fixed universal periods, which means the work is to define category-based schedules tied to purpose, legal obligation, and sensitivity, and to write down the reasoning, rather than applying one blanket period to everything.

He was direct about why over-retention is not a harmless default. Every extra record an organization keeps enlarges the blast radius of any future breach, raises storage and audit cost, and makes legacy systems and cloud migrations riskier, because historical data nobody needed is exactly what turns a routine project into an exposure. The more you hold, the more you have to lose, which reframes deletion as risk reduction rather than housekeeping.

The distinction the session pushed hardest on was archiving versus deletion, because it is the one organizations most often get wrong. Archiving is a security and access-control practice; the data still exists and remains subject to the law. Sushant's framing was concrete: if you have defined a one-year secondary retention for records or audit, archiving during that year is sound practice, but holding the data beyond the point any purpose justifies it is not prudence, it is just risk you have chosen to keep. His CCTV example made the same point from the other direction, that small-scale, short-purpose data rarely justifies long retention at all.

Two practical themes ran underneath. Automation is strongly preferred for deletion, because manual deletion is inconsistent and hard to monitor, and where automation is not available, controls, validations, and audit checks have to enforce the schedule instead. And deletion has to be evidenced: a deletion log is what lets you show what was removed and when, even after the data itself is gone.

Sushant was clear that the DPO cannot set retention alone. Business owners, data stewards, IT, and legal all have to contribute, and the test he put to the business was simple: if no one can articulate a legitimate purpose for continuing to hold a category of data, retention should not continue. Legal holds are the disciplined exception, applied narrowly to the relevant datasets and tracked in a register, not used as a blanket reason to keep everything indefinitely.

The session also addressed the reality that a data subject's request to delete everything frequently produces partial rather than complete erasure, because labour-law and other statutory obligations require certain records to be kept. The retention lifecycle framework and the documentation toolkit are best taken from the recording and the takeaways.

The throughline was that retention and deletion do not stand alone. They depend on the rest of the program, the inventory, the governance, the cross-functional ownership, and on a business that can articulate why it still holds what it holds.