Article · June 17, 2026
Multi-brand group consent management: how to get it right
How to manage consent for multi-brand, multi-entity groups: separation, consolidated reports, access control, and evidence per PDPL.
Quick answer
What is multi-brand group consent management?
It is how a group controls the collection, storage, lookup, and proof of user consent for multiple websites, apps, brands, or member companies without mixing data between units.
A real example: the same group has 3 legal entities, 5 brands, 2 apps, and multiple lead forms. If a customer consents to receive emails from brand A, you cannot assume consent for brand B unless your notice and consent mechanism explicitly states this as required. Under the Personal Data Protection Law (Law 91/2025/QH15), businesses must manage consent by processing purpose and be able to prove that consent was collected properly. This law is expected to take effect on 01/01/2026, replacing Decree 13/2023/ND-CP.
Why do multi-brand groups easily “break consent”?
Here are 4 common mistakes:
- Sharing one database across multiple legal entities: it becomes unclear who is the data controller and who is allowed to access what.
- One checkbox for multiple purposes: asking for consent to advertising, partner sharing, and customer care in a single tick box.
- Not distinguishing brand from legal entity: the user sees the brand logo, but the legal responsibility belongs to another company.
- No logs as proof of consent: when asked “who consented, when, on which screen,” the business cannot answer.
This is not just a UX issue. If there is a complaint or inspection, the business must be able to prove who consented, to what, at what time, and under which notice. The enforcement authority is the Ministry of Public Security — Department of Cybersecurity and High-Tech Crime Prevention (A05).
How should a group separate consent data?
Separate along three layers: legal entity, brand, and processing purpose.
1) Separate by legal entity
Each member company should have its own identifier in the consent system: legal entity name, enterprise code, processing role, and the list of channels/websites/apps within its scope. This helps avoid confusion when there are consent withdrawal requests or audits.
2) Separate by brand
Users may interact with the brand, but the data must be mapped back to the legal entity that owns that brand. If a landing page shares infrastructure, the system must know which brand and which campaign the form is collecting consent for.
3) Separate by purpose
At minimum, separate: processing to deliver services, customer care, marketing via email/SMS/calls, intra-group sharing, and third-party sharing. Each purpose should have its own consent status. Do not use “agree to all” as the default.
| Management layer | What to store | Benefit | |
|---|---|---|---|
| Legal entity | company name, role, system scope | correctly identify the responsible party | |
| Brand | brand_id, collection channel, campaign | prevent mixing consent across brands | |
| Purpose | purpose_id, consent status, timestamp | easy to prove and withdraw consent within scope | |
| Evidence | IP, timestamp, notice version, source | reconciliation when there is a complaint |
How should consolidated reporting for the group be done?
Consolidated reporting does not mean pooling personal data in one place and erasing legal boundaries. Consolidate at the level of governance metrics: number of consents by brand, opt-in rate, number of consent withdrawal requests, number of active campaigns, and SLA for handling requests.
A practical model:
- Group-level dashboard: view the overview; do not allow exporting identifiable data unless necessary.
- Legal-entity dashboard: view detailed data for each company.
- Brand/marketing dashboard: only see the data needed to run campaigns.
If the group wants to report “group-wide,” standardize minimal fields such as brand_id, legal_entity_id, purpose_id, consent_status, consent_timestamp, source_channel. This allows the BI team to aggregate without breaking the compliance structure.
How to set access controls for both operation and safety?
Follow the least privilege principle: those who only need to view statistics must not download raw files; those running campaigns should only access lists that are authorized for the correct purpose.
Recommended roles:
- Group admin: set baselines; do not view detailed data without a business reason.
- Legal-entity admin: manage consent and handle requests within their company’s scope.
- Brand marketing: only use lists eligible to receive messages according to consent.
- Legal/Compliance: view logs, policies, notice versions, and change history.
- IT/DevOps: operate the system; do not use data for business purposes.
Note: all access should be logged for traceability. If a data leak occurs, the business must assess and notify of the data breach within 72 hours from discovery, as required.
Define the legal model:
list each legal entity, brand, website, app, and related processors.
Design a consent taxonomy:
create brand_id, legal_entity_id, purpose_id, consent_version, source_channel.
Separate consent screens:
give each purpose its own checkbox; avoid bundling marketing and data sharing into one.
Store proof of consent:
record the timestamp, notice content, policy version, IP/device, and the user action.
Set up access control:
grant by role, by legal entity, and by data-use purpose.
Build consolidated reports:
only consolidate governance metrics; do not mix data beyond what is necessary.
Audit regularly:
review forms, cookie banners, DSAR workflow, and consent withdrawal processes per brand.
What is a ready-to-use consent data structure?
You can start with a minimal schema as follows:
- consent_id
- user_id or anonymous_id
- legal_entity_id
- brand_id
- purpose_id
- consent_status
- consent_version
- consent_timestamp
- source_channel
- proof_url or proof_hash
- revoked_at
- revoked_channel
Example record:
- legal_entity_id: CTY_A
- brand_id: BRAND_X
- purpose_id: marketing_email
- consent_status: granted
- consent_timestamp: 2025-08-14T10:32:11+07:00
- source_channel: web_checkout
- consent_version: v3.2
FAQ on multi-brand group consent management
- Yes. Separate by legal entity first, then by brand and processing purpose to avoid mixing responsibilities and proof of consent.
- You can in terms of UI, but it must clearly show which brand/legal entity is requesting consent and for what purpose. Avoid vague bundling.
- No, if you only consolidate statistics and still maintain data boundaries by legal entity, brand, and purpose.
- That tool triggers obligations to notify, record, and manage consent under the regulations. If the setup is complex, have a lawyer review it.
When should businesses standardize early?
If your group has more than 2 legal entities, runs multi-channel marketing, or shares CRM/CDP/analytics across brands, you should standardize now. This reduces risk when the PDPL takes effect and avoids having to “patch” systems later. consent.vn can help with cookie banners, storing proof of consent, and DSAR workflows by legal entity.
Source: the Personal Data Protection Law (Law 91/2025/QH15), Decree 13/2023/ND-CP, A05 — thuvienphapluat.vn, bocongan.gov.vn
Get started — set up in 5 minutes.
Deploy PDPL solutions for your business?