Turning an Obligation into Assigned Work

When you ask a company what it has in place for data protection, the answer is usually a list of documents. The list will include a privacy policy, a notice for each service, a retention schedule, and a written procedure for handling requests from customers. These are all necessary, and they are usually drafted carefully and reviewed by a lawyer.

Now ask a different question about how many customer requests are open at this moment, who is handling each of them, and how long the oldest one has been waiting. In a good number of companies nobody knows without asking around, and asking around means sending messages to three or four teams and waiting for replies. By the time those replies arrive the position has changed, because new requests have come in and others have been closed.

The reason for this is not carelessness. A privacy policy explains what the company intends to do, and it does not say who will do it, what exactly they will do, whether they have done it yet, or how anyone would check afterwards. Those four things have to exist somewhere else, and they commonly live in the memory of a few people and in a spreadsheet that one person maintains.

The spreadsheet works until it does not. It 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 version of the sheet from that time exists.

The Digital Personal Data Protection Act 2023 places several duties on a company that handles personal data. It has to answer requests from the people whose data it holds, erase that data once the purpose has been served, report a breach to the Data Protection Board and to the people affected, keep reasonable security safeguards in place, put proper terms into its contracts with processors, and run a grievance mechanism.

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, and showing is different from having intended to.

When a regulator looks at a company, the questions are about particular events. They will ask which request came in, when it was received, who dealt with it, when it was closed, and what the outcome was. A privacy policy cannot answer any of those, because a policy sets out a general standard while the question concerns one specific case. Only a record of the actual work can answer it, and that record has to have been written while the work was being done.

TrustOS was built for that pairing. The duties have to be carried out, and carrying them out has to leave a trail behind it. The rest of this article explains how the platform arranges that.

TrustOS handles every obligation through the same sequence of five stages. Understanding those stages explains most of what the platform does and why it is built the way it is.

The first stage is the requirement itself, meaning something the Act or your own policy asks the company to do. The second stage is responsibility, where that requirement is attached to a specific team and a named person. The third stage is the assigned action, which turns the requirement into a piece of work with a clear beginning and end. The fourth stage is completion, where the platform records what actually happened, including the cases where the work could not be finished. The fifth stage is evidence, meaning what remains afterwards and can be shown to management, an auditor, a lawyer, or the Board.

Reading that sequence in reverse shows why each stage matters. Evidence is what a regulator eventually asks for, and evidence only exists if somebody recorded the completion. Completion can only be recorded against a defined action. An action only gets done if a person owns it. And ownership can only be attached if the requirement was captured in the first place.

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

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

Each processing purpose is then connected to several things at once. It is connected to the personal data it involves, to the legal ground you are relying on, to the retention requirement that applies, to the team responsible for it, and to the version of the notice that was approved for it.

These connections are what make the platform useful and not merely organised. A notice inside TrustOS is not a document sitting on its own. It is attached to the purpose it covers, and that purpose is attached to the data categories involved and the systems that hold them. If a system starts collecting a new field, the notice tied to that purpose is visibly affected, and somebody can be asked to review it.

The same connections let the platform show a gap instead of waiting for a person to notice one. A purpose with nobody assigned to it appears as unassigned. A purpose with no current notice version appears as incomplete. A processing activity with no retention requirement recorded against it appears as open. None of these gaps has to be discovered by reading through files.

The actions that TrustOS creates cover the things a privacy programme actually consists of, which include reviews, responses to requests, remediation after a finding, retention and erasure work, communication with individuals, and approvals. Each action sits against a specific record in the platform, has a named owner, and carries the information that the owner needs for acting on it.

Actions reach a person in three different ways. Some are scheduled in advance, such as a periodic review of a processor or a check that a notice is still accurate. Some are created by an event, such as a request arriving from a customer or an incident being recorded by the security team. Some are created by a person, usually as remediation after an assessment has found something that needs fixing.

Whichever way an action arrives, it lands in one place for the owner. That may sound like a small convenience, and it repays comparison with the way many privacy officers work today. Obligations reach a privacy officer through email, through a ticketing system, through a shared spreadsheet, and through conversations in corridors. Four channels carry the work, gaps open up between all of them, and no single place shows the full list of what is outstanding.

The information 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 finished. Without that context the owner has to start by asking questions, and the asking usually takes longer than the work itself.

One detail decides whether any of this holds together over time. An action assigned to a team reaches nobody in particular, and an action assigned to a person who has left the company reaches nobody at all. Assignment therefore has to resolve to a current individual, which means the ownership records behind it need to be maintained as people join, move between teams, and leave.

Anybody with the appropriate access can see the current position without having to ask a colleague for it. That view covers the requests that are open and how long each has been waiting, the retention actions that completed and the ones that did not, the processor reviews falling due, the impact assessments still outstanding, and the incidents that are 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 working on the exceptions. A privacy lead who has to assemble that position spends the week assembling it instead. The obligations facing both people are identical, and only one of them has the time to meet them properly.

Management and audit readers need the same information at a different level of detail. They are looking at the shape of the programme instead of individual actions, so they need to know how many obligations are open, where ownership has not been assigned, which areas are carrying unresolved exceptions, whether the scheduled reviews are actually happening, and how all of that is moving across a quarter.

Among those figures the one that tends to matter most to a board is the count of obligations with nobody assigned to them. A programme where every purpose, notice, processor and control has a named owner has a question about performance in front of it. A programme with a long list of unassigned items has a more basic problem, and the number states that plainly without anybody having to argue the point.

Some work cannot be finished the way it was intended, and how a system handles those cases decides whether the people using it come to trust what it shows them. Three situations come up regularly in practice. An erasure may be blocked because a statutory retention period covers part of the data involved. A request may only be partly answered because a processor holding some of the information has not responded. A retention action may verify successfully in two connected systems and come back as pending in the third.

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

Responsibilities under the Act do not sit inside a single department, and a platform that assumes they do will be adopted by the privacy team and ignored by everybody else. TrustOS gives each authorised team access to the records and the actions that relate to its own work, so that each function is looking at the part of the programme it is accountable for.

The privacy and legal team manages purposes, notices, consent, the rights of individuals, grievances, processors, impact assessments and legal review records. Their assigned actions are things like reviewing a purpose, approving a notice, responding to a request, and recording a legal assessment.

The security team looks after breach records, safeguards, communication during an incident, remediation and risk review. The technology team looks after system connections, executing actions inside those systems, identity and access, technical controls and exception handling. 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 the open obligations, the ownership, the evidence, the findings, the remediation and the overall state of the programme.

All of these teams are working from the same underlying records, which removes a problem that appears as soon as each function keeps its own list. When there is only one record, there is nothing to reconcile and no disagreement about which version is current.

Access to the platform follows that same principle. Each team sees what relates to its work, which keeps the system straightforward to use and keeps personal data inside the boundaries where it belongs. A support agent verifying somebody’s identity has no reason to be looking at an impact assessment, and an auditor reviewing evidence has no reason to be able to change an operating record.

Somebody working in privacy or legal will find that this way of operating takes away much of the effort of finding out where things stand, and leaves more room for the decisions that only a person can make. Those decisions 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. Whether a particular incident needs to be reported. Each of these requires reading the law and understanding the company, and neither of those can be done by software.

The division is worth being clear about. TrustOS handles the tracking, the routing, the records and the reminders, while the person handles the interpretation. A company that expects software to make legal judgements on its behalf will receive confident answers to questions the software never understood in the first place.

It is easier to see how this works by following one processing purpose from beginning to end. Consider a financial services company that collects identity and contact information so that it can onboard a new customer.

That purpose sits in TrustOS with everything attached to it. The categories of personal data involved, the legal ground being relied on, the retention requirement that applies, the team responsible for it, and the version of the notice that the customer was actually shown. When the customer gives their consent, that decision is recorded against the purpose along with the notice version they saw at the time.

Some months later the customer withdraws their consent. The withdrawal is recorded, and the actions that follow from it are created and assigned automatically. One action stops a downstream use of the data. Another erases the data that was being held only for the withdrawn purpose. That erasure action reaches the technology owner for the systems concerned, runs successfully in two of the three connected systems, and comes back as pending verification in the third.

That pending case stays visible and stays assigned until somebody resolves it, and when it is resolved the completion is recorded with the date on which it happened. Nothing in this sequence depended on anybody remembering to write it down afterwards, because each step recorded itself as it occurred.

Some time after all of this, the customer lodges a grievance saying that the company kept their data after they had withdrawn consent. The company now has to establish what actually happened, and it has to do so quickly and accurately.

Everything needed to answer the grievance sits in one place. The record holds the purpose and the legal ground taken for it, the version of the notice the customer saw, the consent decision with its date, the withdrawal with its date, and the actions created in response along with their owners and completion dates. It also holds the pending case in the third system and the date on which that was closed. If the company was late in dealing with any of it, that shows as well, and knowing that in advance puts the company in a far stronger position than finding it out during an inquiry.

Answering the same grievance without those records means something quite different. It means interviewing people who have since changed roles, searching through message archives, and trying to work out dates from system backups. The answer arrives slowly, it arrives incomplete, and it arrives with a level of confidence that nobody wants to put in writing to a regulator. Compliance programmes are eventually judged on cases like this one and not on the straightforward ones.

An accurate description of the platform has to cover what it does not do. TrustOS does not decide which legal ground applies to a purpose. It does not judge whether a notice is adequate, determine whether an incident crosses the threshold for reporting, or settle whether your company falls within a class that has been 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.

What the platform does is hold each of those decisions once it has been made, connect it to the work that follows from it, and keep the record of what was done. The decision itself remains a human responsibility, and the quality of the decision remains a human matter.

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

That leads to a point you should know before evaluating 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 and not something to be assumed.

One further limit deserves a plain statement. TrustOS records the work and keeps track of it, and the work itself still has to be carried out by people and by systems. An erasure that has been assigned to somebody who never executes it will remain open, and the platform will go on showing it as open for as long as that continues.

Treating a well populated system as proof of a well run programme is therefore a mistake. What the platform genuinely removes is the excuse that nobody knew the work was outstanding, which in practice is the excuse that allows most of it to go undone.

A sensible way to begin is with the one area where you most need control at the moment. That might be mapping your personal data, or your notices, or consent, or requests from individuals, or oversight of processors, or impact assessments, or breach readiness, or retention, or evidence. Any one of them can be brought into the platform first, with the others following as the programme develops.

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

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.