Giving each team the view it needs

One request, four departments

A policyholder of a general insurer in Mumbai emails the grievance address asking for a copy of all the personal data the company holds about her, including the medical reports from a health claim settled last year.

The email reaches the customer service team, who need to confirm she is who she says she is. Then someone in IT has to search the policy administration system, the claims system, the call recording platform and the document store. The claims file includes a doctor's note that mentions a third party, so legal has to decide what can be shared. Someone has to write the response, send it and record what was done.

Five people in four departments are involved. In most organisations the coordination happens by email, and the request moves only as fast as people remember to chase each other. The privacy lead keeps a spreadsheet, IT keeps a ticket, customer service keeps a case in its CRM, and the three cannot agree on whether the request is still open.

Why this work crosses departments

One law, several functions

Inside many organisations, data protection is treated as the job of one person or one small team. A privacy lead is appointed, the policies are written, and everyone settles into the belief that data protection now has an owner. That belief lasts until the first piece of work arrives that the privacy lead cannot finish alone, which happens early.

The Mumbai request shows why. Somebody has to receive it and confirm the identity of the person asking. Somebody has to search the systems where her data might sit, and those systems belong to the technology team. Somebody has to decide whether any of the data is exempt from disclosure, which is a legal judgement. Somebody has to write and send the response, and somebody has to record what was done.

The law sets it up this way. The DPDP Act makes the organisation, as the Data Fiduciary, responsible for compliance, including processing done on its behalf by processors. It gives Data Principals rights of access, correction, completion, updating and erasure, along with grievance redressal and nomination. It requires you to publish the contact details of a person who can answer questions about your processing, or of the Data Protection Officer where one is needed. The DPDP Rules, 2025 were notified on 13 November 2025, and most of these duties apply from around 13 May 2027; check for later amendments.

The same pattern repeats across the whole Act. A breach involves security, technology, legal and communications. A retention rule is decided by legal and carried out by technology. A processor review involves procurement, legal and whoever owns the vendor relationship. None of the substantial duties sits inside a single function.

When those handovers are informal, work moves only as fast as people chase each other. Requests wait because the privacy lead emailed a team inbox and nobody there treated it as theirs. Erasures do not happen because the instruction was given aloud in a meeting, and the person who heard it had three other priorities that week.

Why a privacy tool used by one team falls short

A good deal of privacy software assumes that the privacy team will use it and coordinate everyone else through email. That design leads to a familiar result. The privacy team keeps its records inside the tool, the actual work happens outside it in other teams, and the two versions drift apart until someone reconciles them by hand.

The reconciliation is the telling sign. If a privacy officer has to ask IT what happened and then type the answer into a system, that system is a reporting layer. It records what someone says happened, which carries less weight than a record made when it happened.

TrustOS works the other way round. Each team that carries part of a duty does its part inside the platform, so the record is created by the person doing the work at the time they do it. Nobody transcribes anybody else's account of events.

What each team is accountable for

Privacy and legal

The privacy and legal function handles the parts of the programme that involve reading the law and applying it to the organisation. In TrustOS that covers purposes and their grounds, notices, consent, rights requests, grievances, processors, impact assessments and records of legal review.

Their assigned work includes reviewing a purpose against the ground recorded for it, approving a notice version before it goes live, deciding how to answer a request where the position is unclear, checking whether a processor contract carries adequate terms, and writing down the reasoning behind a decision so that someone else can follow it later.

This function needs one thing from a system more than the others do: the reasoning kept next to the outcome. A decision to rest a purpose on a legitimate use, with no consent sought, can only be defended if the reasoning was written down at the time. TrustOS keeps that reasoning attached to the purpose it concerns.

Security

The security function owns the parts of the programme about protecting the data and responding when protection fails. In the platform that covers incident records, the safeguards in place, communication during an incident, remediation afterwards and periodic risk review.

During an incident the value of a shared system shows quickly. Facts emerge over hours and days, and several people work in parallel on scoping, containment, notification and communication. Under Rule 7 the Board and the affected Data Principals must be told without delay, with a detailed report to the Board within 72 hours. When everyone is reading the same record, nobody works from a version of events that has since been corrected.

Security also relies on the inventory the privacy team maintains. Deciding which systems need the closest protection depends on knowing which of them hold the most sensitive personal data, and that map sits in the same platform. There is no separate register to keep in step.

Technology

The technology function does most of the work that actually touches data. In TrustOS that covers connectors to your systems, running approved actions inside those systems, identity and access, technical controls, and handling exceptions when an action cannot complete.

Technology teams are often poorly served by the way privacy work reaches them, and the cause is usually the form of the request. It arrives as an email with partial information, from someone who cannot say exactly which records are involved or what has been approved. The engineer then spends longer working out what is being asked than doing it.

In the platform the same work arrives with its context attached. An erasure action names the systems in scope, the records concerned, the approval behind it, who asked for it and what needs confirming afterwards. The engineer can act and record the result, including a result that only partly succeeded, without first reconstructing the background.

Customer and business operations

Operations teams are usually the first contact when a person exercises a right, and they carry a specific and often underrated part of the work. In TrustOS they receive requests, verify the identity of the person asking, complete the steps assigned to them and keep the person informed.

Identity checks deserve care, because getting them wrong creates the very problem they exist to prevent. Handing someone's personal data to the wrong person is itself a breach, so the check protects the organisation as much as the individual. Recording what was checked, and by whom, means you can show the step was taken.

Keeping the person informed matters for reasons that have more to do with grievances than with the letter of the law. A policyholder who hears nothing for three weeks usually escalates, and an escalation is more work than an update would have been. When the status is visible to the team handling the request, an update takes a moment.

Audit and management

Audit and management read the programme without working inside it. In the platform they review open duties, ownership, evidence, findings, remediation and the overall state of the programme.

Their needs differ from everyone else's in one important way. The other teams want to see their own work. Audit and management want to know whether the whole thing is functioning. They need counts and trends more than individual items, plus the ability to open any single case and follow it to the evidence behind it. Auditors read records and leave them unchanged.

For an organisation notified as a Significant Data Fiduciary this function carries extra weight. It needs a Data Protection Officer based in India, an independent data auditor, and an impact assessment and audit every year, with significant observations reported to the Board. All of that rests on operating records kept by other teams. An organisation already keeping those records can support the requirement without assembling it from scratch.

How one record serves several teams

The problem of separate lists

When each function keeps its own record, the organisation ends up with several accounts of the same activity and none of them is authoritative. Privacy has a spreadsheet of requests, IT has tickets, and customer service has its case system. Nobody can say with confidence how many requests are open, because each list counts something slightly different and none is complete.

Reconciling the lists takes time that could have gone into the work, and it is never finished, because all three keep moving. A figure that was right on Monday is wrong by Wednesday, and producing it has to be repeated.

The deeper problem is what happens when the lists disagree on something that matters. If the privacy record says an erasure completed and the IT record says it did not, someone has to establish which is right, and that investigation tends to happen just when time is short.

What changes with one underlying record

In TrustOS each request, purpose, incident, processor and control exists once. Each team sees its own view of that same record, and none of them holds a copy.

The reconciliation problem goes away, because there is nothing left to reconcile. When the IT owner marks an erasure complete, the privacy officer sees it as complete at the same moment, and the entry shows who marked it and when.

It also changes how teams talk to each other. A privacy officer asking about a delayed erasure is already looking at the exception and its reason before the conversation starts, and so is the IT manager. They can discuss the blocker itself, and skip the argument about whether one exists. That is a shorter and more useful conversation.

Access, separation and why both matter

Each team sees what relates to its work

Giving several teams access to one system raises an obvious question about who should see what. TrustOS gives each authorised team the records and actions tied to its own responsibilities, and keeps the rest out of view.

There are two reasons for this, and only one is about security. A customer service agent who logs in and sees the entire compliance programme has to work out which part is hers, and a system that is hard to find your way around gets used reluctantly. Showing people their own work keeps the platform usable.

The second reason carries more weight. The platform itself holds personal data, and the same principles apply to it as to any other system. An agent verifying identity has no need to read an impact assessment. An auditor reviewing evidence has no need to edit an operating record. Access that matches the work keeps personal data inside the boundaries where it belongs, which fits the access controls expected under Rule 6.

Recording who did what

Access control and record keeping are more closely linked than they first seem. If several people can act on a record, the record has to show which of them did, and when.

That matters for ordinary reasons, since a question about why a purpose changed can only be answered if the change carries a name and a date. It matters more in a regulatory response, where an organisation describing how it handled an incident has to say who took each step.

It also protects the people doing the work. An engineer who carried out an approved erasure correctly has a record of the approval they acted on. Without it, a later question about why data was deleted lands on someone with nothing to point to.

Where work passes between teams

The handover as the point of failure

Most delays in privacy work happen at a handover between teams. A request received by customer service needs a legal view. A legal decision needs technology to carry it out. An erasure completes in part and needs legal to decide what to do about the rest.

Each of those points is where an informal process loses time. An email is sent and not read. A message is read and not acted on. Two people leave a meeting remembering the agreement differently.

In TrustOS a handover is the creation of an assigned action. When legal has made a decision, the resulting work appears in the queue of the person who has to carry it out, with the decision attached. The handover happens as part of finishing the previous step, so nobody has to remember to send a separate message.

Following a request across three teams

The Mumbai policyholder's request for a copy of her data is one of the most common any organisation receives. In TrustOS it runs as follows.

The request arrives with customer service, who verify her identity and record what they checked. Completing that step creates a search task for IT, which runs it across the systems in scope and returns what it finds. The doctor's note mentioning a third party raises a question about disclosure, so that question becomes an action for legal with the material attached.

Legal records its decision and the reasoning. The response is prepared and sent, and the case closes with the full sequence in place. Three teams did the work, each within its own competence, and the record shows every step with its owner and its date without anyone assembling it afterwards.

What this changes day to day

Fewer meetings about status

A recurring cost in compliance programmes is the meeting held to establish where things stand. Several people spend an hour reporting to each other on work the others cannot see, and the meeting has to be held again next week because the position has moved.

When the position is visible to everyone who needs it, those meetings shrink or stop. A shorter conversation about exceptions takes their place, because the routine items no longer need discussing.

This benefit is small next to the regulatory ones, and it is the one people notice first. A system that gives someone an hour back each week gets used. A system that adds an hour of data entry falls out of use, however well it covers the Act.

A programme that survives people leaving

Organisations lose knowledge every time someone moves on, and privacy programmes are unusually exposed because so much of that knowledge is never written down. Which purposes rest on which grounds, why a particular retention period was chosen, what was agreed with a processor, how a difficult request was handled last year.

When that knowledge sits with one person, their departure sets the programme back by however long it takes someone else to rebuild it. A new privacy lead who finds no map of ownership starts by asking questions that were answered two years ago.

A shared record changes what a handover involves. The successor inherits the purposes, grounds, owners, decisions and reasoning, and starts from where things stand today. Over several years that continuity is worth more than any single feature of the platform.

Checklist

• Map each DPDP duty to the teams that share it.
• Name one owner per record, and say which teams may view it or act on it.
• Replace email handovers with assigned actions that carry their context.
• Record identity checks for every rights request.
• Keep the reasoning next to every legal decision.
• Give management counts and trends, with the ability to open any case.
• Give auditors read access only.

The Rights and grievances page shows a request moving between teams.