Before deploying an application in China, I want to know where its data will live, who can support it from Singapore and how it will recover. The answers affect the cloud provider, network, access controls and support arrangements.
I previously wrote about Alibaba Cloud and Aliyun. Here, I look at the wider decisions an APAC infrastructure team has to make: choosing the provider, meeting the workload’s security requirements, launching a public service and managing data flows between China and the rest of the organization.
Checked 26 October 2026. This guide covers mainland China. Requirements depend on the entity, sector, system, data and locality, so confirm applicability with China legal/privacy colleagues and the relevant assessor before committing to a production design. The architecture examples are hypothetical.
Workloads and data
I would start with a workload register and a data-flow diagram.
A useful register identifies the business service, application owner, China operating entity, infrastructure owner, users, hosting locations, data categories, integrations and recovery requirements. It should also identify who has authority to accept operational risk and approve expenditure.
“The APAC team owns it” leaves too much unanswered. A regional engineering team may run the platform while a China entity operates the business service and has local obligations. Those responsibilities need to be explicit.
The data inventory needs to cover more than the production database:
- Customer and employee information.
- Authentication records and privileged-session recordings.
- Application logs, security events, traces and monitoring labels.
- Screenshots, database extracts and vendor support bundles.
- Backups, snapshots, replicas and recovery-test copies.
- CI/CD output, configuration and deployment artefacts.
- Prompts, attachments and diagnostic results sent to AI services.
A log line can contain an email address, an account identifier or information about a customer transaction. Calling it “telemetry” does not settle its classification.
The Multi-Level Protection Scheme (MLPS) grades the protection required for a system according to the consequences of compromise. The Personal Information Protection Law (PIPL) distinguishes personal information and sensitive personal information. The Data Security Law establishes a separate classification and important-data regime. These categories can overlap, but they are not interchangeable. PIPL, Data Security Law
Commercial confidentiality alone does not automatically make something statutory “important data.” That determination needs the relevant identification rules, sector catalogues and notifications. An MLPS grade also does not determine the data-export route.
Architecture, procurement and legal teams should work from the same inventory.
Regulators and rules
What CAC does
The Cyberspace Administration of China (CAC, 中央网络安全和信息化委员会办公室) coordinates national cybersecurity work and related supervision. It also coordinates network-data security and personal-information protection, alongside authorities responsible for their own sectors. Its wider remit includes internet information-content regulation. Cybersecurity Law, Article 9, PIPL, Article 60, CAC responsibilities
For a cloud project, CAC matters particularly when data leaves mainland China. It issues cross-border data rules and organizes the required national data-export security assessments. Assessment applications go through the relevant provincial cyberspace authority; personal-information standard contracts are filed at provincial level. CAC assessment guide, standard-contract filing guidance
Other authorities handle related requirements. The Ministry of Industry and Information Technology (MIIT) and provincial communications administrations oversee the relevant telecommunications authorizations and ICP filing or licensing. Public-security authorities supervise MLPS. Sector regulators may add requirements. The project needs to identify which authority handles each process and which internal owner will coordinate it. ICP responsibilities, MLPS supervision
Which rules apply?
Six sets of requirements need separate review:
- Cybersecurity Law, Data Security Law and PIPL: the underlying network-security, data-security and personal-information obligations.
- MLPS, or 等保: the system protection regime, including classification, implementation and applicable filing and assessment work.
- Cross-border data transfer, or CBDT: the conditions and mechanisms for providing relevant data outside mainland China.
- Internet Content Provider (ICP) and other service requirements: whether the internet information service requires filing, licensing or additional approvals.
- Cloud provider qualifications: whether the actual operating entity and platform are suitable for the service we are buying.
- Sector and critical information infrastructure requirements: additional obligations that may apply to particular organizations and workloads.
Critical information infrastructure is often shortened to CII, and its operators to CIIOs. I would establish whether that status applies through the appropriate local process. It should not be assumed simply because an application is important to our company.
The Network Data Security Management Regulations took effect on 1 January 2025. Amendments to the Cybersecurity Law and the personal-information outbound certification measures took effect on 1 January 2026. Older guides can therefore contain outdated article numbers or incomplete processes. Network Data Security Management Regulations, Cybersecurity Law amendment, outbound certification measures
The project record should identify which rules were checked, when they were checked, and who confirmed their applicability. That record should be reviewed when the service changes.
The Network Data Security Risk Assessment Measures took effect on 20 August 2026. They require annual assessments for important-data processors, while encouraging ordinary-data processors to assess at least every three years. That encouragement should not be converted into a universal mandatory three-year cycle. Risk assessment measures, implementation guidance
Choosing a cloud provider
Check the operator’s authorization, the assessed platform and the responsibilities that remain with the customer.
Operator and authorization
Start with the contracting legal entity and its relevant telecommunications authorization. MIIT's IDC category includes Internet Resource Collaboration Services used for cloud services. The authorization concerns an operating entity and service scope; a familiar global brand is not the evidence on its own. MIIT telecommunications service classification
Procurement should request the applicable authorization, covered service and geography, contractual responsibilities and a route for validating the evidence.
China accounts and services
AWS documents Beijing as operated by Sinnet and Ningxia by NWCD, with China accounts and credentials separate from global AWS. Azure China is a physically separate instance independently operated by 21Vianet, with differences in service availability. AWS China Gateway, Azure China operations
Alibaba Cloud's China and International websites also use separate account, billing and compliance arrangements. That distinction should not be assumed to work exactly like AWS's partition model. The specific account and service capabilities need checking. Alibaba Cloud China versus International website
Validate identity integration, API endpoints, infrastructure-as-code providers, service availability, support and recovery tooling in the intended China environment. A module that works in a global region is a useful starting point for testing, rather than proof that the China deployment will work unchanged.
Assessment scope
Ask which platform, region and services the provider's MLPS evidence covers. A certificate for one assessed platform does not answer every question about another product or deployment.
For party/government and CII contexts, CAC's cloud security assessment framework adds another layer. Its measures address platforms serving those customers, including personnel, supply chain, continuity and portability. I would not describe it as a universal approval requirement for every ordinary enterprise cloud workload. CAC cloud security assessment measures
Also be careful with old ownership assumptions. MIIT has introduced pilots removing foreign ownership caps for specified telecommunications services in approved locations. The relevant authorization and conditions still need verification; the pilot does not make every foreign provider automatically eligible. MIIT June 2026 update
Provider evidence
My procurement checklist covers the operator, authorization scope, platform assessments, service locations, support access, subprocessors, incident notification, backup and restoration responsibilities, data exportability, deletion and exit assistance.
For each item, record the evidence, its date, its limitations, the internal owner and the acceptance decision. This makes renewals and service changes easier to review.
Connectivity and dependencies
Cross-border connectivity belongs in the design and procurement review. AWS's China guidance explains that cross-border connection services are ultimately delivered by or through China telecommunications carriers, and that the data owner must ensure the transit meets applicable data-transfer requirements. Confirm the actual carrier, provider arrangement and service scope for the proposed connection. AWS China connectivity guidance
A private circuit can improve performance and control, but it does not itself authorize the data flowing over it. Network availability and data-transfer compliance are separate acceptance questions.
The pilot should exercise normal and degraded conditions: authentication, package downloads, container-image pulls, monitoring queries, certificate renewal and vendor support. Record latency, failure behaviour, service/API differences and fallback arrangements. Testing only a connection between two virtual machines misses much of the operating environment.
The business also needs to understand the continuing cost of connectivity and local dependencies. A standardized global platform may require additional services, support and engineering capacity in China. Those costs belong in the business case before a launch date is agreed.
MLPS requirements
Moving an application to an assessed cloud platform can provide a useful foundation. Our workload still needs a responsible operator and an agreed scope.
Under the official MLPS management measures, system grading is based on the consequences of compromise. Level 2 and above require filing; Level 3 requires at least annual assessment. The measures distinguish existing-system filing after classification from new-system filing after operation begins. I would confirm the current local process and project sequence with the assessor and responsible authority. Official MLPS management measures
Agree which system and dependencies the assessment covers, often called the “protection object” in MLPS materials. An application can depend on shared identity, databases, management access, network services, monitoring and backup. Drawing the boundary too narrowly can leave essential controls without an owner.
The current technical baseline includes GB/T 22239-2019, with a separate grading guide in GB/T 22240-2020. Ask the assessor to identify which requirements apply to the protection object. Current baseline standard, grading guide
Engineering controls
The design review should identify who implements and operates each control:
- Network boundaries: ingress, egress, management paths and separation of environments.
- Administrative access: named identities, appropriate authentication, privilege approval and session evidence.
- Workload security: hardening, vulnerability handling, patch ownership and supported software.
- Audit: relevant events, collection coverage, access to evidence and retention rules.
- Data protection: encryption, backup, restoration and permission boundaries.
- Operations: change control, incident handling, supplier responsibilities and recurring review.
Article 23 of the amended Cybersecurity Law includes retaining relevant network logs for at least six months. Define which logs this covers and how they will be retained. Avoid extending that period to every application record or all personal information. Current Cybersecurity Law
AWS China's acceptable-use policy explicitly addresses customer MLPS responsibility. Read these obligations alongside the provider's assessment evidence. AWS China customer MLPS provisions
Budget for assessment, evidence preparation, remediation and continuing operations. A platform can be technically ready while the organization still lacks access reviews, procedures or the people needed to run it.
Cross-border data transfers
Consider a hypothetical application hosted in mainland China. Its database is local, but Singapore engineers query production, the regional security operations centre (SOC) receives logs, a vendor receives support bundles, and an AI assistant analyses incident information overseas.
CAC's October 2025 clarification addresses data stored domestically that can be queried, retrieved, downloaded or exported from overseas. The relevant location is where the access or call occurs. A Singapore engineer's query can therefore create an export scenario even when the database stays in China. CAC remote-access clarification, question 5
Illustrative flows requiring classification and review. An arrow does not mean that a transfer is prohibited, exempt or approved.
Each flow needs a record: purpose, data categories, source, recipient, access location, frequency, scale, retention, onward recipients, safeguards and applicable transfer route.
For a SOC integration, that means looking at the event fields and who can query them. For vendor support, it means the actual ticket attachments and diagnostic content. For an AI service, it means prompts, tool results and outputs as well as the underlying model's processing location.
Alibaba's STAROps documentation provides a concrete example: selecting its Singapore centre to query mainland resources creates a cross-border transfer scenario for query results and diagnostic outputs, even though the original cloud-product data remains in its source region. STAROps data security and compliance
Transfer mechanisms
Before using the simplified bands below, establish the applicable exemptions, CIIO status and important-data obligations. Count cumulative individuals since 1 January of the current year for the non-CIIO personal-information bands. The standard-contract/certification band assumes no important data and that neither security-assessment threshold is reached:
- For a non-CIIO, fewer than 100,000 individuals' ordinary personal information generally qualifies for the volume-based exemption from the three formal mechanisms where no sensitive personal information or important data is exported under that exemption.
- 100,000 to fewer than 1 million individuals' ordinary personal information, or where sensitive personal information is exported, concerning fewer than 10,000 individuals, generally requires a standard contract or certification for a non-CIIO.
- 1 million or more individuals' ordinary personal information, 10,000 or more individuals' sensitive personal information, or important data generally triggers CAC security assessment for a non-CIIO.
- CIIO exports of personal information or important data ordinarily require security assessment, subject to applicable exceptions.
The figures concern people, not database rows or API calls. CAC 2024 cross-border provisions
CAC's September 2026 guidance confirms the certification route and explains that certification does not replace a required security assessment when the applicable thresholds are reached. CAC September 2026 guidance
Necessary cross-border HR management can qualify where the specified lawful employment-rule and collective-contract conditions are met. Confirm those conditions with China HR and legal colleagues; they do not make every transfer to a global HR platform exempt. CAC HR clarification, question 3
Exemption from a formal transfer mechanism leaves other applicable privacy duties in place. Lawful-basis exceptions also affect consent requirements. CAC July 2026 guidance
Access and data controls
Depending on the approved use case, I would consider local collection and retention, narrower permissions, purpose-specific APIs, reduced diagnostic fields and controlled regional access.
Masking and filtering need testing against the actual data. Replacing a name with a stable identifier may still leave information linkable to a person. Encryption protects a transfer but does not automatically exempt it from the transfer rules.
Record what can leave, who can receive it, the purpose and the conditions.
Example: Singapore SOC access
Suppose the Singapore SOC requests direct access to the China application's logs. I would start by asking which detection and response tasks require that access.
The application owner and security team inspect a representative schema and sample. They identify usernames, customer identifiers, source addresses and request content, then check for unexpected personal information in free-text fields. The review records where the SOC analysts, platform and onward support recipients operate.
China legal/privacy colleagues assess the data categories, scale, purpose and applicable transfer conditions. Engineering then tests a proposed design: collect locally, exclude unnecessary fields at source, restrict queries to the agreed use case, and preserve the audit trail. Filtering is tested against real log patterns rather than assumed from the configuration.
The recorded outcome could be conditional approval for a defined event feed, with raw production-log access remaining a separate decision. It could also be a requirement to change the design or complete a transfer mechanism first. Neither outcome should be assumed in advance.
The decision record names the business owner, legal/privacy reviewer, security owner and implementing team, plus the evidence and review triggers. A new field, recipient, processing region or AI analysis feature reopens the relevant review.
ICP and other filings
Renting infrastructure and publishing an internet information service are different decisions.
The operative Internet Information Service Measures distinguish noncommercial services, which follow a filing regime, from commercial internet information services, which follow a licensing regime. The commercial definition relates to the regulated service activity, such as paid information services; being a company with revenue does not by itself determine the answer. Some service categories need additional approvals. Current Internet Information Service Measures
For a mainland-hosted public website, I would establish the entity, domain, service category and hosting/access-provider requirements early. Alibaba's guide explains its domain and mainland-hosting filing requirements. Alibaba Cloud website filing requirements
A private internal application needs its own scope review. Check whether its service and exposure fall within the filing requirements. Its MLPS, data-security and access obligations still need attention.
APP filing and public-security networking registration are separate again. MIIT's APP notice addresses covered applications providing internet information services; public-security rules have their own covered entities and filing trigger. They should be individual entries in the readiness checklist. MIIT APP filing notice, public-security networking measures
Treat filings and permissions as launch dependencies. A working server and DNS record do not establish that the public service is ready. The project plan needs the responsible entity, domain evidence, required filings or permissions, provider workflow and approvals.
Keep enacted rules separate from consultation drafts. The July 2026 proposed revision of the internet information measures was published for consultation; proposed requirements should not be presented as current law. CAC consultation notice
Residency and disaster recovery
Whether data must stay in mainland China depends on the applicable rules, the entity and the data involved. PIPL, Article 40
Use those requirements to choose the recovery location and access arrangements.
I would separate four questions:
- Availability: how does the live service tolerate component or zone failures?
- Backup: what recoverable copies exist, and can they survive deletion or corruption?
- Disaster recovery: where and how can we restore the business service after a larger failure?
- Operational continuity: can the team authenticate, access keys, deploy software and communicate during that event?
A replica can reproduce a bad change. A successful backup job does not demonstrate a successful restoration. Multiple availability zones also do not answer every regional failure scenario.
Recovery location
For a workload subject to relevant restrictions, a second mainland region may be a sensible starting point to evaluate. An offshore recovery copy, including one in Hong Kong or Singapore, needs a separate data-export review. I would not treat Hong Kong as an onshore mainland recovery destination for that analysis.
The choice must also account for sector requirements, provider capabilities, recovery objectives and cost. A particular three-centre topology should not be presented as universally mandatory for every enterprise.
An illustrative mainland recovery option. The locations, topology and external dependencies must be validated for the actual workload.
Recovery dependencies
A recovery exercise should include:
- Encryption keys and the permissions needed to use them.
- DNS, certificates and public or private endpoints.
- Identity and emergency administrative access.
- Container images, packages, configuration and deployment tools.
- Network connectivity and integration partners.
- Security monitoring and evidence collection during recovery.
- The people and vendors authorized to execute the runbook.
Test whether the China service can recover when a regional dependency is unavailable. Check any reliance on global identity, an overseas image registry or a Singapore administrator.
Recovery point and recovery time objectives should be agreed with business owners and tested against a realistic scenario. The test record should include the restored service, elapsed time, data loss, failures, workarounds and owners for corrective actions. A provider's infrastructure availability statement is one input to that exercise.
Ownership and incident response
An APAC infrastructure team can provide common engineering standards, automation and expertise. Local requirements still need named decision-makers and working escalation paths.
The responsibilities need to be explicit:
- China business and operating entity: service ownership, local accountability and business priorities.
- Regional infrastructure: platform design, access, configuration, capacity, backup and recovery engineering.
- Security operations: detection, triage, evidence and technical response.
- Legal/privacy: applicability, data-processing arrangements and transfer decisions.
- Procurement and vendor management: authorizations, contracts, incident terms and continuing evidence.
- Application owners: data use, software changes, integrations and acceptance testing.
- Provider and assessor: their contracted services, evidence and assessment responsibilities.
The responsibility matrix should identify who decides, who executes and who must be consulted. It should also identify a deputy and an escalation route when a key person is unavailable.
Incident reporting
The national incident reporting measures, effective 1 November 2025, prescribe reporting routes for incidents assessed as 较大 or above. The initial time limits differ: CII operators have no more than one hour to the specified protection department and public-security authority; central/state bodies have no more than two hours to their departmental function; other network operators have no more than four hours to the provincial cyberspace authority. Sector requirements can add obligations. CAC incident reporting measures
These are not deadlines for every minor security alert. They do mean the runbook needs rapid classification, appropriate local contacts and authority to act on initial facts. Waiting for a complete root-cause report or relying on a generic global reporting timetable can leave the team unprepared.
Agree vendor notification and escalation responsibilities before an incident. The operating team also needs to know which records to preserve, who communicates with authorities and who coordinates business recovery.
Change reviews
The compliance record should be revisited when we add an overseas support team, enable a new SaaS connector, change a backup destination, introduce an AI assistant, change the public service or move to a different cloud product.
A small configuration change can alter the data flow or assessed boundary. Those questions belong in change review; waiting for an annual document refresh can leave the record out of step with the live service.
A 90-day plan
This is a suggested assessment sequence, not a statutory timetable or a promise that external approvals finish within 90 days.
Days 1–30: inventory
Inventory workloads, responsible entities, data and overseas access. Draw the existing flows, identify public services and recovery copies, and request provider evidence. Establish the sector and CII questions with the appropriate colleagues.
The output should be a shared picture of the environment and a list of unresolved applicability decisions. I would resist buying a bundle of “compliance tools” before the scope is clear.
Days 31–60: design and budget
Confirm the MLPS scope and process, transfer route, public-service requirements and provider responsibilities. Assess control gaps and design the access, logging and recovery arrangements.
Price the continuing operating model as well as the initial implementation: assessments, security services, log storage, recovery capacity, connectivity, local support and staff time.
For each gap, assign an owner, evidence requirement, target date and acceptance decision. The business needs to understand how these dependencies affect launch or migration timing.
Days 61–90: test and review
Pilot the architecture, validate administrative access and integrations, run restoration tests and collect evidence. Confirm incident contacts and rehearse the escalation process. Complete the required internal decisions and applicable external steps, allowing those processes their actual lead times.
The readiness record should show completed tests, open issues, owners and conditions for operation. Keep it with the service records so the support team can use it after handover.
Common questions
Does the provider’s MLPS cover our application?
The provider’s assessment covers its platform. Check the application’s own classification, controls and filing or assessment requirements.
Can Singapore engineers provide support?
The support model needs assessment. Review what they can access, where access occurs, the data involved and the applicable transfer arrangements. Controlled access is an engineering safeguard; it does not determine the legal route by itself.
Can logs go to the global SIEM?
Start with the actual fields, query capabilities, recipients, processing locations and retention. Some logs may contain personal information or other regulated data. A filtered dashboard and raw production-log access can have different data scopes.
Can backups go offshore?
That destination needs review against the workload's data and sector obligations, the applicable export mechanism or exemption, and the recovery requirements. I would document the answer before enabling replication.
Does every application need MLPS Level 3?
The grade follows the applicable classification process and consequences of compromise. It should not be assigned solely because the organization is multinational or the application runs in a public cloud.
What does a transfer exemption cover?
It concerns the specified transfer mechanism. Other applicable privacy and security duties remain, including a documented purpose, appropriate processing arrangements and safeguards.
Before approving the next China deployment, I would put its data-flow diagram, provider evidence, responsibility matrix and recovery test on the review table.