Law-firm explainers cover the statute; none of them cover your app's location prompt
Most English-language coverage of this topic stops at the statute. Law-firm explainers and market-entry advisories get the legal summary right — consent has to be explicit, the rules changed — but none of them go on to say which screen in a field sales app actually needs to change because of it.
Some of what's circulating is also just outdated. Decree 13/2023 governed personal data protection before it was superseded; from January 1, 2026 the operative framework is Law No. 91/2025/QH15 — the Personal Data Protection Law, passed and officially announced in June 2025 — together with its implementing Decree 356/2025/NĐ-CP. Enough English content still cites Decree 13 as current that it's worth checking any compliance document you've been handed against that date before trusting it.
Location consent needs its own explicit prompt, not a line inside general terms
The new law requires consent that's explicit, verifiable and traceable — not implied, and not satisfied by an opt-out. For a field app, that means the first time it requests a rep's location, it needs a standalone prompt explaining why: route verification, visit proof, safety — not a clause folded into a general terms-of-service screen tapped through once at onboarding.
"Explicit and verifiable" also means the app has to record that consent happened — who, when, and which version of the prompt they saw — not just proceed once a checkbox is ticked. If a rep or a regulator ever asks whether consent was actually given, the answer needs to come from a log, not from memory.
- A standalone prompt the first time location is requested, not a clause inside general terms
- A record of who consented, when, and to which version of the prompt
- No default-on tracking and no opt-out-only design — implied consent isn't sufficient under the new standard
Every lead needs a traceable source, not just a name and a phone number
The list a field team works from is personal data with its own provenance requirement. Each entry needs a traceable source — which visit, which referral, which public listing it came from, and when it entered the system. A list that's just names with no origin field is the kind of gap that's easy to ignore until someone specifically asks where a contact came from.
This matters more the moment a list gets merged from multiple sources or brought in from a third party. Whatever field app sits behind the list needs to carry that source field forward through the merge, not drop it the moment a record gets imported — the traceability requirement doesn't go away just because the record changed hands.
Rep data and customer data are two different data subjects, not one bucket
A field sales app collects two categories of personal data at once: the rep's own location and activity, and the customer's contact and visit details. They have different legal bases for collection, different retention logic, and often a different set of people who should be allowed to see them — but most field apps store both in the same visit record and apply one blanket policy across it.
Splitting them means separate consent flows: one for the rep as an employee tracked for work purposes, one for the customer as an outside contact engaged for a business relationship, and being able to answer, for each independently, what was collected, why, and how long it's kept.
None of this is legal advice, and it isn't meant to be. It's the engineering translation of what the statute requires — the actual consent wording and retention schedule still need sign-off from local counsel before any of it ships.