01What counts as an incident
The plan's definition is deliberately broad — an incident is any suspected or actual event that could trigger a legal, contractual, insurance, regulatory, customer, or safety duty, not only an obvious break-in. That includes unauthorized access or disclosure, one restaurant's data becoming visible to another, account takeover, payment-credential exposure, harmful or unsafe behavior from the AI system, a communications opt-out that wasn't honored, a critical provider's own incident, a failed backup restore, and physical loss of a device carrying Dohos data.
02How severity is set
Every reported issue gets a severity based on how actively it's being exploited, how sensitive and how much data is involved, whether people's safety or payment credentials are at risk, and how hard it is to contain — not based on how alarming it sounds on first read or which channel it came in on.
| SEVERITY | WHAT LANDS HERE |
|---|---|
| Critical | Active or likely cross-tenant compromise, loss of privileged access, exposed payment credentials, a destructive event, or an imminent legal deadline. |
| High | Confirmed unauthorized access or a material control failure, with a scope that's contained or boundable. |
| Moderate | A limited suspected event or control failure that needs formal investigation and tracked remediation. |
| Low | A policy deviation or benign event with no supported adverse impact, kept for trend analysis. |
03The first hour
The plan's first-hour sequence is ordered the same way every time: protect anyone's physical safety first, then open a formal incident record and assign an owner, preserve evidence before it can degrade or be lost, contain further harm using action that can be reversed if it turns out to be wrong, keep discussion limited to people who need to know, identify exactly which services and data are affected, revoke or rotate any exposed access, bring in affected providers through verified channels, and set a time for the next update.
- Protect life and safety first
- Open the incident record and assign an owner
- Preserve evidence before it degrades
- Contain using reversible, scoped action where possible
- Restrict discussion to people who need to know, and involve counsel for legal calls
- Identify affected services, data, and identities
- Revoke or rotate exposed access
- Contact affected providers through verified channels
- Set the next update time
04Recovery without overstating it
Restoring service after containment follows staged steps rather than a single flip back to normal — a clean rebuild, verified access controls, checked data integrity, and a period of closer-than-usual monitoring before things are called settled. The plan is specific that Dohos shouldn't describe something as "fully restored" while a material function or a piece of data is still uncertain — an update that oversells recovery is treated as its own kind of failure, not a harmless simplification.
05How it gets communicated
Every message during an active incident is required to separate what's confirmed, what's a reasonable estimate of scope, what's still unknown, what's being done, and when the next update is coming — and to avoid guessing at a cause, assigning blame, or promising a fix time nobody can actually back. Current status is the live surface this gets published to; a closed incident's account belongs at incident history.
A significant incident is also meant to get a real after-the-fact account — what happened, what the actual cause was, and what's changing as a result — not just a one-line "resolved" notice.
06Reporting something
A security researcher, or anyone else who finds a vulnerability from outside Dohos's own monitoring, has a dedicated route for it: vulnerability disclosure covers scope and safe harbor. A restaurant that's simply experiencing a problem — a call not going through, the console behaving strangely — reports it through ordinary support; it gets escalated internally as a possible incident if the facts warrant it, rather than requiring the restaurant to make that judgment call itself.
07After it's over
A material incident gets a documented review afterward — timeline, root and contributing cause, what worked and what didn't in the response itself, and a list of corrective actions with named owners and deadlines, not just a verbal debrief. Lessons from that review are meant to feed back into more than just this plan: product design, provider selection, training, contract terms, and — where a policy actually exists to notify one — an insurer, without overstating what that policy covers.