Executing retention and erasure across systems

The schedule nobody ran

An online fashion marketplace based in Surat wrote a sensible retention schedule in 2023. Order data for seven years because of tax and accounting rules, marketing preferences until consent is withdrawn, abandoned cart data for ninety days, customer support chats for two years. Legal approved it, and it has sat in a shared folder ever since.

In 2026 an engineer looks at the main database and finds abandoned cart records going back to 2019, support chats from launch day, and a reporting copy of the customer table that refreshes every night and has never deleted a single row. Nobody set out to ignore the schedule. No job was ever built to enforce it, and the person who wrote it left eighteen months ago.

The pattern is common. The rule exists, and nothing in any system acts on it.

What the Act requires of retention

Data lives as long as its purpose

The Digital Personal Data Protection Act, 2023 ties the life of personal data to the life of the purpose it was collected for. Data should be erased when consent is withdrawn, or when the purpose is no longer being served, unless another law requires you to keep it for longer.

The DPDP Rules, 2025 give that principle a definite shape for one class of business. Certain large e-commerce, online gaming and social media platforms, above the user thresholds set in the Third Schedule to the Rules, must treat the purpose as over three years after the person last approached them or used the service, and erase the data. They must also tell the person at least forty eight hours before the erasure, so that someone who has simply been away has the chance to come back.

Organisations below those thresholds are not bound by the three year figure, and the principle still governs them. Holding personal data indefinitely by default is the position the Act is written against. You need a period for each category of data and a reason behind each period.

That moves retention from a storage question to a compliance one. Keeping data has always cost money. Keeping it past its purpose now carries a regulatory cost as well. The DPDP Rules, 2025 were notified on 13 November 2025, and these duties apply from around 13 May 2027; check for later amendments. Organisations that start now have time to do the work properly.

Where statutory retention pulls the other way

Some data has to be kept, and that obligation sits alongside the erasure duty without contradicting it. Tax law, company law, financial regulation such as the RBI's KYC directions, and employment law all set retention periods of their own, and where one applies it governs.

The DPDP Rules add one of their own. Rule 6 expects logs and related personal data to be kept for at least one year so that unauthorised access can be detected and investigated. A retention plan that deletes every log after thirty days to save space has created a different problem.

A common mistake is a single retention rule applied across a data set that holds both statutory records and material with no such requirement. That fails in both directions at once. Invoices needed for GST are destroyed early, and marketing data is held long after its purpose ended.

The right treatment is to separate the two inside the retention schedule, and that needs the purposes to be recorded so the distinction has something to attach to. Retention belongs to the purpose, which means one order table can hold data for fulfilment, for GST records and for marketing analytics, each with a different period. The guide on linking purposes to grounds and notices covers that groundwork.

TrustOS records what sets each period: a statutory requirement, a genuine business need or a decision about when a purpose ends. A period with no recorded reason cannot be defended when someone asks about it, and cannot be revised sensibly when the business changes.

From a rule to an action

Why a schedule alone changes nothing

A retention schedule is a statement of intent. It says how long each category of data should be kept, and on its own it has no effect on any system. Organisations with excellent schedules routinely hold data far past the periods those schedules set, for the simple reason that nothing acts on the document.

Most retention failures live in the gap between the schedule and the systems. Somebody wrote the rule, somebody approved it, and no scheduled job was ever built to enforce it. The rule holds for as long as someone remembers to apply it by hand, and that usually ends when the person who wrote it moves on, as it did in Surat.

TrustOS closes that gap by turning each retention rule into scheduled work. As a period approaches its end, the platform creates an action against each system holding that data, assigned to the owner of that system.

That conversion is the whole point of the retention area in the platform. The requirement stops being a line in a document and becomes a piece of work with an owner, a due date and a completion state.

Approval before anything is deleted

Deletion cannot be undone, so each retention action passes through approval before it runs. The action reaches the responsible owner with the detail of what would be removed, from which systems and under which rule, and the approval is recorded with a name and a date.

The step exists because retention rules are set in advance and circumstances change afterwards. Customer records due for erasure under a three year rule may since have become relevant to a consumer court case, a payment dispute, an internal investigation or a tax assessment. Approval gives someone with current knowledge the chance to check before the data goes.

Skipping approval leads to a specific and unpleasant failure. An automated job deletes records needed for a matter nobody told the system about, and the deletion cannot be reversed. The approval step costs a few minutes and prevents that entirely.

Where a legal hold applies, TrustOS records it against the data. The action then pauses with a reason attached, and stops coming back every month to be declined again.

Reaching every copy

Data does not sit in one place

An erasure that removes a record from the main database and leaves it everywhere else has not done what the Act intends. Personal data in a working organisation sits in several places at once, and each of them is a place the obligation reaches. In a typical business the same customer's data also sits in:

• reporting or analytics stores, which hold copies so that queries do not slow the main application;
• caches and search indexes, which hold recent data and extracts for speed;
• test environments copied from production, often for legitimate technical reasons;
• processors such as a CRM, a courier partner, a payment gateway or an email tool;
• spreadsheets and exports on shared drives, and attachments in mailboxes.

TrustOS creates the erasure action against each recorded location, which is why the inventory and the data movement records matter so much here. The platform can only reach the copies it knows about. A copy nobody recorded stays where it is.

Retention is only as complete as the map it runs against, which is why it depends on the data inventory. Organisations that treat the inventory as a documentation exercise find out the cost at exactly this point.

Instructing processors

Where a processor holds personal data on your behalf, the erasure duty reaches them too. You remain answerable for that data, so you have to instruct the processor and you have to know whether the instruction was carried out.

TrustOS sends the instruction as an action against the processor record and tracks the confirmation coming back. An instruction sent with no confirmation received leaves you unable to say whether the data still exists, which is a weaker position than it first appears.

Some processors respond promptly and some do not. Recording the pattern is useful in its own right. A vendor that rarely confirms deletions is a risk worth raising at the next contract review, and the record gives you the specifics to raise.

Backups, logs and the parts that resist erasure

Backups hold the data as it was when they were taken, so a record erased today still exists in a backup taken yesterday. That is a technical constraint, and it says nothing about the diligence of the team.

The defensible approach has three parts. Erase promptly from live systems. Keep backups on a defined retention cycle, so erased data ages out on a known timetable. Keep a documented procedure that reapplies erasures if a backup is ever restored. TrustOS records your position and the procedure, so you can explain what deletion means in your own environment when someone asks.

Append-only logs raise the same question and deserve the same treatment. Where a log stores a reference to a person, such as an internal customer number, the problem becomes far smaller. That is a good argument for designing logs this way from the start, and it fits well with the one year log retention that Rule 6 expects.

What matters is an answer that has been engineered, written down and tested. Some difficulty is expected here. The exposure comes from staying silent about it while the privacy notice promises complete deletion.

Verified completion

Running inside connected systems

Where TrustOS is connected to a system, an approved erasure action can run inside it and the platform records the result. The confirmation then comes from the system that did the work, which turns a claim into evidence.

The guide on connecting TrustOS to the systems you already run covers how those connections are set up. From the retention side, what matters is the range of results a connected system can report: completed, partial or failed, each recorded differently.

The case worth planning for is the partial result. An action that removed rows from a table but could not remove them from a linked search index has done part of the job, and recording it as complete would be inaccurate. The platform keeps it open with the specific gap named.

Where the platform is not connected

Some systems will stay unconnected, particularly older applications and outside services with limited interfaces. Retention still has to happen there, and the platform handles them by assigning the action to the system owner with the detail they need.

The owner carries it out and records what they did, including any part they could not finish. That record carries less weight than a system confirmation, since it rests on a person's statement. It carries far more weight than having no record at all.

Organisations often find that the unconnected systems are where retention has lapsed for years. Bringing them into the assigned action cycle makes that gap visible so it can be closed.

Exceptions and what to do with them

Some retention actions will not complete, and the reasons fall into a few recurring groups:

• a statutory hold applies to part of the data;
• a processor has not confirmed;
• a system returned a failure;
• a legal matter has paused the erasure;
• a technical dependency means removing a record would break something else.

TrustOS keeps each exception open with its reason and its owner. The count of open exceptions is one of the more useful figures a privacy function can watch, because it measures the distance between what the organisation has decided and what its systems have actually done.

If that count is small and shrinking, the programme is working. If it grows quarter on quarter, there is a structural problem, and the exceptions themselves point to where it sits.

Notice before erasure

The forty eight hour requirement

For platforms in the Third Schedule class, a person has to be told at least forty eight hours before their data is erased on the grounds that the purpose has ended. The reasoning is simple: someone who has not used the service for a while gets the chance to return before their account is removed.

Meeting this needs the retention engine, the messaging channel and the record to work together. The sequence runs like this: identify accounts inactive for three years, send the notice, let the window run, cancel the erasure for anyone who comes back, then erase the rest and record the whole sequence.

Compared with breach reporting this is a small obligation, and it reflects the character of the Rules. Systems are asked to act on time, in order and with evidence kept.

Handling the response

A person who responds by using the service again has renewed the purpose, and the erasure should not go ahead. Detecting that requires the platform to know what counts as coming back, whether a login, an order or opening the app. That is a decision for you to make and record.

For a person who does not respond, the erasure goes ahead as scheduled. The record shows that the notice was sent, the date it went and the date the erasure followed.

Both outcomes need recording, because the question will be the same either way: what did you tell the person, when did you tell them, and what happened next.

What this gives you

A retention position you can defend

An organisation working this way can state, for any category of personal data, how long it is kept, what sets that period, which systems hold it, when the last erasure cycle ran, what completed, what did not and why.

That is the position a regulator asks about, and the one an enterprise customer asks about in a security review. You need it internally as well, because retention is one of the few areas of the Act where doing the work reduces cost along with risk.

Data that no longer serves a purpose costs storage, costs licence fees in some systems, slows queries and widens the damage if a breach occurs. Removing it on a schedule improves all four, on top of the compliance benefit.

Where to start

Retention is a sensible area to bring into the platform early. It works best once the inventory and the purpose register exist, since a retention rule needs a data category and a purpose to attach to.

A practical first pass covers the categories with the most sensitive data and the largest volumes. Set the periods, record the reasoning and schedule actions against the systems that are already connected. The unconnected systems follow, and the exceptions list shows how far you still have to go.

What to avoid is publishing a retention schedule and treating that as the work. A schedule with no actions behind it describes something the organisation is not doing, and anyone comparing the document with the systems will find that gap quickly.

Checklist

• Attach every retention period to a purpose and record what sets it.
• Separate statutory records from data held only for business reasons.
• Include the one year log retention for security in your plan.
• List every location of each data category, including processors and test copies.
• Require approval before erasure, and record legal holds against the data.
• Write down your backup and restore position.
• Track partial and failed erasures as open exceptions with owners.
• If you are in the Third Schedule class, build and test the forty eight hour notice flow.

See Retention and erasure for how TrustOS schedules and tracks this work.