PDPL purpose limitation: use only as notified—when is further use allowed?

What is the "purpose limitation principle for data processing" under the PDPL?

The principle: collect and process data only as correct and sufficient for the purposes transparently disclosed to the data subject. You must not unilaterally broaden or switch purposes unless you meet the corresponding legal conditions (notification, supplementary consent, or falling within a statutory exception). This applies to both data you collect directly and data you receive from third parties.

• Purposes must be specific, lawful, and easy to understand (avoid vague phrases like "improve the experience" if what lies behind it is behavioral advertising).
• The processing scope must be necessary for that purpose; avoid hoarding data just in case.
• When changing purposes, you must assess compatibility and update documentation, permission/consent interfaces, as well as technical systems.

When can data be used for other purposes (further processing)?

There are three common situations:

• Same purpose or a compatible ancillary purpose already notified: you may proceed if you can demonstrate compatibility (the nature of the relationship, users’ reasonable expectations, privacy impact, data type, and additional safeguards).
• Different purpose: you will typically need to notify again and obtain clear, separate consent before the new processing.
• Statutory exceptions: no additional consent is required in certain cases provided by law, e.g., to fulfill legal obligations; to protect life and health in emergencies; to comply with lawful requests from competent state authorities; research and statistics using anonymized data. Cross-check the implementing decree and sectoral laws; consult counsel for uncertain claims.

How to assess “compatibility” with the original purpose?

You need to reasonably demonstrate that the data subject could expect the new processing from the original purpose. Suggested criteria:

• Relationship and collection context (B2C, B2B, internal).
• Data type (sensitive or not), degree of privacy impact.
• Reasonable link between the old and new purposes (e.g., fraud prevention versus cross-selling).
• Additional safeguards: anonymization/pseudonymization, access limits, shorter retention.

If in doubt, treat it as a different purpose and obtain additional consent.

What should devs/SMEs do to comply when expanding purposes?

You should design “purpose” as a controllable technical attribute, not just policy text.

Vietnam examples:

• An e-commerce marketplace wants to use order data to run lookalike ads: requires separate marketing consent; otherwise use only anonymized data for statistical analysis.
• Fintech fraud detection: may be a compatible purpose aligned with system security; apply data minimization and log the compatibility assessment.
• Internal HR wants to reuse applicant profiles for a sales campaign: different purpose; requires new consent before transferring systems.

What if you don’t comply? Do you have to report breaches?

• Under the PDPL, administrative penalties will be detailed in an implementing decree; serious violations may be criminally prosecuted. Don’t wait for the penalty decree to retrofit your systems.
• If a data breach occurs (e.g., leakage due to poorly controlled purpose expansion), the business must notify within 72 hours of discovery as required.
• The enforcement authority is the Ministry of Public Security (A05). Prepare purpose records, consent evidence, and access logs for inspection readiness.

What to watch for when relying on a “statutory exception”?

• Apply only within scope and with substantiation: legal texts, lawful requests from competent authorities, emergencies with evidence, or anonymized data for research/statistics.
• Record the decision, time, approver, and legal basis.
• Review immediately once the exceptional conditions end; revert to the normal consent process if you wish to continue.
• If uncertain, seek independent legal advice.

One line for product/dev: Expanding purposes always comes with operational costs (consent UI, data separation, logging, DSAR). Optimizing early at the architecture level reduces risk and rework later.

Need a cookie banner manager, consent evidence storage, and a DSAR portal? consent.vn helps SME/dev teams implement quickly, in line with the PDPL.

Source: the Personal Data Protection Law (Law 91/2025/QH15) – https://thuvienphapluat.vn; Decree 13/2023/ND-CP – https://thuvienphapluat.vn; A05 Department, Ministry of Public Security – https://bocongan.gov.vn