CAs are accountable to their clients for the books on this platform. This page exists so you can answer their security questions in one place — without a vendor demo. Every claim here is something we can demonstrate; if a control isn't in place yet, we say so.
Your client books, vouchers, and supporting documents stay inside India.
Postgres on Supabase, region ap-south-1 (Mumbai). No client data leaves Indian soil for normal request handling.
Attachments and generated PDFs stored in Supabase Storage, also pinned to ap-south-1.
Transactional email via Resend. Email content (invoice PDFs, OTPs) traverses Resend infra; we send the minimum required.
Anthropic Claude API. Inference traffic goes to the nearest Anthropic region and is not retained for training. We send only the minimum context required to answer.
End-to-end encryption isn't a thing for a multi-tenant accounting platform — but we get as close as the architecture allows.
TLS 1.2+ for every endpoint. HTTPS only — HTTP redirects to HTTPS at the edge.
AES-256 at the disk level via Supabase + AWS RDS encryption. Backups inherit the same.
API keys, signing secrets, and OAuth tokens never live in the database in plaintext. They are environment-scoped and rotated when staff changes.
On the roadmap (Q1 2027) for PII fields like PAN/Aadhaar, on top of disk-level. Currently disk-level only.
Two firms on OnGravy can never see each other's data — even via a SQL bug. Postgres enforces this.
Every business-scoped table has an RLS policy keyed on the JWT business_id claim. The application code cannot bypass RLS for read paths — Supabase enforces it at the database boundary.
Only specific server-side write paths use the service role key, and they live in well-defined route handlers (audit-logged on use). User-facing reads use the user JWT, which subjects them to RLS.
There is no "look at any business" admin panel for OnGravy staff. Support requires the customer to grant a time-bounded read role.
RBAC matches what CAs already use: owner, admin, accountant/staff, viewer.
owner / admin / accountant / staff / viewer — applied per business, not globally. Each role maps to a permission tier checked on every write.
Every privileged write (vouchers, payments, filings) records actor, action, before/after, IP, and timestamp. Audit log is append-only.
Critical write endpoints (payments, filings, refund initiations) require an idempotency key with a 7-day TTL. Replays are detected and dropped.
JWT access tokens expire in 1 hour. Refresh tokens are scoped to the device and revocable from /dashboard/settings/security.
What happens if a server dies, a disk fails, or someone deletes the wrong row.
Postgres point-in-time recovery (PITR) is enabled. We can restore to any second within the last 7 days. Hot snapshots taken daily, retained 30 days.
Database is multi-AZ in ap-south-1. Storage is replicated across availability zones.
Live system health at /status. Post-mortems are published for every incident over 30 minutes long.
Recovery time objective: 60 minutes. Recovery point objective: 5 minutes. Both targets, not contractual SLAs (that comes with enterprise).
Honest about what we have and what we're working on. No trust-washing.
India's Digital Personal Data Protection Act. Lawful processing basis is contract performance + legitimate interest for compliance features. Subject access + deletion endpoints in /dashboard/settings/privacy.
Audit trail meets the requirements of Rule 9 of the GST Rules and Section 44AA of the Income Tax Act. Logs are tamper-evident (append-only with hash chain).
Working towards. Targeted Q2 2027. We will publish the auditor + observation period when the engagement starts.
Working towards. Stage 1 audit targeted Q3 2027.
For EU-based CAs / customers: Data Processing Agreement available at /dpa.
Found something? We want to know. Bounty programme is live.
security@ongravy.in — please include scope, repro steps, impact. We respond within 24h on weekdays.
Up to ₹50,000 wallet credit + leaderboard recognition. Out-of-scope items and rules at /dashboard/help/bug-bounty.
Good-faith research that follows our policy will not result in legal action. We won't sue you for finding a bug.
We answer real security-review questions personally — not via a chatbot. If you've got a firm that needs sign-off before adoption, send us your questionnaire and we'll fill it out line-by-line.