How do you meet data residency requirements without a region lock-in?
Residency is usually sold as a region selector — a dropdown that moves the vendor's copy of your data to a different country. Structural residency is different: the data and the metadata never leave infrastructure you control, so there is no vendor-side region to choose.
When both the data plane and the control plane run in your environment, residency is a property of your architecture rather than a vendor setting. There is no cross-border copy to audit because no vendor-side copy exists.
Region selection vs structural residency
These are not two flavours of the same thing. One is a contract about where a vendor keeps data; the other is an architecture in which the question does not arise.
| Property | Region-selectable SaaS | Structural residency (Bridge) |
|---|---|---|
| Where rows are processed | Vendor's cloud, in the chosen region | Your VPC, on-prem or isolated network |
| Where metadata lives | Vendor's control plane | Your deployment |
| What crosses a border | Rows, metadata and logs, by design | Nothing, unless you target an external system |
| How you prove it | Vendor attestation and DPA | Your own network and packet evidence |
| Effect of a new regulator | Re-negotiate region availability | Boundary is already inside your control |
This matters commercially as well as legally. A region dropdown ties you to whichever regions the vendor has launched, and to their launch schedule. A structural boundary ties you to infrastructure you already operate. If your requirement is "data must not leave our environment", a region selector is answering a different question.
For teams that do need to sync across a boundary, Bridge supports file exchange across a security gateway: the change set is carried across deliberately, by your rules, with no inbound connection opened.
You need structural residency when…
- ✓The requirement is "data must not leave our environment", not "must stay in country X"
- ✓Your auditor asks for network evidence rather than a vendor letter
- ✓You operate multiple jurisdictions and want one consistent control
- ✓You cannot wait for a vendor to launch a region in your market
Structural residency is overkill when…
- ×You are comfortable with a vendor-hosted control plane
- ×Your only requirement is a contractual region commitment
- ×You have no infrastructure to host the platform on
- ×You need a fully managed service with no operational burden
Residency, answered
Do you make specific country or region commitments?
We deliberately do not sell residency as a list of regions. Bridge runs in your environment, so the boundary is your infrastructure and your jurisdiction — there is no vendor-side region holding a copy of your data to make a promise about.
What crosses the network boundary?
Only what you configure. Source reads and target writes happen inside your perimeter; for isolated segments a change set crosses a security gateway via file exchange, under your rules. No inbound connection is required.
How do I verify it during a POC?
Instrument the egress interface, run a pipeline, and confirm that no flow carries rows, schema metadata or logs to a Sumeta endpoint. The control plane runs locally, so there is no vendor console to fall back on.
Does this replace a DPA?
No. Enterprise includes DPA and audit support, and the DPA still governs the commercial relationship. Structural residency simply means the data-handling surface is much smaller.
Prove residency in your own environment
Run a pipeline with egress instrumentation and confirm the boundary yourself before you sign.