Guide · June 17, 2026
How should a PWA handle PDPL consent for cache, push, and offline?
Guide to PDPL consent for PWAs: service worker cache, push, offline consent storage, 72-hour breach notice, and evidence logging.
Quick answer
What is PDPL consent for PWA progressive web apps?
This question is essentially: when a PWA uses service workers, cache, push, or stores consent state offline, what must a business do to comply with the Personal Data Protection Law (the Personal Data Protection Law (Law 91/2025/QH15), expected effective 01/01/2026).
With PWAs, data may be processed even when the user is not visiting the website in the traditional way. Examples include caching content, storing login tokens, sending notifications, and recording consent choices to sync when back online. These activities may trigger obligations to notify, obtain consent, limit purposes, and ensure users can withdraw consent as required.
The key point: not every cache or tracker is “banned”; the issue is what obligations the tool triggers and whether you can prove validity. When in doubt, cross-check against the regulations and consult a lawyer.
Does a service worker cache in a PWA require consent?
Possibly, if the cache relates to personal data or tracks user behavior.
PWA caches are commonly used to speed up page loads, enable offline, or store app shell assets. If you only cache anonymous static files such as logos, CSS, or public JS, the legal risk is lower. But if you cache personalized HTML, search history, shopping cart, user identifiers, or content from which a personal profile can be inferred, you should treat this as data processing.
In practice, SMEs often make mistakes such as:
- caching responses containing names, emails, or phone numbers;
- keeping sensitive data in the cache for too long;
- lacking a mechanism to clear caches when the user withdraws consent or logs out;
- failing to explain that the app may work offline and store data locally.
A safer approach is to classify caches by purpose—public cache, personal cache, sensitive cache—then define TTL, scope, and how to delete when the purpose expires.
List the types of data in cache:
determine whether the cache stores static files, personal data, or sensitive data.
Attach processing purposes:
state clearly whether caching is for speed, offline support, or personalization.
Block unnecessary sensitive data from being cached:
avoid storing tokens, profiles, or transaction histories unless strictly needed.
Design a data deletion control:
when users log out, withdraw consent, or delete their account, the service worker must clear related caches.
Record evidence:
log the timestamp, banner version, consent wording, and the user’s actions.
Do push notifications in a PWA require separate consent?
Usually yes, because push notifications are a proactive communication channel and may involve personal data.
If you use push for promotions, cart reminders, order updates, or re-engagement, separate consent for each purpose. Consent to “use the app” does not equal consent to “receive marketing push.” Users must understand what they are agreeing to and be able to refuse each notification type.
A real-world example in Vietnam: a retail app requests “allow notifications” as soon as the app opens. If it then sends OTPs, order updates, and flash-sale ads, these should be separated into three flows: necessary notifications, transactional notifications, and marketing notifications. The marketing flow should have a clear opt-in.
In practice, you should record:
- the time push was enabled;
- the consent wording presented;
- the privacy notice version;
- opt-in/opt-out status by notification type.
What should you watch out for when storing consent offline in a PWA?
A lot. Offline consent storage is useful but avoid turning the user’s device into a repository of ambiguous, unsynced, hard-to-control evidence.
PWAs often store consent state in IndexedDB, localStorage, cache, or a sync queue. This helps the app work when offline but also introduces risks: stale consent persists after a policy change; shared devices show incorrect state; or the app syncs the wrong consent from another session.
Safety principles:
- store only the minimum needed to prove consent;
- attach timestamp, policy version, and purpose code;
- when the policy changes, request consent again for new purposes;
- sync to the server as soon as possible;
- do not use offline data to infer intentions beyond the disclosed purposes.
| Item | Do | Don't | |
|---|---|---|---|
| Cache | Only store data needed for offline/speed | Cache entire responses with identifiers when unnecessary | |
| Push | Separate transactional and marketing notifications | Combine all notifications under a single “Agree” button | |
| Offline consent | Store version, timestamp, purpose | Store only a true/false boolean with no context | |
| Withdraw consent | Clear caches and stop push by purpose | Only change the UI while the backend still sends |
What should businesses prepare for PWAs under the PDPL?
Start from the technical architecture, not just the banner.
Minimal checklist for SMEs and dev teams:
- a data map for the PWA: caches, push tokens, device IDs, analytics, form inputs;
- a short, clear privacy notice stating purposes;
- a consent mechanism per purpose;
- a prominent withdraw-consent control;
- a process to delete local and server-side data;
- consent evidence logs;
- vendor controls: push provider, analytics, CDN, service worker scripts;
- an incident response process and data breach notification within 72 hours of discovery.
The enforcement authority is the Ministry of Public Security — Department of Cybersecurity and Prevention of High-Tech Crime (A05). Specific penalties will be set by the Government’s guiding decree; serious violations may be subject to criminal liability.
How to implement a consent banner for a PWA without breaking UX?
Use a concise banner, separate purposes, and do not block the entire experience unless necessary.
Example structure:
- “Accept all” button;
- “Preferences” button;
- a dedicated item for “Store data for offline use”;
- a dedicated item for “Receive push notifications”;
- a brief description of what data is stored, for how long, and for what purpose.
If you need to store evidence of consent, the system should capture it server-side with a consent version. consent.vn can help if you need a cookie banner, consent evidence storage, or DSAR flows for web apps/PWAs.
- Yes. PWAs also have service workers, offline caches, and push, so beyond the banner you must control locally stored data and consent evidence.
- Not in all cases, but if caching serves personalization, tracking, or stores identifiers, assess under the rules and typically disclose the purpose clearly.
- You should not rely only on localStorage. Maintain server-side logs with timestamps, policy versions, and a sync mechanism to prove consent when needed.
- They should be separate. Transactional and marketing notifications have different purposes, so provide clear choices and easy withdrawal per purpose.
Source: the Personal Data Protection Law (Law 91/2025/QH15) and Decree 13/2023/ND-CP at thuvienphapluat.vn; enforcement authority A05 at bocongan.gov.vn
Get started — set up in 5 minutes.
Need help with PDPL compliance?