TL;DR: Most organisations still treat data subject rights requests as a legal inbox: an email arrives, someone forwards it around, and a reply goes out when a person remembers. But a rights request is not a message to answer. It is a multi-step operational process with a statutory clock running from the moment it arrives, an identity check that has to happen before any data moves, fulfilment that spans several departments and systems, and an evidence trail that has to survive a regulator asking "show me exactly how you handled this one." Treating it as an inbox is how organisations miss the deadline, hand data to an unverified requester, and end up unable to prove they did the right thing. This article explains why rights handling is an operational discipline rather than a correspondence task, and how AesirX ComplianceOne runs each request as a tracked case: multi-channel intake (web, phone, postal, in person, and bulk import), a mandatory identity-verification gate, rights-type routing to the departments that hold the data, a response clock with a formal extension workflow, template-driven responses with delivery proof, and a closure record that will not close until the response, the evidence, and the decision rationale are all captured. The inbox answers a message. The engine produces proof.
This article is written for DPOs, privacy operations leads, compliance managers, legal counsel, customer-experience leaders, and the department owners who actually hold the data a request reaches for. It is especially relevant for banks, telcos, payment platforms, e-commerce groups, and multinational subsidiaries operating under Vietnam's Personal Data Protection Law (PDPL) and Decree 356, alongside GDPR and other international regimes.
The Request That Sat In an Inbox For Three Weeks
A customer of a Ho Chi Minh City e-commerce group emails support asking for a copy of everything the company holds about them, and, while they are at it, asking the company to delete their marketing profile. The support agent is not sure who handles this, so they forward it to a colleague, who forwards it to legal, who is on leave. The email moves through three inboxes and then stops.
Three weeks later, the customer files a complaint. Now the company has a problem that is no longer about one email. Nobody verified who the requester was. Nobody logged when the clock started. Nobody knows which of the company's twelve systems hold the person's data. Marketing thinks IT deleted the profile; IT thinks marketing did. There is no record of what was decided, by whom, or when. And the response, when it finally goes out, cannot be proven to have been delivered.
The request was treated as a message. It was actually a process, and the process was never run.
“A rights request is not an email to answer. It is a case to run, and the case has to produce its own proof.”
Data subject rights are where privacy compliance becomes visible to the individual. Everything else, the data map, the impact assessment, the transfer dossier, is internal. A rights request is a person exercising a legal right and watching how you respond. Handling it in an inbox is a decision to run your most visible obligation as your least controlled one. This article is about running it as an engine instead.
The Inbox Loses the Clock
The moment a rights request arrives, a statutory clock starts. An inbox does not know that.
Under Vietnam's PDPL, the exercise of data subject rights is a legal obligation, with the umbrella rights set out in Article 4 and the procedure for exercising them supported by Article 5 of Decree 356. Specific rights carry their own mechanics: withdrawal of consent and restriction of processing under Article 10, correction under Article 13, and deletion or de-identification under Article 14. Under GDPR, the same rights live in Chapter 3, from access through rectification, erasure, restriction, portability, and objection.
None of that machinery works if the request is sitting unread in a shared mailbox. The clock does not pause because the right person was on leave. When the deadline is a real obligation and the tracking is an email folder, the deadline wins.
Answering before you know who is asking
The second failure is quieter and more dangerous. An inbox invites you to answer the person who emailed, not the person who holds the right.
A rights request is a request to move, expose, correct, or delete personal data. If you fulfil it without verifying identity, you may have just handed one person's data to another, which is itself a personal data breach. Identity verification is not a bureaucratic step before the real work. It is the gate that separates a rights fulfilment from a data leak.
An inbox has no gate. It has a reply button. That is the wrong default for an obligation where the cost of answering the wrong person is a breach notification.
One request, many departments, no coordination
The third failure is that a single request almost never lives in a single system.
An access request at a bank reaches into core banking, the card system, the marketing platform, the call-centre logs, and the archive. An erasure request has to be executed everywhere the data lives, including at vendors, and then proven. The DPO does not hold that data. The departments and system owners do. Coordinating them by email means chasing people, losing track of who has responded, and never being sure the request was fully satisfied.
I hear the same frustrations from DPOs across every regulated sector:
- Department responses arrive in different formats, at different times, if they arrive at all.
- There is no single source of truth, so the case is reassembled from email threads and spreadsheets.
- It is hard to prove who supplied what and when, which is exactly what a regulator asks.
- The response goes out, but there is no proof it was ever delivered.
An inbox cannot coordinate a cross-department process. It was never meant to.
Intake Is a Front Door, Not a Mailbox
The first move is to give rights requests a real front door instead of a mailbox.
In ComplianceOne, requests enter through a public, multilingual intake form that a data subject can use without creating an account, and every submission opens a tracked case from the first second. Crucially, the front door is not only the web form. Real requests arrive by phone, by postal letter, by a walk-in at a branch, and by email to a staff member who is not the DPO. The platform lets a staff member open a case for any of these channels, record the source, attach the scanned letter or the forwarded email as evidence, and, where the person is standing at the counter, complete identity verification on the spot.
For organisations that need it, requests can also be registered in bulk, which matters during a system migration or a surge. The point of the front door is singular: however a request arrives, it becomes the same kind of tracked case, with the same clock, the same gate, and the same audit trail. No request starts life as an untracked email.
The identity gate comes before the data moves
Before any department touches any data, the case has to pass the identity gate.
Identity verification is a first-class step with its own record and its own sign-off, and the workflow does not let fulfilment proceed until it is cleared. Verification can be done through the channel the request came in on, including offline methods such as a government ID presented in person or a callback confirmation for a phone request. The verification evidence stays linked to the case.
This is the single most important difference between an engine and an inbox. The engine refuses to move data until it knows who it is moving data for. The inbox has no such refusal built in.
“Identity verification is not paperwork before the work. It is the gate that separates a rights fulfilment from a data breach.”
Routing the request to the departments that hold the data
Once identity is verified, the platform classifies the type of right being exercised, whether that is access, correction, erasure, restriction, objection, or portability, and routes fulfilment tasks to the departments and system owners who actually hold the relevant data.
Because the case links directly to the data mapping inventory, the people doing the work know exactly which systems are in scope rather than guessing. Each department gets its own task with its own sign-off gate, so a response is not issued until every team has confirmed what it holds and what it did. And every department contribution preserves its lineage: who acted, on which system, and when.
This is where the coordination problem gets solved structurally. The DPO is not chasing five inboxes. The DPO is watching one case where five tasks either are or are not signed off, each with an owner and a status.
The clock, and the honest way to extend it
An engine treats the deadline as a tracked property of the case, not a date someone tries to remember.
The platform runs the response clock from intake against the statutory window your organisation is operating under, and it escalates as milestones approach: identity verification not completed, department responses outstanding, no legal review scheduled, response deadline nearing. Where the law allows a request to take longer, the platform provides a formal extension workflow rather than a silent slip. The extension is requested, approved by the DPO, the deadline is recalculated, and the requester is notified.
An extension you can justify and evidence is defensible. A missed deadline nobody logged is not.
The response is a decision with proof, not just a reply
A reply says something. A response proves something.
When fulfilment is complete, the platform generates the response from a template, with the decision behind it made explicit: fully fulfilled, partially fulfilled, or refused. Where it is partial or refused, the rationale is captured rather than left implied. Delivery is tracked across the channel that fits the requester, whether that is email, a secure portal, postal mail, or in-person collection, so there is proof the response actually reached the person. Evidence of the processing and the delivery is captured against the case.
Then the case closes, but only when it is allowed to. Closure requires the response, the evidence, and the decision rationale to all be present. A case cannot quietly disappear as answered when it is missing its own proof.
The registry, and the requests that trigger deletion
Two capabilities turn individual cases into a connected, defensible picture.
The first is a data subject registry that keeps a full rights history per individual, linked across their consent records, their rights requests, and the processing activities that touch them. When the same person makes a second request, or a regulator asks what this individual has exercised over time, the history is one place, not a reconstruction.
The second is what happens when a request is an erasure. Deletion is not a single button; it is a coordinated execution across every system and every vendor that holds the data, each with its own confirmation and, for vendors, a verification deadline. A per-person completeness view shows which systems have confirmed deletion, which are still outstanding, and any retention conflict that has to be resolved before the case can close. This is how an erasure request becomes a provable outcome rather than an assumption that marketing and IT each thought the other had handled.
Walkthrough: The DPO Running a Cross-Department Access Request
Consider a DPO at a large bank whose customer asks for a copy of all the data the bank holds about them.
The request arrives through the intake form and opens a case, and the clock starts. Identity verification runs first: the workflow will not release the request into fulfilment until the requester is confirmed. Once cleared, the platform classifies the request as an access request and routes fulfilment tasks to the departments and systems that hold the data, each pointed at the specific records in scope through the link to the data mapping inventory. Retail banking, cards, marketing, and the call-centre each complete and sign off their own task.
Legal and privacy then review whether the request can be fully satisfied, partly satisfied, or refused in part, and that decision, with its rationale, is recorded on the case. The DPO approves the final response, which the platform generates from a template and delivers through the requester's channel with delivery proof captured. The case closes only once the response, the evidence, and the rationale are all present. If a regulator later asks how this request was handled, the answer is one export, not a reconstruction from email.
Walkthrough: a withdrawal that turns into a proven deletion
Now consider a request to withdraw consent and delete a marketing profile, the kind of request that exercises the withdrawal and restriction right under PDPL Article 10 and the deletion right under Article 14.
After identity is verified, the erasure does not become a single delete click. It becomes a coordinated deletion across every system and vendor that holds the person's data, each with its own confirmation, and, for vendors, a verification deadline with escalation if they do not respond. The completeness view tracks which systems have confirmed and which have not, and it surfaces any retention conflict, for instance data the bank is legally required to keep, so that conflict is resolved and documented rather than ignored. The case cannot close while a deletion is unconfirmed. Where the erasure changes a processing record that was part of a filed impact or transfer dossier, the linked record is updated, which is the dossier-amendment path that PDPL Article 22 and Decree 356 Article 20 address through the update forms.
Walkthrough: the request that never touched the web form
Finally, consider the two requests that break most inbox-based processes: one that arrives as a phone call and one that arrives as a posted letter.
A staff member takes the phone call, opens a case, records the source as a phone request, and captures the caller's details and account of what they want, even though there is no email address to notify. Identity is verified by a callback confirmation. The posted letter is scanned and attached to its own case as evidence, with the source recorded as postal. From that point, both cases run exactly like a web-form case: the same clock, the same identity gate, the same routing, the same closure discipline. The postal response is generated, printed, and mailed, with the delivery method and any tracking recorded as proof. The channel changed. The engine did not.
Run the Process, Not the Email
The shift I am arguing for is to stop treating your most visible privacy obligation as correspondence and start treating it as an operated process.
When a rights request becomes a case rather than an email, it starts its own clock, refuses to move data until identity is verified, routes itself to the people who hold the data, tracks its own deadline and extends it honestly when the law allows, proves that its response was delivered, and refuses to close until its own evidence is complete. The DPO stops being a coordinator of inboxes and becomes the operator of an engine that produces defensible outcomes by default.
“An inbox depends on someone remembering. An engine depends on nothing but itself.”
The Test of Your Privacy Program
Data subject rights are the part of privacy the individual actually sees, and increasingly the part a regulator uses to test whether your programme is real. An organisation that cannot show how it handled one specific person's request, on time, to the right person, with proof of delivery, does not have a rights process. It has an inbox.
If your rights handling still lives in a shared mailbox and a spreadsheet of open items, the distance to an operational engine is not a large project. Multi-channel intake, an identity gate, department routing tied to your data map, a tracked response clock with an honest extension path, delivery proof, and deletion that proves itself all exist in one place today.
If you want to see what a rights request looks like when it runs as a case from intake to closure, or how an erasure proves its own completeness across your systems and vendors, the team at AesirX is happy to walk through it. Visit https://aesirx.io/compliance-one for the current product page, or get in touch to see it run against your own process.
Ronni K. Gothard Christiansen
Technical Privacy Engineer and CEO, AesirX.io
Laws and standards referenced
- Vietnam: Law on Personal Data Protection (PDPL), Articles 4, 10, 13, 14, and 22
- Vietnam: Decree 356/2025 (Decree 356), Articles 5 and 20, with Mẫu số 03a / 03b where a rights request updates a filed dossier
- International: GDPR Chapter 3 data subject rights (access, rectification, erasure, restriction, portability, objection)
Disclaimer
This article is operational guidance from a platform vendor, not legal advice. Specific regulatory positions, especially the PDPL articles, the Decree 356 procedures, and the applicable response timelines for data subject rights, should be confirmed with qualified Vietnamese counsel for your specific industry and supervisor.
