Due diligence has a well-rehearsed technology checklist: what systems does the target run, what does the licensing cost, how much technical debt is there, and how long will integration take. Data sovereignty rarely appears on it, and when it does, it appears as a compliance line item rather than as a valuation input. That omission produces a specific and repeatable surprise. A buyer completes an acquisition, begins integration, and discovers that the target's customer data cannot legally be moved to the group platform, that its shared service arrangement in another country was never documented as a cross-border transfer, or that the entire commercial model depends on a data flow that a regulator has since restricted. The integration synergies in the model assumed consolidation. The law does not permit it. The cost is not usually a fine. It is that the deal thesis quietly stops working — the platform consolidation that justified the multiple cannot happen, the combined analytics that justified the cross-sell cannot be built, and the target has to be run as a separate operation indefinitely.
What diligence should actually establish
Five questions, none of which appear in a standard technology diligence pack. Where does the data physically sit, and under whose control? Not the vendor's marketing claim about a region — which entity holds it, where is that entity incorporated, and which authorities can compel production. A target using a global SaaS platform may have obligations it has never assessed. What transfers happen today, on what legal basis? Every flow between the target's entities, to its parent, to its service providers, to its offshore delivery centre, and to its analytics platform. The common finding is that transfers are happening with no documented basis at all, because nobody ever characterised the group reporting feed as a transfer. What restricts movement after closing? Localisation requirements in the target's markets, sector-specific rules, and — the most frequently missed — customer contract terms. Enterprise and public sector customers routinely impose data location and subprocessor restrictions that survive a change of control and that no one in the target's commercial team remembers agreeing. Does the transaction itself require consent or notification? Transferring personal data to an acquirer is a processing activity. In some jurisdictions and under some contracts it requires notification, consent, or a regulator filing, and this can affect the closing timetable rather than just the integration plan. What is the remediation cost, and who bears it? If the target has been transferring data unlawfully for years, that is an inherited liability. It belongs in the price or in an indemnity, not in the post-close surprise column.
Where the value actually leaks
The pattern across transactions is consistent: sovereignty issues rarely kill deals, but they routinely destroy the synergy case. The acquisition model assumes one ERP, one CRM, one data warehouse, one customer support platform and a consolidated analytics layer. Localisation requirements mean separate instances in some markets. Customer contract restrictions mean certain accounts cannot be migrated at all. Sector rules mean regulated entities keep their own systems. What was modelled as a single integration programme becomes a partitioned estate with permanent duplicate running costs — and the difference between those two outcomes can be a material share of the deal's expected value. The second leak is timing. Integration plans built on a twelve-month consolidation schedule slip badly when each market requires its own assessment, transfer mechanism and regulator engagement. Deals with earn-outs or financing tied to synergy delivery are particularly exposed, because the delay itself has a price. The third is carve-outs, which are harder than acquisitions and are routinely underestimated. Separating a business unit from a parent means untangling shared systems, shared data and shared processing arrangements — and the transitional services agreement that keeps the carved-out business running is itself a cross-border processing arrangement that needs a legal basis. TSA exit dates are frequently the binding constraint on the whole separation, and a sovereignty problem discovered mid-TSA has no easy resolution because the clock is contractual.
Practical Guidance for M&A Data Diligence Review
- Put data location and transfer questions in the diligence request list from day one. They take time to answer properly and the answers change the integration plan, not just the compliance file.
- Read the target's largest customer contracts for data location and subprocessor clauses. This is where migration blockers hide, and the commercial team usually does not know they exist.
- Map transfers at entity and field level, including to service providers and offshore delivery centres. The undocumented group reporting feed is the most common finding.
- Test the integration thesis against the legal constraints explicitly. If consolidation is not permitted in the target's largest markets, the synergy number is wrong and should be revised before signing.
- Price historical non-compliance as an inherited liability. Remediation, regulator engagement and potential exposure belong in the price or in specific indemnities.
- Check whether the transaction itself triggers notification or consent obligations. This is a closing-timetable issue, not a post-close one.
- Treat carve-outs as harder than acquisitions and start the separation analysis earlier. The TSA exit date is usually the real deadline and it does not move.
- Assess the target's AI and analytics estate separately. Model endpoints, embeddings and vector indexes create data locations that the target's own data map almost certainly omits.
The Regional Dimension
Gulf transactions carry sovereignty characteristics that generic diligence templates do not anticipate. The entity structure is the first. A regional target is rarely one company. It is typically a group of entities spanning mainland and free zone jurisdictions, often across several countries, sometimes with a local partner or service agent arrangement in its history, and with different data protection regimes applying to different entities. A DIFC or ADGM entity operates under a framework broadly modelled on European practice; the mainland entity next door operates under the federal regime; the Saudi entity operates under its own law and cloud framework. A single "the target complies with data protection law" representation is close to meaningless across that structure, and diligence needs to be done entity by entity. The second is the shared services concentration that makes these groups attractive in the first place. Regional targets frequently run finance, HR and IT from a hub in Dubai, Riyadh or Cairo serving entities across the Gulf, the Levant, Africa and South Asia. That hub model is efficient and it is a dense web of undocumented cross-border transfers. Buyers should assume the transfer register does not exist and budget for building it. The third is employment and immigration data, which carries unusual sensitivity here because employment is linked to residency. Payroll files flowing through wage protection systems, visa and labour records, medical insurance data, and end-of-service calculations are all personal data with regulatory exposure, and they sit in systems — often local payroll bureaux or the PRO's spreadsheets — that a technology diligence focused on ERP and CRM will never look at. In a share purchase these liabilities transfer with the entity. Three further points. Government and quasi-government customers across the region impose residency and access conditions that are non-negotiable and survive change of control, so a target with public sector revenue needs those contracts read carefully. Local content and in-country value commitments made in tenders may include obligations about where systems are operated and by whom, which constrains post-close consolidation. And the integrator relationship matters: regional targets commonly have their estate operated by an external partner holding privileged access, and that partner's location, contract and access rights are part of the sovereignty picture the buyer inherits.
The objection worth taking seriously
The honest counter-argument is that deal timetables do not accommodate this level of analysis, and that treating it as a gating item would stop transactions that should proceed. Diligence windows are short, target cooperation is limited, and competitive processes reward speed. A full data flow mapping exercise across a multi-entity group is weeks of work that the seller has no incentive to support. In practice, buyers make a judgement with incomplete information, and that is not irrational — most transactions do not encounter a sovereignty blocker, and the ones that do usually find a workable if expensive path. There is also a fair point that this risk is frequently overstated by advisers who bill for assessing it. Regulatory enforcement against acquirers for inherited transfer non-compliance is uncommon; the more realistic consequence is remediation cost and integration delay rather than penalty. Framing sovereignty diligence as an existential risk invites the scepticism it usually receives from deal teams. The proportionate position: scale the work to the exposure. A target with data in one jurisdiction, no public sector customers and no offshore processing needs a short set of questions. A target with a regional hub, government contracts, multiple regulatory regimes and an offshore delivery centre needs real analysis, because the integration thesis — which is where the money is — depends directly on the answers. The discipline worth insisting on is narrow: before signing, confirm that the specific consolidation assumed in the synergy model is legally possible in the target's largest markets. That single question catches most of the value at risk.
Common Questions
What is the most commonly missed issue in technology diligence?
Customer contract clauses restricting data location and subprocessors. They block migration entirely for specific accounts, they survive change of control, and they sit in commercial contracts that the technology workstream never reads.
Does buying a company transfer its data protection liability?
In a share purchase, generally yes — the entity and its history come with it, including historical non-compliance. Asset purchases can be structured differently, but the data itself often carries conditions. This is a question for transaction counsel early, not for the integration team later.
How should sovereignty findings affect the deal?
Through the synergy model first, then through price and indemnities. If consolidation is not permitted in a major market, the duplicate running cost is permanent and belongs in the valuation rather than in a risk register.
What does AI add to the diligence list?
A new category of data location that almost no target has mapped. Ask which AI services the target uses, whether customer or employee data is sent to them, where inference runs, what is retained, whether embeddings or vector indexes exist and where they live, and whether any model has been fine-tuned on customer data — because fine-tuned weights cannot be selectively purged, which complicates both deletion obligations and any post-close separation. For a carve-out this matters more than people expect: a shared vector index or a model trained on combined data is not cleanly divisible, and discovering that during a TSA exit is an expensive place to discover it.
M&A Data Diligence Review — before signing, confirm the consolidation your synergy model assumes is actually legal in the target's biggest markets.