How to approach a cross-border SaaS or data agreement touching the United Kingdom

An Asian group selling software-as-a-service into the United Kingdom, or receiving data from UK-based users, faces a contractual and regulatory question that its domestic counsel cannot answer from one jurisdiction alone. The agreement sits at the intersection of UK data-protection law, the terms of any sub-processor chain, and the licensing position of the entity actually delivering the service – which may sit in Hong Kong, a BVI or Cayman holding vehicle, or an intermediate operating company. Getting the structure wrong at the drafting stage routinely produces an unenforceable limitation-of-liability clause, an unlicensed data-processing arrangement, or an indemnity that runs to the wrong entity.

A cross-border SaaS or data agreement touching the United Kingdom must address three questions in sequence: which entity is the contracting party and where it is licensed or registered; which data-protection regime governs the personal data flowing under the agreement; and how the agreement's governing law and dispute-resolution clause will interact with enforcement on either side of the relationship. The governing instruments include the UK General Data Protection Regulation as retained in UK domestic law, the UK International Data Transfer Agreement (the standard form issued by the Information Commissioner's Office for restricted transfers out of the UK), and – where Hong Kong-resident data subjects or processing infrastructure are in scope – the Personal Data (Privacy) Ordinance (Cap. 486). The sequence below sets out how a cross-border practitioner approaches each gate.

This guide moves through the practical steps in the order they arise: entity and licensing clarity first, data-transfer architecture second, contractual drafting third, and ongoing compliance last. Each step carries the gate that must be cleared before the next step begins.

Step 1: Which entity is actually delivering the service – and does it matter?

The first gate is entity identification: the legal person signing the agreement must be the entity with the relevant rights, licences, and data-processing authority to perform the obligations. This question sounds administrative. In our cross-border practice, it is the point most often overlooked by in-house teams that have structured the group for tax or holding purposes without considering the contractual layer.

A typical structure for a tech group with Asia-Pacific ambitions places intellectual property in an offshore vehicle – often a BVI or Cayman entity – and operating activity in a Hong Kong entity or a Singapore subsidiary. The UK customer, however, will often be contracting with whichever entity the sales team has used. If that entity does not hold the licence to the underlying software, the agreement may be unenforceable at the point of a dispute, or the group may find it is delivering services through an entity that lacks the substance to defend a claim or collect a judgment.

The practical gate at Step 1 is a simple verification: identify the entity, confirm it holds the necessary rights by way of a written intra-group licence or an assignment, and confirm it is authorised to contract in the UK context. Where the service involves regulated activities under UK financial-services law – for example, a SaaS product used by a UK authorised firm in connection with its regulated business – the entity and its product may themselves attract authorisation requirements. That question requires specific advice on the UK regulatory perimeter, which goes beyond standard commercial drafting.

In our cross-border practice, we regularly advise groups at this preliminary stage: reviewing the intra-group IP and licence position, mapping the entity that should be the contracting counterparty, and preparing the internal documentation before the commercial agreement is negotiated.

Step 2: What data flows under the agreement, and does the UK GDPR apply?

Once the contracting entity is confirmed, the second gate is the data map. The UK General Data Protection Regulation – the UK GDPR, which is the version of the EU GDPR retained in UK domestic law following the UK's departure from the European Union – applies whenever a non-UK established entity processes personal data of individuals in the United Kingdom in connection with offering goods or services to them, or with monitoring their behaviour. A SaaS product sold to UK customers will almost invariably satisfy this test.

The data map should answer four questions. First, which categories of personal data does the product process? Second, in what capacity does each entity in the processing chain act – controller, processor, or joint controller? Third, where, physically and legally, does the data sit or transit? Fourth, are there any sub-processors, and where are they established?

The second question carries the most contractual weight. If the Hong Kong or offshore entity processes data on the instructions of the UK customer, it is a processor and the agreement must contain a data-processing addendum that meets the requirements of the UK GDPR. If the Asian entity exercises independent judgment about the purposes of processing, it is a controller, and the compliance obligations – and the liability exposure – are materially different.

Where personal data also flows into or through Hong Kong, the Personal Data (Privacy) Ordinance applies in parallel. The Ordinance imposes requirements on data users – the equivalent of controllers – with respect to data collected in or from Hong Kong. A SaaS platform that routes data through a Hong Kong-based processing infrastructure, or whose Hong Kong entity receives personal data of Hong Kong residents from the UK customer, must satisfy both regimes concurrently.

The gate at Step 2 is a completed data map, with controller/processor roles assigned and documented, before the contract is drafted.

For a broader view of how data-transfer terms are handled across an Asia-facing platform, the briefing at data transfer and privacy terms for an Asia-facing platform sets out the comparative position across the principal Asia-Pacific jurisdictions.

Step 3: Is a restricted transfer mechanism required, and which one applies?

A restricted transfer under the UK GDPR is a transfer of personal data from the UK to a country or territory that does not benefit from a UK adequacy decision. The United Kingdom's own adequacy framework – maintained by the UK government following its departure from the EU – determines which destination countries are deemed to offer adequate protection. Hong Kong does not currently hold UK adequacy status.

Where personal data flows from the UK to a Hong Kong entity that acts as a processor or joint controller, a restricted-transfer mechanism is required. The principal mechanism available for this purpose is the UK International Data Transfer Agreement – the IDTA – or the UK Addendum to the EU Standard Contractual Clauses, both of which are issued by the Information Commissioner's Office. The IDTA is the self-contained UK form; the Addendum may be used where the parties are already using the EU standard contractual clauses for other transfer routes.

The practical gate at Step 3 is determining which form applies and completing it correctly. The IDTA requires the parties to complete a Table in the body of the document that specifies the parties, the data transferred, the purposes, and the technical and organisational measures in place. Incomplete or generic completion is the most common drafting error we see. Courts and regulators look to the substance of the completed Table, not the template's existence.

There is an important structural point for groups using an offshore entity in the chain. The IDTA runs between the UK exporter and the data importer. If the importer is a Cayman or BVI entity rather than the Hong Kong operating company, the analysis changes: the offshore entity's own ability to comply with the IDTA's obligations – including cooperating with the Information Commissioner's Office and subject-access requests – must be assessed on its actual governance and staffing position, not its nominal address.

Step 4: How should the commercial agreement itself be structured?

With the entity and data-transfer architecture resolved, the commercial agreement can be drafted to reflect the actual structure. A well-structured cross-border SaaS agreement in this context has four operative components: the master services agreement or subscription agreement; the data-processing addendum; the IDTA or Addendum (incorporated by reference or appended); and the service levels and acceptable-use terms.

The governing-law clause is a structural decision, not a boilerplate choice. For a UK-facing SaaS product delivered by a Hong Kong entity, the most common options are English law, Hong Kong law, or a neutral third system. Each carries consequences for interpretation, implied terms, and the availability of interim relief.

English law has the advantage of aligning the governing law with the jurisdiction whose data-protection regime applies and whose courts the UK customer will look to in a dispute. It also means the agreement will be interpreted under a well-developed commercial common-law system with an extensive body of SaaS-specific and software licensing authority.

Hong Kong law offers the Asian entity a more familiar and accessible system for enforcement, and it shares the common-law tradition, the doctrine of binding precedent, and English as an official working language of the courts. For a group that expects enforcement in Asia to be the more likely scenario, Hong Kong law reduces friction at the enforcement stage.

The dispute-resolution clause should be considered alongside the governing law. Where enforcement in the Mainland is a possibility – because a Mainland group sits above the Hong Kong entity, or because assets are there – an arbitration clause with Hong Kong as the seat offers meaningful advantages. A Hong Kong-seated arbitration award can be enforced in the Mainland under the mutual enforcement arrangements, and interim measures can be sought from Mainland courts under the arrangement in effect since 1 October 2019. A foreign-court judgment does not carry the same route.

The limitation-of-liability clause is the most frequently contested provision in a SaaS dispute. Its enforceability depends on the governing law selected and, where the UK customer is a consumer or a party entitled to statutory protection, may be overridden by UK statute. For B2B SaaS agreements, English law and Hong Kong law both permit broad limitation clauses, subject to the reasonableness or fairness tests that apply under their respective unfair-contract-terms regimes.

The gate at Step 4 is a complete set of operative documents, internally consistent, with governing law, jurisdiction, and limitation provisions that are coherent across the whole structure.

Step 5: What are the ongoing compliance obligations after signing?

A signed agreement is not the end of the exercise. The UK GDPR imposes ongoing obligations that run through the life of the contract and do not expire at signature. These include responding to data-subject access requests within one calendar month; notifying the Information Commissioner's Office of a personal data breach within 72 hours of becoming aware; maintaining records of processing activities; and keeping the data-processing addendum and IDTA current when the processing arrangement changes.

For the Hong Kong entity, the Personal Data (Privacy) Ordinance imposes its own ongoing obligations, including obligations with respect to retention periods, data security, and the handling of access and correction requests. Where the entity also handles data about individuals in other Asia-Pacific jurisdictions – through the same SaaS platform – further regimes may apply concurrently.

AML obligations are a separate compliance stream that a number of in-house teams treat as irrelevant to a SaaS agreement. That is a mistake. Where the SaaS product is used by financial institutions or regulated firms, the platform operator may itself be subject to customer-due-diligence requirements under the Anti-Money Laundering and Counter-Terrorist Financing Ordinance, depending on the nature of the product and the services it enables. The analysis depends on the specific product; it is not answered by reference to the SaaS label alone.

Where the platform involves virtual assets – for example, a SaaS product that provides custody, trading, or settlement functionality for virtual assets – the licensing position in Hong Kong is material. The mandatory licensing regime for virtual-asset trading platforms commenced on 1 June 2023 under the Anti-Money Laundering and Counter-Terrorist Financing Ordinance, with the Securities and Futures Commission as the licensing authority. A product that falls within the regulated perimeter requires licensing before it is offered to users, regardless of whether those users are in Hong Kong or the United Kingdom.

The gate at Step 5 is a compliance calendar and a clear allocation of ongoing obligations between the parties, confirmed in writing before the service goes live.

What do advisers get wrong when approaching this agreement type?

The most common error is treating the data-transfer mechanism as a standard annexe and completing it generically. The IDTA requires specific, accurate completion of the Table: generic entries such as "all personal data necessary to provide the services" fail to satisfy the requirement and expose both parties on audit.

A second frequent error is mischaracterising the role of the Asian entity. A group whose Hong Kong entity exercises no independent judgment about the purposes of processing should document it as a processor; where that entity sets the processing purposes for its own commercial reasons, it is a controller and must be treated as one. Mislabelling the role does not reduce the liability; it increases it, because a mislabelled processor that behaves as a controller has violated the UK GDPR without a compliant lawful basis.

A third error is selecting English governing law without considering enforcement. If the Hong Kong entity is the defendant in a dispute and its assets are in Asia, an English court judgment requires a separate enforcement step in Hong Kong. That step is available under the common-law regime in Hong Kong, but it takes time and requires its own application. An arbitration clause avoids this friction entirely, because a Hong Kong-seated award can be enforced more directly.

Finally, groups that have expanded from a domestic market into the UK through a reseller or distribution arrangement sometimes discover that the reseller has been named as the data controller in the upstream processing agreement, producing a gap: the end customer's data-processing addendum runs to the reseller, but the IDTA runs to the Asian entity. Resolving this gap mid-contract is more difficult than structuring it correctly at the outset.

A micro-scenario illustrates the point. A Hong Kong-based SaaS group serving mid-market UK financial services firms came to us in the second half of 2026. Their existing agreements had been drafted using a US-law template adapted for the UK market. The governing-law clause selected New York law; the data-processing addendum referred to EU standard contractual clauses without a UK Addendum; and the contracting entity was the offshore IP holdco, which held no personnel, no processing infrastructure, and no ability to respond to a data-subject access request. We restructured the agreement suite, replaced the entity, added a compliant IDTA, and moved the governing law to English law with a Hong Kong-seated arbitration clause. The group relaunched its UK offering within a single commercial cycle.

Decision checklist before the agreement is signed

The following checklist consolidates the five gates described above. It is not exhaustive; it is the minimum verification that a cross-border SaaS agreement touching the United Kingdom requires before execution.

• The contracting entity holds the relevant IP rights by written licence or assignment.
• The contracting entity has the operational capacity to perform the data-processing obligations, including responding to data-subject requests and notifying the Information Commissioner's Office of a breach.
• A data map has been completed identifying each category of personal data, each processing role, and each jurisdiction in which data sits or transits.
• A UK GDPR lawful basis has been identified for each processing activity.
• Where data flows from the UK to a non-adequate country, a compliant IDTA or UK Addendum is in place and the Table is fully and accurately completed.
• Where the processing also engages Hong Kong data subjects or infrastructure, the Personal Data (Privacy) Ordinance obligations have been mapped.
• The governing law and dispute-resolution clause are coherent with the enforcement scenario most likely to arise.
• AML obligations and, where applicable, the VATP licensing position have been assessed for the specific product.
• A compliance calendar allocates ongoing obligations, including breach notification timelines and data-subject request procedures.
• Intra-group agreements – sub-processor agreements, IP licences, intercompany data-transfer agreements – have been executed before the commercial agreement is signed.

For a practical view of how intellectual property and technology licensing is handled for a group expanding into Asia, the note at IP licensing for a technology group expanding into Asia sets out the structuring options and the common points of friction.

The sequence above describes the standard position. Your matter turns on the specific documents, the jurisdictions actually engaged, and the entity through which delivery occurs – which is where the route is won or lost. For a structured assessment of your cross-border SaaS or data agreement position across Hong Kong, the United Kingdom, and any offshore entities in the chain, write to us at info@lockhartyip.com.

Related practices

Related practices

• Tech & Web3 – licensing, regulatory perimeter, virtual assets and cross-border platform structuring
• Sanctions & AML – AML obligations, source-of-funds, and compliance file management

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.