A practical guide to a cross-border SaaS or Mainland

A SaaS or data agreement that crosses the Mainland China boundary is not a commercial contract with an extra clause. It is a regulated activity in at least two systems simultaneously – and the system that catches you first is rarely the one your in-house team prepared for. The governing instruments on the Mainland side impose data-localisation obligations, cross-border transfer restrictions and, in some configurations, licensing requirements that are wholly separate from anything a Hong Kong law review addresses. Get the sequence wrong and the agreement is either unenforceable or, in a worse outcome, in breach before the first invoice is issued.

A cross-border SaaS or data agreement touching Mainland China requires a sequential compliance review across the Mainland's data and technology regulatory regime, the applicable Hong Kong rules, and – where the data involves personal information – the cross-border transfer mechanism prescribed by the Mainland authorities. The governing instruments on the Mainland side include the Data Security Law, the Personal Information Protection Law, and the regulations on cross-border data transfer issued by the Cyberspace Administration of China (the CAC, the principal regulator for data and cyberspace matters on the Mainland). No single instrument resolves the full picture; the sequence of steps and the gate at each step determine whether the agreement can legally operate.

This guide walks through the decision, the sequence, the common structural mistake, and the checklist a cross-border legal team should apply before execution.

What decision does the reader actually face?

The starting question is deceptively simple: who is sending what data to whom, and where does it flow? The answer to that question determines which regime – or regimes – applies, and in which order the compliance gates must be cleared.

A cross-border SaaS arrangement may involve a Hong Kong entity contracting with a Mainland entity for access to a cloud-based platform. It may involve a Mainland operating company transferring user data to a Hong Kong or offshore group parent for processing. It may involve a foreign SaaS provider onboarding Mainland enterprise customers, with data stored on servers inside or outside the PRC. Each fact pattern engages a different combination of instruments. The regime that applies to a simple enterprise software subscription is not the same regime that applies to a data-processing arrangement where Mainland personal information leaves the border.

Three options typically sit on the table at the structuring stage. First, the parties can structure the arrangement so that Mainland personal information stays within the PRC border, with only non-personal or de-identified data crossing. Second, they can implement one of the CAC-prescribed transfer mechanisms – a standard contract, a security assessment filing, or, where the processor volume qualifies, personal information protection certification. Third, they can restructure the service model so that the Mainland entity processes locally and the cross-border element is limited to aggregated outputs that do not attract the transfer rules. Each option has a different cost in time, documentation and commercial flexibility. Our desk regularly advises on which option is viable given the data type, the volume thresholds, and the service architecture the parties actually want.

Which instruments govern – and which regulator enforces?

The Mainland's data-regulatory architecture operates across three principal layers, and all three can be engaged by a single SaaS or data agreement.

The first layer is the Personal Information Protection Law (PIPL, the primary Mainland statute governing personal information). It sets the legal basis for processing, the requirements for cross-border transfer of personal information, and the obligations of controllers and processors. Where a foreign entity processes the personal information of individuals located in the Mainland – even without a physical presence inside the PRC – the PIPL applies extraterritorially.

The second layer is the Data Security Law (DSL), which sits above the PIPL and introduces a data-classification system. Data classified as "important data" or "core state data" attracts heightened restrictions on cross-border transfer and, in some sectors, outright prohibition. For SaaS arrangements, the DSL is most commonly triggered where the platform processes data for regulated industries – financial services, healthcare, energy or government-adjacent operators.

The third layer is the sector-specific regime. Financial-services entities on the Mainland operate under additional rules from the financial regulators alongside the PIPL and DSL. Telecommunications-adjacent services engage their own licensing layer. A SaaS provider selling into regulated Mainland industries cannot rely on a PIPL-compliant structure alone.

The CAC is the principal enforcement authority for the PIPL and DSL at the national level, operating alongside provincial cybersecurity authorities. The CAC administers the security assessment process for large-volume cross-border transfers and maintains the standard contract template for smaller transfers. Understanding which regulator has primary jurisdiction over your Mainland counterparty is a threshold step, not an afterthought.

On the Hong Kong side, the Personal Data (Privacy) Ordinance governs personal data collected or processed in Hong Kong. The Anti-Money Laundering and Counter-Terrorist Financing Ordinance is engaged where the SaaS arrangement touches virtual-asset services or financial intermediation. Where the arrangement involves a centralised virtual-asset trading platform, the Securities and Futures Commission is the licensing authority under the mandatory VATP (virtual-asset trading platform) licensing regime, which commenced 1 June 2023. Our cross-border practice works across both sides of this interface, and we coordinate with locally licensed Hong Kong firms on matters of Hong Kong law.

How does the cross-border interface between Hong Kong and the Mainland actually work in practice?

Hong Kong and the Mainland operate as two legally distinct systems. Data-privacy law is a direct illustration: the Mainland's PIPL and the Hong Kong Personal Data (Privacy) Ordinance are separate instruments with different definitions, different legal bases for processing, and different enforcement authorities. A SaaS agreement drafted to satisfy one system will not automatically satisfy the other.

The cross-border transfer question is where the interface becomes most consequential. Under the Mainland's rules, the transfer of personal information from the Mainland to Hong Kong is a cross-border transfer for PIPL purposes. Hong Kong is not treated as an internal transfer destination. This means a Mainland operating entity moving user data to a Hong Kong holding company – for cloud processing, group analytics, or customer-support functions – must comply with the CAC cross-border transfer mechanisms as fully as if the data were going to a server in Europe or the United States.

What are the practical implications for a SaaS provider headquartered in Hong Kong? If the provider's platform processes Mainland personal information, the provider must either (a) implement one of the prescribed transfer mechanisms before data leaves the Mainland, or (b) ensure that Mainland personal information is processed exclusively on Mainland-side infrastructure. A Hong Kong headquarters receiving raw Mainland personal information without a prior transfer mechanism in place is in breach of the PIPL, regardless of how the commercial contract is drafted.

This is the cross-border interface that most foreign in-house teams underestimate. The commercial agreement is often excellent. The data-flow analysis – the document that maps exactly where personal information moves and which mechanism governs each flow – is frequently absent. That gap is where enforcement begins.

For groups using Hong Kong as a regional hub – and the Greater Bay Area creates strong commercial pressure to do so – the structural answer is a data-flow architecture that is designed before the contract is drafted, not retrofitted after. We have acted on several arrangements of this kind, where the original agreement was commercially sound but legally inoperable because the data flows had not been mapped against the CAC regime before execution.

What is the step-by-step sequence, and what is the gate at each step?

The sequence below applies to a mid-market SaaS or data agreement involving Mainland personal information and a cross-border data flow. It is a practitioner's working order, not a regulatory summary.

Step 1 – Data-flow mapping. Before any drafting begins, identify every category of personal information that will be collected, processed or transferred; map every flow across the Mainland border; and classify the data under the Mainland's three-tier system (general personal information, sensitive personal information, important data). The gate here is classification: until the classification is complete, you cannot select the correct transfer mechanism, and any contract you draft may be structurally defective.

Step 2 – Transfer mechanism selection. Apply the CAC's threshold criteria to the classified data. For transfers of personal information that do not meet the CAC's volume or sensitivity thresholds, a standard contract (the CAC Standard Contract for Cross-Border Transfer of Personal Information) is the prescribed mechanism. For transfers above the thresholds, a CAC security assessment filing is required before transfer. For a personal information protection certification route, an accredited third-party assessor is engaged. The gate is threshold verification: the thresholds are volume-based and change as the regime matures, so parties should verify the current position before selecting the mechanism.

Step 3 – Impact assessment. A personal information protection impact assessment (PIPIA) is a mandatory step before cross-border transfer under the PIPL. The assessment documents the nature of the data, the purpose and method of transfer, the security measures applied, and the risks to data subjects. It is a substantive document, not a pro-forma. The gate is completion and retention: the PIPIA must be completed and retained before any cross-border transfer occurs.

Step 4 – Agreement drafting and integration of the transfer mechanism. The commercial SaaS or data agreement is drafted alongside – or, more accurately, constrained by – the transfer mechanism documentation. Where a standard contract is used, its terms cannot be materially modified. Where a security assessment filing is required, the commercial terms must be consistent with the filed documentation. The gate is consistency: discrepancies between the commercial agreement and the transfer mechanism documentation are a regulatory red flag and, in an enforcement scenario, a liability aggravator.

Step 5 – Governing law and dispute resolution clause. This is where the cross-border interface of Hong Kong and the Mainland becomes commercially decisive. The choice of governing law determines which court or arbitral tribunal interprets the agreement. For a cross-border arrangement, Hong Kong law and HKIAC arbitration is a common and well-tested combination: the Arbitration Ordinance (Cap. 609) governs Hong Kong-seated arbitration, modelled on the UNCITRAL Model Law, and the HKIAC Administered Arbitration Rules (in their 2024 version, effective 1 June 2024) provide an institutional framework that Mainland counterparties regularly accept. Enforcement of an HKIAC award in the Mainland runs via the mutual-enforcement Arrangements between the Mainland and the HKSAR, not the New York Convention. The gate is enforceability: a dispute-resolution clause that cannot be given effect in the jurisdiction where the counterparty's assets sit is commercially worthless.

Step 6 – Ongoing compliance architecture. A SaaS agreement is a continuing arrangement. The data flows it creates do not stop at signature. Build the compliance architecture into the agreement: data-subject rights response procedures, breach notification timelines, sub-processor approval rights, periodic impact-assessment refresh, and a mechanism for responding to regulatory changes. The gate is operationality: the agreement must function as a compliance document, not merely as a commercial one, for its full term.

The sequence above describes the standard position. Your matter turns on the documents, the jurisdictions actually engaged, and the order of steps – which is where the route is won or lost. To discuss how these steps apply to your specific arrangement, write to us at info@lockhartyip.com.

What do advisers unfamiliar with the Mainland regime typically get wrong?

The most common structural mistake is treating the Mainland's data regime as a privacy-compliance layer to be added after the commercial terms are settled. It is not. The Mainland data rules are threshold conditions for the legality of the arrangement. An agreement that transfers Mainland personal information without a compliant transfer mechanism is in breach of the PIPL from the first data flow, regardless of what the commercial contract says about governing law, dispute resolution, or liability caps.

A second error is the assumption that a GDPR-compliant data-processing agreement, or a standard DPA designed for European transfers, maps onto the Mainland's requirements. It does not. The CAC standard contract has a different structure, different mandatory clauses, and different obligations on the data exporter and importer than a GDPR standard contractual clause. Using a European template as a substitute for a CAC standard contract is a compliance failure, and one that enforcement authorities have noted in enforcement actions.

A third error – one we see frequently in arrangements structured through Hong Kong holding entities – is the assumption that processing in Hong Kong takes the arrangement outside the Mainland's extraterritorial reach. The PIPL's extraterritorial scope covers any entity processing the personal information of individuals located in the Mainland, regardless of where the processing occurs. A Hong Kong-based data processor receiving Mainland personal information is within scope. The one country, two systems arrangement does not create a data-protection safe harbour.

A fourth, subtler error is misidentifying the controller and the processor in the Mainland context. The PIPL's allocation of obligations between controllers (entities that determine the purpose and means of processing) and processors (entities that process on behalf of controllers) differs from the GDPR's allocation in ways that affect which entity must implement the transfer mechanism, which entity must conduct the PIPIA, and which entity is the first point of CAC contact in an investigation.

If an earlier filing, structure or enforcement attempt produced an adverse or stalled result, a second read can identify the strategic error and the routes still open. Write to us at info@lockhartyip.com.

A cross-border scenario: restructuring the data flows before execution

A European enterprise software group entered negotiations with a Mainland healthcare technology company in mid-2027. The commercial arrangement was a SaaS subscription for patient-pathway analytics. The group's European legal team had prepared a comprehensive agreement under English law with GDPR-compliant data processing schedules. The Mainland counterparty's legal team flagged that the arrangement would involve the transfer of health data – classified as sensitive personal information under the PIPL – across the Mainland border to the group's EU cloud infrastructure.

Our desk was engaged at that point. The data-flow mapping showed three separate cross-border transfer flows, two of which involved health data at volumes that triggered the CAC security assessment requirement rather than the standard contract route. The commercial agreement's liability structure was also inconsistent with the mandatory clauses in the CAC's security assessment process. A fourth flow – from the group's Hong Kong regional office to the EU – was separately analysed under the Hong Kong Personal Data (Privacy) Ordinance.

The outcome was a restructured service architecture: Mainland health data was processed on a Mainland-hosted instance; only aggregated, de-identified outputs crossed the border. The cross-border SaaS agreement then operated on non-personal data, removing the CAC transfer mechanism requirement for the primary commercial flow. The Hong Kong office's separate data handling was brought into alignment with the Hong Kong Ordinance. The agreement executed on a timeline approximately three months after our engagement, with a governing-law clause of Hong Kong law and HKIAC arbitration for the commercial terms.

This type of restructuring – service-model adjustment before execution – is consistently less expensive than remediation after an enforcement inquiry.

Decision checklist for a cross-border SaaS or data agreement touching Mainland China

Apply this checklist before execution. Each item is a gate. An unchecked gate is an open compliance risk.

Data-flow map completed: every category of personal information identified; every cross-border flow mapped; classification under Mainland rules confirmed.
Transfer mechanism selected and implemented: standard contract, security assessment, or certification route chosen based on verified current thresholds; CAC standard contract terms not modified where that route is used.
PIPIA completed and retained: personal information protection impact assessment on file before first data transfer.
Controller/processor roles correctly allocated: obligations in the commercial agreement match the Mainland's allocation, not the GDPR's.
Sector-specific requirements checked: if the Mainland counterparty operates in a regulated sector (financial services, healthcare, telecommunications), additional sector rules reviewed.
Hong Kong Ordinance position confirmed: if a Hong Kong entity handles personal data, its obligations under the Personal Data (Privacy) Ordinance reviewed alongside the Mainland requirements.
Governing law and dispute-resolution clause operable: the chosen forum can receive and enforce a claim; where HKIAC arbitration is selected, the Mainland counterparty's assets are reachable via the mutual-enforcement Arrangements.
Ongoing compliance architecture built into the agreement: breach notification, sub-processor approval, periodic PIPIA refresh, and a regulatory-change mechanism included.
Extraterritorial scope confirmed: if the foreign party's platform processes the personal information of individuals located in the Mainland, PIPL compliance confirmed regardless of server location.
Virtual-asset or financial intermediation overlay checked: if the SaaS arrangement touches virtual-asset services, confirm whether VATP licensing or SFC authorisation applies on the Hong Kong side.

For guidance on applying this checklist to your specific arrangement across Hong Kong and the Mainland, write to us at info@lockhartyip.com.

Related practices

Tech & Web3 – licensing, AML compliance and regulatory engagement for technology and virtual-asset businesses in Hong Kong and cross-border
Sanctions & AML – counterparty due diligence, source-of-funds analysis and AML compliance file preparation for cross-border arrangements

Frequently asked questions

Which jurisdiction's law applies to a cross-border SaaS or data agreement touching Mainland China?

The governing law of the commercial contract and the law that regulates the data flows are separate questions. The parties may choose Hong Kong law for the commercial agreement – a common and enforceable choice for Mainland-connected arrangements – but the Mainland's PIPL applies to the cross-border transfer of personal information of individuals located in the Mainland regardless of the contractual choice of law. Both layers must be addressed, and they must be addressed in sequence: the data compliance position determines what the commercial agreement can validly do.

What is the first step in a cross-border SaaS or data agreement touching Mainland China?

The first step is a data-flow mapping exercise conducted before any drafting begins. The mapping identifies every category of personal information involved, every flow across the Mainland border, and the applicable classification under the Mainland's three-tier data-classification system. Until the mapping is complete, it is not possible to select the correct cross-border transfer mechanism, and any contract drafted without it may be structurally non-compliant with the Personal Information Protection Law from the first data transfer.

Do I need a Hong Kong adviser for a cross-border SaaS or data agreement touching Mainland China?

A Hong Kong adviser with cross-border experience is particularly relevant where the arrangement uses Hong Kong as a hub – a holding entity, a regional data-processing centre, or the contracting party on the non-Mainland side. The adviser can structure the Hong Kong side of the arrangement, advise on the governing-law and dispute-resolution clause, and coordinate the Mainland-law compliance work with appropriate Mainland counsel. Lockhart & Yip acts on international and cross-border aspects of these arrangements and coordinates with locally licensed firms on Hong Kong and Mainland law matters.

Speak with Lockhart & Yip

For a scoped view of your matter, contact info@lockhartyip.com. Discuss your matter →

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@lockhartyip.com.

A practical guide to a cross-border SaaS or data agreement touching Mainland China