Retail fraud is rarely sophisticated. It is a void raised after hours, a discount nobody approved, a return processed against no invoice, cash that never reached the bank. ambar 27’s security model is built around making those things visible - and hard to do without leaving a name attached.
Hiding a menu item is not security. Every screen in ambar 27 checks the current user’s role against the specific action being attempted - so a user who guesses a URL gets refused, not served.
The person who raises a payment should not be the person who approves it, and neither should be the person who releases the cheque. Planners make that separation structural rather than a policy people are trusted to remember.
Counter terminals are shared, staff turnover is real, and a password written on a sticky note is normal. Two-factor on the accounts that matter, and controlled user provisioning, are the minimum.
When something is wrong at month end, the question is always the same: who did this, and when. Activity logging across the application means that question has an answer, and everyone on the floor knows it does.
| Question | Answer |
|---|---|
| Where is the data stored? | In a MySQL database dedicated to your business, on a server we provision and manage in India. It is never a shared multi-tenant database, and nothing you record is visible to another customer of ours. |
| Who can reach it? | The AWP team that runs and supports your deployment, for operating it and for support you request. Your data is never pooled with another client’s and is not shared with anyone else. |
| Is data sent to third parties? | Only where you configure an integration, and only the fields that integration needs - invoice data to your GSP for IRN, message content to WhatsApp, payment data to Razorpay. Each uses your own account. |
| What about biometric data? | Face recognition stores numeric descriptors in your own database and matches inside your own deployment. No images or biometric data are sent to any external service. |
| Transport security | HTTPS throughout, with certificates issued and renewed automatically - there is no expiry for anyone to forget. Calls out to the GST portal and payment providers are encrypted in transit. |
| Backups | Scheduled database and file backups on a retention policy agreed at implementation, with a restore tested before go-live. |
| Backups | Taken daily and retained for seven days. They are held by us for recovery and are not distributed - a backup copy is not something we hand out, to you or to anyone else. |
Deletion is a permissioned action, and in practice most deployments do not grant it at all - sales are voided instead, which leaves the original record, the void, the reason and the user who did it in the voided-sales register. Close-day history makes an after-the-fact change visible even if someone has the rights.
Discount groups and the discount planner define the ceiling by category, customer group or code before the negotiation happens. Exceeding it requires a user holding the override permission, and the override is recorded against the invoice with the approving user’s name.
Authentication is handled in-application with optional TOTP two-factor. If SSO against an identity provider is a requirement for your deployment, raise it during scoping - it is an integration discussion rather than a product limitation.
Their account is deactivated, which revokes access immediately while preserving every transaction, approval and activity record they created. History is never removed with the user, because the audit trail is the reason it exists.
Yes - void registers, close-day history, approval trails on planners, the inventory log and the report-access register are all available as reports, permissioned separately so an auditor can be given read access to exactly those.
We would rather answer the hard control questions before you buy than after. Book a session and bring the person who signs off your books.