01Scope
This document covers the voice platform that answers a restaurant's calls, the operator console a restaurant manager or owner signs into, the staff tablet, and the internal tools Dohos uses to support and operate the service.
It does not cover:
- a restaurant's own point-of-sale system, network, or devices — Dohos does not integrate live with restaurant POS hardware
- a disabled, internal-only, demonstration, or future capability
- a third-party provider's own independent security program, beyond what Dohos does to evaluate and configure it
02Governance
Dohos's security policy calls for a named security owner with the authority to govern the areas below, escalate material risk, and stop a release that isn't ready. That role, and the risk-review process behind it, is a policy commitment rather than a completed, tested program — Dohos is a build-first pilot, not an enterprise security organization with a standing audit committee, and this document does not claim to be one.
What that means in practice: material changes to how the product handles restaurant data, payment flow, or access are meant to go through a review step before release, proportionate to what the change actually touches. A small copy change on a public page and a change to how card-payment status is recorded are not held to the same bar.
03Identity, access, and tenant separation
Dohos's data model scopes every operational record — a call, an order, a menu item, a configuration change — to the restaurant location it belongs to, and that scope is enforced at the database layer through row-level security policies, not only by what the interface chooses to display. This is a design commitment stated in the product's own build specification, not a policy aspiration: the frontend that renders a restaurant's dashboard never receives a broad service credential capable of reading across locations: it talks to authenticated backend endpoints that already know which location the request is allowed to touch.
Internal access follows the same idea. Dohos's access policy calls for least privilege by default — a role gets what its job actually requires, not standing access to everything — multifactor authentication for anyone with elevated access, and access that is removed the day it's no longer needed rather than left to expire on its own. The product's own access model names four distinct roles with different scopes: a restaurant owner, a restaurant manager, restaurant staff on the operational floor, and a Dohos internal administrator whose access is deliberately narrower than "admin" implies — Dohos's own build requirements state that internal access "must be explicit and scoped" and that an invisible, unrestricted path into a restaurant's account is not something the product is built to allow. Full detail at access control.
04Encryption
Traffic between a caller's phone network, the Dohos platform, the operator console, and the staff tablet is intended to run over encrypted connections, and stored data — orders, configuration, and a completed call's transcript — is intended to be encrypted at the storage layer. Dohos's own security policy is explicit that a bare claim of "encrypted" is not acceptable without stating its scope and exceptions, and this page follows that instruction rather than making the broader claim the phrase invites. Full detail, including where that boundary actually sits, is at encryption.
05Payments
A caller can place a card-paid order by phone without a raw card number ever reaching a Dohos system. This is one of the product's non-negotiable build requirements, not only a policy preference: card and payment digits are not meant to enter the AI, the speech-to-text pipeline, a recording, a transcript, a log, or Dohos's own database at any point. Full detail, including what Dohos stores instead of a card number, is at payments and card data.
06Detection and response
Dohos's logging policy calls for recording security-relevant events — sign-ins, permission changes, exports, configuration changes — in a way that's minimized and protected, while specifically excluding payment credentials, full call audio by default, and other sensitive content from ever reaching a log in the first place. Detail on what's captured and what's deliberately not is at logging.
A vulnerability found by an outside researcher has a real, working route to reach Dohos — see vulnerability disclosure — though there is no staffed response-time commitment or bounty program to describe yet, and this document does not pretend otherwise.
07Independent assurance
This document makes no SOC 2, ISO, PCI, HIPAA, or other certification or compliance claim, and no independent audit or penetration test has been performed. Dohos's own security policy is explicit on this point — it instructs against describing a "pen test," an "audit," or a "SOC 2" claim without the exact report, scope, period, and authorization behind it — and this whitepaper follows that instruction rather than working around it. There is accordingly no testing cadence to state and no findings summary to share; that remains the direct, current answer.
08What's available beyond this page
A vendor-security review sometimes needs more than a public web page can responsibly carry — architecture detail, specific configuration, or evidence that would itself be a map for an attacker if published broadly. Where Dohos has that detail, an authorized reviewer can request it directly rather than finding it withheld with no path forward. A request like that would reasonably expect, once Dohos has it to give: a control summary, an access and tenant-isolation evidence summary, a backup and recovery summary, and — once one exists — an independent testing summary.
Send that request through /contact/security. What's actually returned depends on what exists at the time of the request — this document does not promise a specific evidence package ahead of that conversation.