India compliance notes
Last updated 7 November 2026
This is not legal advice
This page explains how AVS Restaurant POS is built with reference to Indian law, so a restaurant operator deploying it can have an informed conversation with their own advisor — it is not a legal opinion, a certification, or a substitute for review by a qualified lawyer or chartered accountant. Laws referenced here (the DPDP Act 2023, IT Rules, CGST Rules, and CCPA guidelines) are current as of this page’s last-updated date and may have changed since.
Who is the “data fiduciary”?
AVS Restaurant POS is offered as a hosted SaaS service as well as self-hosted software. For hosted accounts, Arivahly Ventures Pvt. Ltd. handles account, billing, support and security information for operating the service. The restaurant decides why it collects diners’ and staff members’ personal data and is responsible for its notices, lawful basis, rights requests and retention choices. The service processes that restaurant data to provide the POS, under the account terms. The parties should confirm their roles and instructions in a data-processing agreement before production use.
The DPDP Act and Rules were notified with phased commencement. MeitY’s notifications place the principal duties on an 18-month schedule from 13 November 2025, with that phase scheduled for 13 May 2027. Some provisions started earlier. See the official commencement notification and notified Rules. This page is product guidance, not a compliance certification or legal opinion.
DPDP Act, 2023 — what the software supports
The DPDP Act gives individuals (“Data Principals”) rights to access, correct, and erase their personal data, and requires Data Fiduciaries to collect only what’s needed for a stated purpose, retain it no longer than necessary, and provide a grievance-redressal channel. AVS Restaurant POS’s data model and controls that a deploying restaurant can use to meet these:
- Customer profiles can be corrected or deleted by staff with the customers.manage permission. Deleting a profile does not automatically erase invoices or every transaction snapshot; those records need a documented retention and anonymization policy.
- Only the data fields actually used by POS/CRM/loyalty features are collected — no speculative profile fields.
- Role-based access control restricts who on staff can view customer contact details and order history, supporting a purpose-limitation and least-privilege posture.
- Authenticated requests are scoped to the signed-in restaurant and assigned branches on the server. This is an architectural control and still requires ongoing security testing and review as new features are added.
The signup flow records acceptance of the service Terms and the Privacy Notice, keeps product-update permission separate, and makes marketing opt-in off by default for restaurant customers. The hosted release still needs an automated restaurant retention schedule, customer-facing request/withdrawal workflow, incident response runbook adoption, and completed data-processing terms before it can claim full compliance. Each restaurant should publish its own customer-facing notice and policy details.
IT Act, 2000 & reasonable security practices
The IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 expect a body corporate handling sensitive personal data (which includes financial information and, in a POS context, payment details) to implement documented, reasonable security controls. What’s implemented here, verified in a security audit rather than just claimed:
- Passwords hashed with bcrypt (cost factor 12), never stored or logged in plaintext.
- Session cookies are httpOnly and SameSite-restricted; JWT sessions verified against a live user/active-status check on every request, not just at login.
- Rate limiting on authentication endpoints to resist credential-stuffing/brute-force attempts.
- Strict tenant isolation and role-based authorization enforced server-side on every request — the frontend is never trusted as an authorization boundary.
- All money calculations (prices, tax, discounts, totals) are computed server-side, never trusted from client input, with race-condition-safe checkout and refund handling.
- Uploaded files are validated against their actual file-signature bytes, not just a client-declared filename or MIME type, and stored under randomized, non-executable filenames.
- No hardcoded secrets in source; the backend refuses to start with a placeholder or short JWT signing secret.
Transport encryption (HTTPS/TLS) for any deployment reachable beyond a trusted LAN is the deploying operator’s responsibility — typically via a reverse proxy (Caddy, nginx, or a tunnel provider) in front of the app. A LAN-only deployment behind a restaurant’s own router is not directly exposed to the public internet by default.
GST invoicing (CGST Rules, Rule 46)
Receipts generated by AVS Restaurant POS display the branch’s GSTIN (when configured in Settings), an itemized CGST/SGST breakup, and a per-order invoice/order number. Whether your specific invoice numbering and layout fully satisfies Rule 46 of the CGST Rules, 2017 for your registration and turnover bracket (e.g. sequential numbering per financial year, HSN/SAC code requirements at your turnover level) is something to confirm with your chartered accountant before relying on AVS Restaurant POS receipts as your sole tax-invoice record — this software generates a receipt in the right shape, it does not itself certify GST compliance for your specific registration.
Honest UI, on purpose (CCPA dark-patterns guidelines, 2023)
The Central Consumer Protection Authority’s 2023 guidelines on misleading advertisements and dark patterns explicitly name fabricated urgency, fake activity counters, and false social proof as prohibited practices. This site’s download counter is a real, server-side count of actual link click-throughs, starting from zero — never pre-seeded with an invented number. If you build on this codebase, we’d ask you to keep that practice rather than quietly seed it later.
Questions
For questions about this software’s architecture or security posture, reach out to help@arivahly.in. For questions about your own restaurant’s legal obligations as a Data Fiduciary or GST-registered business, please consult a qualified lawyer or chartered accountant — this page cannot answer those for your specific situation.