
In the same week, a Riyadh-headquartered bank and a Beirut-based fintech rejected the identical one-page data-residency addendum from an AI vendor pitching a single regional rollout. This is a composite drawn from a pattern I see repeatedly in my advisory work across the region, not a specific client engagement. The Saudi legal team wanted proof the data never left the Kingdom. The Lebanese legal team did not care where the data sat. They wanted to know whether the vendor could be compelled to disclose account activity to a foreign regulator.
Both teams said no to the same clause. Neither was being difficult. They were reading two different bodies of law, sitting on two different sides of a border that most vendor contracts treat as a single line item labeled "MENA." I keep telling clients: there is no such thing as MENA data law. There is Gulf data law, which is primarily a cross-border-transfer regime, and there is a Levant compliance problem, which in Lebanon's case is a banking-secrecy and cross-border-disclosure regime. A contract clause built to satisfy one will fail the other, and it will fail for opposite reasons.
Two Rejections, One Clause
The addendum in question was standard vendor boilerplate: a residency guarantee promising that customer data would be hosted "within the MENA region" and processed "in accordance with applicable regional data protection law." It's the clause I run into most often, written once, in a template, and reused across a dozen markets because nobody on the sales side wants to maintain two versions.
In Riyadh, the guarantee was too vague to pass. "Within the MENA region" does not answer the only question the Saudi reviewer had: is the data physically inside the Kingdom, in a facility Saudi authorities can inspect and compel if needed, or is it sitting in a data center the vendor happens to consider regional. In my experience, a guarantee that data stays in "the region" is not a guarantee that it stays in the country whose regulator governs the institution's license.
In Beirut, the same guarantee failed for the opposite reason. The Lebanese team was not concerned with where the servers physically sat. Lebanon has no local hyperscaler region for the vendor to point to, and everyone in that conversation already knew the data would transit through Europe or the UAE regardless of what the clause said. Their question was legal, not physical: could a foreign court, regulator, or law-enforcement request compel disclosure of the fintech's customer transaction data through the vendor, in a way that put the fintech in breach of its own confidentiality obligations to its account holders. When I read that redline, the addendum said nothing about disclosure obligations, subpoena response, or notification rights. It was answering a question nobody in Beirut had asked, and it was silent on the one they had.
The vendor's sales team read both rejections as the same objection, "data residency concerns," and tried to fix it by tightening the hosting language. I've watched this exact fix play out before: it made the Saudi version marginally better and did nothing for Beirut, because Beirut was never objecting to hosting.
What Gulf Procurement Is Actually Checking For
Gulf data protection law is a comparatively young, codified regime, and it behaves like one in procurement review. But here is the correction I make most often when I sit across from a vendor's legal team: the UAE's Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (Article 22) and Saudi Arabia's Personal Data Protection Law are cross-border-transfer and adequacy regimes, not blanket data-localization mandates. They govern how and under what conditions personal data can leave the jurisdiction; they do not, by themselves, force every dataset to stay physically in place. The Saudi PDPL, issued under Royal Decree M/19 in 2021 and amended in 2023, is enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA) and sets its own conditions on transferring personal data outside the Kingdom — permitting transfer to jurisdictions with an adequate level of protection, and otherwise requiring appropriate safeguards.
The hard, in-Kingdom residency requirement a Saudi bank's legal team is usually actually enforcing comes from somewhere else: the Saudi Central Bank's (SAMA) Cloud Computing Regulatory Framework, a sector-specific rule that does mandate in-Kingdom hosting for regulated financial data, layered on top of the PDPL's transfer conditions. I tell buyers to ask which rule they are actually being held to, because the PDPL and the sector regulator are not the same requirement, and conflating them is the exact error that gets a vendor's contract bounced back.
What I check for in practice, across both markets, is whether the vendor can point to a specific, named, in-country or in-jurisdiction hosting option, not a regional gesture. That is why AWS's Middle East (Bahrain) and Middle East (UAE) regions, and Microsoft's Azure UAE North and UAE Central regions, show up constantly in the contracts I review. They give a vendor a concrete answer to "where, exactly." A vendor that can name the specific region and show the data-residency configuration inside it clears the first review. A vendor that says "MENA" does not, because "MENA" is not a jurisdiction any of these statutes, or SAMA's framework, recognizes.
None of this is exotic once you know it. It is a compliance checklist built around jurisdiction, transfer mechanism, and, for regulated sectors like banking, a sector rule stacked on top, enforced by named regulators, with named technical mechanisms available to satisfy it.
What a Levant Buyer Is Actually Checking For
Lebanon has no comparable statute. There is no in-force, comprehensive Lebanese data-protection law equivalent to the UAE or Saudi PDPLs, and no SDAIA-style regulator issuing enforcement guidance. There is also no local hyperscaler region. A Lebanese enterprise cannot ask a vendor to host inside the country the way a Saudi bank can ask for hosting inside the Kingdom, because that infrastructure does not exist there. In practice, data belonging to a Lebanese customer of a cloud-based vendor is already routing through Europe or the UAE before anyone signs anything. In the deals I review, sophisticated Lebanese buyers already know this and have stopped fighting it.
What they have not stopped fighting is disclosure exposure. Lebanon's Banking Secrecy Law dates to 3 September 1956, and it still creates real personal and institutional liability for a bank or a bank-adjacent fintech that allows customer account information to become accessible to a party who could be compelled to hand it to a foreign authority. But I make a point of telling clients the law is not frozen in 1956: it was narrowed by Law No. 306 of 2022, which opened limited access for the Banking Control Commission, the Special Investigation Commission, the judiciary, tax authorities, and forensic auditors, and it was amended again in 2025 under IMF-linked banking reform. The exceptions are narrower now, but the core confidentiality duty toward customer account data is still binding, and it is still the gate a vendor contract has to clear.
For a Lebanese financial institution, the question I ask on their behalf is not where the servers sit. It is whether using this vendor creates a new pathway by which a foreign regulator, court, or law-enforcement body could obtain account-level data that Lebanese law still obligates the institution to protect, even after the 2022 and 2025 narrowing, and whether the vendor's own legal exposure in its home jurisdiction could force it to comply with such a request regardless of what the contract promises.
That is a fundamentally different legal test than a cross-border-transfer rule. It does not ask where the data can go. It asks who can compel disclosure, under what law, and whether the contract gives the customer any advance warning or right to object before that happens.
A Procurement Checklist That Splits by Market, Not by Region
A single residency addendum cannot serve both markets, because it is answering the wrong question for one of them. This is the checklist I actually walk clients through, split by the legal test each market applies, not by geography.
Gulf buyers (UAE, Saudi Arabia):
- Name the specific hosting region in writing, not "MENA" or "the Middle East." A jurisdiction the buyer's regulator recognizes, such as AWS Middle East (UAE), AWS Middle East (Bahrain), or Azure UAE North/UAE Central.
- Confirm whether any processing, backup, or failover ever leaves that named region, including for support access or model inference.
- Ask which cross-border transfer mechanism under the PDPL applies if any data does leave the named region, and, if the buyer is a regulated bank, confirm whether SAMA's Cloud Computing Regulatory Framework imposes a stricter in-Kingdom hosting requirement on top of it. Get the specific mechanism in writing rather than accepting a blanket assurance.
Levant buyers (Lebanon):
- Ask directly under what circumstances a court, regulator, or law-enforcement authority in the vendor's own jurisdiction could compel disclosure of your customer data, and whether you would be notified before it happened.
- Confirm the vendor's contract does not create a data-sharing or subpoena-response obligation that would put your institution in breach of the Banking Secrecy Law's confidentiality duty to your own account holders, a duty narrowed but not eliminated by the 2022 and 2025 amendments.
- Since routing through Europe or the UAE is often unavoidable, identify the specific jurisdiction the data transits and rests in, and evaluate that jurisdiction's disclosure exposure, not its data-localization compliance, since localization is not the risk being managed here.
The two lists look almost nothing alike, and that is the point. A vendor that walks into a Gulf renewal with the Levant checklist, or into a Beirut negotiation with the Gulf checklist, will sound like it has not done its homework, because it hasn't. What I tell general counsel is simple: the fix is not a longer clause. It is asking the market-specific question before the contract goes out, instead of after legal sends it back.