Guide to building a PDPL-compliant cookie preference center

What is a cookie preference center under the PDPL?

It is an interface for users to grant, manage, and withdraw consent by purpose/cookie group. Under the PDPL, processing non-essential data for analytics/marketing requires prior, specific consent that can be withdrawn at any time, and businesses must be able to prove it (logs).

• A center typically includes: group toggles (Necessary, Analytics, Ads/Marketing, Functional/Personalization), purpose descriptions, a list of vendors, and a Save settings button.
• Cookies necessary for core services (e.g., cart, login) may be on by default; other groups default to off until consent is given.

What are the minimum legal requirements when building a cookie preference center?

Ensure valid consent and users’ rights under the PDPL. Specifically:

• Prior consent for non-essential processing, no pre-ticked boxes, separated by purpose/group; plain language stating who collects, purposes, data types, and third parties.
• Withdrawal must be as easy as giving it (a single click on a “Cookie settings”/“Withdraw consent” link in the footer or a floating icon), taking effect on subsequent page loads.
• Do not load analytics/advertising tags/SDKs before the corresponding group is enabled. Honor choices across all pages, and be consistent across subdomains (if you state as such).
• Store evidence of consent: time, policy version, state of each group, anonymous/pseudonymous identifier; store only the minimum necessary.
• When purposes change or new vendors are added, obtain consent again for the affected group.
• Fulfill data subject requests (DSAR): let users review their choices, export consent records, and delete marketing data when consent is withdrawn.
• Data breaches: notify within 72 hours from discovery; sanctions per the implementing decree, and serious violations may be subject to criminal liability.

How should you design the banner UX and the cookie preference center?

Provide fair choices, avoid “dark patterns,” and make the center accessible at all times.

• First-visit banner: three equally weighted options “Accept all”, “Reject all”, “Customize”. Buttons/borders/colors must not be biased.
• Preference center: concise descriptions for each group, a list of common vendors (e.g., Google Analytics, Meta Pixel — note the obligations this entails rather than declaring legality/illegality), and links to the full cookie/privacy policies.
• Persistent entry point: a “Cookie settings” link in the footer or a floating icon so users can review and withdraw consent at any time.
• Available on mobile, supports keyboard and screen readers (ARIA) to avoid discrimination.

How do you technically implement per-group toggles and consent logging?

Apply a “prior blocking” strategy and minimal, secure consent logging.

• Label each tag/SDK by group: Necessary, Analytics, Ads/Marketing, Functional. By default, run only the Necessary group.
• Block loading before consent: use a wrapper for your tag manager or a homegrown “consent mode” (register scripts into a queue and only execute when the group’s toggle is on).
• SPA/SSR: listen for state changes on each route transition and re-apply tag controls.
• Domain/subdomain sync: store state in a first-party cookie or localStorage with the appropriate domain; consider server-side storage to share across subdomains.
• Store consent evidence (server): create a pseudonymous “consent_id”, along with timestamp, policy version, group states, inferred country (if needed for routing), and proof the banner/center was shown. Avoid storing full IPs; truncate/hash if needed.
• Periodic renewal: re-prompt after X months or when purposes/vendors change; don’t spam re-prompts if the user has recently refused.

Suggested group descriptions to paste into the center:

• Necessary: Basic operations (login, cart). Cannot be turned off.
• Analytics/Statistics: Measure traffic and interactions to improve the product.
• Advertising/Marketing: Personalize and measure ad performance on third-party platforms.
• Functional/Personalization: Remember preferences and enhance the experience.

Updates, withdrawal and DSAR: how do users review and withdraw consent?

Always keep an entry point to the center (footer/icon). Users can:

• Open the center, turn group toggles off, and Save settings. The system immediately stops tags, deletes related cookies, and records the time of withdrawal.
• Submit a DSAR (access/deletion for marketing data). Provide a form with a consent_id or an email verification mechanism (if already collected) as required.
• If a consent log (personal data) is breached, you must assess risk and notify the competent authority within 72 hours; consider notifying users if risk is high. Administrative penalties will follow the Government’s implementing decree; serious cases may be subject to criminal liability.

Additional notes for developers:

• Server-side tagging and proxies must still honor the consent state; don’t “impute” default consent on the server.
• Mobile apps: use SDKs with similar consent mechanisms, synced with the in-app center; iOS/Android must also comply with platform policies.
• Do not declare any tool unlawful; obligations depend on purpose and implementation. When situations are complex, consult a lawyer.

If needed, consent.vn supports cookie banners, preference centers, consent-evidence logging, and DSAR for Vietnamese SMEs.

Source: the Personal Data Protection Law (Law 91/2025/QH15) (https://thuvienphapluat.vn/van-ban?keyword=91/2025/QH15); Decree 13/2023/ND-CP (https://thuvienphapluat.vn/van-ban?keyword=13/2023/NĐ-CP); Ministry of Public Security (A05) (https://bocongan.gov.vn)