Turning an obligation into assigned work

Why a documented programme can still leave work undone

The spreadsheet that went on leave

An NBFC in Lucknow runs a personal loan app with a few lakh borrowers. Its DPDP preparation looks solid on paper: a privacy policy reviewed by outside counsel, a notice for the app, a retention schedule and a written procedure for customer requests. One person, the compliance manager, keeps a spreadsheet of open items.

Then she goes on three weeks of leave. A borrower asks for his data to be corrected, a collection agency's contract comes up for renewal, and the head of risk wants to know how many customer requests are open. Nobody can answer without messaging four teams. The spreadsheet is on her laptop, and nobody knows whether the copy on the shared drive is current.

Documents set the standard and people do the work

Ask most companies what they have in place for data protection and the answer is a list of documents: a privacy policy, a notice for each service, a retention schedule and a written procedure for handling requests. All of these are necessary, and they are usually drafted with care and reviewed by a lawyer.

Then ask how many customer requests are open right now, who is handling each one, and how long the oldest has been waiting. In a good number of companies nobody knows without asking around, and asking around means messaging three or four teams and waiting for replies. By the time the replies arrive the position has moved, because new requests have come in and others have closed.

Carelessness is rarely the cause. A privacy policy explains what the company intends to do. It is silent on who will do it, what exactly they will do, whether they have done it yet, and how anyone would check afterwards. Those four things have to live somewhere else, and they commonly live in the memory of a few people and in one person's spreadsheet.

The spreadsheet works while one person keeps it current and nobody else needs to change it. Trouble starts when that person goes on leave, when a second team needs to update the same file, or when somebody asks what the position was four months ago and no copy of the sheet from that time exists.

What the Act expects you to be able to prove

The Digital Personal Data Protection Act, 2023 places several duties on a Data Fiduciary. It has to answer requests from the people whose data it holds, erase data once the purpose has been served, keep reasonable security safeguards, report a breach to the Data Protection Board and to the people affected, bind its processors by contract and run a grievance mechanism. The DPDP Rules, 2025 were notified on 13 November 2025, and most of these duties apply from the third phase of commencement, around 13 May 2027; check for later amendments.

Every one of these duties carries a second duty behind it, and companies tend to notice that one late. You have to be able to show that you met it. Good intentions leave no record.

When the Board looks at a matter, its questions are about particular events: which request came in, when it was received, who dealt with it, when it was closed and what the outcome was. A policy sets out a general standard, and the question concerns one specific case, so the policy cannot answer it. Only a record of the actual work can, and that record has to be made while the work is being done.

Penalties are set in the Schedule as maximums for each instance, decided by the Board after it considers the nature, gravity and duration of the breach. They reach ₹250 crore for a failure of security safeguards, and for duties without a specific figure the ceiling is ₹50 crore.

TrustOS is built around that pairing. The duties have to be carried out, and carrying them out has to leave a trail. The platform arranges both.

How TrustOS moves an obligation through to evidence

The four steps

TrustOS takes every obligation through the same four steps, and they account for most of what the platform does.

1. Requirement. Something the Act, the Rules or your own policy asks the company to do.
2. Responsibility. The requirement is attached to a team and a named person.
3. Action. The requirement becomes a piece of work with a clear start and finish, and the platform records what actually happened, including the cases where the work could not be finished.
4. Evidence. What remains afterwards and can be shown to management, an auditor, a lawyer or the Board.

Read the sequence backwards and the logic is plain. Evidence is what a regulator eventually asks for, and evidence exists only if somebody recorded how the action ended. An action can be recorded only if it was defined, and it gets done only if a person owns it. And ownership can be attached only to a requirement somebody wrote down.

Companies tend to lose the thread at two points. The first is between requirement and owner, where a duty is written into a policy and never given to anybody in particular. The second is between action and evidence, where the work genuinely gets done and leaves nothing anyone can find months later.

What is connected to what

For any of this to work, the platform needs a picture of how your company is put together. TrustOS holds records for your business services, applications, data stores, processors, categories of personal data, processing activities, the way data moves between systems, and the person who owns each of these.

Each processing purpose is then linked to several things at once: the personal data it uses, the legal ground relied on, the retention rule that applies, the team responsible for it and the version of the notice approved for it.

These links are what make the platform useful. A notice in TrustOS is attached to the purpose it covers, and that purpose is attached to the data categories involved and the systems holding them. If the loan app starts collecting a new field, the notice for that purpose is visibly affected and somebody can be asked to review it.

The same links let gaps show up on their own. A purpose with nobody assigned shows as unassigned. A purpose with no current notice version shows as incomplete. A processing activity with no retention rule shows as open. Nobody has to find these gaps by reading through files.

Turning obligations into work people can finish

How work reaches the person who has to do it

The actions TrustOS creates cover what a privacy programme actually consists of: reviews, responses to requests, remediation after a finding, retention and erasure work, communication with individuals, and approvals. Each action sits against a specific record, has a named owner and carries the information the owner needs to act.

Actions arrive in three ways:

• On a schedule, such as a yearly processor review or a quarterly check that a notice is still accurate.
• From an event, such as a borrower's request or an incident logged by the security team.
• From a person, usually as remediation after an assessment has found something that needs fixing.

Whatever the source, the work lands in one queue for the owner. The convenience matters more than it first appears, given how many privacy officers work today. Obligations reach them by email, through a ticketing system, in a shared spreadsheet and in conversations in the corridor. Four channels carry the work, gaps open between all of them, and no single place shows everything outstanding.

The context travelling with the action matters as much as the routing. When an erasure action reaches a technology owner, it carries the systems involved, the records concerned, the approval behind it, who asked for it and what has to be confirmed once it is done. Without that context the owner starts by asking questions, and the asking often takes longer than the work.

One detail decides whether this holds together over time. An action assigned to a team reaches nobody in particular, and one assigned to somebody who has left reaches nobody at all. Every assignment has to point to a current person, so the ownership records behind it need upkeep as people join, move between teams and leave.

Seeing where everything stands

Anybody with the right access can see the current position without asking a colleague: open requests and how long each has waited, retention actions that completed and those that did not, processor reviews falling due, impact assessments outstanding, and incidents still being handled.

The practical effect is a change in where the week goes. A privacy lead who can see the position on Monday morning spends the week on the exceptions. One who has to assemble the position spends the week assembling it. Both face the same obligations, and only one has the time to meet them properly.

Management and audit need the same information at a different level. They look at the shape of the programme: how many obligations are open, where ownership is missing, which areas carry unresolved exceptions, whether scheduled reviews are actually happening, and how all of that moves across a quarter.

For a board, one number tends to matter most: obligations with nobody assigned. A programme where every purpose, notice, processor and control has a named owner faces questions about performance. A programme with a long unassigned list has a more basic problem, and the number says so plainly without anybody having to argue the point.

What happens when work cannot be completed

Some work cannot be finished as intended, and how a system handles those cases decides whether people trust what it shows. Three situations come up again and again. An erasure is blocked because a statutory retention period covers part of the data. A request is only partly answered because a processor holding some of the information has not replied. A retention action verifies in two connected systems and comes back pending in the third.

TrustOS records the unresolved case as unresolved, with the reason, and keeps it assigned until it is dealt with. A system that recorded only successes would show a cleaner picture and hide exactly the items that carry risk. The open exceptions are the ones a privacy lead most needs to see, because that is where the company is still exposed.

Several teams working in one place

What each team looks after

Responsibilities under the Act cross departments, and a platform built for one department ends up used by the privacy team and ignored by everybody else. TrustOS gives each authorised team access to the records and actions that relate to its own work, so each function sees the part of the programme it is accountable for.

• Privacy and legal manage purposes, notices, consent, the rights of individuals, grievances, processors, impact assessments and legal review records. Their actions include reviewing a purpose, approving a notice, responding to a request and recording a legal assessment.
• Security looks after breach records, safeguards, communication during an incident, remediation and risk review.
• Technology looks after system connections, carrying out actions inside those systems, identity and access, technical controls and exceptions.
• Customer and business operations receive requests, verify who is asking, complete the work assigned to them and keep the individual informed.
• Audit and management review open obligations, ownership, evidence, findings, remediation and the overall state of the programme.

All of these teams work from the same underlying records. That removes the problem that appears the moment each function keeps its own list. With one record there is nothing to reconcile and no argument about which version is current.

Access follows the same principle. Each team sees what relates to its work, which keeps the system simple to use and keeps personal data within the boundaries where it belongs. A support agent verifying a borrower's identity has no reason to read an impact assessment, and an auditor reviewing evidence has no reason to be able to change an operating record.

What still needs a person to decide

People in privacy and legal find that this way of working takes away much of the effort of finding out where things stand and leaves more room for the decisions only a person can make. Those are the substantial ones: whether a purpose is compatible with the legal ground recorded against it, whether a notice actually covers what a system collects, whether the terms in a processor contract are adequate, and whether a particular incident needs to be reported. Each of these needs a reading of the law and an understanding of the company, and software can do neither.

The division is worth being clear about. TrustOS handles the tracking, the routing, the records and the reminders. People handle the interpretation. A company that expects software to make legal judgements for it will get confident answers to questions the software never understood.

An example: one purpose from onboarding to a dispute

What the platform records along the way

Consider the NBFC's onboarding purpose from start to finish: collecting identity and contact details to open a loan account.

In TrustOS that purpose carries its data categories, the legal ground relied on, the retention rule, the owning team and the version of the notice the borrower was shown. When a borrower consents to an optional purpose, such as offers on other loan products, that decision is stored with the notice version he saw at the time.

Some months later he withdraws that consent. The withdrawal is recorded, and the follow-up actions are created and assigned automatically. One stops the use of his data in the marketing tool. Another erases data held only for the withdrawn purpose. That erasure action reaches the technology owner, runs successfully in two of the three connected systems and comes back as pending verification in the third.

The pending item stays visible and assigned until somebody resolves it, and the completion is then recorded with its date. Nothing in this sequence depended on anybody remembering to write it down afterwards, because each step was recorded as it happened.

What that record is worth when the borrower disputes it

Later still, the borrower lodges a grievance saying the company kept his data after he withdrew consent. The company now has to establish what actually happened, quickly and accurately.

Everything needed sits in one record: the purpose and the legal ground taken for it, the notice version he saw, the consent with its date, the withdrawal with its date, and the actions created in response with their owners and completion dates. It also holds the pending item in the third system and the date it was closed. If the company was slow with any of it, that shows too, and it is far better to know that before replying than to discover it during an inquiry.

Answering the same grievance without those records looks very different. It means interviewing people who have since changed roles, searching message archives and working out dates from system backups. The answer arrives slowly and incomplete, with a level of confidence nobody wants to put in writing to a regulator. Compliance programmes are judged in the end on cases like this one, far more than on the straightforward ones.

What TrustOS leaves to you

Interpretation and configuration stay with you

TrustOS has clear limits. It does not decide which legal ground applies to a purpose. It does not judge whether a notice is adequate, whether an incident crosses the threshold for reporting, or whether your company falls within a class notified as Significant Data Fiduciaries. Those are legal readings, and they belong with qualified people working from the Act, the Rules and your own circumstances.

The platform holds each of those decisions once it is made, links it to the work that follows and keeps the record of what was done. The decision, and its quality, remain a human responsibility.

Configuration follows the same division. TrustOS is set up around the services, systems, processors, data categories, teams and regulatory duties your company actually has. Examples from your sector give a useful starting point, and every implementation still has to reflect your real data environment and your real legal position.

This matters when you evaluate the platform. Its value depends on the configuration being accurate, and accuracy depends on somebody in the company knowing what data sits where and who owns it. Where that knowledge is incomplete, establishing it becomes the first phase of the work.

Recording work and doing work

There is one more limit. TrustOS records the work and tracks it, and people and systems still have to carry it out. An erasure assigned to somebody who never runs it stays open, and the platform keeps showing it as open for as long as that continues.

A well populated system is therefore weak proof of a well run programme. What the platform does remove is the excuse that nobody knew the work was outstanding, and in practice that excuse is what lets most of it go undone.

Where to begin

A sensible start is the one area where you most need control right now. That might be mapping personal data, notices, consent, requests from individuals, processor oversight, impact assessments, breach readiness, retention or evidence. Any one of them can come into the platform first, with the others following as the programme develops.

Starting narrow has a practical reason. Bringing a whole programme in at once means configuring everything before anything is usable, and companies that try it often stall during configuration. Bringing in one area means the platform is doing real work within a few weeks, and the next area benefits from what the first one taught you.

TrustOS is where the compliance work runs and where its evidence is kept. The judgement and the effort stay with your teams.

A short checklist

• Write down each requirement you have to meet.
• Give every requirement a named owner, a person as well as a team.
• Turn requirements into actions with a clear finish.
• Record completion, including failures and their reasons.
• Keep ownership current as people change roles.
• Watch the count of unassigned items every month.
• Start with one area, such as requests or consent, and add the next once it works.

The gap assessment helps you choose which area to start with.