01Tenant isolation
Every operational record Dohos stores — a call, an order, a menu item, a configuration change, a transcript — carries the identifier of the restaurant location it belongs to. That scope is meant to be enforced at the database layer itself, through row-level security policies, not only by what the console or staff tablet chooses to show on screen. The frontend a restaurant signs into never receives a broad service credential capable of reading across locations; it talks to authenticated backend endpoints that already know which location a given request is allowed to touch.
This is stated as the system's design, not as a completed isolation audit. Dohos's security policy calls for testing both ordinary and adversarial cross-tenant access — identifier substitution, a missing filter, an indirect reference, a bulk export path — before a capability goes live and again after a material change to schema or authorization. A suspected failure of this boundary is treated as the most serious category of security incident Dohos has, ahead of most other categories, because it is the one failure mode that would let one restaurant see another's calls, orders, or customers.
The same separation is meant to hold beyond the primary database — in caches, background job queues, search or menu-lookup indexes, and exports — not only in the tables a dashboard query touches directly. A tenant boundary that holds in the main database but leaks through a shared cache or a bulk export path is still a failure of this control, not a partial success.
02Hosting
Dohos's database and authentication run on Supabase's managed Postgres platform, and the backend services run on Railway. Naming the actual platforms, rather than describing "established cloud infrastructure" in the abstract, is a deliberate choice: a reviewer evaluating Dohos inherits an informed opinion about those providers' own security posture, and a vague description would only make that harder to check.
Running on managed infrastructure means the underlying physical security, network hardware, and platform-level protections are the hosting provider's responsibility, evaluated as part of Dohos's own provider-diligence process rather than built from scratch. That diligence — reviewing a provider's access controls, encryption, subprocessors, and incident duties before relying on it — is a policy commitment; it does not by itself certify Dohos's own configuration on top of that platform.
03Network boundaries
Dohos's policy calls for a default-deny approach to network access: administrative interfaces and internal services aren't meant to be reachable from the open internet just because nobody got around to closing the door, and what is public-facing is meant to be limited to what actually needs to be. Cloud configuration — storage buckets, service permissions, access keys — is meant to be reviewed against common misconfiguration patterns like a storage bucket left open to the public or a default credential nobody rotated, rather than assumed correct because a provider's default settings are usually reasonable.
None of this is described as independently verified yet — it's the standard the design is held to, consistent with how policy-sourced content is treated throughout this library.
04Environment separation
Dohos's design keeps the live production environment that serves real restaurant calls and orders logically separate from development, test, and preview environments — separate credentials, separate data, separate deployments. Production restaurant data is not meant to be copied into a test or development tool without a specific, approved reason and its own minimization and retention rules.
05Backup and recovery
Dohos's policy calls for regular backups of operational data — a restaurant's menu, configuration, order history — with periodic restoration tests, so a backup is treated as a proven recovery capability rather than a checkbox a hosting dashboard happens to show as enabled.
06Region
Where a specific restaurant's data is stored and processed — which region, and what that means for cross-border processing — is answered directly, not summarized here, at data residency.