Skip to main content
For global organisations subject to data-localisation obligations in multiple countries, the right architecture is to run one Databunker Pro instance per jurisdiction. Each instance keeps the PII for that jurisdiction inside the jurisdiction, with its own keys, audit trail, and operators if local law requires. This page covers the pattern, the reasons behind it, and how the privacy office runs operations across N deployments without violating data-localisation rules.

​
The problem this pattern solves

A growing number of jurisdictions explicitly prohibit transferring personal data out of the country — or impose burdensome conditions that make centralising PII in one cloud region commercially impractical. Examples: A single-region deployment that holds PII for all these jurisdictions in, say, AWS Frankfurt, is non-compliant the moment a Russian, Indian, or Chinese resident’s record lands in the vault.

​
The pattern

Deploy a separate Databunker Pro instance in each jurisdiction where you hold PII. Each instance is:
  • Independent — its own database, its own master key, its own wrapping key, its own audit log.
  • In-region — deployed on local cloud infrastructure (AWS Mumbai, Azure Russia, etc.) or local on-prem hardware.
  • Operated locally if local law requires (operator citizenship, residency, or licensing constraints).
The application chooses which regional vault to call based on user domicile, data classification, or originating system.
Each regional vault holds only the records of users domiciled in that jurisdiction. Cross-vault correlation is not possible at the SQL or token layer — that is the point of the pattern.

​
The next-order problem: operating privacy across N vaults

Once an organisation has five, ten, or fifteen regional Pro deployments, the privacy office faces a new problem:
  • A data subject in India submits a DSAR through the company’s global website. How does the DPO team find their data without logging into the Indian Pro instance separately?
  • A consent withdrawal in Brazil needs to propagate to every system that holds the user’s data — but the regional vaults are intentionally air-gapped at the PII level.
  • A compliance report for the EU board needs aggregated metrics (number of records, DSAR counts, consent rates) across every region.
Running a separate DPO seat per vault is impractical at scale.

​
The unifier: Databunker DPO

Databunker DPO is the operational layer designed for exactly this scenario. DPO connects to each regional Pro deployment over an authenticated channel and gives the privacy office a single UI spanning the full estate, with the critical property that:
  • Minimises the chance of PII leaving its home jurisdiction. By design, only operational signals flow through DPO — DSAR tickets, consent state transitions, audit summaries, processing-activity metadata, aggregated metrics. Raw PII is never required for these operations, so under normal operation it stays inside the regional vault. Customers remain responsible for configuring DPO and any custom workflows to honour their local data-localisation constraints.
  • Each regional Pro deployment continues to enforce its own access control, audit, and key custody locally.
This lets a small privacy team operate at global scale without violating any localisation rule, because the data that crosses borders in the DPO operational plane is not personal data — it is metadata about the privacy operations themselves.

​
DPO deployment options

​
When NOT to use this pattern

This pattern is for organisations operating in multiple jurisdictions with localisation constraints. If you operate in a single jurisdiction, or in multiple jurisdictions without conflicting localisation rules, the right tool is multi-tenancy inside a single Pro instance — it gives cryptographic per-domain isolation without the operational overhead of running N deployments. The two patterns can be combined: each regional Pro deployment can itself use multi-tenancy internally to separate its security domains (Student Services vs Analytics vs External Integrations), so the architecture remains consistent regardless of scale.
  • Multi-tenancy — per-instance tenant isolation (different concern).
  • Architecture — core single-instance architecture.
  • Security overview — sovereignty and key custody guarantees that make this pattern work.
  • Databunker DPO — the operational unifier across regional Pro deployments.