Does Asana Work in China? Data Residency, PIPL Cross-Border & ICP
Asana isn't formally blocked in mainland China — but reachability is not the China question. Asana runs on AWS and keeps your tasks, projects, attachments and team members' personal information offshore: its own Security Statement lists data-residency options in Europe, Australia and Japan on top of a United States default, with no mainland-China region. So a China team's workspace is a cross-border transfer of personal information under PIPL, with in-country storage duties for some handlers and an ICP filing for any public China-facing surface. A compliance-first look at the data-residency, cross-border and ICP exposure — and the lawful in-country path, with no circumvention of any kind.
Does Asana work in China?
Whether you can use Asana for a mainland-China team is first a data-residency and cross-border question under PIPL — not a question of whether the board loads. Asana is work and project management: it holds your tasks, projects, comments, attachments and the identities of the people doing the work, and where it keeps that data is what China's law responds to.
Asana is not on China's sanctions list or any formally published block, so reaching it is not the hard part — but its own Security Statement says it "offers global data residency options with data centers in Europe, Australia and Japan," layered on a default in the United States, with every region hosted on Amazon Web Services per its help documentation. Mainland China is not among them and there is no China data region, so a China team's workspace sits offshore: a cross-border transfer of personal information PIPL governs (notice, a separate consent and one transfer mechanism, Articles 38–40), with in-country storage for a CIIO or large-volume handler (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) and an ICP filing for any public China-facing surface served from inside the mainland. The table below is Asana's own wording and the rule each line triggers.
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 Asana's own documentation says about China
| Fact | Primary source |
|---|---|
| Asana states in its own Security Statement that its data-residency options are Europe, Australia and Japan — not mainland China. Under the Data residency heading Asana says it "offers global data residency options with data centers in Europe, Australia and Japan," on top of its default United States hosting. There is no mainland-China data region on that list, so the tasks, projects, attachments and member identities a China team keeps in Asana are held offshore — a cross-border transfer of personal information under PIPL (notice, separate consent and a transfer mechanism, Articles 38–40). | Asana Security Statement — Data residency (retrieved 2026-10-09); PIPL Articles 38–40 |
| Asana's data-residency documentation hosts every region on Amazon Web Services, defaults to the United States, and keeps an organization in a single region. Its help article names the United States (Virginia) as the default and Frankfurt, Tokyo, Sydney and Dubai as the residency options — all on AWS — with an organization's data confined to one geography and residency offered only on Enterprise and Enterprise+ plans. None of those regions is in mainland China, and there is no China instance to select. | Asana Help Center — Data residency for Asana (retrieved 2026-10-09) |
| An Asana workspace is personal information — the tasks, assignees, comments, attachments and the identities of the people doing the work. Collecting that from people in mainland China and keeping it in a workspace hosted offshore is what PIPL governs as a cross-border transfer: the personal-information handler (you, Asana's customer — not Asana) must give notice, obtain a separate consent for the transfer, and satisfy one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification — and above certain thresholds clear China's data-export security assessment first. | PIPL Articles 38–40; Measures for the Security Assessment of Outbound Data Transfers |
| For some handlers the data must stay in China — and a public China-facing surface served from inside the mainland needs 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 Asana's offshore regions cannot meet. And any public site actually served from inside China carries an ICP filing (State Council Order No. 292; MIIT Order No. 33), bound to a mainland hosting resource Asana 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.
The first instinct with a tool like Asana is to ask whether it even loads from Shanghai or Shenzhen. For a China-facing team that is the wrong first question. Asana is not on China’s sanctions list or any formally published block, and mainland teams often reach it in the ordinary course — connectivity can be uneven, but that is not where this decision is made. What decides whether you can use Asana for a China-facing team is where your work actually lives: the tasks, projects, attachments and the identities of the people doing the work. Asana keeps that data offshore, and the moment it is collected from people in China, a different body of law decides whether that was lawful. Even if every board loaded instantly, that question would still stand — which is why this is a compliance decision, not a performance one. And to be unambiguous from the outset: the only ways to force a connection to a service that will not open are forms of circumvention, which are themselves non-compliant and which 21YunBox never uses or suggests.
Asana in China at a glance
| What decides it | In Asana's own terms — and China's law |
|---|---|
| What it is | Asana is a work and project-management platform: tasks, projects, comments, attachments, and the identities of the team members doing the work. There is no Asana data region or operating entity inside mainland China. |
| Is it reachable from the mainland? | Asana is not on China's sanctions list or any formally published block, and mainland teams often reach it, though connectivity can be uneven. But reachability is not the China question, and the only ways to force a connection to a service that will not open are circumvention, which 21YunBox never uses or suggests. |
| Where does your workspace actually sit? | Offshore. Asana's Security Statement lists data-residency options in “Europe, Australia and Japan” on top of a United States default, and its help documentation hosts every region on Amazon Web Services. China is not a region, and there is no China data instance to select. |
| Putting China-collected work in that workspace | A cross-border transfer (数据出境) of personal information under PIPL (Articles 38–40): notice, a separate consent, and one transfer mechanism. It may trigger China's data-export security assessment, and for a critical information infrastructure operator the Cybersecurity Law's Article 39 (formerly Article 37) sets an in-country storage duty an offshore workspace cannot meet. |
| Serving a public China-facing surface | A portal, form or embedded view served to the mainland public from inside China needs an ICP filing (备案) bound to a mainland hosting resource. Asana names no mainland region, so there is nothing of its own to file against. |
| The lawful path | Keep China-collected work that must stay in-country on a consented, in-country store, move only what may lawfully leave, and deliver the China-facing surface in-country on ICP-filed infrastructure. 21YunBox maps, localizes and delivers; it never uses or suggests circumvention. |
The data-residency question: your Asana workspace sits offshore
Here is the gate most teams miss. Everything your team puts into Asana — every task, subtask, comment, attachment and the profile of each assignee — is stored on Asana’s infrastructure, and by Asana’s own account that infrastructure sits outside mainland China. Its Security Statement puts it plainly: under the Data residency heading it says it “offers global data residency options with data centers in Europe, Australia and Japan,” layered on a default in the United States, and its help documentation hosts each of those regions on Amazon Web Services. None of them is China. So the ordinary act of a Shanghai-based colleague assigning a task or uploading a file places personal information collected in China onto storage outside the country. That is a cross-border transfer of personal information under China’s Personal Information Protection Law.
PIPL puts the duty on the handler — you, Asana’s customer, not the vendor. Articles 38–40 require notice, a separate consent distinct from a user’s agreement to use the product, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. Above certain thresholds, or where the records include “important data,” that transfer may also require China’s data-export security assessment (数据出境安全评估) before anything leaves.
And if your organization is a critical information infrastructure operator, the Cybersecurity Law adds a harder duty. Its Article 39 — renumbered from Article 37 in the 2016 text by the amendment in force January 1, 2026, the obligation unchanged — requires that personal information and important data collected and generated in the mainland be stored in the mainland. An offshore Asana workspace cannot satisfy that, whichever residency region you pick, because none of Asana’s regions is in China. Which of these obligations actually bite on your data is a risk to confirm with counsel against what your team collects and stores.
Why there is no Asana “China region” to switch on
With some vendors the fix is to move onto a mainland instance the vendor itself runs. Asana is not one of them. Its residency choices — Europe, Australia and Japan, on top of the United States default — are the whole menu, data residency is offered only on Enterprise and Enterprise+ plans, and an organization’s data must all sit in one geography; there is no China setting to enable and no in-China operating partner for the workspace. So localizing for China is not a toggle inside Asana — it is a decision about where the regulated data lives.
The work, then, is to separate the China-collected records that must stay in the country from those that may lawfully leave: hold the first on a consented, in-country store inside the mainland, and let only the second reach the Asana your team already uses. There is no clean, drop-in domestic twin of Asana to name here — what there is, is a lawful in-country pattern, consented storage inside the mainland for the data that has to stay, and that pattern is the heart of the fix.
Serving a China-facing surface adds an ICP duty
If your use of Asana is purely an internal team tool, the residency and cross-border questions above are the whole story. But the moment any China-facing surface built on or around it is served to the public from inside the mainland — a client portal, an intake form, an embedded project view — that surface is a public internet service in China and carries an ICP filing (备案) duty under State Council Order No. 292 and MIIT Order No. 33, bound to a hosting resource physically in the mainland. Asana names no mainland region, so there is nothing of its own to file against.
This is a risk map, not a verdict: whether you owe separate consent, a transfer mechanism, in-country storage, an ICP filing, or some combination turns 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 lawful way to run work-management for a China-facing team, and it has a clear shape — three moves, in order.
Map. Our China team works through the PIPL cross-border exposure and the data-residency duties that attach to what you keep in Asana — sorting which China-collected records carry personal or important information that must stay in-country, which may lawfully be transferred, and where a data-export security assessment or an Article 39 storage duty applies. The legal conclusions are settled with counsel; we supply the technical picture that feeds them.
Localize. Keep the China-collected records that must stay on a consented, in-country store inside the mainland, and let only what may lawfully leave reach your global Asana — so the projects and workflows your team depends on keep running, without the workspace becoming the thing that carries regulated data out of China unlawfully. 21YunBox stands up and integrates that in-country option in place of the storage that cannot run compliantly in the mainland.
Deliver. Any China-facing surface that serves or receives that work is itself a public service in the mainland, so it needs compliant, ICP-filed, in-country delivery — the 21YunBox Optimizer, set in front of what you already run, with no rebuild and no re-platform. The result is work-management and a China-facing surface that run legally and compliantly for your users in China. What we never do — and what no one lawfully can — is hand you a way around a block: we localize what must stay and deliver in-country, and circumvention is never on the table.
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
