The boundary is architectural. Not a policy promise.
Where your data lives isn’t a setting applied after the fact. It’s determined by the deployment environment you choose — before ZHC produces anything.
Location follows the environment
You select the environment. ZHC operates inside it.
Your policies control what crosses the boundary. None of these are separately negotiated after deployment — they’re set by which environment you chose in the first place. The architecture is the boundary, not a document describing one.
Same boundary structure as the rest of Trust & Control: your governance boundaries → the ZHC-produced system → data and integrations → your infrastructure. Data doesn’t sit outside that chain at a separate layer — it moves inside it.
Deployment models
How the deployment model sets the boundary.
Essert CloudData stays inside Essert-managed infrastructure.
Dedicated Managed EnvironmentData stays inside infrastructure dedicated to your enterprise, operated by Essert.
Customer CloudData stays inside your own cloud account or VPC.
Sovereign DeploymentData stays inside infrastructure your enterprise controls, including supported on-premises configurations.
Sovereign Deployment’s guarantees here describe a control posture, not automatically the strongest option for every requirement — some sovereign capabilities are available today, others are platform direction. Confirm which applies to your specific requirement directly, before it’s assumed.
Access
Access is governed the same way it’s governed everywhere else in ZHC.
Data access isn’t a separate control model from model, tool, and agent access — it’s the same policy enforcement, applied to data specifically. What an agent can reach is explicitly controlled, not inferred from what it’s doing.
How data is held and handled is one of the specific items covered in the gated Security Overview, alongside architecture, deployment considerations, and applicable deployment options — reviewed before any commercial conversation starts.
