Where a cross-border SaaS or data agreement touching Mainland China stands now

A SaaS agreement that routes personal data from a Mainland Chinese entity to a server outside China is not a standard software contract with an international flavour. It is a regulated cross-border data transaction, subject to a data-export regime that has been built, revised, and partially relaxed since the Personal Information Protection Law came into force. For a general counsel signing a data-processing addendum or a cloud-services agreement today, the threshold question is not which governing law clause to use. It is whether the transaction is permitted at all, and under which mechanism.

A cross-border SaaS or data agreement touching Mainland China is currently governed by a layered regime under the Personal Information Protection Law, the Data Security Law, and the administrative measures issued by the Cyberspace Administration of China. The cross-border interface with Hong Kong is direct: Hong Kong operates a separate, common-law data-protection regime under the Personal Data (Privacy) Ordinance, without Mainland-law extraterritorial reach, which creates an asymmetric compliance picture for any arrangement that moves data in both directions across the boundary. The route for any cross-border data flow depends on the volume, sensitivity, and category of data involved – and the threshold triggers that determine which of three main mechanisms applies.

This analysis works through the commercial stakes, the governing instruments on both sides of the boundary, the comparative read across the two systems, and where the risk sits now for counterparties structuring or reviewing a cross-border SaaS or data agreement.

What is commercially at stake in a cross-border SaaS or data agreement?

The commercial stakes are high, and they are asymmetric. A SaaS provider based outside Mainland China – whether in Hong Kong, the United States, or Europe – that serves Mainland enterprise clients is almost certainly processing personal information of Mainland residents. That processing triggers the Personal Information Protection Law regardless of where the provider is incorporated. The law's extraterritorial reach is clear on this point.

For the Mainland enterprise client, the stakes are different but equally material. A data-processing or SaaS agreement that involves a cross-border transfer without a compliant mechanism in place exposes the client's own data-compliance programme. Regulators in the Mainland have imposed fines and restrictions on enterprises for failing to govern their data-processor relationships. The client's compliance team – not just the foreign provider – carries residual exposure when the agreement is silent on cross-border-transfer mechanics.

What does this mean commercially? A SaaS agreement that does not address Mainland data-export mechanics is not simply incomplete. It may be unenforceable in the sense that the processing activity it purports to authorise is, in the absence of a permitted mechanism, not lawful under Mainland law. That is a meaningful contract-risk point. It is also a deal-structuring issue: the mechanism chosen will affect data localisation requirements, audit rights, sub-processor restrictions, and the latency of cross-border data flows.

In our cross-border practice, we regularly see agreements drafted entirely under a foreign governing-law clause – often English law or New York law – that make no mention of the Mainland's data-export regime. The governing-law clause does not displace Mainland public-law obligations. That gap is where the regulatory exposure begins.

What are the governing instruments, and how do they interact?

Three Mainland instruments form the core of the cross-border data regime. The Personal Information Protection Law is the primary statute. The Data Security Law governs data in the broader sense, including data that may not constitute personal information. The administrative measures on cross-border data flows – issued by the Cyberspace Administration of China and periodically amended – set the practical conditions for each permitted mechanism.

Under the current administrative-measures regime, there are three main routes for a lawful cross-border personal-information transfer out of Mainland China. First, a security assessment conducted by the Cyberspace Administration. This route is mandatory above certain volume and sensitivity thresholds. Second, standard contractual clauses (the SCC mechanism, the Mainland's own version, which differs in material respects from the European standard contractual clauses under the GDPR). Third, a personal information protection certification issued by a qualified institution. The Cyberspace Administration has published guidance on the conditions for each route, and partial relaxations have been introduced for non-sensitive data below certain volume thresholds.

The Data Security Law adds a parallel layer. Certain categories of data are classified as "important data" under a grading system administered sectorally. For important data, the restrictions on cross-border transfer are stricter, and the security-assessment route is generally mandatory regardless of volume. SaaS agreements that process operational or industrial data for Mainland enterprises often touch important-data categories without the parties having conducted a formal data-classification exercise.

On the Hong Kong side, the Personal Data (Privacy) Ordinance applies to data users in Hong Kong, and it imposes obligations on the transfer of personal data from Hong Kong to third parties – including processors and sub-processors outside Hong Kong. The Ordinance's data-protection principles require contractual protections when data is transferred to a processor. Since 1 October 2012, the direct-marketing provisions have been substantially tightened. The Ordinance does not, however, impose a general restriction on cross-border transfer in the way the Mainland regime does. There is no security-assessment requirement for a Hong Kong-to-overseas transfer. That asymmetry is significant for structure.

The two regimes do not speak to each other formally. There is no mutual-recognition arrangement, no joint regulatory body, and no cross-boundary data-flow corridor for commercial SaaS purposes analogous to the EU–UK adequacy decision. The "one country, two systems" principle means the Mainland's data-export rules stop at the boundary, but a SaaS architecture that routes data from the Mainland through Hong Kong to a third country must comply with the Mainland rules at the point of export, regardless of Hong Kong's more permissive position.

How does the cross-border interface between Hong Kong and Mainland China actually bite?

The interface bites at three points in a typical SaaS or data-processing arrangement: the point of data collection, the point of cross-border transfer, and the point of sub-processing.

At collection, a Mainland enterprise collecting personal information of Mainland residents for processing by a foreign SaaS provider must give appropriate notice and obtain consent (or rely on another lawful basis) under the Personal Information Protection Law. The notice must include information about the cross-border transfer itself, and in some cases the data subject has the right to refuse. This is an upstream contractual and operational requirement that many enterprise SaaS customers have not fully integrated into their user-consent flows.

At transfer, the mechanism must be in place before the data moves. The standard contractual clauses mechanism – the most commonly used route for mid-volume commercial arrangements – requires the Mainland enterprise to enter into a prescribed-form contract with the overseas recipient. The form is prescribed; it is not freely negotiable on its core terms. A SaaS provider that requires back-to-back data-processing terms with its own sub-processors must ensure those terms are consistent with the Mainland SCC obligations. That is a contract-architecture point that frequently surfaces in our cross-border practice when a foreign provider's standard data-processing addendum conflicts with the Mainland's prescribed SCC form.

At sub-processing, the Mainland rules effectively require the overseas recipient to impose equivalent restrictions on any onward transfer. For a SaaS provider using hyperscale infrastructure in multiple regions, this creates a mapping problem: which of the provider's infrastructure sub-processors are receiving Mainland personal information, and are those onward transfers covered by a permitted mechanism in their own right? Cloud providers have begun publishing specific Mainland-compliance documentation, but the contractual architecture between the enterprise client, the SaaS provider, and the infrastructure layer still requires deliberate assembly.

The Hong Kong dimension adds a further layer where the SaaS provider is itself a Hong Kong entity. A Hong Kong-incorporated SaaS company that operates under a Hong Kong-law contract is not exempt from the Mainland's extraterritorial provisions merely because it is outside the Mainland. But it is also subject to the Personal Data (Privacy) Ordinance in its own right. A Hong Kong-based SaaS provider may therefore have to satisfy both regimes – the Ordinance for its own obligations as a Hong Kong data user, and the Mainland rules for its role as an overseas recipient of Mainland personal information.

For a structured assessment of cross-border SaaS or data-agreement positions across Hong Kong and Mainland China, the governing instruments, and the compliance architecture your specific arrangement requires, write to us at info@lockhartyip.com.

What does a comparative read across the two systems reveal?

The Mainland and Hong Kong data regimes share a common ancestry in OECD data-protection principles, but their practical architecture is now substantially different. The comparison is instructive for any cross-border arrangement.

The Mainland regime is consent-and-mechanism-first. A lawful cross-border transfer requires a positive enabling step: either the security assessment, the SCC, or the certification. Absence of a mechanism is not a gap that can be cured by a well-drafted contract alone. The contract is the mechanism, or part of it, but the contract is not self-sufficient.

The Hong Kong regime is principles-based and less prescriptive on cross-border transfer. The Ordinance requires data users to take contractual or other steps to protect personal data transferred to processors, but it does not prescribe a mandatory-form contract. It does not require a security assessment before an international transfer. The Privacy Commissioner's guidance sets out best practice, but the regulatory enforcement posture has historically been less prescriptive on cross-border mechanics than the Mainland.

What does this mean for a SaaS provider choosing Hong Kong as its contracting entity? It means the Hong Kong position is the easier side of the equation to satisfy. The difficulty lies on the Mainland side, where the compliance obligations travel with the data regardless of the contract's governing law or the provider's place of incorporation. A provider that structures its contract through a Hong Kong entity under Hong Kong law does not thereby escape the Mainland's administrative requirements.

Consider a practical scenario. A European technology company establishes a Hong Kong subsidiary to serve its Mainland enterprise clients. The subsidiary enters into SaaS agreements under Hong Kong law with Mainland clients. The subsidiary's servers are in Singapore. Data flows from Mainland China to the Singapore infrastructure via the Hong Kong entity. At the point of export from the Mainland, the Mainland's cross-border data-transfer rules apply. The Hong Kong entity's involvement in the chain does not constitute a permitted mechanism. The Mainland enterprise client must still execute a prescribed SCC with the overseas recipient – which in this structure is the Hong Kong subsidiary or the Singapore infrastructure operator, depending on the data-flow architecture.

A second scenario. An Asia-Pacific SaaS provider headquartered in Hong Kong has a product used by both Mainland Chinese and Southeast Asian enterprise clients. The product logs user-behaviour data centrally. The provider's data-residency architecture was designed for a Southeast Asian customer base. When the Mainland enterprise clients came on board, the cross-border data mechanics were not revisited. In autumn 2026, a Mainland client's internal audit flagged the gap. The SaaS provider had to retrofit the compliance architecture – separate SCC execution, data-residency adjustments, and sub-processor mapping – under time pressure and contractual renegotiation risk. That sequence, which our desk sees with some regularity, is considerably more costly than front-loading the structure.

Where does the risk sit now under the current data-export regime?

The Cyberspace Administration's measures have been revised more than once since the Personal Information Protection Law came into force, and the general direction has been to create workable commercial pathways rather than to restrict all cross-border transfers. Certain exemptions and threshold relaxations have been introduced for lower-volume transfers of non-sensitive data, and the SCC route has become the primary mechanism for mid-market SaaS arrangements.

The risk, as the position now stands, is concentrated in three areas.

First, volume and threshold creep. Arrangements that were initially below the security-assessment thresholds can breach those thresholds as a product scales. A SaaS provider that assessed its Mainland transfer volumes at contract inception may be in a different position eighteen months later. The assessment is not a one-time exercise. Obligations migrate as volume grows, and the assessment should be revisited periodically. Contracts that do not build in a review mechanism are structurally exposed to the risk that the chosen mechanism becomes inadequate without either party noticing.

Second, important-data misclassification. The data-security grading system for important data is implemented sectorally, and the sectoral catalogues are not uniformly published or final. A SaaS provider processing operational data for a Mainland manufacturing, energy, or financial-services client may be handling important data under the relevant sectoral catalogue without having conducted a formal classification exercise. Important-data status changes the mechanism: the SCC route may not be available, and a security assessment may be required. Misclassification – treating data as ordinary personal information when it is important data – is not a technical error that can be corrected retroactively without regulatory exposure.

Third, contract-architecture fragmentation. A SaaS provider that has executed Mainland SCCs with its enterprise clients, but whose sub-processor agreements do not address the onward-transfer restrictions, has a gap between the Mainland compliance documentation and the actual data-flow architecture. The Mainland rules require that the onward-transfer protections travel with the data. A gap at the sub-processor layer is not a minor omission; it is a structural hole in the compliance position.

If an earlier structure or compliance filing produced a stalled or adverse result, or if a cross-border SaaS arrangement has grown in scope without a corresponding review of the data-export mechanisms in place, a second read can identify the strategic error and the routes still open. Write to info@lockhartyip.com to discuss your position.

How does the licensing and AML dimension interact with data agreements?

For SaaS or data arrangements in the technology and Web3 space, the data-export question does not sit in isolation. It frequently intersects with the licensing posture of the product itself and with anti-money laundering (AML) obligations where the SaaS product processes financial transactions or virtual-asset transfers.

A SaaS product that provides payment-processing, digital-asset custody, or financial-intermediation functionality for Mainland users may require licensing in the Mainland under the relevant financial-services regime, in addition to satisfying the data-export rules. The data flows and the licensing obligations are not the same question, but they are governed by the same commercial relationship. A SaaS agreement that processes financial transaction data is likely to involve important data under the financial-services sectoral catalogue, which affects the choice of data-export mechanism.

On the Hong Kong side, a SaaS provider that operates a virtual asset trading platform (VATP) – a centralised platform for trading virtual assets – is subject to mandatory licensing under the Anti-Money Laundering and Counter-Terrorist Financing Ordinance, with the Securities and Futures Commission as the licensing authority. The VATP licensing regime commenced on 1 June 2023. Where the SaaS product includes virtual-asset functionality, the licensing obligations and the data obligations run in parallel. AML and FATF travel rule (the requirement to transmit originator and beneficiary information for virtual-asset transfers) requirements apply to VATPs in Hong Kong, and compliance with those requirements involves data-handling obligations that are not identical to the Mainland's data-export regime.

The intersection point is the sub-processor layer. A Hong Kong-licensed VATP that uses Mainland-based technology infrastructure, or a Mainland enterprise that integrates a Hong Kong SaaS product for virtual-asset purposes, must navigate both the Mainland data-export rules and the Hong Kong licensing requirements simultaneously. That is not a theoretical scenario. Our desk sees arrangements of this kind with some regularity, and the compliance architecture for both regimes must be assembled deliberately rather than by analogy from either system alone.

See also our analysis of digital asset funds structured through Hong Kong and the Mainland, where the interaction between Hong Kong's licensing framework and Mainland regulatory posture is examined in a different product context. The structuring logic for a SaaS arrangement and a digital-asset fund diverge, but the cross-border compliance architecture they require shares common elements.

What foreign counsel routinely get wrong, and what the sequence should look like

Foreign counsel advising on cross-border SaaS agreements from outside the region routinely make three errors that have predictable consequences.

The first is treating the Mainland data-export rules as analogous to GDPR. The GDPR framework – adequacy decisions, standard contractual clauses, binding corporate rules – is the reference point for European lawyers. The Mainland's prescribed SCC form is not the European SCC. The security-assessment mechanism has no direct GDPR equivalent. The important-data concept has no GDPR counterpart. Mapping Mainland obligations onto a GDPR template is not simply imprecise; it can produce a compliance document that satisfies neither regime.

The second error is treating the choice of governing law as a substitute for Mainland compliance. A SaaS agreement governed by English law or New York law, with dispute resolution in Hong Kong arbitration under the HKIAC Administered Arbitration Rules, is a perfectly standard structure for a cross-border technology agreement. It does not, however, displace the Mainland's public-law data-export obligations. Governing-law clauses govern private rights between the parties. Mainland administrative requirements apply regardless of the parties' choice of law.

The third error is staging the compliance work after the commercial agreement is signed. Data-export mechanisms, particularly the security assessment and the SCC, require steps that precede or accompany the commencement of data transfers. Retrofitting compliance architecture into a live SaaS relationship – after data has been flowing, after the security-assessment threshold has been breached, after the commercial agreement has been executed without the prescribed-form SCC – is structurally more complex, more costly, and more likely to require contractual renegotiation than front-loading the work.

The sequence that actually works looks like this. The data-flow mapping exercise comes first: what data, from whom, to where, in what volume, with which sub-processors. The classification exercise follows: ordinary personal information, sensitive personal information, or important data under the relevant sectoral catalogue. The mechanism selection comes next: security assessment, SCC, or certification, depending on volume and classification. The contract architecture is then built around the selected mechanism, including the sub-processor chain. The Mainland enterprise client's consent flow and notice requirements are verified against the data-flow map. And a review trigger is built into the commercial agreement so that the compliance architecture is revisited when volumes or data categories change.

That is not a complicated sequence. But it requires the cross-border compliance question to be asked before the commercial terms are settled, not after. The difficulty, in our experience, is that the commercial teams on both sides of a SaaS negotiation are focused on price, service-level agreements, and liability caps. The data-export compliance question tends to surface late, when it should be anchored early.

For a structured read on your cross-border SaaS or data-agreement position – the data-flow map, the mechanism choice, and the contract architecture across Hong Kong and the Mainland – contact us at info@lockhartyip.com.

Where is this heading, and what is the practical position now?

The Mainland's data-export regime has developed in the direction of workable commercial pathways. The Cyberspace Administration's successive revisions to the administrative measures have created meaningful exemptions for lower-volume and non-sensitive transfers, and the SCC route has been operationalised with published prescribed forms. The direction of travel is toward a functioning cross-border data-transfer regime, not toward a blanket restriction.

That said, the regime remains dynamic. Sectoral catalogues for important data are still being developed. The security-assessment thresholds and the conditions for the SCC route have changed more than once, and they may change again. For a cross-border SaaS agreement that involves a Mainland party, any compliance assessment should include an explicit verification step against the current version of the administrative measures. Historical assessments do not carry forward automatically.

The position now, practically, is this. A cross-border SaaS agreement touching Mainland China that does not address the data-export mechanism explicitly is a structurally incomplete agreement. Whether that incompleteness creates immediate regulatory exposure depends on the data volume, the data classification, and the sub-processor architecture. But the question is not whether the gap matters; it is how quickly it matters and who it matters to first.

For the foreign SaaS provider, the first exposure is typically a Mainland enterprise client's audit right or a contractual compliance warranty. For the Mainland enterprise client, the first exposure is typically the Cyberspace Administration's administrative-enforcement posture. For the Hong Kong entity in the middle – the subsidiary, the reseller, the regional contracting entity – the first exposure is typically the need to renegotiate the commercial agreement to accommodate a compliance architecture that was not built in from the start.

Our desk's read is that the risk for mid-market cross-border SaaS arrangements sits primarily in the contract-architecture gap: not in the existence of a regime that prohibits cross-border transfers, but in the mismatch between what the commercial agreement purports to authorise and what the Mainland compliance documentation actually covers. That gap is manageable if it is addressed before the agreement is signed and before data flows begin. It becomes progressively harder to manage once the commercial relationship is live.

See our Tech & Web3 practice page for the range of cross-border technology and digital-asset matters we advise on, and our analysis of stablecoin and digital-asset custody arrangements for related structuring considerations at the intersection of Mainland and Hong Kong regulatory requirements.

Related practices

• Sanctions & AML – AML compliance, source-of-funds, and sanctions-neutral contracting for cross-border arrangements
• Corporate Counsel – cross-border entity structuring, governance, and contract architecture for international groups

Speak with Lockhart & Yip

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

Related

• Tech Web3
• Digital Asset Fund Structured Through Hong Kong Mainland 3
• Stablecoin Or Digital Asset Custody Arrangement

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