Does Didomi Work in China? EU-Hosted Consent, PIPL Cross-Border & the Consent-Regime Gap
Didomi is a consent & preference management platform — yet its own sub-processor list hosts its consent, preference and DSAR data in the EU (Frankfurt, Germany), with no mainland-China region. For China that turns the consent records it keeps for your users into a cross-border transfer under PIPL, with no ICP-filing footing and no in-country storage — and a GDPR-built consent flow doesn't by itself meet PIPL's separate-consent regime. A compliance-first look at the data-residency and consent exposure, and the lawful in-country path.
Does Didomi work in China?
The irony is the answer: Didomi is a consent and preference platform that, run as-is for mainland China, can become a compliance exposure of its own. Reaching the banner isn't the problem — where it keeps your Chinese users' consent records, and which law its consent was built for, are.
Didomi's own sub-processor list (updated July 2026) puts its hosting in the EU: AWS "Data centers located in the European Union (Frankfurt, Germany)," and Snowflake servers "located in the AWS eu-central-1 region (Frankfurt, Germany)" for client analytics — no mainland-China region. So every consent record, preference and data-subject request it captures from a Chinese visitor is personal information held offshore — a cross-border transfer PIPL governs (notice, a separate consent and a transfer mechanism, Articles 38–40), with an in-country storage duty for a CIIO or large-volume handler (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). On top of that, Didomi's consent is built for the GDPR regime — which China's PIPL does not mirror — so a GDPR- or TCF-style opt-in does not by itself meet PIPL's separate, specific consent. The banner is also fetched from offshore, so from inside China it can load slowly or fail — and a consent gate that can't load can hold up the page it guards.
This is a risk map, not a verdict — what you owe turns on your data volumes, your role as handler and who your users are, and it's worth settling with counsel. Our China team can map your exposure with you →
What Didomi's own documentation says about China
| Fact | Primary source |
|---|---|
| Didomi hosts its consent, preference and DSAR data in the EU — not China. Its own sub-processor list (updated July 2026) states that its AWS hosting sits in "Data centers located in the European Union (Frankfurt, Germany)" for the raw data of its CMP, PMP and DSAR services. For a consent platform that is the point in reverse: the record proving a Chinese user consented is itself personal information held offshore — a cross-border transfer of personal information under PIPL (notice, separate consent and a transfer mechanism, Articles 38–40). | Didomi — Our sub-processors as a data processor, retrieved 2026-10-09; PIPL Articles 38–40 |
| Client data and analytics also sit in Frankfurt — still no mainland-China region. The same sub-processor list states that "The Snowflake servers used by Didomi are located in the AWS eu-central-1 region (Frankfurt, Germany)," and locates its remaining sub-processor in the EU (Belgium). With no in-country region anywhere on the list, there is no mainland hosting resource for consent and preference data to live on, and none to attach an ICP filing to. | Didomi — Our sub-processors as a data processor, retrieved 2026-10-09 |
| Didomi's consent is built for the GDPR regime, which China's PIPL does not mirror. Didomi describes its CMP as covering "GDPR, CCPA, and all major global regulations" — a list that does not name China's PIPL. A GDPR- or TCF-style opt-in does not by itself satisfy PIPL, which requires separate, specific consent for several purposes and a distinct consent for the overseas transfer itself (PIPL Articles 38–40). A banner valid in Europe can still fall short of what China asks for a Chinese user. | Didomi (didomi.io) product description, retrieved 2026-10-09; PIPL Articles 38–40 |
| For some handlers the data must stay in China — and serving from inside the mainland triggers an ICP filing. Where the handler is a critical information infrastructure operator or moves personal information at volume, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a duty an EU consent store cannot meet — and above certain thresholds the transfer may require China's data-export security assessment. And any public site actually served from inside China must carry an ICP filing (State Council Order No. 292; MIIT Order No. 33), bound to a mainland hosting resource Didomi does not provide. | PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37); State Council Order No. 292; MIIT Order No. 33 |
Sources verified by the 21YunBox compliance team on 2026-10-09.
For a mainland-China audience, Didomi comes with a question that folds back on itself. Didomi is a consent and preference management platform — the software a company installs in order to keep its data collection on the right side of privacy law — yet pointed at China as it ships, it can turn into an exposure of its own. The deciding issue is not whether the banner loads. It is two things at once: the consent records, preference profiles and data-subject requests Didomi gathers from your Chinese users come to rest on infrastructure inside the European Union, and the consent logic itself is written for Europe’s rules, not China’s. The first is a data-residency and cross-border question under Chinese law; the second is a consent-regime question that China’s PIPL answers very differently from the GDPR. Both sit ahead of performance — and Didomi documents the first in its own sub-processor list.
Didomi in China at a glance
| What decides it | In Didomi's own terms — and China's law |
|---|---|
| What Didomi runs | Didomi's platform spans a Consent Management Platform, a Preference Management Platform and data-subject-request (DSAR) handling. So it keeps a standing record of who consented to what, each visitor's stored preferences, the device and IP signals its banner reads, and the requests your Chinese users file — every item of it personal information. |
| Where the records live | Its sub-processor list places hosting in the EU: AWS “Data centers located in the European Union (Frankfurt, Germany),” and Snowflake servers “located in the AWS eu-central-1 region (Frankfurt, Germany)” for client data and analytics, with its remaining sub-processor in Belgium. None is inside mainland China. |
| Your China users' records | Consent records, preferences and DSAR data collected from people in China and held in the EU are a cross-border transfer of personal information PIPL governs (Articles 38–40): notice, a separate consent, and one cleared transfer mechanism. |
| Built for the wrong regime | Didomi describes its CMP as covering “GDPR, CCPA, and all major global regulations” — a list that does not name China's PIPL. A GDPR- or TCF-style opt-in does not by itself meet PIPL's separate, specific consent, nor the distinct consent PIPL requires before data is sent abroad. |
| Residency & serving the public | For a critical information infrastructure operator or a large-volume handler, personal information collected in China must stay in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — which an EU store cannot do. A site served from inside China also needs an ICP filing bound to a mainland hosting resource Didomi does not provide. |
The consent record is itself personal information — and Didomi keeps it in the EU
The awkward part is structural, not a detail at the edges. Didomi exists to capture and hold the evidence that you collected personal information lawfully — the consent a visitor gave, the preferences they set, the paper trail behind a data-subject request. But Didomi’s own sub-processor list, updated July 2026, puts that evidence in Frankfurt: its AWS hosting sits in “Data centers located in the European Union (Frankfurt, Germany),” and the “Snowflake servers used by Didomi are located in the AWS eu-central-1 region (Frankfurt, Germany)” for client data and analytics. So the proof that a Chinese user consented is held in Europe — which means the consent tool has quietly produced the very cross-border transfer it is meant to keep you clear of.
Under China’s Personal Information Protection Law that is a cross-border transfer, and the duty rests on the personal-information handler — you, not Didomi. You owe notice, a separate consent for the overseas transfer, and one cleared transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (PIPL Articles 38–40). A platform that records the consent does not take on the obligation attached to wherever that consent is then stored.
A consent flow built for the GDPR is not a PIPL consent flow
Here is the part specific to Didomi. It is a European CMP, and it describes its consent experiences as covering “GDPR, CCPA, and all major global regulations” — a line that, tellingly, does not name China’s PIPL. That matters, because China’s consent rules are not a dialect of the GDPR; they are their own regime. PIPL asks for consent that is voluntary and explicit, and for several purposes it requires separate, specific consent rather than one blanket opt-in — including a distinct consent before any personal information is sent outside the mainland (PIPL Articles 38–40). A banner built around GDPR lawful bases and the Western consent frameworks Didomi lists can be perfectly valid in Europe and still fall short of what PIPL asks for a Chinese user. So even where Didomi loads and the banner renders cleanly, the consent it captures may not be the consent China’s law actually requires — a question to settle with counsel, not an assumption to ship on.
No mainland region, so no in-country storage and no ICP footing
Didomi names AWS, Snowflake and Addingwell as its sub-processors and locates every one of them in the EU — Frankfurt and Belgium; it publishes no mainland-China region. That geography settles two further questions before speed is ever in the frame.
First, residency. If you are a critical information infrastructure operator or a large-volume handler, personal information collected in China has to be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 — the data-localization provision renumbered from Article 37 by the 2025 Cybersecurity Law amendment that took effect on January 1, 2026, its substance unchanged). An EU consent-and-preference store cannot meet that duty however it is configured, and above certain volume thresholds — or where the records qualify as important data — the transfer may itself require China’s data-export security assessment before anything leaves. Second, licensing. A public-facing site actually served to mainland visitors from inside China turns on an ICP filing (ICP 备案) under State Council Order No. 292 and MIIT Order No. 33, and that filing has to attach to a hosting resource physically in the mainland. Didomi offers none, so there is nothing on Didomi to file against. “We already run Didomi for consent” does not travel across the border; the tidy compliance story the platform is supposed to hand you is exactly what it leaves open in China.
A consent gate served from offshore can hold up the page
The delivery half is real as well, and for a consent gate it bites harder than for an ordinary script. A cookie-consent experience is fetched client-side, and is often wired to hold the page until the visitor makes a choice. Because Didomi’s infrastructure sits in EU regions, that script and its configuration are pulled from outside the mainland — the same cross-border hop every offshore asset makes to reach a user in China.
So when an offshore-served consent gate loads slowly or fails from inside China, it does not fail off in a quiet corner — it can stall the very content it stands in front of. That is a delivery problem, not a legal one, but on a China-facing site the two reinforce each other: the gate that is hardest to deliver is also the one carrying the cross-border exposure. We publish no first-party China latency figure for Didomi here, because speed is not the axis this decision turns on, and a number without a method, a sample and a date would only mislead. And one thing 21YunBox never does — and that no lawful provider can offer — is route around China’s data-export rules or any network restriction: we never use or suggest circumvention of any kind.
This is a risk map, not a verdict. Whether you owe a separate consent, a transfer mechanism, in-country storage, a data-export assessment, an ICP filing, or some mix of them depends on your data volumes, your role as handler, and who your users are — worth settling with counsel before you rely on it.
The lawful path — map, localize, deliver
There is a compliant way to run Didomi for a China-facing audience, and it has a definite shape. First, map: our China team works through the PIPL cross-border and data-residency obligations that attach to the consent, preference and request data Didomi records — set against your entity, your data volumes and who your users are — and marks where a data-export assessment, an Article 39 storage duty, or PIPL’s separate-consent rule actually bites. The legal conclusions are reached with counsel; we build the technical picture that feeds them.
Then localize: for the records that must stay in the country, and the consent that has to meet China’s own rules, we stand up and integrate a China-resident store and a PIPL-aligned consent flow on an ICP-filed, in-country footing — the lawful in-country pattern of consented, in-country processing and storage — so what cannot lawfully leave no longer does, while you keep Didomi for the markets it already serves.
Then deliver: the China-facing site or app that presents the consent gate is itself a public service in the mainland, so it carries an ICP-filing duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — set in front of what you already run, with no rebuild and no re-platform. The result is a consent and preference setup that runs legally and compliantly for your users in China.
Related reading:
- Cross-border data transfers under PIPL
- China’s data-export security assessment
- China’s Cybersecurity Law (data localization, Article 39)
- How to get an ICP filing for China
