Data residency is an architecture problem wearing a legal costume

Residency requirements arrive as legal text and get filed as a compliance obligation, which is how they end up being satisfied last and expensively. The requirement is not really legal, though. It is a constraint on where a workload may be scheduled and where its bytes may come to rest.

Expressed that way it belongs in the same conversation as availability zones and failover, and it can be enforced by the same machinery. Expressed as a clause in a contract, it belongs to nobody in particular until an auditor asks about it.

Why the costume matters

The costume is not harmless. It determines which function owns the requirement, and ownership determines when the requirement is considered. A legal obligation is owned by legal, reviewed at the end, and verified by attestation. A placement constraint is owned by whoever designs the topology, considered at the start, and verified by the platform refusing to schedule the workload anywhere else.

The second arrangement is dramatically cheaper, and the difference is not marginal. Remediation after the fact means moving live workloads, re-pointing integrations, renegotiating with vendors whose regions do not line up with the requirement, and doing all of it under a deadline set by someone outside the organization. Designing for it up front usually means choosing differently between two options that cost about the same.

What it looks like as an architecture concern

Placement policy. Regions are not a deployment detail but a declared property of the workload, enforced by admission control rather than by convention. If a workload can be scheduled outside its permitted set, the requirement is aspirational.

Data movement. Residency is rarely violated by the primary store. It is violated by the backup, the replica, the analytics export, the log aggregator and the third-party service that helpfully caches responses in a region nobody chose. Each of those is a data flow, and each needs to be enumerated and constrained.

Contractual guarantees that match the technical ones. A vendor who cannot tell you where your data rests cannot be part of a residency story, however good the product is. This is usually the constraint that eliminates options, and it is far better discovered during selection than during remediation.

The two versions of this programme

The remediation nobody wants is the one that starts after the finding. It has a fixed deadline, a known scope, an unknown amount of undiscovered data movement, and an audience. It consumes senior attention for two quarters and produces no capability the business asked for.

The one that goes well starts as a topology decision, months before anyone writes the finding down. It is not visible as a programme at all, because it looks like a handful of design choices — a placement policy, an enumerated set of flows, a vendor eliminated early — each of which cost very little at the moment it was made.

The organizations that end up in the second version are not better at compliance. They are better at recognising a technical constraint when it is dressed as a legal one, and at putting it in front of the people who design systems rather than the people who document them.

A closing test

Ask where a given workload is permitted to run, and then ask what would happen if someone deployed it elsewhere. If the answer to the second question is "the pipeline would reject it", residency is an architecture property. If the answer is "we would find out at the next audit", it is still a costume.