China Cybersecurity Law — which CSL or DSL gate blocks launch

China Cybersecurity Law is which statute blocks launch — CSL China or Data Security Law China — not a PIPL rewrite. CSL China is the network / CIIO / MLPS-system statute. DSL China is the classification / important-data / processing-activity statute. A product can fail one and still owe the other. PIPL is a third statute. Do not claim CSL blocks App Store; ICP and store stay other clocks.

What CSL and DSL actually gate

Hard names this statute map uses:

• China Cybersecurity Law (CSL) — In force 1 June 2017. Network operators owe real-name where required, content and security duties, and incident reporting. Critical Information Infrastructure Operators (CIIO) take extra localization and procurement duties. Official: CAC text. English reading aid: DigiChina translation.
• Data Security Law China (DSL) — Adopted 10 June 2021, in force 1 September 2021. It governs data processing activities and classification — general, important, and national core — plus important-data catalogs. Official: CAC text. English: SPP English. Promulgation: gov.cn presidential order.
• CSL China vs DSL China — CSL China is the network / CIIO / MLPS-system statute. DSL China is the data classification / important-data / processing-activity statute. A product can fail one and still owe the other.
• Launch vs post-launch — CSL-adjacent CIIO localization and network-operator duties can freeze architecture. DSL important data often freezes outbound (assessment) more than store listing. Do not claim “CSL blocks App Store.” ICP and store remain other clocks. MLPS grading is post-launch — China MLPS.
• PIPL is a third statute — Personal information of natural persons. Sequence that map on PIPL product gates; do not retell consent gates here.
• Common myth — “We did PIPL / GDPR so CSL and DSL are done.” Wrong statute map. Export depth sits on Cross-border data transfer.

Vocabulary first. Next: what must exist before you pick the blocking statute.

What must exist before you pick the blocking statute

Missing a statute map stops your product team before a launch date is real work.

Precondition	Why your process stalls
Network vs data job named — China-facing network / CIIO vs processing / catalogs	Teams staff PIPL notices while CIIO localization or important-data outbound never gets an owner
Honest CIIO screen — is this stack CIIO-class, or an ordinary network operator?	Extra localization and procurement duties appear after architecture is already frozen overseas
Data classification started — general / important / national core	DSL China catalogs cannot start from a global privacy spreadsheet
Launch clocks separated — architecture vs outbound vs ICP / store	Boards treat one “cybersecurity” checkbox as App Store, ICP, and export at once
PIPL scoped as a third statute	Consent work is funded as if China Cybersecurity Law and Data Security Law China were done
Mainland China entity or landing-partner path	Mandarin regulator channels and catalog work have no organizing path

The Cyberspace Administration of China is the regulator umbrella for these tracks — not one form you buy. Product teams without Mainland China ops rails usually cannot treat “we have a cybersecurity slide” as the launch plan.

From network operator to data classification

Stages are product decisions — not console click-paths.

Stage	Decision / outcome
1. Name the job	China-facing network operator / CIIO, or data processing / catalogs, or both
2. Screen CSL China	Real-name where required, security and incident duties, CIIO localization / procurement if in scope
3. Screen DSL China	Classification (general / important / national core); start important-data catalogs
4. Fork localization vs outbound	CIIO localization can freeze architecture; important data often freezes outbound more than store listing
5. Keep PIPL on its own map	Personal information go-live stays on PIPL product gates
6. Keep MLPS post-launch	CSL requires the multi-level protection system; grading and filing do not replace ICP / store clocks — China MLPS
7. Only then fund clocks	Architecture, export, and store as separate calendars — not one cybersecurity checkbox

Hard gate — which statute owns the block

Necessity: confusing CSL China with DSL China (or with PIPL) wastes the quarter — either you freeze the wrong clock, or you ship on a global privacy PDF while CIIO localization or important-data outbound stays open.

Job	Blocking statute	What must already be true
China-facing network / CIIO-class stack	CSL China	Operator duties named; CIIO localization / procurement scoped if in scope
Processing activities + catalogs	DSL China	Classification started; important-data path named before export rails ship
Personal information of natural persons	PIPL (third statute)	Do not retell consent here — PIPL product gates
“Cybersecurity done” via GDPR / PIPL pack only	Myth as CSL / DSL plan	Wrong statute map

Hard gate — not a store freeze, not an MLPS launch bar

Do not claim CSL blocks App Store. ICP, store review, and app filing remain other clocks. CSL-adjacent CIIO localization and network-operator duties can freeze architecture. China MLPS is a post-launch grading program for China-operated systems — CSL requires the multi-level protection system, but MLPS does not block store or ICP launch.

DSL important data often freezes outbound (assessment) more than listing. Catalog and assessment depth: PIPIA / Important Data. When the outbound path is a standard contract for personal information, that is China Standard Contractual Clauses — not this contrast map.

Why a CSL pass is not a DSL pass

CSL China ≠ DSL China. Network-operator and CIIO duties do not classify your datasets. Clearing a security questionnaire does not invent an important-data catalog.

DSL China ≠ PIPL. Classification and important data are processing-activity gates. Personal information of natural persons is a third statute. A PIPL consent pack does not retire DSL China.

CIIO localization ≠ store listing. Extra localization and procurement duties can freeze where systems and data sit. They do not replace ICP or store clocks, and they do not mean “CSL blocks App Store.”

Important-data outbound ≠ architecture freeze. DSL often blocks the export pipe (assessment) while the in-country product can still list. Treat that as the CBDT / important-data fork, not as a hosting myth.

MLPS binder ≠ CSL launch pass. CSL requires the multi-level protection system. Grading, PSB filing, and assessment run after (or as) China-operated systems exist. Do not freeze store launch on MLPS, and do not skip CSL operator duties because an MLPS binder is on the roadmap.

GDPR / PIPL done ≠ CSL and DSL done. Overlap exists on security measures. It does not auto-clear CIIO localization, important-data catalogs, or CAC-adjacent channels.

Where CSL and DSL work stalls

• One “cybersecurity” checkbox — Product treats China Cybersecurity Law, Data Security Law China, and PIPL as the same slide.
• CIIO assumed away — Teams discover localization and procurement duties after overseas architecture is already funded.
• Catalogs never started — DSL China important data has no owner, so outbound rails ship on hope.
• Store date owns the statute map — ICP / listing is staffed as if it cleared CSL architecture and DSL outbound.
• MLPS used as a launch bar — Grading is pulled in front of store / ICP, or used as an excuse to skip operator duties.
• PIPL pack reused as CSL / DSL — Notices and consent UX are necessary for personal information; they are not this map.
• No owner for the fork — Nobody owns “which statute blocks this launch,” only “finish cybersecurity.”

What “fixed” means: the product team can name whether CSL China, DSL China, or both block the next funded date; CIIO localization is scoped or ruled out; important-data catalogs have an owner before export rails ship; PIPL stays on its own go-live map; MLPS stays post-launch; ICP and store remain other clocks. A GDPR PDF plus a PIPL policy is not fixed.

When a China landing partner owns the statute map

Most product teams exploring Mainland China entry need a China landing partner once they stop treating PIPL or GDPR as the whole cybersecurity plan — to screen CIIO vs ordinary network-operator duties, start important-data catalogs, keep Mandarin regulator channels, and sequence architecture vs outbound vs store as separate clocks. Your team still owns which product surfaces are China-facing and which data jobs are in scope; the partner path makes that statute map executable when those rails are not already in-house. A PIPL notice pack does not remove the need for that China landing partner on CSL China or DSL China work.

What we can offer?

China Cybersecurity Law work is a which-statute decision — CSL China versus Data Security Law China — before any single cybersecurity checkbox. Chinaready helps your product team pick the blocking gate and run the Mainland China path beside hosting and distribution:

1. China Readiness Assessment — Decide whether CSL China, DSL China, or PIPL owns the next funded date, and sequence CIIO localization, important-data catalogs, and store clocks the board can actually staff.
2. China Access Acceleration — Keep China-facing journeys reachable from Mainland China so the statute map matches the path users actually hit — not an overseas staging story.
3. China Product Hosting — Place China-critical workloads where CIIO localization or in-country processing is the CSL gate, with an access path that can hold the architecture story.
4. Mobile App Distribution — Align store questionnaires and SDK / data answers with the same CSL / DSL diagram — without treating listing as a CSL freeze or as a DSL catalog.

Contact us when you need a CSL versus DSL statute map before you staff another single cybersecurity checkbox.