Giving Each Team the View It Needs

Data protection is often treated inside a company as the responsibility of one person or one small team. Somebody is appointed as the privacy lead, the policies are written, and the assumption settles that data protection now has an owner. That assumption holds until the first piece of work arrives that the privacy lead cannot complete alone, which happens almost immediately.

Consider what a single request from a customer actually requires. Somebody has to receive it and confirm that the person asking is who they claim to be. Somebody has to search the systems where that person’s data might sit, and those systems belong to the technology team. Somebody has to decide whether any of the data is exempt from disclosure, and that is a legal judgement. Somebody has to write and send the response, and somebody has to record what was done. That comes to four or five different people, sitting in three or four different departments.

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

When those handovers are informal, the work moves only as fast as people remember to chase each other. Requests sit waiting because the privacy lead sent an email to a team inbox and nobody there treated it as theirs. Erasures do not happen because the instruction was given verbally in a meeting and the person who received it had three other priorities that week.

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

The reconciliation is the giveaway. If a privacy officer has to ask the technology team what happened and then type the answer into a system, the system is a reporting layer and not an operating one. It records what somebody says happened, which carries less weight than a record of what happened.

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

The privacy and legal function manages the parts of the programme that involve reading the law and applying it to the company. Inside TrustOS that covers purposes, notices, consent, the rights of individuals, grievances, processors, impact assessments and records of legal review.

Their assigned work looks like reviewing a processing purpose against the ground recorded for it, approving a notice version before it goes live, deciding how a request should be answered where the position is not obvious, assessing whether a processor arrangement carries adequate terms, and recording the reasoning behind a decision so that somebody can follow it later.

This function needs something from a system that the others do not. It needs the reasoning preserved alongside the outcome. A decision that a particular purpose rests on a legitimate use instead of consent is only defensible if the reasoning behind it was written down at the time, and TrustOS keeps that reasoning attached to the purpose it concerns.

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

During an incident the value of a shared system becomes obvious very quickly. Facts are established over hours and days instead of all at once, and several people are working in parallel on scoping, containment, notification and communication. When each of them is reading the same record, nobody is working from a version of events that has since been corrected.

Security also holds a standing interest in the inventory that 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 mapping sits in the same platform instead of a separate register that has to be kept in step.

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

No function is let down more often by the way privacy work reaches it, and the reason is usually the form the request takes. Requests arrive as emails with partial information, from people who cannot say precisely which records are involved or what has been approved. An engineer then spends more time establishing what is being asked than carrying it out.

Inside 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 requested it and what has to be confirmed once it is done. The engineer can act and record the result, including a result that is only partly successful, without needing to reconstruct the background first.

Operations teams are usually the first point of contact when an individual exercises a right, and they carry a specific and often underestimated part of the work. Inside TrustOS they receive requests, verify the identity of the person asking, complete the work assigned to them, and keep the individual informed of where things stand.

Identity verification deserves attention because getting it wrong creates the problem it was meant to prevent. Disclosing somebody’s personal data to a person who is not them is itself a breach, so the verification step protects the company as much as the individual. Recording what was checked, and by whom, means the company can show that the step was taken.

Keeping the individual informed matters for a reason that has little to do with the law and a great deal to do with grievances. A person who has heard nothing for three weeks escalates, and an escalation is more work than an update would have been. Where the status is visible to the team handling the request, an update takes a moment.

Audit and management read the programme instead of working inside it. Inside the platform they review open obligations, ownership, evidence, findings, remediation and the overall state of the programme.

Their needs differ from everybody else’s in an important way. The other functions want to see their own work, while audit and management want to know whether the whole thing is functioning. They need counts and trends more than individual items, together with the ability to select one case and follow it through to the evidence behind it.

For a company that has been notified as a Significant Data Fiduciary, this function carries additional weight. The annual impact assessment, the independent audit and the reporting of significant observations all rest on operating records, and a company already keeping those records can support the requirement instead of assembling it from nothing.

When each function keeps its own record, a company ends up with several accounts of the same activity, and none of them is authoritative. The privacy team has a spreadsheet of requests. The technology team has tickets. The support team has a case management system. Nobody can say with confidence how many requests are actually open, because each list counts something slightly different and none of them is complete.

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

The deeper problem is what happens when the lists disagree during something that matters. If the privacy record says an erasure completed and the technology record says it did not, somebody has to establish which is right, and that investigation happens at the point when time is short.

In TrustOS each request, purpose, incident, processor and control exists once. The different teams see different views of it, and they are all views of the same underlying record and not copies of it.

The reconciliation problem disappears completely, because nothing is left to reconcile. One record exists and every team is looking at it. When the technology owner marks an erasure as complete, the privacy officer sees it as complete in the same instant, and the record of who marked it and when is part of the same entry.

It also changes how the teams talk to each other. A privacy officer asking about a delayed erasure is looking at the exception and its reason before the conversation begins. The technology manager is looking at the same thing. They can discuss the blocker itself instead of arguing about whether one exists, and that is a shorter and more useful conversation.

Giving several teams access to one system raises an obvious question about who should be able to see what. TrustOS handles this by giving each authorised team the records and actions that relate to its own responsibilities instead of opening everything to everybody.

Two reasons stand behind that arrangement, and only one of them concerns security. A support agent who logs in and sees the entire compliance programme has to work out which part is theirs, and a system that is hard to navigate gets used reluctantly. Showing a person only their own work keeps the platform usable.

The second reason carries more weight. The platform holds personal data, and the same principles that apply to any other system apply here. A support agent verifying somebody’s identity has no need to read an impact assessment. An auditor reviewing evidence has no need to alter an operating record. Access that matches the work keeps personal data inside the boundaries where it belongs.

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

That matters for ordinary operational reasons, because a question about why a purpose was changed can only be answered if the change carries a name and a date. It matters more for a regulatory response, where a company describing its handling of an incident has to say who took each step.

It also protects the people doing the work. An engineer who executed an approved erasure correctly has a record showing the approval they acted on. Without that, a later question about why data was deleted arrives at somebody with nothing to point to.

Most delays in privacy work happen at a handover and not during the work itself. A request is received by support and needs a legal view. A legal decision is taken and needs technology to execute it. An erasure completes partly and needs legal to decide what to do about the remainder.

Each of those points is a place where an informal process loses time. An email is sent and not read. A message is read and not acted on. A verbal agreement in a meeting is remembered differently by the two people who made it.

Inside TrustOS a handover is the creation of an assigned action. When legal has taken 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 completing the previous step, and not as a separate act of communication that somebody has to remember.

Following one case shows how the sequence works. Take a customer who asks for a copy of the personal data a company holds about them, a request that is among the most common any company receives.

The request arrives with the operations team, who verify the identity of the person asking and record what they checked. Completing that step creates work for the technology team, which searches the systems in scope and returns what it finds. Where anything in the results raises a question about whether it can be disclosed, that question becomes an action for the legal team, along with the material it concerns.

Legal records the decision and the reasoning. The response is then prepared and sent, and the case is closed 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 anybody having assembled it afterwards.

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 repeated because the position changes.

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

That benefit is small compared with the regulatory ones, and it is the one that people using the platform notice first. A system that gives somebody back an hour a week gets used. A system that adds an hour of data entry gets abandoned, however well it satisfies the Act.

Companies lose institutional knowledge every time somebody moves on, and privacy programmes are unusually exposed because so much of that knowledge goes unwritten. Which purposes rest on which grounds, why a particular retention period was chosen, who agreed to what with a processor, and how a difficult request was handled last year.

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

A shared record changes what a handover involves, because the next person inherits the purposes, the grounds, the owners, the decisions and the reasoning, and can start from the current position instead of the beginning. That continuity is worth more over several years than any single feature of the platform.

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.