Template · June 17, 2026
PDPL Personal Data Classification Template
PDPL personal data classification template: sensitivity levels, examples, and safeguards for Vietnamese businesses.
Edit & copy
This is a reference template. Consult a legal advisor before using in production.
Quick answer
What is the PDPL personal data classification template?
This template is an internal table used to list the personal data the business is collecting, group it by sensitivity level, provide real-world examples, and define the safeguards to apply. For SMEs, this is a foundational step before implementing a cookie banner, a privacy policy, DSAR management, and consent logging.
Ready-to-use template
| Data group | Sensitivity level | Data examples | Key risks | Minimum safeguards | Responsible person/unit |
|---|---|---|---|---|---|
| Basic identifiers | Low | Full name, phone number, email, delivery address | Spam, contact details exposure | Access controls, encryption in transit, access logs | Customer Support / IT |
| Account data | Medium | Username, password hash, login history | Account takeover | Strong hashing, MFA, rate limiting, anomalous login alerts | IT / Dev |
| Transaction data | Medium | Orders, payment amounts, purchase history | Exposure of consumption patterns, fraud | Data minimization, role-based access controls | Accounting / Product |
| Location data | Medium | Delivery location, app GPS | Behavior tracking, inferring itineraries | Collect only when needed, clearly disclose purpose, limit retention | Product / Mobile team |
| Sensitive data | High | Health, biometrics, political opinions, children’s data, detailed financial information as defined by regulations | Serious invasion of privacy | Limit collection, conduct impact assessments, tight controls, strong encryption, internal approvals | DPO / Legal / IT |
| Internal system login data | Medium to high | API tokens, integration keys, secrets | System exposure, large-scale data compromise | Secrets management, vaulting, key rotation, environment separation | DevOps |
What sensitivity levels make sense for classification?
You should split at least 3 levels: low, medium, and high/sensitive. The goal is to make operations practical, not to “look good on paper.” An email a customer uses to place an order is very different from an employee’s health data; both are personal data, but they cannot be protected at the same level.
| Level | When to use | Examples | Safeguards | |
|---|---|---|---|---|
| Low | Common data, low harm if exposed | Full name, email, phone number | Limited access, encryption in transit, secure storage | |
| Medium | May cause nuisance, fraud, or inference of behavior | Purchase history, IP, location | Role-based access, logging, alerts, retention policy | |
| High/sensitive | Could cause serious harm if exposed | Health, biometrics, children, sensitive financials per regulation | Limit collection, separate approvals, strong encryption, periodic reviews |
What columns should the classification table include?
A good template should be usable by the operations team and need not be overly academic. At minimum include: data name, description, source of collection, purpose of use, sensitivity level, legal basis, storage location, retention period, person responsible, safeguards, and review status.
Inventory all data touchpoints:
aggregate from signup forms, checkout, apps, CRM, HR, cameras, call center, email, and cookies/SDKs.
Label sensitivity levels:
classify according to impact if leaked; the more “harmful” the data, the higher the level.
Record purposes and legal bases:
specify what the data is used for; if consent exists, you must be able to retain proof.
Select corresponding safeguards:
access control, encryption, data masking, access logs, DLP, backups, deletion procedures.
Review periodically:
update when there are new products, new integrations, new vendors, or process changes.
Practical examples for Vietnamese businesses
A small e-commerce marketplace typically has 4 main groups: customer data, order data, payment data, and operational data. Customer emails and phone numbers may be low; order history may be medium; payment tokens or identity data used for authentication may require stricter protection under regulations. If you use chatbots, pixels, or advertising SDKs, clearly record what data is collected, who receives it, how long it’s stored, and whether it is shared with third parties.
For an HR company, candidate profiles often include national ID (CCCD), education, and work experience; if health or family data is present, classify it at a higher level and restrict viewing rights. For apps with location, separate “when using the app” and “background” location; collect only when needed, not by default.
What should businesses watch out for to avoid risks when classifying?
Classification only matters when tied to enforceable measures. Under the Personal Data Protection Law (Law 91/2025/QH15), businesses must manage data by purpose, minimize it, protect it, and be ready to explain. If an incident occurs, businesses must notify of a data breach within 72 hours of discovery as required. Specific penalties will be set by the Government’s guiding decree; serious violations may be subject to criminal handling.
A common mistake is marking “all data is confidential” or, conversely, “everything is open to the team.” Neither is acceptable. Classify with enough detail so DevOps knows which secrets need a vault, Customer Support knows not to export the entire CRM, and Legal knows which records need closer review.
If your business needs to implement a cookie banner, store consent evidence, or a DSAR process, consent.vn can help standardize from template to operations.
- The law does not require a single prescribed template, but businesses should maintain an internal classification table to show they manage data by risk level and processing purpose as required.
- Typically health data, biometrics, children’s data, sensitive financial data, and other categories requiring strict protection under applicable law.
- Yes. If you receive data from partners, you still must know what it is, how sensitive it is, what the purpose is, and whether there is a valid legal basis for processing.
- Review when there are new products, new integrations, vendor changes, market expansion, or at least on a regular internal cycle.
Source: the Personal Data Protection Law (Law 91/2025/QH15); Decree 13/2023/ND-CP: https://thuvienphapluat.vn; Ministry of Public Security (A05): https://bocongan.gov.vn
Access the full template library — no account needed.
Need more PDPL templates?