Matter note: a cross-border SaaS or data agreement UK

A technology group operating across Hong Kong and the United Kingdom faces a structural question that sits between two legal orders: which governing law controls the contract, which regulator has standing to act, and where, precisely, does enforcement bite. For a SaaS or data agreement with one party in each jurisdiction, those questions are not theoretical. They determine whether the commercial arrangement is defensible when a dispute or a regulatory inquiry arrives.

A cross-border SaaS or data agreement touching the United Kingdom requires careful attention to the governing instrument on each side: the UK's data-protection regime, administered by the Information Commissioner's Office, and Hong Kong's Personal Data (Privacy) Ordinance, administered by the Privacy Commissioner for Personal Data. Since the two regimes differ on lawful-basis requirements, data-transfer mechanisms and the territorial reach of each authority, the structure of the agreement – and the order in which compliance steps are taken – materially affects the enforcement exposure of both parties.

This matter note describes an anonymised engagement. It covers the situation the client presented, the structural problem that emerged, the route taken, and the transferable lesson for groups managing similar cross-border data or SaaS arrangements.

What was the situation?

A technology group incorporated in Hong Kong – with a development team seated in the city and a commercial counterparty in the United Kingdom – was operating under a SaaS agreement that had been drafted for a purely domestic context. The contract had been prepared early in the relationship, before the arrangement grew to include the processing of personal data belonging to UK-based data subjects.

By the time the group came to us, the agreement had been in operation for over a year. The UK counterparty was processing data on behalf of the Hong Kong entity's clients. That relationship placed the UK party in the position of a data processor under UK data-protection rules, and the Hong Kong entity in a position that arguably amounted to that of a controller directing the processing of personal data of UK residents.

The group's in-house team had been advised by US-qualified technology counsel, who had flagged that the agreement lacked standard SaaS data-processing provisions. What the US counsel had not been positioned to assess was the specific interaction between the UK's data-protection requirements, the Hong Kong position on cross-border data transfers, and the question of which regulator was most likely to act first if a data incident occurred.

That gap – between a technically accurate domestic assessment and a complete cross-border read – was the starting point for the engagement.

What was the structural problem?

Two distinct issues emerged on closer analysis. They were related, but the remediation sequence for each was different.

The first was a transfer-mechanism gap. Personal data belonging to UK data subjects was being transferred to servers in Hong Kong and processed by the Hong Kong entity's team. Under the UK's data-protection regime, a transfer of personal data to a third country requires either an adequacy decision, standard contractual clauses, or another recognised mechanism. Hong Kong does not have an adequacy decision from the UK. The existing agreement contained no data-transfer mechanism of any recognised kind.

The second issue was a controller-processor relationship that had never been formalised. The UK party was performing processing operations on instructions from the Hong Kong entity. That relationship – which engaged specific obligations under the UK regime regarding data-processing agreements, security measures and audit rights – existed entirely in practice but not in contract. If either regulator were to examine the arrangement, there was no document that accurately described who was responsible for what.

On the Hong Kong side, the Personal Data (Privacy) Ordinance imposed its own requirements in relation to data collected in Hong Kong about individuals. The group had been collecting and processing that data under a privacy policy that pre-dated the current arrangement and did not disclose the involvement of the UK processor. That was a separate exposure.

What the group was facing, in effect, was a dual-regulator risk: the Information Commissioner's Office on the UK side, and the Privacy Commissioner for Personal Data on the Hong Kong side. Neither exposure was catastrophic in isolation. Together, and in the context of a data incident or a complaint from a data subject, they created a meaningful enforcement risk.

What route was chosen?

The remediation route had to achieve three things simultaneously: correct the contractual gap between the two parties; bring the data-transfer mechanism into compliance with UK requirements; and update the Hong Kong-side data governance documents without inadvertently creating admissions about the prior period.

We worked alongside locally qualified counsel on both sides of the arrangement. The structure of the work was as follows.

The SaaS agreement was renegotiated to include a data-processing schedule that correctly identified the roles of each party, set out the subject matter and purpose of processing, specified the technical and organisational security measures required, and created an audit and oversight mechanism. That schedule was drafted to satisfy the requirements of the UK regime as the higher standard, while also being consistent with the Hong Kong position.

The data-transfer mechanism was addressed by incorporating UK-standard contractual clauses into the schedule. The clauses were adapted to reflect the actual structure of the arrangement – a UK processor receiving instructions from a non-UK controller – which is a specific module under the UK standard contractual clause framework. The mapping of data flows was completed first, before the clauses were drafted, to ensure that the module chosen accurately reflected the direction and nature of the transfer.

On the Hong Kong side, the privacy policy was updated to disclose the involvement of the UK processor, describe the purpose and legal basis for the data transfer, and set out the subject's rights under Hong Kong law. The update was timed to coincide with the execution of the revised agreement, so that the contractual and public-facing documents became consistent at the same point.

A data-incident response protocol was also prepared, specifically addressing the different notification timelines and notification recipients under each regime. Under the UK's data-protection rules, the timeframe for notifying the Information Commissioner's Office of a personal data breach is a short statutory period following awareness of the incident. The Hong Kong regime operates on a different basis. A protocol that failed to account for both would risk a breach of one regime while attempting to comply with the other.

Throughout the process, the drafting approach was conservative: the documents described the arrangement as it would operate from the effective date forward. No document purported to characterise the prior period.

If your cross-border data or SaaS arrangement has a similar gap between practice and documentation, the position is almost always addressable. The sequence matters: the data-flow map comes before the contractual structure, and the contractual structure comes before the public-facing documents. To discuss how this applies to your arrangement, write to us at info@lockhartyip.com.

What was the turning point?

The turning point in this matter was the data-flow mapping exercise. It is the step that foreign counsel most often abbreviate or skip, and it is the step that most often determines whether the compliance remediation actually works.

In this engagement, the mapping exercise revealed a third data flow that had not been identified in the initial instructions: personal data belonging to Hong Kong data subjects was being routed through the UK party's infrastructure as part of the SaaS platform's architecture. This was not processing on behalf of the Hong Kong entity in the conventional sense – it was a technical transit that occurred automatically as part of the platform's operation.

That discovery changed the analysis in two respects. First, it created a transfer of personal data from Hong Kong to the United Kingdom that was not covered by the data-processing schedule as originally conceived. The Hong Kong entity was in a position of a data user transferring personal data abroad, which engages specific requirements under the Personal Data (Privacy) Ordinance. Second, it meant that the UK counterparty had been processing personal data about non-UK individuals without an adequate legal basis for doing so under the UK regime.

Neither issue was apparent from the contractual documents or the commercial description of the arrangement. Both emerged from a technical interrogation of how the platform actually operated.

The schedule and the transfer mechanism were adjusted to cover both data flows. The notification to data subjects was also extended. The turning point, in short, was the decision to treat the mapping exercise as a substantive legal step rather than a formality – because it was the mapping, not the drafting, that located the actual risk.

If an earlier attempt to remediate a cross-border data arrangement has stalled, or if a data incident has prompted a review that has not yet reached a clear route forward, a second read of the data-flow position often identifies the gap that the drafting has missed. To discuss that position, email info@lockhartyip.com.

What was the outcome, and what is the transferable lesson?

The revised agreement was executed. The data-transfer mechanism was in place. The Hong Kong-side governance documents were updated. The incident-response protocol was prepared and tested in a short tabletop exercise with the group's technical and legal teams.

The group did not face a regulatory inquiry in the period following the remediation. That is not a result that can be attributed to the work in any direct sense – regulatory inquiries arise from incidents and complaints, not from the presence or absence of compliant documents. What the remediation produced was a defensible position: a set of documents that accurately described the arrangement and allocated responsibility in a way that would withstand scrutiny from either regulator.

The transferable lesson is structural. A cross-border SaaS or data agreement that operates across Hong Kong and the United Kingdom engages two distinct regulatory regimes with different territorial reach, different lawful-basis requirements and different enforcement postures. The Information Commissioner's Office and the Privacy Commissioner for Personal Data are both active enforcement authorities. An agreement drafted to satisfy one regime is rarely adequate for both.

The most common point of failure is the data-transfer mechanism. In our cross-border technology practice, we regularly see arrangements where the contractual structure is otherwise sound but the transfer mechanism either does not exist or has been lifted from a template designed for a different jurisdictional pair. For the UK-Hong Kong corridor, the absence of an adequacy decision makes a documented transfer mechanism mandatory, not optional.

The second most common failure is the controller-processor characterisation. SaaS arrangements frequently involve processing operations that are performed by one party on the instructions of the other, but the contractual documents describe the relationship as a service contract without any data-specific allocation of responsibility. That gap does not just affect the parties' obligations to each other – it affects their respective positions with the regulators if a data subject makes a complaint or a breach occurs.

For groups managing technology arrangements that touch both jurisdictions, the practical question is not whether both regimes apply – they do, if personal data of the relevant data subjects is involved – but whether the documents accurately describe who is responsible for what, and whether the transfer mechanism is one that each relevant authority would recognise. Our desk is built around that question across the Hong Kong and international technology practice. See also our analysis of the wider Tech & Web3 practice, our matter note on IP licensing for a technology group expanding into Asia, and our note on a digital-asset fund structured through Hong Kong for related cross-border structuring work.

Related practices

Tech & Web3 – licensing, AML, VATP and cross-border data structuring
Sanctions & AML – counterparty review, source-of-funds and compliance documentation

Frequently asked questions

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

The timeline for documenting a cross-border SaaS or data agreement across the Hong Kong – United Kingdom corridor depends primarily on the complexity of the data flows and the responsiveness of both parties to the mapping and negotiation process. A straightforward arrangement with a single, well-defined data flow can be documented and executed in a matter of weeks. Where the mapping exercise reveals multiple data flows, or where the parties' technical and legal teams need to resolve architectural questions before the documents can be finalised, the process typically takes longer. In our cross-border technology practice, the data-flow mapping exercise is the rate-limiting step in almost every engagement of this kind.

How does the cross-border element affect a cross-border SaaS or data agreement touching the United Kingdom?

The cross-border element is determinative, not incidental. A domestic SaaS agreement between two UK parties, or two Hong Kong parties, operates under a single regulatory regime. Once the arrangement crosses the boundary between the two jurisdictions and involves the processing of personal data of residents of either, two distinct regulatory regimes apply simultaneously. The Information Commissioner's Office in the United Kingdom and the Privacy Commissioner for Personal Data in Hong Kong each have standing to act in relation to their own data subjects. The lawful-basis requirements, the data-transfer mechanisms and the notification obligations differ between the two. An agreement that satisfies one regime without addressing the other creates a compliance gap that the other regulator can exploit.

What does the route look like for a cross-border SaaS or data agreement touching the United Kingdom?

The route follows a defined sequence. First, the data flows are mapped technically – identifying every category of personal data processed, the direction of transfer and the parties involved. Second, the controller-processor relationship is characterised correctly under both regimes, which determines the structure of the data-processing schedule. Third, the transfer mechanism for the UK-to-Hong Kong or Hong Kong-to-UK transfer is selected and incorporated into the agreement. Fourth, the Hong Kong-side governance documents – the privacy policy and any data collection notices – are updated to reflect the arrangement accurately. Fifth, an incident-response protocol is prepared that accounts for the different notification obligations under each regime. In our experience, the mapping exercise frequently reveals data flows that were not apparent from the commercial description of the arrangement, and those discoveries often require the subsequent steps to be adjusted.

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.

Matter note: a cross-border SaaS or data agreement touching the United Kingdom