Built like it holds your money — because it does
A POS holds a restaurant’s cash flow, customers and compliance. Here is exactly how CountStand protects them — the real mechanisms, stated plainly, with the roadmap labelled as roadmap.
Six protections, all shipping
Every claim on this page maps to a mechanism that exists in the product today.
Tenant isolation at the database
Row-level security means one restaurant’s sales, stock and customers are physically unreadable by another tenant — enforced by the database, not by application code remembering to filter.
Personal data encrypted
Guest personal data (phone numbers and the like) is AES-256 encrypted at rest and handled in line with India’s DPDP Act, including the right to erasure.
A YES-code on anything that moves money
No spend, payment or transfer happens without an explicit human confirmation code — including anything the AI proposes. Approval is the default; autonomy is opt-in and bounded.
Every consequential action audited
Actions — human and AI — run through permissioned, idempotent commands and land in an audit log with actor, action and time. Traceable, attributable, reversible.
Roles and permissions
Staff see what their role needs: a cashier bills, a manager approves voids, an owner sees everything. Sensitive actions are permission-gated and logged.
Offline-first, not offline-fragile
Billing, KOTs and the KDS run without internet and sync when the connection returns — an availability property as much as a resilience one: your data survives bad networks.
What data does CountStand hold, and where?
CountStand holds the operational data a restaurant produces: bills, orders, menu and recipes, stock movements, staff roles, settlement records, and — where a guest shares it — contact details for loyalty and receipts. Operational data is stored per tenant with database-enforced row-level security; personal data fields are AES-256 encrypted at rest.
Data is processed to run your restaurant: billing, inventory, compliance, briefings. Your operational data is not sold, and it is not used to train a public AI model. The AI manager reads your data to work for you, within the same tenant boundary a trusted manager would have.
How is the AI kept safe around money and data?
The AI operates through governed tools only — the same permissioned, audited commands the product itself uses. It cannot reach around them, and it cannot cross tenant boundaries: another restaurant’s data is invisible to it by construction.
Anything that touches money waits for a human YES-code, every time. Every AI action is written to the audit log alongside human actions, so what the agent did is always inspectable — and reversible. The full model is on the AI trust page.
What about compliance and certifications?
CountStand is built in line with India’s DPDP Act: itemized consent, a named grievance channel, the right to erasure, and breach-notification readiness. GST computation is deterministic and paise-exact, with one-click GSTR-1 export.
Formal certifications (SOC 2, ISO 27001) are on our roadmap as the company grows — we state that plainly rather than borrowing badges. Enterprise buyers who need a security questionnaire answered can write to us; we answer honestly, including about what is not yet in place.
How do I report a security issue?
We welcome responsible disclosure. Write to security@countstand.com with steps to reproduce, and give us a reasonable window to fix before public disclosure. Our machine-readable security contact lives at /.well-known/security.txt (RFC 9116). We acknowledge reports, keep you informed, and credit researchers who ask to be credited.