Executing Retention and Erasure Across Systems

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

The Rules give that principle a definite shape for the largest consumer platforms in commerce, online gaming and social media, treating the purpose as exhausted three years after the individual last engaged with the service, and requiring notice to the individual at least forty eight hours before erasure so they have the chance to return.

Companies 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 posture the Act is written against, so a company needs a period for each category and a reason behind it.

That reframes retention from a storage question into a compliance one. Keeping data costs money and always has, and now keeping it past its purpose carries a different kind of cost.

Some data has to be kept, and that obligation sits alongside the erasure duty instead of conflicting with it. Tax legislation, company law, financial regulation and employment law all impose retention periods, and where one applies it governs.

Companies commonly apply a single retention rule across a data set that contains both statutory records and material with no such requirement. That approach fails in both directions at once, destroying records the company was obliged to keep and holding data past the point its purpose was served.

Separating the two inside the retention schedule is the correct treatment, and it needs the purposes to be recorded so the distinction has something to attach to. The article on purposes in this series covers that groundwork.

TrustOS records what determines each period, whether that is a statutory requirement, a genuine business need or a decision about when a purpose ends. A period with no reasoning behind it cannot be defended when questioned, and cannot be revised sensibly when circumstances change.

A retention schedule is a statement of intent. It says how long each category of data should be kept, and it has no effect on any system. Companies with excellent schedules routinely hold data far past the periods those schedules specify, and the reason is simply 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 somebody remembers to apply it manually, and that usually ends when the person who wrote it moves on.

TrustOS closes that gap by turning each retention requirement into scheduled work. As a period approaches expiry, the platform creates an action against the systems holding the data, assigned to the owner of each of those systems.

That conversion carries 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.

Deleting data is irreversible, so a retention action passes through approval before it executes. The action reaches the responsible owner with the detail of what would be removed, from which systems, under which requirement, and the approval is recorded with a name and a date.

That step exists because retention rules are set in advance and circumstances change afterwards. Data due for erasure under a three year rule may have become relevant to a legal hold, an ongoing investigation or a live dispute. Approval gives somebody with current knowledge the chance to check.

Skipping approval produces 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 minutes and prevents that entirely.

Where a legal hold applies, TrustOS records it against the data so the action is suspended with a reason instead of being repeatedly proposed and repeatedly declined.

An erasure that removes a record from the primary database and leaves it everywhere else has not achieved what the Act intends. Personal data in a working company sits in several places at once, and each of them is a location the obligation reaches.

Reporting stores hold copies so that queries do not slow the main application. Caches hold recent data for speed. Search indexes hold extracts. Test environments hold copies made for legitimate technical reasons. Outside services hold whatever was sent to them. Exports sit in spreadsheets on shared drives.

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

Here lies the practical connection between the inventory article and this one. Retention execution is only as complete as the map it runs against, and companies that treat the inventory as a documentation exercise discover the consequence at this point.

Where a processor holds personal data on the company behalf, the erasure duty extends to them. The company remains answerable for that data, so it has to instruct the processor and it has to know whether the instruction was carried out.

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

Some processors respond promptly and some do not. Recording the pattern serves a purpose in its own right, since a processor that consistently fails to confirm deletions is a risk worth raising at the next contract review.

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

The defensible approach combines prompt erasure from live systems with a defined backup retention period, so erased data ages out on a known cycle, and a documented procedure that reapplies erasures if a backup is ever restored. TrustOS records the position and the procedure, so the company can explain what deletion means in its own environment.

Append only logs raise the same question and deserve the same treatment. Where a log records a reference to an individual instead of their personal data, the problem largely disappears, and that is an argument for designing logs that way from the start.

What matters here is an answer that is engineered, written down and tested. Difficulty here is expected. Silence about the difficulty, combined with a notice promising unqualified deletion, is what creates exposure.

Where TrustOS is connected to a system, an approved erasure action can execute inside it and the platform can confirm the result. That confirmation turns a claim into evidence, because the completion is recorded by the system that did the work.

The article on connecting TrustOS to your systems covers how those connections are set up. From the retention side, what matters is the range of results a connected system can report. Completion, a partial result or a failure, each recorded differently.

The case worth planning for is the partial result. An action that removed data from a table and could not remove it from an associated index has done part of the job, so recording it as complete would be inaccurate. The platform keeps it open with the specific gap identified.

Not every system will be connected, particularly older applications and outside services with limited interfaces. Retention still has to happen in those places, and the platform handles them by assigning the action to the system owner with the detail they need.

The owner executes it and records what they did, including any part they could not complete. That record carries less weight than a system confirmation, since it rests on a person statement, and it carries a great deal more weight than no record at all.

Companies frequently find that the unconnected systems are where retention has quietly not been happening for years. Bringing them into the assigned action cycle makes the omission visible, and that is uncomfortable and useful.

Some retention actions will not complete, and the reasons divide into a few recurring categories. A statutory hold applies to part of the data. A processor has not confirmed. A system returned a failure. A legal matter has suspended the erasure. A technical dependency prevents removal without breaking something else.

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

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

For companies within the classes the Rules specify, an individual has to be told at least forty eight hours before their data is erased on the grounds that the purpose has been exhausted. The reasoning behind it gives somebody who has simply not used a service for a while the chance to return before their account is removed.

That obligation needs the retention engine, the messaging capability and the record to work together. The platform identifies the data due for erasure, the notice goes out, the window runs, any renewed engagement suspends the erasure, and the action proceeds afterwards with the whole sequence recorded.

That obligation is small compared with breach reporting, and it illustrates the character of the Rules well. Systems are asked to act on time, in order, and with evidence retained.

An individual who responds by using the service again has renewed the purpose, and the erasure should not proceed. Detecting that requires the platform to know what counts as engagement, and that is a configuration decision for the company.

An individual who does not respond has the erasure proceed as scheduled, and the record shows the notice was sent, the date it went, and the date the erasure followed.

Both outcomes need recording, because a company challenged on either will be asked the same question. What did you tell the individual, when, and what happened next.

A company operating this way can state, for any category of personal data, how long it is kept, what determines 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 position an enterprise customer asks about during a security review. The company needs that position internally as well, since retention is one of the few areas of the Act where doing the work reduces cost alongside risk.

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

Retention is a reasonable area to bring into the platform early, and it works best after the inventory and the purpose register exist, since a retention rule needs a category and a purpose to attach to.

A practical first pass covers the categories carrying the most sensitive data and the largest volumes, with periods set, reasoning recorded and actions scheduled against the systems that are already connected. The unconnected systems follow, and the exceptions list shows the distance still to travel.

What companies should avoid is publishing a retention schedule and treating that as the work. A schedule with no actions behind it describes something the company is not doing, and a regulator comparing the document against the systems will find that gap before anybody else does.

TrustOS is a DPDPA compliance platform developed and operated by Code Colonies Private Limited. It gives privacy, legal, security, technology, operations and audit teams a single system for personal data records, purposes and notices, consent and withdrawal, requests and grievances from individuals, retention and erasure, breach response, processor oversight and compliance evidence. Every obligation is connected to a responsible owner, turned into assigned work, tracked through to completion, and left with the records that an audit or a regulatory response will call for.

The platform can be deployed inside infrastructure that you control, and the agreed scope can include source code handover, environment setup, security configuration, technical documentation, integration support and knowledge transfer. A scoped gap assessment establishes your current position, the responsible teams, the priority gaps, the technical dependencies and a practical order in which to implement.

To see the platform or to discuss your requirements, continue to the product overview or start a gap assessment. To learn more about our consulting and engineering work, visit codecolonies.com. To start a conversation, write to us at consulting@codecolonies.com.