01What the agreement actually does
A data processing agreement, once signed, is the contract that says Dohos may only handle a restaurant's caller and order data for the specific purposes the restaurant has actually asked for — receiving and structuring an order, routing it, confirming it, supporting it, evidencing it if something goes wrong — and for nothing else. It's the document a security or procurement reviewer asks for before data starts flowing, and it's meant to sit alongside, not replace, the plain-English Privacy Notice.
It exists because a services agreement alone doesn't say enough about data specifically — what categories are touched, who else might see them, how long they're kept, and what happens to them if the relationship ends. This document is where those questions get concrete answers, in contract language a legal team can actually rely on.
02The roles it assigns
The agreement is built around a specific division of authority: for the data it covers, the restaurant is the one who decides why that data is processed at all, and Dohos processes it only on the restaurant's documented instructions — never on a purpose Dohos comes up with independently. If Dohos ever needed to use that data for a reason the restaurant hadn't authorized, the agreement requires stopping and getting a new instruction first, not proceeding and asking forgiveness.
That role assignment isn't just a label — it's checked against what a restaurant's instructions actually say, and against what the agreement's own annex lists as the specific things Dohos may do with the data. A restaurant asking for something the annex doesn't cover means the agreement needs updating before that request can be honored, not a quiet exception.
03What it covers, at a glance
The agreement's core content lives in four annexes, each answering a different question:
- What's being processed. the exact categories of data in scope — order details, contact information for fulfillment, transaction records — described specifically enough that "all customer data" wouldn't qualify.
- Who else touches it. the authorized vendors — see subprocessors below — each with its own row identifying purpose, location, and role.
- Which jurisdictions apply. a schedule identifying which state or federal privacy laws the agreement's terms are built to satisfy, and how.
- What happens at the end. how data gets exported, returned, or deleted if the relationship with a restaurant ends, and how that gets verified rather than just promised.
The body of the agreement outside those annexes covers the more general commitments: confidentiality, security obligations, how a security incident gets reported, and what happens if Dohos can no longer meet an obligation it agreed to.
04The transcript question, inside the contract
One specific point is worth being exact about here, because an earlier draft of the underlying contract language got it backwards. A restaurant's instructions to Dohos don't, by themselves, authorize a raw audio recording capability — that stays off unless the restaurant separately activates and discloses it. But a role-gated, retention-bound text transcript of each completed call is standard processing under the agreement once a voice-ordering capability is active at all — it isn't something that needs its own separate authorization the way audio recording does. See retention for exactly how long that transcript is kept and who can see it.
That distinction — audio needs a separate switch, the transcript doesn't — is the same one that applies everywhere else this library discusses call data, not something unique to the contract.
05What isn't finished yet
Being direct about the current state: the vendor annex has no approved rows yet — see subprocessors for why that's an honest zero, not an oversight. The jurisdiction schedule has no state activated yet, including the two states with drafted-but-unapproved schedules. And the agreement's security-incident notification clock — how many hours a restaurant would be notified within after an incident — doesn't have an approved number in it yet.
06Getting a copy signed
There's no self-serve way to execute this agreement today, and that's a deliberate scope decision, not a missing feature — the agreement isn't ready to be signed until the gaps in the previous section close. What does work: reaching /contact/legal directly, which is where a request to review or discuss the current draft actually goes, and where you'd be told the real state of any specific term you're asking about rather than getting a generic answer.
There's no downloadable file linked from this page yet either. When one exists, it will be the same draft text as the canonical link below, carrying the same draft status — not a cleaner, execution-ready version circulating separately from what's publicly documented.
07Where the full contract text lives
Every clause and every annex, in full contract language, is at /legal/dpa. This page is the plain explanation of what's there; that page is the actual text a lawyer would read.