Taking a Data Principal Request to Closure

The Digital Personal Data Protection Act 2023 gives every individual a set of rights over the personal data a company holds about them. They can ask for a summary of what is held and what is being done with it, including the identities of other companies and processors the data has been shared with. They can ask for correction, completion or updating of data that is wrong or incomplete. They can ask for erasure. They can lodge a grievance, and they can nominate somebody to exercise these rights on their behalf if they die or become incapable.

Each of those is a request that arrives without warning, from somebody the company may not immediately recognise, and each carries a response period the company has published. The volume is unpredictable and the work is not optional.

These rights are demanding for one shared reason. Every one of them requires the company to find all the personal data it holds about a single person. That single requirement sits underneath the whole of this article, and it explains why the inventory article in this series comes before this one.

A company that cannot locate a person across its systems will answer requests incompletely without knowing it. The response goes out, it looks complete, and the systems nobody remembered to search are simply absent from it.

The Act requires a company to operate a grievance mechanism, and an individual has to use it before approaching the Data Protection Board. That sequence gives the mechanism a particular significance, because it is the company first line of contact with a complaint and the point at which a matter either resolves or escalates.

A grievance handled well ends there. A grievance ignored, or answered slowly, or answered without addressing what was actually asked, reaches the Board with the company handling of it as part of the record.

TrustOS treats grievances along the same lines as rights requests, with intake, assignment, tracking, response and a closed record. What differs is the work itself and not the way it is managed. A complaint usually calls for investigation into what the company did, where a rights request calls for a search.

Requests arrive through whichever channel the individual chooses. Some come through a form on the website. Some arrive by email to an address published in the privacy notice. Some are made to a support agent on a call. Some arrive by post, and some are mentioned in passing to somebody who happens to work at the company.

A response period runs from receipt, so a request that sits unrecognised in a shared inbox for a week has consumed a week of it. Companies that lose control of this usually lose it at the point of intake and not during the work itself.

TrustOS records each request as it arrives, whatever channel brought it, with the date and time of receipt. Where a request comes through a form the platform captures it directly. Where it arrives another way, the person who received it records it, and that step is short enough to do immediately.

Recording the channel alongside the request serves two purposes. It shows where requests are actually coming from, which usually surprises companies that built a form and assumed everybody would use it. And it supports the response, because an individual who wrote by email expects a reply by email.

A request record in TrustOS holds the individual identity as they gave it, the right they are exercising, the date and time of receipt, the channel, the response period that applies, and the person assigned to handle it.

Assigning the request at intake, and not later, prevents the most common failure. An unassigned request belongs to the function that received it, and functions do not complete work. A named owner can be asked about it, and the platform shows how long it has been waiting.

Where the request is unclear, that is recorded too. An individual who asks for their data without saying which data, or who asks for something the Act does not provide, needs a clarifying reply. The clarification and the response to it become part of the same record, so the history of the exchange stays together.

Before a company discloses personal data in response to a request, it has to establish that the person asking is the person the data belongs to. Getting this wrong means disclosing somebody personal data to a stranger, and that is a breach the company caused itself.

The verification therefore protects the company as much as the individual, and it deserves treating as a substantive step and not a formality. Somebody who knows a customer name and email address has proved very little, since both are widely available.

What counts as adequate verification depends on what is being asked for and how sensitive the data is. A request for a copy of a full customer record calls for more checking than a request to correct a spelling. TrustOS records what was checked and by whom, so the standard applied can be seen and can be applied consistently.

Consistency is what companies find hardest without a system. Two agents facing similar requests in the same week will apply different standards unless the standard is written down and visible where the work happens.

Some requests cannot be verified. The individual may not respond to a request for further information, or the information they provide may not match what the company holds.

A request in that position stays neither closed nor open indefinitely. TrustOS keeps it recorded with its verification state, so the company can show what it asked for and when, and can close the matter with a reason if the individual does not continue.

That record matters if the same person later complains that their request was ignored. A company able to show that it asked for verification on a stated date, and received no reply, is in a different position from a company with nothing on file.

The Act allows an individual to nominate another person to exercise their rights in the event of death or incapacity. A request may therefore arrive from somebody who is not the data principal and who is entitled to act for them.

Handling that case requires the platform to represent a relationship most systems have never modelled. TrustOS records the nomination alongside the individual, so a request from a nominee can be verified against it instead of being treated as an unusual case resolved by discussion.

Requests also arrive from lawyers, family members and agents who have no recorded standing. Those need a decision about whether the person is entitled to act, and the decision belongs with the legal function. TrustOS routes it there as an assigned action with the request attached.

Once a request is verified, the substantive work begins, and for access and erasure requests that work is a search across every place the company holds personal data about the individual.

Here the inventory earns its keep. TrustOS knows which systems hold personal data and which categories each of them holds, so the search covers a known list instead of a remembered one. Actions reach the owner of each system, and each returns what it found.

The results come back in pieces and at different times, since different systems have different owners and different levels of automation. The platform holds the partial state, so the person coordinating the response can see which systems have reported and which have not.

Where a system is connected to the platform, the search can run inside it and return results directly. Where it is not, the action reaches the owner with the individual identifiers and the categories being sought, and the owner records what they found.

An access request does not automatically entitle an individual to everything the company holds. Some material may be exempt, some may reveal personal data about other people, and some may be subject to legal privilege or an ongoing investigation.

Those judgements belong with the legal function, and they arrive as assigned actions with the material attached. The decision and the reasoning are recorded against the request, so the response can be explained later if it is questioned.

Recording the reasoning gets skipped most often and turns out to be needed most often. An individual who receives a response with material withheld may ask why, and a company that recorded only the outcome has to reconstruct the thinking of whoever made the call.

A request for erasure or correction has to change data instead of reporting it, and the change has to reach every copy. That makes it harder than an access request, since a correction applied to the primary record while a stale copy sits in a reporting store leaves the company holding two contradictory versions.

TrustOS creates the actions against each system holding the data and tracks them individually. Where one system completes and another returns a pending state, the request stays open with the exception visible.

Some erasure requests cannot be completed in full, and the reasons are usually legitimate. A statutory retention requirement may cover part of the data. Backups may hold it until they age out on their own cycle. The platform records those positions with their reasons, and the response to the individual can state accurately what was erased and what was retained on what authority.

A response to an access request has to give the individual what the Act provides, meaning a summary of the personal data being processed, the processing activities involved, and the identities of other fiduciaries and processors the data has been shared with.

Writing that in plain language takes some care, since an internal record dumped into a document counts as a response and remains unusable. The individual asked what the company holds about them, and a readable answer serves both sides where a data export does not.

The response is sent through the channel the individual used or asked for, and the sending is recorded with its date. That timestamp demonstrates the response period was met, and it has to come from the system and not from anybody memory.

A closed request in TrustOS leaves a complete record. The request as received, the date and channel, the verification performed and by whom, the systems searched, what each returned, any decision to withhold and the reasoning behind it, the actions taken in each system with their completion states, any exception with its reason, the response sent and the date it went.

That record answers a question asked months later without anybody reconstructing anything. It also supports the management view, because a company reviewing its own performance needs to know how long requests are taking, where they are getting stuck, and which systems are slowest to respond.

Companies that keep this record consistently find a second use for it. Patterns emerge. If the same system is always the last to report, that is a technical problem worth fixing. If verification is where most time goes, the verification process is worth revisiting. Neither pattern is visible when each request is handled in isolation.

A company operating this way can state its position on rights requests at any moment. How many are open, which right each concerns, how long each has been waiting, who owns it, and which are approaching their response period.

That view changes how the work gets managed. Attention goes to the requests nearest their deadline and to the ones stuck on a particular system, instead of being spread evenly across everything or applied only when somebody complains.

It also changes what the company can say to an individual who asks about progress. A specific answer about where their request sits is a different experience from an assurance that it is being looked into, and it prevents a good number of grievances.

Companies already receiving requests and handling them by email should start with intake, because that is where the response period is lost. Getting every request into one place with a date, a channel and a named owner takes little effort and has an immediate effect.

Verification comes next, since it protects the company and it is the step most often applied inconsistently. Then comes the search itself, which depends on the inventory and improves as the inventory does.

The inventory article in this series covers that foundation, and the article on retention and erasure covers what happens when a request results in data being removed. Rights requests sit on top of both, and they are the part of the Act that individuals actually experience.

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.