Vietnam's new data law changes what insurers can send
Vietnam's new personal data framework put a clock on every claim. The harder problem is that anonymising a photograph destroys the signal an insurtech vendor needs.

A claim photograph is the most sensitive file an insurer holds, and anonymising it enough to share destroys the signal the model was there to read. Vietnam's new framework did not make AI harder to use on claims. It moved the decision that matters to the front. Settle the data path first, then choose the vendor.
Vietnam's personal data framework changed on 1st January 2026.
Law 91/2025/QH15 and Decree 356/2025/ND-CP replaced Decree 13/2023, and most of what has been written since has been a list of deadlines:
- 60 days from the day you start processing to file an impact assessment.
- 60 more from the first transfer to file the cross-border one.
- Six months to carry any change into either file.
- 72 hours to report a breach.
- 24 hours to say your systems were attacked, which is consumer law rather than data law and fires on its own trigger.
- Two working days to acknowledge a data subject request, 10 to answer one for access or correction, 20 to complete a deletion.
The six months point is one that is often misunderstood. The assessment is done once for the life of the business, so six months is the outside limit for carrying a change into the file. If nothing changes, then nothing is due. If something changes, then you have six months to update the file.
The deadlines are tight, but that's not what actually matters.
What matters shows up the first time a claims operation wants to put an AI vision model near its accident photographs. Now, photographic damage assessment still works. Severity triage from a first notice also works. Fraud signals from image analysis? You guessed it. It works. All three are available in this market today and working well.
Whether the model is good enough isn’t the question here. It’s not even the problem.
A claim photograph is the surest personal data an insurer holds
An image set in a motor claim file is typically very clear.
The plate is legible. Faces are often in frame, sometimes the claimant's and sometimes a passer-by's. Somewhere in the set there is usually a photograph of a document: a vehicle registration, an identity card, a signature, a repair order with a phone number printed on it. The EXIF carries GPS coordinates and a device identifier.
Under the new framework this matters more than it did before.
Health, biometric, location and financial data are sensitive personal data, so a claim involving bodily injury sits in the most protected category the law defines, and the small-entity exemption from the impact assessment does not survive contact with it.
Nor does that exemption survive scale, or the business you happen to be in. The grace period for small enterprises falls away once processing reaches 100,000 data subjects, and it does not apply at all to anyone providing data processing services.
Between those three tests, every insurer in this market is inside the regime, and so is every platform working for one.
There is a second obligation worth knowing about, because this reaches your customers rather than your lawyers. Where a breach involves location or biometric data, telling the Ministry is not enough. The affected people have to be told inside the same 72 hours, and the record kept for five years afterwards.

Sending that file to an insurtech vendor outside Vietnam is a cross-border transfer. It needs a lawful basis from the data subject, a transfer impact assessment filed within 60 days of the first transfer, and an update within six months regarding anything that changes. Five percent of prior-year revenue is the statutory ceiling on that band, not the going rate. Decree 330 has been in force since 19th August. It puts an ordinary assessment failure at 50 to 100 million dong.
So what can you do? You anonymise it. Blur the plate, drop the faces, strip the metadata, and send.
(Un)lawful behaviour
This is where two problems become one big problem.
Fraud-detection vision lives on exactly the traces removed. Compression artefacts, sensor noise, metadata consistency and edge behaviour around a plate are not incidental to the assessment. They are the assessment.
Published image-forensics research finds that detection techniques generally fail once an image has been through lossy recompression. Blurring a region and exporting the file is a re-encode plus a metadata strip.
Anonymise enough to send it, and the data is no longer verifiable. Send it intact, and you have made a cross-border transfer of sensitive personal data belonging to somebody who is not your data subject to give away. Ergo, you’ve broken the law.
So, between a rock and a hard place, what is our resolution?
The way out is architectural
Our intrepid developers have landed on a solution. We move the model to the data instead of the data to the model.
Trisilva runs a split-residency design for exactly this. All personal data sits inside Vietnam, hosted by a Vietnamese data centre operator as sub-processor. That covers every record belonging to a Vietnamese resident: every piece of processing that touches an individual, and every uploaded document, which in motor means inspection photographs, scanned forms and copies of identity papers.
Aggregate, non-personal processing runs on separate infrastructure. A gate inside the Vietnam tier strips or replaces the personal fields before anything goes over, and the keys that would reverse that never leave the country.
Applied to an insurtech vendor, the same shape gives you a deployment rather than a transfer. The detector runs in-country, inside infrastructure you control. The images never leave the environment. Only the result does.

Because nothing crosses, the arrangement is not a cross-border transfer at all. No transfer impact assessment to file for it. No five percent exposure on that axis. No separate consent to collect for sending anything overseas.
Be clear about what that does and does not buy you though. It removes one obligation completely but not the others.
You remain the controller, so your own impact assessment, breach notifications and answers to data subjects are still yours to make. No architecture moves a controller's duties onto a processor. If that is ever offered to you, it is not something the law allows.
The boundary is enforced by network and identity controls rather than by policy, so components on the aggregate side hold no route and no credentials to the personal-data store. That concentrates trust in one place that can be enumerated and tested during due diligence, instead of spreading it across a rule people have to remember. It is a checkable control, and that claim is narrower than structural safety.
Re-identifiability is the most contested question in this area. Our position is that aggregate data on the far side of that gate is not personal data under Law 91/2025, so no cross-border transfer arises. If a regulator disagrees with the assessment, the design has to change.
Four’s a party
The other thing the deadline lists leave out is who owes what.
A motor claim in this market rarely runs between one insurer and one policyholder. A manufacturer's service network supplies repair-operations data. A broker holds the mandate. Several carriers each hold part of the book and supply the claimant and policy data while a platform operates between them.
Those are different roles under the law and they carry different obligations. The party that decides why and how data is processed is a controller. The party operating the platform on their instruction is a processor. The party providing hosting underneath is a sub-processor.
A processor cannot consent on a controller's behalf, and this is the point frequently missed in practice: a platform holding claims data has no authority to hand it to a fourth party for a technology evaluation, however reasonable the evaluation is.
The data is not the platform's to share.
An NDA is not a lawful basis
This is the specific version of the same mistake, so it’s important to be clear because signing an NDA is often treated as a safety net to share confidential information under the auspices of the law.
An NDA protects commercial confidence between two companies. It gives you no lawful basis to process somebody else's personal data. The two documents answer different questions and only one of them belongs to the regulator.

The practical trap is a calibration sample. An insurtech vendor asks for a few hundred real images, unmodified, straight from the camera with metadata intact, so they can tune a threshold. It reads like preparation, it is often minuted as an agreed action, and somebody can execute it without asking anyone.
Read it again and carefully. Doesn’t it describe a bulk cross-border transfer of the most sensitive category of personal data in the least mitigated form available?
The line between calibrating a threshold and training a model sits with the insurtech vendor, not with you.
What to verify before committing
Our cross-border position rests on an assessment that could be challenged, and our own assessments are an adaptive, live piece of work rather than a finished one.
Not because the law refreshes on a timer, but because we keep moving the data path, and every move has six months to reach the file. It’s important to be honest here because whether it works or not, it’s the law we’re talking about. We have to work within it and apply solutions to those challenges.
So here are four questions for you to ask any insurtech vendor (including us):
- Can the insurtech vendor run in-country, in your infrastructure, and request it in writing. A verbal yes in a demo is common and costs the vendor nothing. So have a record of it.
- Ask for the sub-processor list and the processing country, for the hosted option and the in-country option separately. They might say they can’t, but if you don’t ask, you won’t know for sure.
- Check whether the data you send is used to train or improve the model, and where they draw the line between calibration and training. Then ask what deletion means for anything already learned.
- Confirm what the vendor owes you on a breach, and by when. If nothing in the contract obliges them to tell you fast enough for you to meet the 72 hour deadline, then that obligation has not moved to the vendor. It still falls on you.
Crossing the line
Let’s return to the deadline list for a moment: 60 days, 72 hours, and a 24 hour deadline that comes from a different statute altogether.
Those numbers are easy to find because everybody publishes them, and they are the part of compliance that fits inside a calendar.
The architecture is the part people tend to gloss over or omit. And that’s a problem because it quietly decides whether the calendar is needed.
An insurer that picks a vendor first and works out the data path afterwards meets the same wall eventually: a model that performs only on data it cannot lawfully receive.
From there, there are three ways out but unfortunately they aren’t very good choices.

You send the data anyway and put yourself in the cross-border band, the one that tops out at five percent of prior-year revenue. If you degrade the images, the evaluation proves nothing. Or you can rebuild the data path, which was always the answer, but now at the market price after negotiations are done and contracts signed.
So, make sure you settle the data path first. It’s more important to find someone who will run their model where your data already lives than who has the best model.
And let’s be clear. We’re not saying the current way of working is outdated. Photographic assessment still works. Triage still works. Nothing that happened on 1st January made the technology less useful, and nothing in the framework rules it out of a Vietnamese claims operation.
What changed was the order. Ask the four questions before the demo rather than after it. The answers will be the same either way.
What they cost you will not.