Building a retention schedule around real business purposes

A retention schedule should explain why a record remains and what happens when that reason ends. A column saying “keep for seven years” is not enough if nobody knows which law, purpose or record category supports it. Equally, a promise to delete everything immediately can be inaccurate where lawful retention is required.

Start with actual business records: enquiries, orders, invoices, job applications, support tickets and consent evidence. Different records may require different treatment, even when they concern the same person. The schedule should help an operator make the right decision without conducting a new legal investigation each time.

As of 22 October 2026, the main DPDP retention duties are scheduled for 13 May 2027 under the commencement notification. The final Rules should inform readiness work, alongside requirements already applicable to the business.

Give every category a purpose and an owner

A hypothetical equipment rental business holds booking details, identity checks, invoices and photographs documenting damage. The booking record supports the rental; the invoice supports accounting; the damage photographs may support a specific dispute. Calling all four categories “customer data” hides those differences.

For each category, record the purpose, responsible owner, relevant systems and recipients. Identify the event that starts the retention period, such as completion of a transaction, rejection of an application or resolution of a dispute. A period measured from an undefined “closure” date will be applied inconsistently.

Also distinguish the active operational period from restricted retention. Keeping an invoice to meet a legal obligation does not automatically justify keeping the customer in a promotional audience.

Read the Act and final Rules together

Section 8(7) of the Act addresses erasure when consent is withdrawn or when it is reasonable to assume the specified purpose is no longer being served, whichever is earlier, unless retention is necessary for compliance with law. It also addresses causing processors to erase the personal data made available to them.

The final Rule 8(3) adds an important retention requirement: personal data, associated traffic data and other logs of processing must be retained for a minimum of one year from processing for the purposes specified in the Seventh Schedule. After that period, erasure is required unless further retention is required by law or a relevant government notification.

This provision should not be reduced to “keep security logs for one year”. It addresses personal data and associated records in its own terms. Rule 6 contains a separate security-related retention provision. A schedule should identify which provision applies rather than flattening both into a generic number.

Do not apply the large-platform inactivity rule to everyone

Rule 8(1) and the Third Schedule prescribe an inactivity-based period for specified classes of large e-commerce, online gaming and social media entities, subject to the schedule’s thresholds and purposes. Rule 8(2) provides a related advance warning process.

Those provisions do not create a universal three-year retention allowance for every small business. A neighbourhood rental company should not copy a large-platform account rule merely because the number looks convenient.

Where the schedule applies, assess its exact threshold, trigger and exclusions. Where it does not, continue analysing the business’s purposes, applicable law and the other relevant Rules. One inapplicable provision does not remove the rest of the retention analysis.

Add implementation details that make deletion possible

List the primary system, exports, supplier copies and backups. For each, identify how removal or restriction occurs and who can verify it. A policy that covers the main application but ignores weekly spreadsheets will produce incomplete outcomes.

Set an exception process for legal holds and unresolved disputes. The exception should identify its scope, authority, owner and review date. “Keep in case needed” is not a useful permanent reason. When a hold ends, the records should return to the ordinary schedule rather than remain indefinitely forgotten.

Review the schedule with real records

Choose three examples: a completed order, an abandoned enquiry and an active dispute. Ask the team to determine what remains, what is restricted and what can be removed. If the answer depends on information the system does not record, repair that gap before relying on automated deletion.

Keep the source and approval behind each rule, and date the schedule. Review it when purposes, suppliers or applicable requirements change. The result should be an executable record of justified retention, with enough detail to explain both why information was kept and why it was eventually erased.