Article · June 17, 2026
How do anonymization and pseudonymization differ under the PDPL?
Anonymization vs pseudonymization under PDPL, legal impact, when data is out of scope, and a checklist for Vietnamese businesses.
Quick answer
What is the difference between anonymization and pseudonymization under the PDPL?
In short: anonymization is making data no longer tied to a specific individual and not re-identifiable by reasonable means; pseudonymization is replacing direct identifiers with a code, token, or substitute key while retaining the ability to trace back. In PDPL compliance practice, pseudonymized data typically remains subject to personal data protection obligations.
A real-world example in Vietnam: an e-commerce company replaces a phone number with USR_10329 to analyze purchasing behavior. If it still keeps the mapping table USR_10329 ↔ 098xxxxxxx, that is pseudonymization. If it has permanently deleted all linkage keys, removed all attributes that enable re-identification, and there is no reasonable way to trace back to the individual, the data then has a chance to be considered anonymized.
When does data fall outside the scope of personal data under the PDPL?
Data only truly falls outside the scope when re-identifying the individual is no longer feasible by reasonable means. In other words, merely deleting names, masking phone numbers, or encrypting a column is not enough. You must consider the full context: mapping tables, auxiliary data, the ability to join with other datasets, and current technical capabilities.
Points to remember for SMEs and technical teams:
- If there is still a decryption key, mapping table, or token vault, the data is usually still pseudonymized.
- If you only remove direct identifiers but a set of attributes is still unique enough to “guess” the real person, the data may not be out of scope.
- If the data has been aggregated such that it cannot be traced back to individuals—for example, revenue reports by province/month with no per-user rows—it is more likely to be out of scope.
| Criteria | Anonymization | Pseudonymization | |
|---|---|---|---|
| Possibility of re-identification | Not possible by reasonable means | Possible via key/mapping table | |
| Applicability of the PDPL | May be out of scope if conditions are met | Usually still personal data | |
| Typical uses | Analytics, sharing, statistics | Risk reduction for internal processing | |
| Primary risk | Re-identification from auxiliary data | Leak of keys/mapping exposing identities | |
| Example | Aggregated reports with no per-user rows | Tokenizing email while keeping the linkage store |
What are the legal impacts of anonymization and pseudonymization?
The biggest impact is determining whether the data remains within the PDPL’s protection. If it is still personal data, the business must continue to have a valid legal basis for processing, limit purposes, ensure security, manage access, keep audit trails, and respond to data subject requests as required. If the data is truly anonymized, the compliance burden is significantly reduced because the data is no longer linked to individuals.
However, do not misunderstand “pseudonymization = exemption from compliance.” In real systems, pseudonymization is usually only a risk-reduction layer. You still must manage:
- access rights to the mapping table or token vault;
- segregation of dev/test/prod environments;
- encryption and access logging;
- retention periods;
- deletion processes when the purpose ends.
Example: the data team uses a copy of the production database to test. If they only replace names with random strings but keep emails, phone numbers, or internal identifiers that can be linked back, this is not anonymization. Treat this as personal data and apply appropriate controls.
What should businesses do to classify correctly?
Use a simple check before sharing, analyzing, or feeding data into AI/BI:
Identify direct identifiers:
list name, phone number, email, Citizen ID (CCCD), payment account, shipping address, IP, device ID, and other identifiers.
Check linkability:
see whether any mapping table, decryption key, token vault, or auxiliary data could bring you back to the individual.
Assess re-identification context:
consider third-party data, system logs, sales data, shipment history, to see whether “recognizing” someone is feasible.
Minimize to what’s necessary:
if you only need statistics, aggregate at group/month/region levels instead of keeping per-user rows.
Label and control access:
clearly classify “anonymized,” “pseudonymized,” “personal data,” apply role-based access, and log access.
Review periodically:
when new data is added or systems change, reassess because previously anonymized data may become re-identifiable later.
Can anonymization be used to share with partners or AI?
Yes, but only when anonymization is done correctly and you have assessed re-identification risks to a reasonable level. For pseudonymized data, treat it as personal data: sharing with vendors, advertising partners, AI providers, or outsourced teams still requires a legal basis, contractual terms, and security controls as required.
A common mistake is “removing the name before uploading to AI” but forgetting that prompts, attachments, or metadata still contain identifiers. If your system uses cookies, tracking, or attribution to link user behavior, make sure the cookie banner, consent evidence mechanism, and DSAR processes are aligned with your data classification.
FAQ on anonymization and pseudonymization under the PDPL
- Anonymization means individuals cannot be re-identified by reasonable means; pseudonymization replaces identifiers with codes/tokens but remains traceable via a key or mapping table.
- Generally yes. If it is still possible to trace back to an individual, the data should be considered within the PDPL’s protection.
- When data has been anonymized such that individuals cannot be re-identified by reasonable means, even when combined with available auxiliary data.
- Not automatically. If a mapping store or token reversal mechanism remains, this is typically pseudonymization, not anonymization.
Conclusion: don’t call it “anonymized” too soon
In PDPL audits, the key is not the technical label but the possibility of re-identification. If there is still a path back to the individual, treat it as personal data. Only when that possibility has been reasonably eliminated can data fall out of scope. For systems with analytics, CRM, ads, or AI pipelines, review with counsel and your technical team before rollout.
If you need to standardize the cookie banner, store consent evidence, or DSAR flows for pseudonymized/anonymized data, consent.vn can help you design streamlined, operable processes.
Source: the Personal Data Protection Law (Law 91/2025/QH15); Decree 13/2023/ND-CP; Ministry of Public Security (A05) — thuvienphapluat.vn, bocongan.gov.vn
Get started — no account needed.
Ready to comply with PDPL?