Data residency is a design decision, not a negotiation

In most enterprise software conversations in this region, data residency arrives late and is treated as friction. Procurement raises it, the vendor says the platform is 'compliant', and everyone moves on without establishing what was actually agreed.

That sequence produces systems that cannot answer the question when a regulator eventually asks it properly.

The question is not whether, it is where and who

'Compliant' is not a location. The useful questions are concrete: which physical region holds the data at rest, which jurisdictions can a support engineer reach it from, what leaves the boundary in logs, backups and telemetry, and who can be compelled to hand it over.

A platform can hold your data in-country and still ship error traces containing customer records to a logging service on another continent. That is not a hypothetical failure mode; it is the normal default of most observability tooling.

Why it has to be an input

Retrofitting residency is expensive because it is rarely one change. It touches where the database sits, where backups go, where the queue lives, which third-party APIs are called, where the identity provider is, and where the people operating it are.

If residency is a design input, those are a series of ordinary choices made once. If it is a late requirement, they are a migration — and migrations of systems already in production are where budgets go.

What a system designed for it looks like

The architectural move that buys the most flexibility is reducing what has to cross a boundary at all. A document signing platform does not need to receive your documents: it needs a cryptographic hash of them. Once the design only consumes hashes, 'can this run inside our network' stops being a deployment argument.

The same reasoning applies to an HR platform that overlays an existing system of record rather than replacing it, and to integration layers that can be deployed on either side of a boundary.

• Can it run entirely inside the client's network, with no outbound dependency?
• If not, exactly what leaves, and can that be enumerated rather than described?
• Where do backups go, and who can decrypt them?
• From which jurisdictions can support staff access production?

The commercial point

This is not only an engineering concern. For regulated buyers in the GCC — government, banking, defence — residency is frequently the constraint that decides the shortlist before features are discussed. A vendor who can answer the four questions above precisely has already separated itself from most of the field.

And answering them precisely requires having decided them early. Which is the whole argument.