Security posture
What's built into the product today, what Dohos's security policy commits to as it grows, and where to find the detail on access, infrastructure, encryption, payments, and disclosure.
Dohos carries restaurant phone calls, the orders that come out of them, and — for a caller paying by card — payment intent. A product that touches all three has more to protect than a typical web form, and more ways for something to go quietly wrong: a call that should have stayed inside one restaurant's account, a transcript that should have been redacted before it was stored, a card number that should never have reached a server in the first place.
No system is completely secure, and this page does not claim otherwise. What it does is separate two different kinds of statement, so a reviewer can tell which is which without guessing: what the product is specified to do, and what Dohos's security policy commits to as the company and its customer base grow.
A small number of facts on these pages are stated as settled, because they come from the specification the product is being built against rather than from security policy alone: that a raw card number is not meant to reach Dohos's own systems at any point in a call, that every operational record carries the identifier of the restaurant location it belongs to, and that internal access to a restaurant's data is scoped by role rather than granted by default. Those are design commitments a reviewer can treat as architecture, not as a claimed track record — Dohos has not yet operated at a scale that would support an audited operating history, and none of the pages below imply one.
Everything else — review cadences, access-recertification schedules, the incident playbook, the vulnerability-management program — is drawn from Dohos's internal security policy, which is itself an unapproved draft covering the company's target state. It is written throughout as policy and design intent, not as a report of what has already happened, and each detail page carries the same draft status this page does. This draft must not be read as evidence of a certification, audit, or penetration test, because none has occurred.
These pages cover the platform Dohos operates: the voice system that answers a call, the operator console a restaurant manager signs into, the staff tablet, and the internal tools Dohos support and engineering use to run the service. They do not cover a restaurant's own point-of-sale system, network, or devices — Dohos does not integrate live with restaurant POS hardware, so there is no shared security boundary to describe there.
Access control
Roles, least privilege, audit trails.
OPEN →PLATE Nº 093Encryption
In transit and at rest.
OPEN →PLATE Nº 094Infrastructure
Where it runs and how it's isolated.
OPEN →PLATE Nº 095Logging
What's logged, what's redacted.
OPEN →PLATE Nº 096Payment security
Payment-data handling. DRAFT — pending the payments gate.
OPEN →PLATE Nº 097Practices
SDLC, review, and testing posture.
OPEN →PLATE Nº 098Vulnerability disclosure
How to report, what to expect.
OPEN →PLATE Nº 099Security whitepaper
The whole posture, one document.
OPEN →A vendor-security review usually needs more than eight short web pages. The security whitepaper gathers the same material into one page meant to be read in order. The vendor packet collects the documents a procurement review typically asks for in one place, including what's available today and what is not yet. For anything not answered here — a specific question a review needs pinned down, or a document this page does not yet publish — reports and questions can be sent through /contact/security.