Compliance by Region: Data Residency and Filing Reality Checks

The layer most people forget when choosing a region: compliance. Where your node sits decides where your data legally "is" — and "where" triggers a completely different checklist of obligations. This is the compliance companion to the Regions & Data Center Hub: it turns filing, data residency and PIPL/GDPR into three executable checklists, from an engineering point of view. This article is not legal advice — for your actual workload, consult qualified counsel; its value is in telling you which questions to ask.

ICP filing: the mainland / overseas watershed

The skeleton of the ICP filing rule (defer to the regulator's latest requirements): if a website serves the public from a server inside mainland China → the domain needs an ICP filing; if you run from Hong Kong, Macau, Taiwan or overseas nodes → mainland filing obligations are not triggered. That is the real weight of "filing" in a placement decision:

Three practical constraints on the engineering side: ① during the filing period the site must not serve mainland users (put it in the project plan); ② the filing subject must match the domain and server records (changing data center or IP can trigger a filing amendment — check before you migrate); ③ "using an overseas node to skip filing" is a compliance violation for mainland commercial operations, not a trick — this article discusses no avoidance path.

Data residency and cross-border transfer: where the line is

• Personal information going abroad: PIPL sets conditions for providing personal information outside China (notice and consent, assessment / certification / standard-contract paths; applicability per regulator and counsel). The engineering reading: putting a database that contains personal information on an overseas node is a cross-border transfer — do data classification before you place anything;
• The minimal classification move: split fields into four classes — personal information / sensitive personal information / business data (non-personal) / logs — and answer per class "may it leave the country, and through which path";
• Logs are data too: IPs, user agents and behaviour traces in access logs can constitute personal information — the practical "what must never land in logs" checklist lives in the Security Baseline Hub;
• Multi-region architecture: the common pattern is "personal information stays in the user's region; only aggregates and cold backups leave" — narrowing the cross-border surface at the architecture layer.

GDPR: the reality when you serve European users

If your product targets EU users, GDPR can apply even when your servers are nowhere near the EU. The four clauses that bite small sites most: ① consent and notice (consent management for cookies and analytics scripts); ② data-subject rights (access / erasure / export requests need an engineering channel); ③ records of processing (what you process, why, retention — one table); ④ breach notification (a 72-hour window — impossible without monitoring and an incident playbook; see the security hub's incident-response article). Placement implication: when Europeans are a large share of users, a European node or CDN edge plus a classified-data architecture is far cheaper than "everything in SG or us-west".

Industry-specific requirements (engineering view)

• Finance-adjacent: physical isolation, tamper-evident audit logs and data-not-leaving-the-country are usually hard requirements — the bare-metal + mainland-node combination (threshold analysis in the Choosing Hub, bare-metal article);
• Healthcare: sensitive personal information at the highest tier; strictest residency and encryption demands;
• Games: mainland publishing runs through the licence + filing system; go-global (including HK/MO/TW and Southeast Asia) mostly lands on HK/SG;
• E-commerce: storage location of transaction and personal data, payment-data boundaries (PCI-DSS if card payments are in scope) — check item by item.

Translating compliance cost into engineering units

Compliance is not pure legal overhead; only once you price it in engineering units can it enter the placement decision: filing time (project schedule + amendment constraints on migration), classification implementation (field-level tagging + storage partitioning), rights-request channels (export / erasure APIs), breach-notification ops (monitoring + playbook + drills). Rough calibration: for a small site, doing all four is a "person-weeks" job, not "person-months" — provided they are scheduled at placement time; retrofitting typically costs several times more (architecture torn down and rebuilt). That is the other meaning of "compliance is a pre-condition": it is cheapest exactly when it is earliest.

Three compliance questions before placement (checklist)

# Write these three answers into the architecture doc; only then is the placement decision complete:
1. Does my user data contain personal information? Where is the field-level inventory?
2. Which jurisdiction will store it? Does that trigger filing / cross-border / consent duties?
3. Do engineering channels exist for user rights (access / erasure) and breach notification (72h)?

Next step: once the three questions have answers, return to the Regions & Data Center Hub for the latency-and-cost placement decision — compliance is a pre-condition, not a patch applied later. Security baseline practice → Security Baseline Hub; node resources → current configurations.