The First Question Is Legal, Not Technical
When you run several brands or domains, the instinct is to ask "how do I sync consent across them?" Wrong first question. The one that decides everything is: who is the data controller for each property? Under the GDPR, the controller is whoever determines the purposes and means of processing, and it's the entity that owes the obligations to the visitor. Two brands under one holding company can be two separate controllers, or a joint-controller arrangement, or a single controller with several sites. The EDPB's guidelines on controllers and processors lay out how to work this out.
Get this answer first, because it dictates whether consent can flow between your sites at all. Sharing a consent record across two separate controllers means one entity is relying on a choice a visitor made with a different entity, which usually isn't valid.
Share or Isolate: The Decision
Once you know the controller boundaries, the sharing question answers itself:
- Same controller, multiple domains (for example a company running
brand.comandbrand.co.ukas one legal entity). You can share consent across them, and you probably should, so visitors aren't re-prompted on each. This is a genuine multi-domain sync. - Separate brands or entities under one group. Each is its own controller, so each collects its own consent, keeps its own record, and shows its own banner naming that brand. You manage them from one place, but the consent doesn't cross the boundary.
- Uncertain or mixed. If a shared login or data platform spans brands, you may have joint controllers, which needs an arrangement defining who does what. Don't paper over it with a shared cookie.
The technical mechanism for the first case (parent-domain cookies, postMessage bridges, server-side sync) is its own topic, see cross-domain consent sharing and the implementation patterns.
Structuring a multi-property setup
Inventory every property
List all domains and brands, and for each, run a cookie audit. Different brands often load different trackers, so a shared config rarely fits all of them.
Draw the controller boundaries
Mark which properties share a controller and which don't. This line is where consent can and can't be shared. Write it down, it's the basis of your whole structure.
Use one account, many configs
Manage every property from a single CMP account, but give each its own banner configuration, category set, and consent store. One dashboard, isolated records where the law requires isolation.
Theme and domain each banner per brand
Each brand's banner should carry that brand's look and name its own entity in the text. Reusing brand A's banner copy on brand B misidentifies the controller. See customizing the banner.
Apply regional rules per property
Each property still needs to adapt to the visitor's region (opt-in in the EU, opt-out in US states). A region-aware engine handles this per site, see one banner across a global audience.
Keep consent records separate where controllers differ
Store each controller's consent independently so an audit or a data subject request for one brand doesn't pull another brand's records. Logging requirements are in consent logging and audit requirements.
When Sharing Consent Is Fine, and When It Isn't
Sharing is legitimate when the same controller operates multiple domains and the visitor is, in substance, dealing with one organization. A visitor who accepted analytics on your .com shouldn't have to repeat it on your .de if both are the same entity with the same purposes. That's good UX and it's compliant.
Sharing breaks when the brands are distinct controllers, when the purposes differ, or when the visitor wouldn't reasonably expect their choice on one brand to bind another. In those cases each property earns consent on its own. The safe default: share within a controller, isolate across controllers, and never let a shared consent cookie quietly substitute for a choice the visitor never made on that brand.
One more trap: a shared analytics or advertising platform across your brands can turn you into joint controllers even when the front-end sites look independent. If brand A's pixel and brand B's pixel feed the same ad account, regulators may treat the consent as linked, so map your back-end data flows, not the domains alone, before you decide what's isolated.
If You're an Agency, Not a Brand Owner
Managing consent across clients you don't own is a related but different problem, because there each client is the controller and you're often the processor. The account structure (one dashboard, isolated per client) is similar, but the contracts and liability differ. That's covered separately in cookie consent for agencies.
Multi-brand consent checklist
Controller identity is documented per property
You know which brands share a controller and which don't.
Consent is shared only within a single controller
Never across separate controllers or brands.
Each brand's banner names its own entity
The text identifies the correct controller.
Every property has its own audited category set
Different brands load different trackers.
Consent records are isolated across controllers
One brand's audit or DSAR doesn't expose another's.
Regional rules apply per property
Each site adapts to the visitor's jurisdiction.
Joint-controller arrangements are defined where they exist
Shared logins or data platforms need an explicit agreement.
One Dashboard, Many Boundaries
The operational goal is a single place to manage every property, and clean legal boundaries between them. A CMP that supports multiple banner configurations, per-property consent stores, and region-aware rules gives you both. Start from the cross-domain sharing guide for the same-controller case, and keep separate controllers genuinely separate.