01Why "where does data live" isn't one answer
A security reviewer asking where data lives is usually really asking several different questions at once, and answering with a single country name tends to hide which of them actually got answered. A vendor's primary storage region, its backup region, where its support staff can access data from, and where its own downstream subprocessors sit are frequently different places — sometimes by design, sometimes because a vendor's disaster-recovery posture genuinely requires a second region.
Treating all of those as one answer is exactly the kind of unsupported claim — "U.S. hosted," "data stays in region" — that isn't safe to make unless every one of those categories, not just the convenient one, actually supports it. This page breaks the question apart instead of collapsing it.
02Not one location — several
The categories that have to be checked separately, because a true statement about one doesn't make the same statement true about another:
- Account or project region. the region a vendor's own dashboard or billing is registered to — not necessarily where data actually sits.
- Primary storage location. where the live data is actually written and read during normal operation.
- Backup or disaster-recovery location. where a protected copy is kept for recovery — sometimes the same region as primary storage, sometimes deliberately a different one.
- Transient processing location. where data passes through briefly during live processing — a speech or language model call, for instance — without being stored there afterward.
- Support or administrative access location. where a vendor's own personnel are physically located when they have access to data for support purposes.
- Telemetry and logging location. where operational logs and diagnostic data are kept, which is not always the same system as the data those logs describe.
- Subprocessor location. where a vendor's own downstream vendor processes data, one layer removed from Dohos's direct relationship.
- Legal entity or billing location. where a vendor is legally incorporated, which answers a contracting question, not a data-location question.
03Production isn't the only environment
The same location questions apply to more than the live production system. Test, staging, and demonstration environments are meant to run on synthetic or approved aggregate data specifically so a location or access question about them doesn't turn into a real caller's data sitting in an extra, less-scrutinized environment. A vendor's test-account region is still a real location decision, even on the assumption that nothing a caller actually said is sitting there.
That separation cuts the other way too: a review of "where does data live" that only checks production and skips staging, a support tool, or an analytics export has checked less than it thinks it has. Every category in the previous section applies within each of those environments independently, not only within the primary production system.
04What's committed today
The service is scoped to the United States. No international region is targeted, no cross-border transfer mechanism is in use, and no claim of GDPR, UK, or Canadian compliance is made — those would require a review this design hasn't gone through, and claiming them without it would be exactly the kind of unsupported statement this page is built to avoid.
That's a scope statement about the product's design, not a report on where a specific restaurant's data sits today — the specific facility and region facts for any individual category above are the ones still pending, described next.
05What isn't committed yet
Once a vendor is approved, its row at subprocessors states its processing location specifically — not a blanket "United States" the way an earlier version of this page mistakenly stated it, attributed to a named provider that isn't actually listed anywhere.
06Crossing a border
If personal data is ever transferred out of a jurisdiction that requires a specific legal transfer mechanism to allow that, the applicable mechanism and a completed assessment of it are required before that transfer happens — not applied retroactively after the fact. Given the current United States-only scope, this isn't an active question today, but it's a real constraint the design accounts for rather than one that gets discovered later if the service's footprint changes.
That assessment isn't a formality if it's ever triggered — it has to weigh the actual risk of the destination jurisdiction, confirm the receiving party's safeguards are real rather than just contractually promised on paper, and add whatever supplementary protection the assessment finds missing before data actually moves, not after.
07How specificity actually gets added here
A region only appears on this page, or at subprocessors, once a specific vendor account clears the same verification process described there — that's a standing rule this page follows, not a delay waiting on a date. There's no interim, less-verified tier of disclosure in between "unverified" and "published"; a location claim either has account and contract evidence behind it or it isn't made.