A founder in Dubai signs a six-figure contract with a regional software house to build a custom inventory platform. Three years later the relationship sours over a billing dispute. The agency's CEO sends a final email: "Until the outstanding invoices are settled, we will not transfer the source code. Our position is that the IP remains with us under the contract."
The founder calls a lawyer. The lawyer reads the contract. The contract is silent on source-code delivery, silent on escrow, silent on what happens when the agency refuses to hand over assets. The application is still running — on a server the agency controls, behind a domain registered to the agency, with a database whose credentials only the agency knows.
This is not a hypothetical. It is the most common incident type we see when MENA businesses ask Noqta to audit a vendor relationship or take over a stalled project. And it is almost always preventable by one paragraph that should have been in the original contract.
That paragraph is the source-code escrow clause. This article is what it looks like, how to operationalise it without enterprise-grade overhead, and why MENA contracts almost never have it.
Why MENA Contracts Skip the Clause
Source-code escrow is standard in EU and US enterprise software procurement. Most large vendors that sell into European banks or American hospitals expect to deposit code with NCC Group's Escode, Iron Mountain, or EscrowTech as a condition of closing the deal. The market is mature, the templates are battle-tested, and the cost is rarely a deal-breaker — typically a few thousand dollars per year for a mid-market deposit.
In MENA, this market is thin for three structural reasons.
The first is procurement maturity. Most SME and even mid-market software procurement in Tunisia, Saudi Arabia and the broader GCC happens without a procurement function. The CEO meets a vendor at an event, signs a one-page proposal, and trusts the relationship. There is no contract review, no escrow line item in the procurement template, no comparison against a procurement playbook — because there is no procurement playbook.
The second is legal-services geography. The escrow providers (NCC, Iron Mountain, EscrowTech) operate primarily out of the UK and the US. They do serve MENA clients, but they do so through London or Dubai offices, and the contract documents are drafted under English or US law. A Tunisian SME signing a TND 60,000 contract is not going to engage an English-law escrow agreement. The friction is too high.
The third — and most painful — is vendor incentive. A regional agency or freelancer does not want to deposit your source code in an escrow that the client controls. The leverage of keeping the code is the leverage that lets them rehire on the next contract, charge for migration, or simply walk away with the IP. Vendors who would gladly sign an escrow clause exist, but they are not the cheapest bid in the RFP. So the cheapest bid wins, and the escrow clause is the first thing cut from the contract.
The combined effect is that nine out of ten MENA SME software contracts have no escrow clause and no operational mirror of the code. When the inevitable dispute or vendor departure happens, the client discovers they own nothing.
What the Clause Should Actually Say
The legal clause is short. The operational discipline behind it is what makes it work.
A defensible source-code escrow clause covers six points:
- Scope of deposit. Not just source code. Include build artifacts, infrastructure-as-code (Terraform, Ansible, Pulumi), CI/CD pipeline definitions, encrypted secrets manifests, deployment scripts, database schema, seed data, and all written documentation needed to rebuild the system from a clean machine.
- Deposit cadence. Continuous mirror for the operational version. Snapshot deposit at least monthly with the escrow agent if a third-party agent is engaged. The clause should require an updated deposit within a defined number of days of every production release.
- Verification right. The client (or the escrow agent acting on the client's behalf) has the right to verify at any time that the deposit is current, complete, and buildable from a clean environment following the written instructions. Verification failure is a defined breach.
- Release conditions. The list of events that trigger release of the deposit to the client. Standard items: vendor bankruptcy or insolvency, sustained material breach of SLA, vendor refusal to hand over operational access, vendor written notice of withdrawal, sustained service outage above a defined threshold, or written request from the client after a defined notice period.
- Vendor warranty. The vendor warrants that the deposit reflects the production system and contains no licence violations, no embedded credentials, no third-party code that cannot be redistributed to the client.
- Breach remedy. Failure to comply with the deposit obligation constitutes material breach allowing the client to terminate without penalty, and entitles the client to either the deposit (via the agent) or specific performance (via the court).
A version of this clause that fits on a single page of any standard MENA software contract is the difference between owning what you paid for and owning nothing.
The Operational Pattern: Continuous Git Mirror
For the vast majority of MENA SME engagements, formal third-party escrow is overkill. The cheaper and more useful pattern is a continuous Git mirror enforced by the contract.
The operational discipline is straightforward. The client creates a Git repository on a service they control — GitHub Organization, GitLab Cloud, Bitbucket, or self-hosted. They grant the vendor push access. They contractually require the vendor to push to that remote on every release.
The vendor's release script becomes one line:
git push --mirror clientThat is it. Every branch, every tag, every commit is mirrored to the client-owned repository at every release. The client never has to ask for the code. They already have it.
For infrastructure-as-code and CI/CD definitions, the same pattern applies. If the vendor uses GitLab CI, the .gitlab-ci.yml is part of the repository and is mirrored automatically. If the vendor uses Terraform, the .tf files are in the repository and are mirrored. If the vendor uses Ansible, the playbooks are in the repository and are mirrored. If anything lives outside the repository, the contract is broken — that is itself a useful red flag.
For secrets, the contract should require an encrypted secrets manifest (a .env.example with all keys, paired with an encrypted vault — Bitwarden Secrets, 1Password Vaults, Vaultwarden, HashiCorp Vault) where the client owns the master key. The vendor never holds the only copy of production credentials. The handover protocol is one rotation away from being clean.
This pattern costs nothing beyond the client's existing Git hosting subscription. It requires no escrow agreement, no third-party agent, no English-law contract. The contractual obligation can sit in a one-page software services agreement under Tunisian, Saudi or UAE commercial law.
The day the vendor relationship ends, the client clones the mirror, rotates the secrets, redeploys to a server they control, and the application keeps running.
When Third-Party Escrow Is Worth It
The Git-mirror pattern is sufficient for most engagements. There are three situations where a formal third-party escrow with a regulated agent earns its fee.
The first is when the build is mission-critical and the vendor is financially fragile. A small agency or single-founder vendor without succession planning is a risk that the Git mirror does not fully address — the founder could be incapacitated, the company could be wound up, ownership of the Git account could be disputed in probate. A third-party escrow agent provides a neutral custodian that survives the vendor.
The second is when the client's procurement or legal team requires it. Some MENA financial institutions, government entities, and large enterprises require escrow as a procurement standard. Saudi PIF-funded entities, ADQ portfolio companies, and major UAE banks routinely require deposits with NCC Group or Iron Mountain. If you are selling into that customer, you need to be ready to deposit.
The third is when the deposit needs to be verified by a neutral party. NCC Group's Escode service, for example, offers a verification level where they confirm the deposit builds cleanly from documented instructions on a clean machine — a service that is meaningfully more rigorous than the client running their own quarterly verification. For regulated workloads (banking core systems, health platforms, government records) this verification level may be required by the regulator.
For these cases, the escrow providers that serve MENA clients today include:
- NCC Group Escode (UK-based, serves MENA through London office) — the largest commercial escrow provider globally.
- Iron Mountain Escrow Services (international, with Dubai presence) — strong in regulated industries.
- EscrowTech International — competitive on price, US-based.
- Al Tamimi & Company (UAE law firm) — does not act as escrow agent directly but structures escrow arrangements under DIFC and ADGM law, referring to regional agents.
A typical mid-market escrow deposit with verification costs USD 3,000 to USD 8,000 per year. For a critical workload, it is a rounding error against the cost of an actual incident.
Where MENA Law Lands Today
The legal enforceability of an escrow clause in MENA is jurisdiction-dependent and worth understanding before you draft.
In the UAE, escrow arrangements under DIFC and ADGM law are well-supported. DIFC courts have a track record of enforcing software escrow release conditions in commercial disputes. Federal courts in mainland UAE also recognise escrow but the process is slower. The Federal Personal Data Protection Law (Decree-Law 45/2021) reinforces the client's right to data portability, which strengthens any escrow-release argument when personal data is involved.
In Saudi Arabia, the Personal Data Protection Law (PDPL) under SDAIA supervision creates strong duties around data controller access to personal data — and by extension to the systems processing that data. SAMA cyber-resilience guidance for banking and CITC guidance for telecom both reinforce the requirement for source-code access in certain regulated workloads. Source-code escrow is becoming a standard procurement requirement in Saudi enterprise contracts, particularly in PIF-affiliated entities.
In Tunisia, the legal framework is thinner. Loi 2004-63 on personal data protection (the active law as of 2026) governs data controller obligations but does not specifically address source-code escrow. The 2018 Code des sociétés provides general contractual enforcement. There is no dedicated escrow agent in Tunisia today. Tunisian clients should use the Git-mirror operational pattern combined with a strong contractual obligation enforceable in commercial court, and consider an English-law overlay if the contract value is significant.
In Egypt, the Personal Data Protection Law (Law 151/2020) creates data controller obligations but does not specifically mandate source-code escrow. Egyptian commercial law enforces contractual obligations including escrow if drafted clearly. There is no dedicated regional escrow agent operating in Egypt today.
The pattern across the region is consistent: the contractual clause is enforceable where well-drafted. The thin layer is the operational infrastructure of escrow agents — which is why the Git-mirror pattern is the realistic baseline for SMEs in the region.
What This Looks Like in a Real Vendor Audit
When Noqta runs a vendor audit for a MENA client — typically a one-day engagement assessing risk in an existing software relationship — the escrow and source-code question sits in section 8 of our standard 8-point review.
We ask the incumbent vendor four questions:
- Where is the source code repository, and who owns the account?
- Is the source code mirrored to a repository owned by the client?
- What are the release conditions in the current contract that trigger handover of code, infrastructure access, and credentials?
- Can you demonstrate a clean build of the current production version on a clean machine following written instructions, today, in front of us?
The fourth question is the most revealing. A vendor who cannot demonstrate a clean build today is a vendor whose deposit (if it existed) would not be useful in a real handover. We have run this exercise with vendors who could not rebuild their own production code without the original developer's laptop. That is the gap that escrow — operational or formal — is supposed to close.
Where the audit identifies a gap, our remediation is sequenced: contract amendment first (escrow clause backed by Git-mirror obligation), operational mirror setup second (client-owned remote, vendor push access, contract-enforced release discipline), then quarterly verification cadence to confirm the deposit is current and buildable.
For our PMaaS clients, this discipline is part of standard project governance — every project we manage has a client-owned mirror from day one, and every release goes to that mirror. Our clients never have to ask for their code. They already have it.
The Honest Trade-Off
Source-code escrow does not solve every vendor risk. It does not magically transfer operational knowledge, it does not replace documentation, and it does not protect against a vendor who deposits incomplete or unbuildable code. The operational mirror only works if the contract is actually enforced — if no one is checking, the mirror falls out of sync, and the deposit becomes a fiction.
The honest position is this: escrow is the contractual mechanism that gives you the option to take back control. Whether you exercise that option, and how cleanly, depends on the operational discipline behind it. A weekly Git mirror with quarterly verification is more useful than a quarterly escrow deposit with no verification. A formal escrow with verification by a regulated agent is more useful than either, at proportionate cost.
For MENA businesses today, the single most useful action is to put the clause in the contract and the mirror in place. The clause costs nothing. The mirror costs almost nothing. The cost of not having either is the cost of the incident — and the incident is not a hypothetical.
Where Noqta Sits
Our PMaaS practice writes the contract clause and operates the mirror for every project we govern. Our vendor-audit deliverable surfaces the gap when it exists in legacy vendor relationships. Our standard recommendation is the Git-mirror pattern as the baseline, escalating to formal third-party escrow only where the workload, the regulator, or the vendor's financial fragility require it.
If your current vendor cannot answer the four questions above to your satisfaction, the audit pays for itself in the first quarter of operational discipline that follows.
Related reading: the vendor audit playbook, the AI dashboards architecture for governance reporting, and the GitLab + AI PM dashboard pattern we use to keep client visibility on every project.