Choose a deployment pattern with verified controls and responsibilities
Evaluate tenancy, data residency, key control, network connectivity, administrative access, recovery, updates, support, migration, and evidence against your organization's approved requirements.
Deployment patterns, regions, controls, integrations, recovery targets, support models, and key options vary by market, subscription, configuration, and implementation status.
Five canonical patterns, presented neutrally
Selecting a pattern filters the comparison below — it does not recommend. There is no winner badge, no default selection, and no checkmark implying legal or compliance suitability.
Regional hosting
Provider-operated service in an approved region. Exact services, data classes, support paths, backup, and recovery must be verified.
Enterprise single-tenant
A customer-specific tenancy pattern. Account, network, compute, database, storage, key, operations, and support isolation must be defined.
Dedicated private cloud
A dedicated environment with approved infrastructure and operating responsibilities. Provider and customer boundaries vary by implementation.
Sovereign deployment
A requirement-led pattern addressing approved sovereignty dimensions across data, access, operations, keys, network, support, supply chain, and legal control.
On-premise deployment
A customer-controlled environment with explicit platform, capacity, security, update, observability, backup, recovery, and support responsibilities.
Evaluate regional service boundaries — not only a map pin
No region is named on this page until it is verified and approved for publication. What matters more than the pin is what crosses the boundary.
Define what is isolated, who operates it, and how it changes
“Single-tenant” is a tenancy relationship, not a complete architecture. Fifteen dimensions need an explicit answer.
Use a dedicated environment with an explicit operating boundary
The phrase carries almost no information on its own. What makes it evaluable is naming the operator for every layer and every action.
Define sovereignty requirement by requirement
“Sovereign” is not a product tier and not a legal conclusion. It is fifteen separable requirements, each needing an interpretation owner and evidence.
Where the boundary sits when systems span environments
Most real deployments are hybrid. What matters is that each crossing is named, directional, authenticated, and monitored.
Residency is a per-class, per-stage question
Fourteen data classes across thirteen lifecycle stages. A single “data residency” label cannot answer all of them, so this page does not offer one.
Eighteen dimensions across the
five patterns
This matrix is descriptive. It does not rank patterns and it does not declare a best security or compliance option.
| Dimension | Regional | Single-Tenant | Private Cloud | Sovereign | On-Premise |
|---|---|---|---|---|---|
| Commercial | Shared controlled service | Dedicated | Dedicated | Requires verification | Dedicated |
| Account / project | Shared controlled service | Dedicated | Dedicated | Requires verification | Customer-operated |
| Network | Logically isolated | Dedicated | Dedicated | Requires verification | Customer-operated |
| Compute | Logically isolated | Dedicated | Dedicated | Requires verification | Customer-operated |
| Orchestration | Shared controlled service | Requires verification | Dedicated | Requires verification | Customer-operated |
| Database | Logically isolated | Dedicated | Dedicated | Requires verification | Customer-operated |
| Storage | Logically isolated | Dedicated | Dedicated | Requires verification | Customer-operated |
| Cache / queue | Shared controlled service | Requires verification | Dedicated | Requires verification | Customer-operated |
| Backup | Logically isolated | Dedicated | Dedicated | Requires verification | Customer-operated |
| Logs | Logically isolated | Logically isolated | Dedicated | Requires verification | Customer-operated |
| Keys | Shared controlled service | Requires verification | Requires verification | Requires verification | Customer-operated |
| Identity | Federated | Federated | Federated | Requires verification | Customer-operated |
| Management plane | Shared controlled service | Shared controlled service | Jointly operated | Requires verification | Customer-operated |
| Observability | Logically isolated | Logically isolated | Jointly operated | Requires verification | Customer-operated |
| Support tooling | Shared controlled service | Shared controlled service | Shared controlled service | Requires verification | Customer-approved access |
| Release channel | Shared controlled service | Requires verification | Jointly operated | Requires verification | Customer-executed |
| Data plane | Logically isolated | Dedicated | Dedicated | Requires verification | Customer-operated |
| Control plane | Shared controlled service | Shared controlled service | Jointly operated | Requires verification | Customer-operated |
Key ownership is not the same as key authority
Four models, twelve lifecycle stages. What matters operationally is what happens when a key is revoked or the key service is unreachable.
Platform-managed keys
ZokoSuite generates, stores, rotates, and uses keys within the approved region.
Simplest operations; customer holds no revocation authority.
Customer-managed / BYOK
The customer supplies key material into an approved key service; ZokoSuite uses it under policy.
Customer can rotate and revoke; service dependency remains.
External key authority / HYOK-type
Keys remain under an external authority the customer controls, with ZokoSuite calling out for operations.
Strongest customer authority; availability and search behavior change.
Customer-managed local keys
For approved on-premise scenarios, keys are generated and held entirely in the customer environment.
Full customer authority and full customer recovery responsibility.
Seven identity types across nine access planes
The question that decides most security reviews is not whether access is encrypted — it is whether standing access exists, and who authorized it.
Name every path, its direction, and what happens when it fails
Connectivity patterns are listed in the hybrid section's flow register. What belongs here is the dependency question: which outbound paths must remain reachable for the deployment to function at all.
Structure without invented numbers
This page publishes the fields a recovery model must contain. It does not publish targets, because a target only means something against a contractually approved scope.
Who authorizes a change, and what you are told
Change control differs sharply between provider-operated and customer-operated patterns. Eleven change types, each with an approval path.
Nineteen control domains, named owners
This describes operating responsibility. Contractual allocation remains governed by your executed agreement, and the two are not the same thing.
What the evaluation returns
A neutral artifact organized into requirements, observations, conflicts, unknowns, and evidence requests. Deliberately not a recommendation.
Ten stages from qualification to operational handover
Select a stage to see its artifacts, decision owner, and exit criteria. Acceptance is evidence-based, not date-based.
Qualify
Scope, decision team, requirements, assumptions, unavailable claims, information needed.
Discover
Systems, data, entities, jurisdictions, policies, integrations, security, operations, support, constraints.
Architecture
Pattern, boundaries, data flow, identity, network, keys, responsibility, dependencies, exceptions.
Contract and control review
Availability, commitments, DPA and subprocessors, support, change, exit, evidence, professional review.
Build nonproduction
Provision and configure the approved environment and integrations; create a baseline and evidence.
Validate
Functional, security, privacy, accessibility, performance, backup and restore, recovery, monitoring, support.
Shadow Mode
Compare workflows and policy outcomes against current operation without authorizing production actions.
Acceptance
Evidence review, gate approval, exceptions, rollback plan, and named sign-off per domain.
Cutover
Freeze rules, migration, reconciliation, communication, support cover, rollback authority.
Operate and hand over
Monitoring, exception resolution, evidence confirmation, ownership transition, change enrolment.
Bring your requirements, not a shortlist
The most productive first conversation starts from your residency, isolation, key, access, recovery, and change requirements — including the ones that conflict with each other. We will tell you plainly which are verified, which need configuration, and which are not available.
No pricing, lead time, or availability commitment is made outside an approved commercial document.
Architecture, privacy, security, and availability
Direct first sentences, then qualified detail. Every answer is present in the page source.
The canonical architecture includes regional hosting, enterprise single-tenant, dedicated private cloud, sovereign, and on-premise patterns, with customer-controlled key options where approved. Exact availability and controls require verification for your market, subscription, configuration, and implementation scope. A named option is a taxonomy item, not proof of availability.
Govern your global operations with confidence
Unify finance, workforce, legal, tax, compliance, and commercial operations under one governed platform.