Guide · June 17, 2026
Consent SDK for enterprise iOS/Android apps: how to implement
Guide to Consent SDK for enterprise iOS/Android: block ad SDKs pre-consent, sync across devices, and keep valid evidence.
Quick answer
What is the Consent SDK for enterprise iOS and Android apps?
The Consent SDK for enterprise iOS/Android is an in-app consent control layer that only allows non-essential SDKs to run after the user has explicitly chosen as required. For enterprise apps, it typically has to do three more things: gate the initialization of ad SDKs before consent, record proof of consent, and synchronize consent status by user ID across multiple devices.
Why do enterprise apps need to block ad SDKs before consent?
Because in enterprise apps, a single early initialization of an advertising or measurement SDK can trigger the collection of device data, behavior, advertising identifiers, or usage events before the user can make a choice. Under PDPL, businesses need appropriate notice and consent mechanisms and should only process data when there is a valid legal basis. If the app has many SDKs pre-embedded by the product team, “accidental runs” usually happen right at app launch, not on a settings screen.
A real example: an internal app for employees to book business trips, but analytics and remarketing SDKs still auto-init when the app opens. If there is no clear consent and the SDK has already sent events to third parties, the business will struggle to explain the scope of collection and purposes of processing during an audit.
What should the Consent SDK block on iOS and Android?
Short answer: block all SDKs that are non-essential to core functionality before consent. Commonly includes advertising, attribution, advanced analytics, non-mandatory crash reporting, A/B testing, and SDKs that share data outside your system. “Essential” components like login, security, payments, fraud prevention, or session persistence may fall under necessary processing, but should still be reviewed for their specific purposes.
| SDK group | Can initialize before consent? | Practical notes | |
|---|---|---|---|
| Auth / session / security | Yes, if truly needed for the service | Use only for core operations | |
| Ads / attribution | No | Enable only after user consent | |
| Behavioral analytics | Usually no | Put after consent or run in minimal mode | |
| Crash reporting | Config-dependent | Disable unnecessary payloads before consent | |
| Feature flags / experiments | Purpose-dependent | If personal data is involved, assess need for consent |
How do you implement the Consent SDK for enterprise iOS and Android apps?
Design with a “default off, explicit on” flow: when the app opens, do not initialize non-essential SDKs; display the choice screen; store the decision; then enable the corresponding SDKs. This is easier to control than trying to “undo” an SDK after it has already sent data.
Classify SDKs by purpose:
list all SDKs in iOS/Android, label essential, analytics, ads, marketing, crash, experiments.
Decouple initialization from app launch:
do not init ad SDKs in `Application.onCreate`, `AppDelegate.didFinishLaunching`, or global constructors before consent exists.
Create a central consent state:
store status by user/account, for example `consent_ads=true`, `consent_analytics=false`, with timestamp and notice version.
Block network calls before consent:
use wrappers, feature gates, or lazy init so SDKs only turn on after a valid state.
Multi-device sync:
when a user signs in on a new device, pull the consent state from the backend by account; if it has changed, update the status on all related devices.
Store consent evidence:
store notice version, timestamp, locale, device, and a hash of the consent content to support internal audits and demonstrate compliance.
Provide a clear revoke button:
allow users to change choices in-app; upon withdrawal, stop the corresponding processing and update the backend.
How should multi-device consent state be synchronized?
With enterprise apps, a user may sign in on a work phone, a tablet, and a personal device. If consent is stored only locally on one device, states will diverge: device A has consent, device B still treats it as absent. The right approach is to use the backend as the source of truth, binding consent to the account or tenant, then synchronizing on login, profile changes, or when the user updates preferences.
Points to note:
- Consent should be tied to a specific notice version, not just “previously consented”.
- If you change processing purposes or add new SDKs, request consent again as required.
- In multi-tenant environments, separate consent by tenant if policies differ.
- If the app works both online/offline, cache the last state but refresh upon reconnect.
What evidence should be stored to meet PDPL?
At a minimum, businesses should store: the time the user accepted or refused, notice version, categories of purposes, collection channel, internal user ID, device, IP address if permitted by policy, and a log of consent changes. For enterprise apps, this is critical operational data to answer DSARs, handle internal disputes, or pass compliance checks.
If a personal data breach occurs, the business must quickly assess impact and notify of the data breach within 72 hours of discovery as required. Serious violations may be subject to sanctions under the guiding decree and, in special cases, could incur criminal liability.
Technical checklist for the mobile team
- Do not init ad/analytics SDKs before the consent screen.
- Have a shared consent store for both iOS and Android.
- Provide a backend API to sync state by account.
- Provide a mechanism to revoke consent and reconfigure SDKs.
- Maintain logs/audit trails for grant and changes of consent.
- Provide a policy screen that clearly states processing purposes.
If you are designing a cookie banner, storing consent evidence, or DSAR for an enterprise app, consent.vn can be a starting point to standardize this flow before going to production.
- It may still be needed if the app collects or shares personal data and includes third-party SDKs. “Internal use” does not automatically exempt obligations under the regulations.
- Not recommended. If the SDK sends data before consent, it will be hard to prove compliant processing. Use lazy init or block it entirely before consent.
- The law doesn’t use that exact term, but for enterprise apps with multi-device sign-in, synchronization is a practical measure to keep consent state consistent with regulatory requirements.
- Stop the corresponding processing, update the backend, and reconfigure SDKs. If data has already been collected, the business should review retention purposes and legal bases for continued processing as required.
Source: the Personal Data Protection Law (Law 91/2025/QH15), Decree 13/2023/ND-CP: thuvienphapluat.vn; Ministry of Public Security (A05): bocongan.gov.vn
Get started — set up in 5 minutes.
Deploy PDPL solutions for your business?