Retention periods in India are not set by a single statute. Company records, tax records, GST records, employment records and sector-specific records each have their own requirement, and the periods do not align. A software system with one global retention setting will inevitably be wrong for some category of data.
The practical consequence is that retention is a per-record-type attribute, not a system-wide configuration. Invoices, contracts, employee files, transaction logs and correspondence each need their own clock, and the clock usually starts from an event — the end of a financial year, the closure of a contract, the departure of an employee — rather than from creation.
Design the data model to record that trigger event. A system storing only a creation timestamp cannot compute a retention date measured from contract closure, and retrofitting the trigger later means going back through historical records to establish it.
There is a tension with the DPDP framework, which points towards erasing personal data once the purpose is served. Where another law requires retention, that requirement generally governs — but the organisation needs to be able to say which law it is relying on for each category. 'We kept it because deleting things is hard' is not that answer.
Electronic records are acceptable in most cases, and the Information Technology Act supports their evidentiary use, but integrity matters. A record that could have been altered without trace is weaker evidence than one held in a system with immutable storage and an audit trail. For anything you might one day need to rely on, that difference is worth the storage configuration.
Write the schedule down as a table: record type, retention period, trigger event, legal basis, system of record. Most organisations do not have this document, and producing it usually reveals two or three categories nobody was managing at all.
