Vietnam's Personal Data Protection Law: the legal text takes an afternoon, the engineering takes months

On 26 June 2025 Vietnam's National Assembly passed the Personal Data Protection Law, No. 91/2025/QH15 — 5 chapters, 39 articles — and the law took effect on 1 January 2026. Decree 356/2025/NĐ-CP, issued on 31 December 2025, applies from the same date — 5 chapters, 42 articles and an appendix of 10 forms — replacing Decree 13/2023/NĐ-CP.

Reading both documents takes an afternoon. But the question businesses actually need answered is a different one: *can our current systems do what those texts require*. That is an engineering question, and for a business already in operation the answer usually takes months.

This article is written from a systems-architecture perspective, not as legal advice. Deadlines, thresholds and business-size classifications should be checked against the original texts and with qualified legal counsel before you act on them.

Three questions your systems have to answer

Strip away the terminology and most of the obligations reduce to three operational questions:

• What personal data are you holding, and where?
• For each of those, what allows you to hold it, and until when?
• When someone asks for access or deletion, how long does it take you to do it everywhere?

They sound simple enough to skip past. In practice, when auditing systems that are already running, most organisations cannot answer the first one — and that isn't a failure of legal diligence, it's the natural consequence of how systems grow over years.

Why the first question is the hard one

Nobody loses track of customer data on purpose. It happens gradually: a CRM bought in 2019, the sales team's spreadsheets, the time-attendance system, web server logs, an analytics tool, the support inbox — and backups of all of it. This is exactly the five-or-six disconnected systems problem we've described before; from 2026 it simply carries legal consequences as well.

A data inventory is therefore not a Word file listing database tables. The approach that works is to start from the collection flows: every form, every public API, every file import, every third-party integration is a way in. Following each one to see where the data lands surfaces the stores nobody remembers when they try to list them from memory.

Deletion is an architecture problem, not a button

Try listing where a single customer record exists in an average system: the primary database, read replicas, the data warehouse, the search index, caches, message queues, application logs, exported files already sent by email, partner systems — and backups of nearly all of the above.

A "delete account" button handles the first item on that list.

Backups are the hardest part, and the part most often glossed over in written policies. You cannot open a six-month-old snapshot to remove one row; and if you could modify it, it would no longer be a backup in any meaningful sense. Two approaches work in practice:

• Crypto-shredding — encrypt each subject's data under its own key and store keys separately from data. Destroying the key renders that data meaningless in every backup without touching a single snapshot. The cost: it has to be designed in from the start, and the key store immediately becomes the most critical system you operate.
• A suppression list applied on restore — keep a list of subjects who requested deletion and apply it as a mandatory step in the recovery procedure. Far cheaper, but it only works if that step lives in the restore script rather than in the runbook.

If you have neither, the honest move is to record that limitation in your internal documentation and in what you tell data subjects, rather than promising "complete immediate erasure" — a sentence the system cannot deliver.

Consent has to be provable, not just displayed

A checked box in a user interface is not evidence. Evidence is a record that answers: who consented, when, for which purpose, through which channel, and against which version of the policy.

That last detail is the one most often missing. If the privacy policy page is edited over the top of the previous version — which is what nearly every website does — then every consent collected earlier loses its context: you can no longer demonstrate what the user agreed to. The fix is cheap: version the policy, keep old versions at stable URLs, and store the version number on each consent record.

In the other direction, withdrawing consent must be as easy as giving it, and it has to propagate downstream. A withdrawal that flips a flag in the CRM but doesn't stop the email campaign already in flight is a withdrawal that hasn't finished.

Three kinds of personal data that are usually missing from the map

• Logs. IP addresses, user agents, user IDs, and occasionally phone numbers that end up inside error messages. Logs are often kept indefinitely simply because nobody set a retention window — while being the fastest-growing store of personal data in most systems.
• Biometric data produced somewhere nobody calls a "data system". Fingerprint or face-recognition time clocks generate biometric data for the entire workforce. This matters more than it looks, because the category of data determines whether you qualify for the small-business exemptions — more on that below.
• Inferred data. Internal credit scores, customer segments, model-generated behavioural labels. Customers never supplied them, so they rarely appear in an inventory, yet they attach to an identified person.

Cross-border transfers happen even when you don't think you're transferring

Plenty of businesses answer "we don't send data abroad" while running a SaaS CRM hosted offshore, an analytics tool, a CDN, an email marketing service — and, increasingly, language-model APIs.

That last one deserves a longer pause. Every API call carrying a customer name, a phone number, a complaint text or a clinical summary is an instance of personal data leaving your infrastructure. Architecturally it is no different from any third-party integration — but because it lives in a line of code calling a library rather than in a signed contract, it typically never passes through vendor review.

The engineering consequence: the map of outbound data flows has to be built from source code and configuration, not from a list of contracts. Three ways to narrow the exposure, in increasing order of cost: send fewer fields (most prompts don't need real names); substitute pseudonymous identifiers before sending and rejoin afterwards; and run the model locally for exactly those flows that touch sensitive data.

It's also why we design the AI orchestration layer so the provider can be swapped: when a legal constraint or a data-residency requirement changes, what you edit should be configuration, not architecture.

Impact assessment records: 60 days, then every 6 months

This part comes with concrete deadlines, so it's worth writing down. Under Article 21, the data controller prepares and retains a personal data processing impact assessment record and sends one original to the specialised authority within 60 days of the first day of processing; the assessment is carried out once for the lifetime of the controller and updated under Article 22 — every 6 months where there are changes, and immediately on major changes such as corporate restructuring or a change of data-protection service provider. For data transferred abroad, the transfer impact assessment is likewise filed within 60 days of the first transfer.

The engineering question hidden inside that is a question about where the record comes from. A hand-typed record is accurate at first filing, drifts at the second update, and is fiction by the fourth — because the system changes weekly while the record is revisited twice a year. It stays accurate only if most of its content is generated from the system: the field inventory with data-category labels, the outbound integration list taken from configuration, retention windows taken from the retention policy that is actually enforced.

Put differently, durable compliance looks more like a data quality monitoring practice than like a paperwork exercise.

The exemptions — and the trap inside them

The law makes a clear concession to small scale. Household businesses and micro-enterprises are not required to comply with Articles 21 and 22 or with Article 33(2) — the clause requiring appointment of a qualified data protection function or personnel, or engagement of an external service provider. Small enterprises and startups may choose whether to comply, for five years from the law's effective date.

The trap is in the carve-out. The exemption does not apply to entities providing personal data processing services, entities that directly process sensitive personal data, or entities processing the data of a large number of data subjects. Those three clauses describe a great many real small businesses:

• A private clinic handling health data — sensitive by category.
• A 30-person company running fingerprint attendance — biometric data.
• An app with a few hundred thousand registered accounts, even where the company is still small by revenue and headcount.

Two things worth stating plainly. First, where the "large number" line falls, and how small and micro enterprises are classified, are legal questions to be checked against the source texts — not something to estimate from a feeling about size. Second, the exemption covers only those three record-keeping and personnel obligations; the duty to protect data and the rights of data subjects are not waived. Not having to file an impact assessment does not mean not having to delete data on request.

Penalties: read the ceilings, not the averages

Under the administrative sanctions applicable in this area, the maximum for an organisation is VND 3 billion per violation; for buying or selling personal data the maximum is 10 times the proceeds obtained from the violation; and for breaching the cross-border transfer rules the maximum is 5% of the prior year's revenue. For individuals, the maximum is half the organisational figure.

What's notable is how the latter two are constructed: they are not fixed sums but are tied to proceeds and to revenue. Financial exposure therefore scales with the size of the business, and cannot be reduced to a predictable operating cost you decide to absorb.

How to verify: run a drill, don't write a policy

We apply the same method to data compliance that we apply to accessibility: measure on the real system before writing any commitment down.

The concrete test: pick an account old enough to have left traces across several systems — with the subject's consent, or an internal account — then carry out a complete access request and a complete deletion request, from intake to confirmation.

Measure three numbers: how long it took, how many people you had to ask, and how many locations were missing from the data map. The first run almost always turns up at least one system that isn't on the map — typically a marketing tool, a spreadsheet, or a staging environment holding a copy of production data.

Production data in test environments deserves its own note: it usually isn't access-controlled as tightly as production, isn't covered by the deletion process, and exists for an entirely reasonable reason — you need realistic data to test against. The durable fix is generating synthetic data from the real distribution rather than copying rows; costly once, and cheap forever after, in the same way dual-write and backfill cost design effort and buy you a cutover without risk.

After the fixes, run the drill again and compare the three numbers. That is the difference between "we are compliant" and "we measured".

Conclusion

The legal half reads in an afternoon: 39 articles of law, 42 of decree, 10 forms. The engineering half is the three questions at the top of this article, and none of them can be answered by a well-written policy page.

The encouraging part is that the work points the same direction a business should be going anyway, law or no law: knowing what data you hold, where, why, and for how long. The organisations that can answer the first question are almost always the ones that already consolidated their data into one trustworthy source — for them, compliance is mostly documenting what exists rather than building something new.

If you want to know how far your systems actually get, get in touch to have a specific data flow reviewed, or see KonexForge's Data Analytics and Development capabilities.