dohosGet started
PLATE Nº 093 · DOCUMENT

Encryption

TARGET-STATE DRAFT — NOT APPROVED OR EFFECTIVE
STATUSTarget-state draft
LAST REVIEWEDNone yet — no review has run
CONTACTvia /contact/security
DRAFT NOTICEThis page describes Dohos's target approach to encryption — in transit, at rest, and for the keys that protect both. It draws on an internal security policy that is itself unapproved. The one instruction from that policy this page follows most carefully is its own: a bare claim of "encrypted" is not acceptable without stating where the protection actually applies and where it doesn't, so this page states both.

01In transit

Traffic between a caller's phone network and the Dohos voice platform, and between the operator console or staff tablet and Dohos's servers, is designed to run over encrypted connections throughout — not just at the outermost edge. Certificate validation is not meant to be disabled in production, and certificate issuance, renewal, and expiry are meant to be monitored rather than left to fail silently.

The call itself has a leg that's outside Dohos's own control: how a phone carrier routes a call between the caller's handset and the telephony provider that hands it to Dohos follows that carrier's own network practices, not Dohos's. What Dohos controls, and designs to be encrypted, is the connection from that point forward — into the voice platform and everything downstream of it.

02Session and browser protection

The operator console a restaurant manager signs into is designed to protect the session itself, not only the data it carries: session cookies and tokens are meant to be scoped and flagged so a browser won't send them somewhere they shouldn't go, sessions are meant to expire and be invalidated on sign-out rather than staying valid indefinitely, and a state-changing action — like publishing a menu change — is meant to be protected against being triggered from outside the actual console a manager is looking at.

03At rest

Stored data — orders, restaurant configuration, and a completed call's transcript — is designed to be encrypted at the storage layer, building on the protections Dohos's hosting platform provides for its managed database.

ATTENTION"Encrypted at rest" is not used here as a blanket, unconditional claim, on purpose. Dohos's own security policy is explicit that the phrase is prohibited without stating its scope and exceptions — because a database can be encrypted on disk and still be readable in plain form by the application that queries it, by a support tool, in a log line, or in an export. The specific boundary — exactly what is protected at the storage layer versus what becomes plaintext the moment an authorized process reads it — is not yet published in a form precise enough to state here without overreaching, and this page would rather say that plainly than round up to a claim it can't fully stand behind.

04What "encrypted" doesn't mean while something is being used

Encryption protects data while it's moving and while it's sitting still. It doesn't, and can't, protect data at the moment something is actually working with it — the speech-recognition step has to work with a caller's actual words to understand an order, and the AI model has to read a menu item's actual name to talk about it. That's not a gap in this page's claims; it's what "processing" means for any system, and any vendor who implies otherwise is describing something that isn't how computers work.

What matters is what happens around that moment: how briefly the data stays in a readable form, what's allowed to read it, and whether it's redacted — a spoken card number stripped, a payment digit interrupted — before it's ever written down anywhere permanent. That redaction discipline is described at logging and payments and card data.

05Keys and secrets

Cryptographic keys are meant to have a defined owner, an approved method of generation, controlled access, and a rotation and revocation path — not created once and forgotten. Application secrets — database credentials, API keys, provider tokens — belong in a dedicated secrets-management system under this policy, never hard-coded into source, committed to a repository, or exposed in a log line, a ticket, or an ordinary document.

Where Dohos relies on its hosting platform's own key-management service rather than operating one independently, that dependency is itself part of the provider diligence described at infrastructure — a platform's key-management feature existing is not the same as Dohos having verified and configured it correctly for this specific use.

06What this page doesn't claim

  • a specific encryption algorithm, cipher suite, or key length as a public commitment
  • that every field in every system is encrypted with no exception
  • any third-party certification of Dohos's encryption implementation — none has been sought or granted

Where a reviewer's process needs one of those specifics confirmed, the direct route is /contact/security, not an inference from this page's general language.