Data retention schedule: how to set one and run it in software

Open the system first. Leads, quotations, invoices, KYC scans, CVs, support tickets, call recordings and site photos all count, and most owners find ten or twelve types they had never named. Walk through the CRM, the accounts package, the HR folder, the shared drive and the mailbox export folder, since each gathers personal records.

Beside each type, note the system that stores it, the person who owns it and every other place a copy might sit. One CV may sit in the careers inbox, the HR sheet and a shared drive at once, and each copy needs its own rule. Name the owner too.

Do not start with the law. Start with what you hold. If a record type has no owner, nobody will approve its deletion, and it will still be sitting there when the next audit or breach arrives.

A period needs a clock start. An invoice is kept from the end of the financial year, not the day it was raised, so its clock starts late. A lead’s clock starts at its last contact, and a CV’s starts when the vacancy closes and the shortlist is final.

Give the start event its own column. Software can only count days if the table names the date field it counts from, so write that field’s name beside the keep period. For a quotation the clock starts when the order is lost or the contract ends, which are two different date fields.

Where a record serves two purposes, the longer purpose wins, but only for the fields that genuinely need it, such as the invoice amounts. Drop the cheque scan.

Some records carry a legal minimum. Tax books, payroll registers, provident fund challans and signed contracts are the usual ones, so never copy a period from a blog post, including this one. Your accountant can tell you how long the sales ledger, purchase bills and bank statements must stay, and your lawyer can answer for employment files and identity documents.

Ask your chartered accountant about books and invoices, and your lawyer about employee files, KYC and anything specific to your sector. Record each answer and its date. A table citing a dated email from your adviser is far easier to defend than one citing a hunch.

Where no minimum applies, choose a short period. The Digital Personal Data Protection Act expects you to stop holding personal data once its purpose is served, so a defensible reason beats a round number. Write the reason down.

A yearly purge depends on memory. Build a weekly job instead. It finds records past their date, removes or anonymises them, and writes a log line for every batch it processes. Run it from a server schedule under a service account that holds delete rights on only those tables, and have it email a summary after every run.

Start in report-only mode. The job lists what it would delete, and the owner reads that list for two or three runs before anything is removed. After three clean runs in a row, flip the flag and keep the log file for as long as your adviser says.

Some deletions would break linked records. An invoice may point to a customer row, so anonymise the name, mobile and email fields and keep the amounts and GST numbers.

Deleting the row is half the job. The same person’s data also lives in CSV exports on laptops, email attachments, report folders and the nightly backup, and each of those counts as a copy. Search laptops and shared folders for old exports named leads_final.csv or customers_backup.xlsx, which outlive the system they came from.

Backups are the awkward case. You rarely edit a backup, so keep a deletion register of what was removed and when, and replay it after any restore before the system goes live.

Test with one dummy customer. Create them, wait for the clock to expire and see which copies survive, then fix every survivor and schedule the same test each quarter. Name an owner for each survivor.