Keep data location explicit. Keep deployment choices governed.
ZolkoSuite is architected to make storage, processing, backup, replication, recovery, key custody and sovereign deployment constraints visible by jurisdiction, workload, data class and deployment. Availability varies by deployment and jurisdiction.
How a policy becomes a technical location constraint
Residency is not a single setting. A requirement resolves through entity, jurisdiction, workload and data class before it produces an enforceable constraint.
Requirement stated
Customer residency requirement mapped across architecture logic or contractual terms.
Entity & jurisdiction
Which legal entities and jurisdictions the requirement governs.
Workload scope
Which workloads and data classes fall inside the requirement.
Feasibility check
Whether the constraint can be met in approved regions, per dimension.
Deployment selected
Deployment model determines what is actually achievable.
Policy applied
Constraint configured across storage, processing, backup and recovery.
Evidence & drift
Configuration evidenced, with drift and exceptions tracked.
Policy, scope, status and evidence in one record
Each residency policy carries its entity and jurisdiction scope, the dimensions it constrains, its current status and its last verification. Synthetic data throughout.
Seven dimensions that must never collapse into one
"Where is our data?" has seven answers, not one. Conflating storage with processing is the most common residency misunderstanding, and this matrix exists to prevent it.
What is achievable depends on how you deploy
Four models. The residency constraints each can satisfy differ materially, and the sovereign option is feasibility-gated rather than simply available at a price.
Multi-tenant SaaS
Storage: region-selectable
Processing: region-aligned
Backup: region target
Replication: platform-managed
Key custody: provider-managed
Support access: per support model
Lowest configurability. Suitable where storage-region constraint is the requirement.
Dedicated environment
Storage: region-selectable
Processing: region-aligned
Backup: configurable target
Replication: configurable
Key custody: provider or customer
Support access: scoped per engagement
Most residency constraints achievable here. Availability by region.
Single-tenant enterprise
Storage: region-selectable
Processing: isolated, region-aligned
Backup: configurable target
Replication: configurable or disabled
Key custody: customer options
Support access: scoped and logged
Highest isolation short of sovereign. Eligibility confirmed per engagement.
Sovereign / customer-controlled
Storage: sovereign region
Processing: sovereign boundary
Backup: within boundary
Replication: within boundary
Key custody: subject to requirements
Support access: subject to requirements
Not currently available. Subject to legal, operational, technical and commercial feasibility.
Five coverage states, applied per workload
Coverage is never published for a jurisdiction as a whole. Different workloads within the same region can carry different states.
Governed records
Policy, decision and evidence records — the objects ZolkoSuite is authoritative for.
Document storage
Uploaded documents attached to governed decisions and obligations.
Search indexing
Derived indexes supporting retrieval across governed records.
Audit & operational telemetry
Security and governance events supporting evidence and detection.
Backup & recovery
Backup copies and restoration paths for resilience.
AI processing paths
Optional governed intelligence features where enabled.
Sovereign-boundary operation
All workloads operating entirely within a sovereign boundary.
Three things people assume are settled by a region setting
None of them is. Each is a separate control with its own availability and its own consequences.
- •Provider-managed: available across deployments
- •Customer-managed: eligibility by deployment and region
- •Key location is a separate question from data location
- •Revocation has operational consequences for service availability
Revocation is not a soft control. Withdrawing key access renders the environment inoperable until restored, and that consequence is discussed during assessment rather than discovered later.
- •Subprocessors with their processing locations
- •Telemetry collection paths
- •Support access origin
- •Optional AI provider paths where enabled
Transfer governance — whether a movement is permitted and on what basis — belongs to Privacy Architecture. This page covers where things physically are.
Deletion is not complete until backups expire
A deletion request against live data does not remove copies already written to backup. The expiry window is stated rather than glossed.
Live data deletion
Executed against the primary store on a governed request, with approval and scope recorded.
Backup expiry
Copies in backup persist until the backup retention window elapses. The window is stated per deployment.
Replica propagation
Deletion propagates to replicas on the configured schedule, not instantaneously.
Archive
Archived records follow their own retention reference and are not covered by a live deletion.
Legal hold interaction
An active hold blocks deletion. Privacy Architecture owns the conflict-resolution workflow.
Deletion evidence
Job result, approval, object scope, timestamp and integrity reference retained.
Configuration is evidenced, and deviations are visible
A residency claim is only as good as the evidence that the configuration is actually in force, and the record of when it was not.
- •Configured policy with scope and effective date
- •Verification result and verification date
- •Change history with actor and approval
- •Open exceptions with owner and expiry
- •Drift events with detection time and resolution
- •Named owner for the whole record
- •That the configuration satisfies applicable law
- •That a transfer has a valid legal basis
- •That a regulator would accept the arrangement
- •That no drift occurred between verification points
Residency configuration does not by itself establish legal compliance.
Answers require your context
A residency answer depends on entity, jurisdiction, workload, data class and deployment. A generic pack cannot produce one, and this page will not pretend otherwise.
- Dimension-by-dimension answer — all seven, for your deployment
- Deployment recommendation — what your constraint actually requires
- Key custody eligibility — for your regions, with revocation consequences
- Backup and recovery position — including the residency-resilience trade
- Cross-border dependency list — subprocessors, telemetry, support
- Explicit gaps — requirements that cannot be met in approved scope
Request a residency assessment
Enough to scope a response, nothing more.
Bring the requirement written as "data must stay in country"
That sentence resolves into seven separate questions, and usually two or three of them turn out to be the hard ones — telemetry, support access, or backup geography rather than storage. We will work through all seven against your deployment and say which cannot be met.
No region availability, deployment option, key custody eligibility, sovereign capability or jurisdiction coverage is committed outside an approved commercial document.
Talk to a solutions architect
Every section of this page was readable without it.
Location, backup, sovereign, keys and transfers
Direct first sentences, then qualified detail. Every answer is present in the page source.
No blanket guarantee is offered, and "all data stays in-region" is not a claim this page makes.
That requirement resolves into seven separate dimensions — storage, processing, backup, replication, recovery, telemetry and support access. Storage is usually the easy one; telemetry, support access and backup geography are usually the hard ones. See the matrix