Policy-Based Data Residency: Turning a Requirement Into a Control
Policy-based data residency is the enforcement of a geographic restriction as an evaluated attribute at the access decision point rather than as a deployment choice about where data is stored. The location constraint is written into the data object's own policy, and every request to open the object is checked against the requester's jurisdiction, the device's location, the network path and the object's jurisdiction attributes. Deployment-based residency asks where the bytes live. Policy-based residency asks whether this request, from this place, for this purpose, may open this object, and answers the question again on every request.
Policy-based residency compared with deployment-based residency
| Property | Deployment-based data residency | Policy-based data residency |
|---|---|---|
| Where the constraint lives | In infrastructure configuration: region, tenancy, storage account | In the access policy bound to the data object |
| When it is enforced | At provisioning and replication time | At every request to open the object |
| What it controls | Placement of the primary store and its managed replicas | Release of plaintext to a requester in a given location |
| Coverage of unmanaged copies | None; an export or attachment leaves the control | Retained; the copy carries a policy that denies release outside permitted jurisdictions |
| Response to a change of rules | A migration project | A policy version update that takes effect on the next request |
| Evidence produced | Region configuration and provider attestation | Per-object decisions with requester attributes, reasons and policy version |
| Granularity | Per store, per tenant or per region | Per object, per requester, per request |
| Primary weakness | Copies, caches, backups, logs and derived artifacts | Trustworthiness of the location claim being evaluated |
| Satisfies a statute requiring bytes to remain in-country | Directly | Not on its own; a legal determination in each regime |
The two are complementary. Deployment-based residency answers where the primary store sits, which regulators still ask about directly. Policy-based residency answers what happens to every copy that configuration never saw.
How access policies incorporate location
Access policies incorporate location by treating geography as one attribute among several in an attribute-based access control (ABAC) evaluation, rather than as a property of the environment the application happens to run in.
A policy decision point (PDP) evaluating a residency rule reads several categories of attribute at once. Subject attributes carry the requester's employer, role, citizenship and jurisdiction of employment. Device attributes carry enrollment region, posture and attestation state. Environment attributes carry the observed network origin, the egress path and the time of request. Object attributes carry the classification, the data subject's jurisdiction, the legal basis for processing and the list of permitted release jurisdictions. Purpose of use carries the reason the request is being made.
A residency rule is a condition over those attributes: release only where the object's permitted-jurisdiction list contains the requester's jurisdiction and the observed network origin, and the device is enrolled in a permitted region. Defaults are fail-closed, so a request whose location attributes cannot be established is denied rather than allowed.
Two design details separate a working control from a decorative one. The rule references the object's own attributes, so one policy expression covers records with different jurisdiction obligations. And the decision is short-lived and re-evaluated, so a laptop that was in a permitted country this morning does not retain that authorization after crossing a border. The general contrast between attribute conditions and static role membership is covered in ABAC vs RBAC as the Zero Trust Default.
How encryption enforces geographic restrictions
Encryption enforces a geographic restriction indirectly. Encryption makes the ciphertext inert without a release decision, and the release decision is the point at which geography is evaluated.
The chain runs as follows. The object is encrypted with a data encryption key. That key is wrapped to a key service rather than stored in the file. The access policy naming permitted jurisdictions is written into the object and cryptographically bound to the key, so an attempt to widen the permitted list breaks the binding and the request fails. A requester presents subject, device and environment attributes. The policy decision point evaluates the residency condition. On allow, the key is rewrapped to the requester's ephemeral key and returned. On deny, no key material leaves the service.
The consequence is that a copy landing in a prohibited region is unreadable there. Geographic enforcement therefore extends to copies that no deployment configuration ever knew about: the attachment forwarded to a partner, the export in an unmanaged bucket, the backup replicated by a service with its own regional defaults.
Placing the key service inside the governing jurisdiction strengthens the control structurally. When the service authorized to release keys operates in-region under in-region personnel, the decision physically occurs inside the jurisdiction and ciphertext held elsewhere carries no value without it.
One boundary needs stating plainly. Encryption plus bound policy does not stop ciphertext from being stored in a prohibited region. Where a statute requires the bytes themselves to remain inside national borders, policy-based residency does not satisfy the statute on its own. Whether strongly encrypted data held abroad under in-country key control is treated as compliant varies by regime and is a legal determination, not a technical one. The distinctions between sovereignty, residency and localization that this depends on are set out in What Is Data Sovereignty: Enforcement, Not Geography.
How far a location claim can be trusted
Attribute-based geographic control depends entirely on the trustworthiness of the location claim it evaluates. A policy evaluated against a forged attribute is enforced faithfully and produces the wrong answer, so signal sources deserve explicit grading.
| Location signal | How it is obtained | How far it can be trusted |
|---|---|---|
| Self-asserted client location | A field supplied by the client application | Not evidence. Trivially forged and should never be a sole condition |
| IP geolocation | Address-to-location databases maintained by commercial providers | MaxMind reports country-level accuracy above 99 percent excluding VPN traffic, and city-level accuracy between 20 and 75 percent. Defeated by VPN, proxy, relay services and carrier-grade address translation |
| Platform location services | Operating system location API on a managed device | Reasonable on an attested managed device. Spoofable on rooted, jailbroken or emulated devices |
| Enterprise egress path | Request arrives from a known in-region egress over mutually authenticated TLS | Strong for corporate traffic. Establishes where the connection left the network, not where the person is |
| Device attestation | Signed platform attestation binding device identity to an enrolled fleet | Strong evidence of device identity, supporting a location inference through the enrollment record rather than proving location |
| In-jurisdiction key service | The service authorized to release keys operates inside the jurisdiction | Strongest available. It removes the need to trust a claim, because the decision itself happens in-region |
| Contractual and operator attestation | Provider commitments, audit reports, personnel residency undertakings | Legal evidence about the operator. Not a runtime signal about a request |
The practical conclusion is to combine signals and prefer structural controls over asserted ones. Country-level IP geolocation with anonymizer detection, an attested enrolled device, and a known enterprise egress path form a defensible composite. Any one alone does not.
What policy-based data residency cannot do
Policy-based data residency cannot stop ciphertext existing in a region. It controls readability, not placement.
Policy-based data residency cannot govern plaintext after an authorized release. A requester in a permitted jurisdiction who legitimately opens an object can carry the content anywhere. The control ends at release.
Policy-based data residency cannot compensate for wrong object attributes. If an object is labelled with the wrong data-subject jurisdiction, the policy will enforce the wrong restriction with complete consistency.
Policy-based data residency cannot function without a reachable decision service unless offline operation has been provisioned deliberately. Because defaults are fail-closed, an outage denies access.
Frequently asked questions
What is policy-based data residency?
Policy-based data residency enforces a geographic restriction as an attribute evaluated at the access decision point rather than as a deployment choice about storage location. The permitted jurisdictions are written into the data object's policy and checked on every request against the requester's jurisdiction, device location and network origin. Copies that leave the intended region remain unreadable there.
How does encryption enforce geographic restrictions?
Encryption makes ciphertext inert without a release decision, and the release decision is where geography is evaluated. The data encryption key is wrapped to a key service, the permitted-jurisdiction policy is bound to that key, and a request from outside the permitted set returns no key material. A copy that reaches a prohibited region cannot be opened there.
How do access policies incorporate location?
Access policies incorporate location as one attribute in an attribute-based access control evaluation. The decision point reads subject jurisdiction and citizenship, device enrollment region and posture, observed network origin and egress path, purpose of use, and the object's own permitted-jurisdiction list. The residency rule is a condition over those attributes, evaluated per request with a fail-closed default.
Can geographic access controls be bypassed with a VPN?
IP geolocation alone can be defeated by VPNs, proxies and relay services, which is why location should never rest on a single signal. Composite evaluation raises the cost considerably: anonymizer detection on the network origin, device attestation tied to an enrolled fleet, a known enterprise egress path, and a key release service operating inside the jurisdiction.
Does policy-based residency satisfy a data localization law?
Not on its own. Localization statutes generally require the data itself to remain inside national borders, and policy-based residency controls readability rather than placement. Whether strongly encrypted data held abroad under in-country key control is treated as compliant differs by regime and is a legal determination. Most programmes pair in-region storage with object-level policy enforcement.
How Lattix evaluates geography
Lattix evaluates geography at the policy decision point (PDP) alongside subject, device, environment, purpose of use, network posture, risk and data-object attributes, using attribute-based access control (ABAC). The decision returned is signed and short-lived, carrying allow or deny, the reasons, the policy version hash and the object identifier. The policy enforcement point (PEP) acts at decrypt time, so a jurisdiction restriction applies to every copy rather than to one storage location. Defaults are fail-closed and revocation propagates to deny. Deployment across cloud, regional hub, tactical edge and air-gapped environments allows key release to sit inside the governing jurisdiction. The category this control belongs to is defined in What Is Data-Centric Security: A Technical Reference, and the case of two jurisdictions issuing incompatible instructions is treated in Cross-Border Data Sharing Under Conflicting Legal Regimes.