A practical guide to a cross-border SaaS or data UAE

A SaaS vendor headquartered in Hong Kong, a data processor sitting in a BVI-held structure, and a customer contracting through a UAE free-zone entity: the agreement looks straightforward on paper. In practice, it crosses three regulatory systems simultaneously – and the compliance obligations that attach to each layer are not interchangeable.

A cross-border SaaS or data agreement touching the UAE requires the contracting parties to address, in sequence, the choice of governing law, the data-handling rules of each jurisdiction engaged, the AML and licensing posture of any entity processing payments or handling financial data, and the enforcement route if the agreement breaks down. The UAE and Hong Kong each maintain distinct regulatory perimeters, and a gap between them is an exposure, not a neutral space.

This guide walks through the decision, the sequence, the gates at each step, and the mistakes that produce the most avoidable disputes. It is written for in-house counsel and founders who need a working map before they brief their external team.

What decision does the contracting party actually face?

The first question is not which clause to include. It is which regulatory system the agreement sits inside – and whether the answer is the same for both parties.

A SaaS or data agreement touching the UAE can engage one of several distinct legal perimeters. The onshore UAE, governed by federal civil and commercial law. The Dubai International Financial Centre (DIFC – an independent common-law jurisdiction within Dubai with its own courts and data-protection law). The Abu Dhabi Global Market (ADGM – a second common-law free zone, also with its own courts and data framework). A non-financial free zone such as Dubai Internet City. The choice is not cosmetic: the governing law, the enforcement route, the data-protection obligations, and the licensing exposure differ materially across these perimeters.

On the Hong Kong side, the question is simpler in structure but not in detail. The entity contracting from Hong Kong is subject to the Personal Data (Privacy) Ordinance (Hong Kong's primary data-protection statute) and, where the SaaS platform handles virtual assets or financial data that meets the relevant thresholds, to the licensing and AML obligations under the Anti-Money Laundering and Counter-Terrorist Financing Ordinance. Both instruments apply to the entity, not to the contract's governing law.

The decision the contracting party faces is therefore a two-part one. First, which UAE perimeter is the counterparty actually operating within? Second, does the nature of the data or the service trigger any licensing, AML, or sector-specific regulatory obligation on either side?

Step 1: Identify the correct UAE perimeter and its regulator

Establishing which UAE perimeter applies is the structural gate for the rest of the agreement. Getting this wrong is the single most common error we see on our cross-border tech desk, and it typically produces an unenforceable governing-law clause.

The onshore UAE operates under federal law. The primary data-protection instrument is the Federal Decree-Law on Personal Data Protection, which sets conditions for the processing and cross-border transfer of personal data of UAE residents. Disputes under onshore agreements are resolved in the UAE federal courts or, where parties have chosen arbitration, through recognised arbitral institutions – verify the current position on institutional choices before specifying a venue.

The DIFC and the ADGM are each common-law jurisdictions with their own legislative frameworks. The DIFC maintains the DIFC Data Protection Law and the DIFC Courts, which share a memorandum of guidance with the courts of England and Wales and maintain enforcement arrangements with a number of jurisdictions. The ADGM operates under the ADGM Data Protection Regulations and the ADGM Courts. Both free-zone courts are English-language, common-law fora – a material advantage for international counterparties unfamiliar with civil-law procedure.

The practical gate at this step: confirm the entity registration number, the licensing certificate, and the address of the UAE counterparty before the agreement is drafted. A Dubai Internet City entity operating a SaaS platform is not the same regulatory subject as a DIFC-registered entity offering the same service. The SaaS vendor's counsel needs both documents before choosing a governing-law clause.

Non-financial free zones (Dubai Silicon Oasis, Dubai Internet City, Ras Al Khaimah Digital Oasis) do not have their own courts or data-protection frameworks to the same degree. An agreement with a counterparty in one of these zones may default to onshore UAE law and the UAE federal courts unless the parties make an explicit common-law choice – typically by selecting DIFC law or English law, both of which are available as a governing-law option in commercial contracts, subject to UAE conflict-of-laws analysis.

Step 2: Map the data flows and the applicable data-protection obligations

Once the UAE perimeter is identified, the agreement must map every category of personal data that crosses the boundary and assign a legal basis for each transfer.

On the Hong Kong side, the Personal Data (Privacy) Ordinance imposes obligations on data users (controllers) and data processors operating in Hong Kong. A Hong Kong-based SaaS vendor processing personal data of UAE residents must consider both regimes: the Ordinance governs what the vendor may do with the data it holds in Hong Kong; the UAE instrument (federal, DIFC, or ADGM, depending on the perimeter identified in Step 1) governs whether the transfer of that data out of the UAE was lawful in the first place.

The practical point is sequencing. The data-protection analysis runs before the agreement is signed, not after. A SaaS agreement that is silent on data residency, processing purpose, sub-processor chains, and cross-border transfer mechanisms is not merely incomplete – it creates an immediate exposure under whichever data-protection regime applies to the UAE customer.

What should the agreement include at this step? At minimum: a clear identification of which party is the data controller and which is the processor; the categories of personal data covered; the processing purposes and the instruction mechanism; sub-processor controls; the security standards that apply; a breach-notification protocol; and the mechanism for cross-border transfers (adequacy finding, standard contractual clauses, or consent, depending on the applicable regime).

The gate at this step: the data-protection schedule must be completed and agreed before execution. Where the UAE perimeter is onshore federal law, verify whether the current data-protection rules require registration with or notification to the competent UAE authority. Where the perimeter is DIFC or ADGM, confirm the applicable controller or processor registration requirements in each free zone. Requirements in this area continue to develop; parties should verify the current position before acting.

Step 3: Assess the AML and licensing exposure on both sides

Not every SaaS agreement triggers AML or licensing obligations. But the category is broader than most in-house teams expect, and the cost of misclassification runs high.

On the Hong Kong side, the critical threshold is whether the platform processes, transmits, or facilitates the transfer of funds or virtual assets. If the SaaS product handles payment flows, provides financial data analytics that qualify as regulated advice, or operates any component of a virtual-asset transfer, the entity may fall within the scope of the Anti-Money Laundering and Counter-Terrorist Financing Ordinance and, where virtual assets are involved, the licensing regime for virtual-asset trading platforms (VATPs) administered by the Securities and Futures Commission. That regime commenced 1 June 2023. AML obligations for VATPs include customer due diligence and compliance with the FATF travel rule for virtual-asset transfers.

Where a virtual asset processed by the platform qualifies as a security or futures contract, the licensing requirements under the Securities and Futures Ordinance also apply. These are parallel obligations, not alternatives.

On the UAE side, the licensing question depends on the perimeter. The Dubai Financial Services Authority (DFSA) is the financial regulator within the DIFC; the Financial Services Regulatory Authority (FSRA) performs the equivalent function within the ADGM. Both have published frameworks for fintech, digital assets, and data services. Onshore UAE financial licensing sits with the Central Bank of the UAE for certain activities and with the Securities and Commodities Authority for others. In the non-financial free zones, the licensing requirement for a pure SaaS service is generally a commercial licence only – but any financial-services component reactivates the sector-specific overlay.

The gate at this step: the agreement should include a representations and warranties clause under which each party confirms its licensing status, and an undertaking to maintain that status for the duration of the term. A change-of-law clause covering material regulatory change (including new licensing requirements) is standard on any cross-border SaaS agreement with a technology component that is likely to develop. Our desk sees this clause omitted in a significant proportion of first-draft agreements presented by counterparties' teams.

Step 4: Draft the governing-law and dispute-resolution clause

The governing-law and dispute-resolution clause is the most litigated provision in cross-border tech agreements. It deserves more time than most counterparties give it.

For an agreement between a Hong Kong entity and a UAE entity, there is no single correct answer on governing law. The realistic options are: Hong Kong law (common law, well-tested in commercial disputes, English-language courts); DIFC law (if the UAE entity is DIFC-based, or if the parties choose it as a neutral common-law option); ADGM law (on equivalent logic); English law (widely accepted in international commercial contracts, including in the UAE); or onshore UAE law (if the UAE counterparty requires it and the parties accept the civil-law procedure).

For dispute resolution, arbitration is the preferred route for most cross-border tech agreements because it produces an award that can be enforced across jurisdictions under the New York Convention. Hong Kong is a signatory jurisdiction under the Convention, and the Arbitration Ordinance (Cap. 609), modelled on the UNCITRAL Model Law, governs Hong Kong-seated proceedings. The HKIAC 2024 Rules, effective 1 June 2024, apply to arbitrations filed under those rules from that date. The UAE has ratified the New York Convention, and awards from recognised institutions are enforceable in the UAE courts, including within the DIFC and ADGM, subject to the applicable enforcement procedure in each perimeter.

The DIFC–LCIA Arbitration Centre and the ADGM Arbitration Centre both offer institutional rules for UAE-seated arbitration. A Hong Kong-seated HKIAC arbitration with an English or Hong Kong law governing-law clause is a well-tested combination for agreements with UAE counterparties and is a route our desk uses regularly on cross-border tech matters.

One practical point on enforcement. If the agreement produces a monetary judgment rather than an arbitral award (for example, because the parties chose court litigation), the enforcement route becomes more complex. Hong Kong maintains a reciprocal enforcement regime with the Mainland under the Mainland Judgments in Civil and Commercial Matters (Reciprocal Enforcement) Ordinance (Cap. 645), in force from 29 January 2024. The UAE is not yet within a formal reciprocal-enforcement arrangement with Hong Kong for court judgments. Arbitral awards avoid this gap; court judgments do not.

The gate at this step: the governing-law and dispute-resolution clause must be reviewed against the UAE perimeter identified in Step 1. A clause selecting DIFC arbitration is not effective for an onshore UAE counterparty unless the parties have validly opted into the DIFC framework. Confirm the basis for the choice before finalising.

The sequence described so far reflects the standard analytical path. The documents, the jurisdictions actually engaged, and the regulatory status of both parties will adjust that path in almost every matter. That is precisely where the route is won or lost.

For a structured read of your SaaS or data agreement against the UAE and Hong Kong perimeters, write to us at info@lockhartyip.com.

Step 5: Address intellectual-property ownership and data-portability rights

A SaaS agreement transfers access to a service, not ownership of the underlying software. That distinction matters less to the commercial teams and more to the legal team, which must make it explicit in the agreement.

The IP ownership clause should confirm that all intellectual property in the platform, the underlying code, and any algorithms remains with the vendor. The customer's data – all personal data, transactional records, and outputs generated from the customer's own inputs – belongs to the customer. This seems obvious. In our cross-border practice, disputes over data ownership and extraction rights on termination are among the most common sources of post-agreement friction on tech matters.

Data portability and return-on-termination provisions deserve a dedicated clause. The customer should be able to extract its data in a machine-readable format for a defined period after termination. The vendor should be required to delete the customer's data within a confirmed period after that extraction window closes. Both obligations have regulatory dimensions: the applicable data-protection regime may impose independent requirements on both parties regardless of what the contract says.

The UAE federal data-protection instrument and both the DIFC and ADGM frameworks include data-subject rights that the customer must be able to honour in relation to its own users. The SaaS agreement must include sufficient processor obligations on the vendor to allow the customer to meet those rights – including access, correction, deletion, and portability – within the timeframes the applicable regulation requires.

Step 6: Build the liability and indemnity structure for a cross-border risk profile

Liability caps and indemnity carve-outs in a cross-border SaaS agreement must reflect the actual risk profile – not a standard template imported from a single-jurisdiction deal.

The standard approach of capping liability at the fees paid in the preceding twelve months is commercially workable for routine service failures. It is not workable for data-breach liability, regulatory fines, or intellectual-property infringement claims in a cross-border context, where the exposure can far exceed the contract value. Separate, higher (or uncapped) liability provisions for these categories are standard on well-drafted international tech agreements.

The indemnity structure should address: data breaches attributable to the vendor's systems; infringement of third-party intellectual-property rights in the platform; regulatory sanctions arising from the vendor's failure to maintain required licences; and, on the customer side, misuse of the platform that generates a regulatory exposure for the vendor.

Force majeure provisions in cross-border tech agreements should address regulatory change specifically – including the introduction of new licensing requirements, data-localisation mandates, or sanctions measures that affect the ability of either party to perform. Hong Kong implements United Nations sanctions and does not give domestic effect to unilateral measures of other states; the UAE's sanctions posture differs in structure. A force majeure clause that does not address the regulatory-change scenario will produce an argument on whether that scenario is covered.

The common mistake and how the correct sequence avoids it

The most common mistake on cross-border SaaS agreements with a UAE element is treating the agreement as a standard international contract with a UAE-flavoured addendum. It is not. The UAE is not a single legal system for these purposes; the DIFC and ADGM are functionally closer to English-law jurisdictions than to the onshore UAE civil-law environment; and the data-protection obligations differ materially across those perimeters.

The consequence is a governing-law clause that does not match the counterparty's actual legal perimeter, data-protection schedules that comply with the wrong instrument, and a dispute-resolution clause that selects a forum the onshore UAE counterparty cannot validly use.

The sequence in this guide – perimeter identification first, data-flow mapping second, AML and licensing assessment third, governing-law and dispute-resolution drafting fourth, IP and data-portability fifth, liability structure sixth – is not arbitrary. Each step produces a defined output that the next step requires. Jumping to the governing-law clause before confirming the counterparty's perimeter is the structural error. Jumping to the liability cap before assessing the data-breach exposure is the commercial error. The two together are the most frequently avoidable path to a contract that does not perform its primary function: allocating risk clearly between the parties.

A related mistake is treating the Hong Kong side as the simpler half of the transaction. Where the SaaS vendor processes personal data of UAE residents, the Hong Kong entity must comply with both the Personal Data (Privacy) Ordinance and the applicable UAE data-protection instrument simultaneously. The two obligations are additive, not alternative.

If a first-draft agreement has already been exchanged and the parties are working from a template that did not follow this sequence, the error is recoverable. The perimeter-identification and data-protection analysis can be run retrospectively and the agreement restructured before execution. Our desk has assisted on several matters where the structural correction was made at this stage rather than after a dispute arose.

Decision checklist for in-house counsel

Use this checklist as an internal gate before instructing external counsel to finalise the agreement.

Confirmed the UAE counterparty's entity registration, licensing certificate, and physical address – and identified whether it sits within onshore UAE, the DIFC, the ADGM, or a non-financial free zone.
Identified every category of personal data that will flow across the Hong Kong–UAE boundary and the applicable data-protection instrument on each side.
Assessed whether the SaaS platform's functions trigger AML, VATP licensing, or financial-services licensing obligations under Hong Kong law, DIFC/ADGM law, or UAE federal law.
Confirmed each party's current licensing status and included a representation and warranty to that effect in the agreement.
Selected a governing law that is consistent with the UAE counterparty's actual legal perimeter and with any mandatory provisions of UAE law that cannot be contractually displaced.
Selected a dispute-resolution mechanism (arbitration preferred) that produces an enforceable award in both jurisdictions and specified the institutional rules and seat.
Included a data-portability and return-on-termination clause that complies with the applicable data-protection requirements on both sides.
Reviewed the liability and indemnity structure against the actual risk profile – including data-breach, IP-infringement, and regulatory-change scenarios.
Included a change-of-law clause addressing new licensing requirements, data-localisation mandates, and sanctions-related restrictions.

If any item on this list has not been addressed, the agreement is not ready to execute.

If an earlier draft was exchanged before this analysis was completed, or if the counterparty's template does not reflect the correct UAE perimeter, a structural review before signature is the better route than a dispute after breach. Write to us at info@lockhartyip.com to arrange a read of the current draft.

Related practices

Tech & Web3 – licensing, AML, and regulatory structuring for technology and digital-asset businesses
Sanctions & AML – counterparty review, source-of-funds compliance, and sanctions-neutral contracting

Frequently asked questions

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

A Hong Kong international adviser adds material value where the contracting entity is Hong Kong-based, where the SaaS platform may trigger licensing or AML obligations under Hong Kong law, or where the governing-law and dispute-resolution clause has an enforcement dimension in Greater China. The Personal Data (Privacy) Ordinance applies to the Hong Kong entity regardless of the governing law the agreement selects. Understanding both sides of the cross-border interface – including the VATP licensing regime for any platform touching virtual assets – requires counsel with a working knowledge of both systems. We regularly advise on agreements of this type and coordinate with UAE-qualified advisers on the local-law questions.

How long does a cross-border SaaS or data agreement touching the UAE usually take?

The timeline depends primarily on how quickly the parties complete the perimeter-identification and data-protection analysis. A straightforward agreement between a Hong Kong SaaS vendor and a DIFC-registered customer, where the licensing positions are clear and no AML or virtual-asset issues arise, can be finalised in four to eight weeks from instruction. Where onshore UAE law applies, where the data-protection obligations are complex, or where a licensing review is required on either side, the timeline extends. The regulatory-analysis stage – Steps 1 to 3 in this guide – should run in parallel with initial commercial negotiations, not after heads of terms are agreed.

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

The parties may generally choose their governing law, subject to mandatory UAE provisions that apply regardless of that choice. Hong Kong law, DIFC law, ADGM law, and English law are all viable choices for an agreement with a common-law UAE entity and produce a well-understood body of commercial contract law. Onshore UAE law applies where the counterparty requires it or where the subject matter of the agreement falls within categories that UAE federal law treats as non-displaceably subject to UAE jurisdiction. Confirming the applicable mandatory provisions – including any data-localisation or sector-specific regulatory requirements – is part of the governing-law analysis, not a separate step.

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 the UAE