How to approach a cross-border SaaS or data agreement touching Mainland China

A SaaS deployment that routes user data across the Mainland border looks, on paper, like a standard software transaction. In practice, it sits at the intersection of three distinct regulatory regimes – data localisation and cross-border transfer rules under Mainland Chinese law, Hong Kong's own data-protection position, and the international contractual standards the SaaS provider's home jurisdiction imposes. Each of those three systems has its own gating conditions, and they do not always sequence in the same order.

A cross-border SaaS or data agreement touching Mainland China requires a structured approach: identify which regulatory regime attaches to each data flow, confirm the transfer mechanism the Mainland rules demand for that category of data, and draft the commercial agreement so that its governing-law and enforcement clauses reflect the forum where the contract can realistically be honoured. The governing instruments on the Mainland side include the Personal Information Protection Law, the Data Security Law, and the Measures on Security Assessment of Cross-Border Data Transfers, each of which imposes conditions that must be satisfied before the data leaves the jurisdiction. Since 29 January 2024, when the Mainland Judgments in Civil and Commercial Matters (Reciprocal Enforcement) Ordinance (Cap. 645) came into force, Hong Kong has become a materially more viable choice of forum for the dispute-resolution clause of agreements between Mainland and offshore counterparties.

This guide works through the key decisions in order – from the initial characterisation question to the governing-law choice, the contract architecture, and the enforcement posture – and identifies the point at which each decision becomes irreversible.

What is the commercial question the parties are actually answering?

Before any drafting begins, the in-house team needs to characterise the transaction precisely, because that characterisation drives everything that follows. A SaaS agreement that processes only anonymised, non-personal operational metrics sits in a different regulatory category from one that transfers gè rén xìnxī (personal information, as defined under the Personal Information Protection Law) of Mainland-resident users to servers outside the PRC. The distinction matters enormously: the former may require no specific Mainland cross-border mechanism; the latter triggers a mandatory compliance pathway.

Three questions determine the regulatory weight of the arrangement. First: where are the data subjects resident? Second: where is the data stored and processed? Third: is any of the data "important data" as defined under the Data Security Law, which imposes additional controls independent of whether the data is personal information? Many in-house teams focus on the first question and overlook the second and third entirely. That is the single most common framing error our desk sees on transactions of this kind.

The answer to those three questions produces one of four scenarios. The data is entirely anonymised and does not relate to Mainland-resident individuals – in which case the Mainland cross-border data transfer regime likely does not attach, though data-security obligations may still apply. The data involves personal information of Mainland residents, the volume is below the thresholds that trigger mandatory security assessment, and a standard contractual clause mechanism under the Mainland rules is available. The data involves personal information above those thresholds, or includes critical information infrastructure data, or is classified as important data – each of which demands security assessment and, potentially, government approval. Or the arrangement involves a Mainland entity providing SaaS to an offshore customer, in which case the data flows are reversed and the analysis changes again.

Getting this characterisation right at the outset is not a formality. A contract negotiated, signed, and deployed on the wrong assumption about data classification may be unenforceable on the Mainland side from day one.

How does the Mainland data-transfer regime actually work for a SaaS arrangement?

The Mainland cross-border data-transfer regime operates through three parallel mechanisms, and the applicable mechanism depends on the volume and sensitivity of the personal information being transferred. The Personal Information Protection Law sets the overarching obligation: a personal-information processor that transfers personal information outside the PRC must use one of the permitted mechanisms – security assessment approved by the Cyberspace Administration of China, certification by a qualified institution, or a standard contract filed with the Cyberspace Administration. The Data Security Law adds a separate tier for data classified as important data, regardless of whether that data constitutes personal information.

The Measures on Security Assessment of Cross-Border Data Transfers set out the thresholds that make security assessment mandatory rather than optional. Those thresholds turn on the volume of personal information transferred, the involvement of sensitive personal information, and whether the transferring entity operates critical information infrastructure. Where mandatory assessment applies, the parties cannot proceed simply by signing a standard contract; the Mainland entity must apply to and receive approval from the Cyberspace Administration before transfer begins.

For a mid-sized SaaS deployment below the mandatory-assessment thresholds, the standard-contract route is the more common path. It requires the parties to execute a standard contract in the prescribed form and for the Mainland entity to file it with the local branch of the Cyberspace Administration within a defined period. The standard contract itself is not freely negotiable: its core clauses on the obligations of the data exporter and data importer are fixed. The commercial agreement between the SaaS provider and the Mainland customer must sit alongside this standard contract without contradicting it.

What does this mean for the SaaS agreement itself? The commercial terms – pricing, service levels, liability caps, termination – live in the main commercial agreement. The data-transfer obligations and the data-subject rights provisions live in the standard contract. Both documents must be executed, and the main commercial agreement must not attempt to qualify or override the data-subject protections in the standard contract. Where counsel for the SaaS provider draft the commercial agreement first and treat the data annex as an afterthought, they routinely introduce exactly that contradiction.

Where does Hong Kong sit in the structure, and why does it matter?

Hong Kong is not merely a convenient neutral forum for cross-border tech agreements. It is a common-law jurisdiction with a well-developed body of commercial contract law, an independent judiciary, and a functioning mechanism – since 29 January 2024 under Cap. 645 – for the registration and enforcement of Mainland civil and commercial judgments in Hong Kong, and reciprocally for the recognition of Hong Kong judgments in the Mainland courts. For a SaaS agreement between a Mainland entity and an offshore provider, Hong Kong arbitration or Hong Kong court proceedings represent a genuinely bilateral enforcement route, not merely an offshore fallback that the Mainland counterparty can ignore.

That bilateral character changes the negotiating dynamic. An offshore SaaS provider that previously had to choose between Mainland courts (with jurisdiction over the customer's assets but unfamiliar procedural terrain) and an offshore forum (procedurally comfortable but disconnected from enforcement) now has a third option: Hong Kong dispute resolution combined with Hong Kong-seated arbitration under the HKIAC Administered Arbitration Rules, coupled with the interim-measures Arrangement that has been available since 1 October 2019 for Hong Kong-seated arbitrations seeking Mainland interim relief. That combination provides both a credible enforcement route into the Mainland and the procedural protections of a common-law seat.

Hong Kong's own data-protection position adds a further consideration. The Personal Data (Privacy) Ordinance governs personal data processed in or through Hong Kong, and a SaaS provider with a Hong Kong processing entity must ensure that its data-handling practices comply with both the Hong Kong Ordinance and the obligations flowing from the Mainland standard contract it has executed. Those two regimes are not identical. The due-diligence step before signing is to map which individuals' data is subject to which regulatory regime at each stage of the data flow.

In our cross-border practice, the most commercially effective structures for SaaS agreements with Mainland exposure use a Hong Kong entity as the contracting vehicle on the provider side, governed by Hong Kong law, with HKIAC arbitration as the dispute-resolution mechanism. That structure keeps the commercial agreement within a well-tested common-law framework, provides a bilateral enforcement route, and separates the commercial layer from the Mainland regulatory compliance layer in a way that is architecturally clean and practically manageable.

For a broader view of how our desk approaches Tech & Web3 matters with a cross-border dimension, see our Tech & Web3 practice.

The sequence above describes the standard position. Your specific 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 the cross-border data-transfer and dispute-resolution architecture applies to your SaaS or data agreement, contact info@lockhartyip.com.

What is the correct sequence, and where is the gate at each step?

Most cross-border SaaS negotiations fail at one of five sequential gates. Working through them in order avoids the most common structural errors.

Gate 1: Data classification. Before the commercial terms are drafted, map every category of data the arrangement will touch. Determine whether any data involves personal information of Mainland residents, whether any data constitutes important data under the Data Security Law, and whether the volume of personal information is likely to cross the mandatory-assessment thresholds over the term of the agreement. This mapping exercise is not a legal opinion in the abstract; it requires input from the technical team about actual data flows. If the mapping is done after the commercial terms are agreed, the parties may find that their agreed commercial structure is incompatible with the required regulatory mechanism.

Gate 2: Transfer-mechanism selection. Once data categories are mapped, identify the applicable transfer mechanism: security assessment, certification, or standard contract. If mandatory security assessment applies, the Mainland party must begin the application process before any data transfer takes place. That process takes time, and the commercial timeline must accommodate it. A SaaS agreement that is commercially effective from a specified date but requires a completed security assessment before data transfer can begin must either build in the assessment timeline or stage the go-live date accordingly.

Gate 3: Contract architecture. Draft the commercial agreement and the data-transfer instrument as a coordinated pair. The commercial agreement should acknowledge the existence and primacy of the data-transfer compliance mechanism. It should not contain representations about data-handling practices that are inconsistent with the standard contract or the security assessment approval. Liability caps and indemnities in the commercial agreement must be calibrated to the risk profile that the data-transfer regime creates: data-subject rights claims and regulatory enforcement actions in the Mainland are not standard commercial contract risks, and the parties need to have an agreed position on how they are allocated.

Gate 4: Dispute-resolution architecture. Choose the governing law and dispute-resolution mechanism with enforcement in mind, not convenience. Hong Kong law and HKIAC arbitration provide a bilateral enforcement route. If the parties choose a third-country law and a non-HKIAC seat, they lose the benefit of the reciprocal-enforcement architecture between Hong Kong and the Mainland. They also lose access to the interim-measures Arrangement, which allows a Hong Kong-seated arbitral tribunal to seek interim relief from Mainland courts – a significant tactical advantage if a dispute arises and assets are held in the Mainland.

Gate 5: Compliance operationalisation. Once the agreement is executed and the data-transfer mechanism is in place, the ongoing compliance obligations begin. These include data-subject rights management, incident-response procedures, and – where a standard contract has been filed – the obligation to notify the Cyberspace Administration if specified changes occur. The commercial team should ensure that the SaaS provider has the operational capability to fulfil these obligations before the agreement goes live, not after the first data-subject complaint arrives.

Each gate is a genuine decision point. Passing through it without addressing the underlying question does not make the question go away; it defers it to a moment of greater pressure and lesser control.

What do providers and customers most commonly get wrong?

The most persistent error is treating the data-transfer compliance mechanism as a post-signing formality. In a significant number of the cross-border SaaS arrangements our desk reviews, the commercial agreement has been executed and the service has gone live before the data-transfer mechanism – security assessment or standard contract – has been completed or filed. That sequencing error exposes both the Mainland entity and, indirectly, the offshore provider to regulatory risk under the Cyberspace Administration's enforcement framework.

A second common error is using a governing-law and arbitration clause that was drafted for a purely offshore transaction. A clause providing for the law of a European jurisdiction and arbitration at a European seat may be entirely appropriate for a transaction with no Mainland nexus. Applied to a SaaS agreement with a Mainland counterparty and Mainland data flows, it removes the bilateral enforcement advantage that a Hong Kong seat and Hong Kong governing law would provide, without offering any countervailing benefit for disputes that arise in the Mainland context.

A third error is failing to anticipate how the standard contract's data-subject rights provisions interact with the commercial liability regime. The standard contract imposes obligations on the data importer that, in some circumstances, can give rise to claims by Mainland data subjects against the offshore provider. Commercial liability caps that were sized for software defect claims may be entirely inadequate for data-protection regulatory exposure. Counsel who draft the commercial agreement without reading the standard contract alongside it routinely miss this interaction.

A fourth, subtler error is ignoring the data-security obligations that apply to data that is not personal information. The Data Security Law's important-data framework applies to data that is important to national economic security, public interests, or other specified categories – and that scope is not limited to personal information. A SaaS arrangement that processes operational or infrastructure data for a Mainland entity in a regulated sector may trigger important-data obligations that have nothing to do with the personal-information transfer regime. The analysis must cover both tracks.

If an earlier filing, structure, or contractual approach produced a stalled or adverse result, a second read of the architecture often identifies the structural error and the routes still open. Write to info@lockhartyip.com to discuss your position.

How should the decision checklist work in practice?

A practical checklist for in-house counsel approaching a cross-border SaaS or data agreement touching Mainland China should address the following questions before any commercial terms are finalised.

• Have you identified every category of data the arrangement will process, and confirmed whether any category constitutes personal information of Mainland residents or important data under the Data Security Law?
• Have you determined whether the volume or sensitivity of personal information requires mandatory security assessment, or whether the standard-contract route is available?
• If mandatory security assessment applies, has the Mainland party begun the application process, and is the commercial timeline calibrated to allow assessment to be completed before data transfer begins?
• If the standard-contract route applies, has the standard contract been executed and filed, and does the commercial agreement coordinate with it rather than contradict it?
• Does the governing-law clause select a law that provides a coherent framework for the commercial obligations across both the Hong Kong and Mainland dimensions of the arrangement?
• Does the dispute-resolution clause select a seat that provides a bilateral enforcement route – specifically, access to the Hong Kong–Mainland reciprocal-enforcement architecture and, for arbitration, the interim-measures Arrangement?
• Are the liability caps and indemnities in the commercial agreement calibrated to the regulatory-enforcement risk that the data-transfer regime creates, not only to the commercial service-defect risk?
• Does the Mainland entity have operational compliance capacity – data-subject rights management, incident response, notification obligations – from day one of the service, not from the date of the first complaint?
• Has the arrangement been reviewed against the Hong Kong Personal Data (Privacy) Ordinance as well as the Mainland data-protection instruments, particularly where a Hong Kong entity is part of the processing chain?

This checklist is not exhaustive. The specific data categories, the parties' regulatory profiles, and the sector in which the Mainland customer operates will all affect which of these questions is most consequential for a given arrangement. But the nine questions above cover the points at which cross-border SaaS and data agreements most frequently fail.

For a worked example of how a digital asset fund with Hong Kong and Mainland dimensions approaches structuring decisions of a related kind, see our guide on structuring a digital asset fund through Hong Kong with Mainland exposure. For the licensing posture that applies when virtual assets form part of the SaaS product, see our analysis of token issuance reviewed under Hong Kong's regime.

What does a well-structured arrangement actually look like?

A European enterprise software provider approached our desk in late 2027 seeking to deploy a data-analytics SaaS platform for a Mainland financial-services group. The provider had negotiated and nearly executed a commercial agreement governed by English law, with arbitration in London. The data flows included personal information of Mainland-resident customers of the financial-services group – well above the volume that triggers mandatory security assessment under the Measures on Security Assessment of Cross-Border Data Transfers.

Three problems were immediately apparent. The Mainland entity had not begun the security-assessment application process. The commercial agreement was about to impose a go-live date that could not legally be met. The London arbitration clause, while standard in the provider's other contracts, provided no access to the Mainland interim-measures architecture and no connection to the reciprocal-enforcement regime under Cap. 645.

We recommended restructuring the contracting vehicle: a Hong Kong entity of the provider group as the contracting party, with the commercial agreement governed by Hong Kong law and HKIAC arbitration as the dispute-resolution mechanism. The Mainland entity's counsel were then engaged to begin the security-assessment process, with a staged commercial go-live timed to the expected assessment timeline. The commercial agreement was revised to coordinate with the standard contract that would govern the pre-assessment data flows during the transition period, and the liability provisions were recalibrated to address regulatory-enforcement exposure alongside software-performance risk.

The restructuring extended the negotiation by several weeks. It avoided a structural error that would have exposed the Mainland entity to regulatory sanction from the Cyberspace Administration from day one of the deployment, and it gave the offshore provider an enforceable contract with bilateral reach across the Hong Kong–Mainland interface.

This is the kind of cross-border analysis our desk provides on tech and data transactions. The legal question is rarely difficult in isolation; the challenge is holding the Mainland regulatory layer, the Hong Kong commercial layer, and the international contractual standard in view simultaneously.

What are the ongoing obligations after the agreement is signed?

Signing the commercial agreement and completing the initial data-transfer compliance mechanism is not the end of the compliance obligation. Several ongoing requirements attach to the arrangement once it is operational.

Where a standard contract has been filed with the Cyberspace Administration, changes to the arrangement that fall within specified categories – a change in the data importer, a material expansion in data categories, a change in processing purpose – may require a new or amended filing. The commercial agreement should contain a mechanism for the parties to manage these notification obligations jointly, rather than leaving them as a unilateral obligation of the Mainland entity that the offshore provider neither monitors nor supports.

Data-subject rights requests from Mainland residents must be handled in accordance with the Personal Information Protection Law's requirements, including response timelines and the obligation to provide information in a form that is intelligible to the data subject. A SaaS provider whose platform processes personal information of Mainland residents must ensure that its incident-response and data-subject rights procedures are capable of operating in that regulatory context – which is not identical to the data-subject rights framework under European or other regimes that the provider may be more familiar with.

Where important data is involved, the ongoing data-security obligations under the Data Security Law continue for the life of the arrangement. Sector-specific data regulations in financial services, healthcare, and telecommunications impose additional requirements that may interact with the cross-border data-transfer regime. Counsel should ensure that the initial regulatory mapping is updated when the arrangement is renewed or expanded to cover new data categories or new sectors.

Finally, the dispute-resolution and enforcement posture should be reviewed periodically. The reciprocal-enforcement architecture between Hong Kong and the Mainland, and the scope of the interim-measures Arrangement, continue to develop. An agreement that was appropriately structured in one period should be checked at renewal to ensure that its dispute-resolution clause still reflects the current enforcement environment.

Related practices

• Sanctions & AML – cross-border AML compliance and counterparty due diligence for tech and data transactions
• Disputes & Arbitration – Hong Kong-seated arbitration and enforcement across the Mainland–HK interface

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 7
• Token Issuance Reviewed Under Hong Kong S Regime 5

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