What stands between your data and trouble.

Encryption

• At rest: per-tenant data isolation with per-tenant encryption keys. Two shops cannot share a key. Compromise of one tenant's key does not put another tenant at risk.
• In transit: TLS 1.3 for every connection between client, edge, and origin. No mixed content, no plain HTTP fallback.
• For backups: backups are encrypted with a separate key set, rotated quarterly. Restore is itself an audited event.

Access controls

• Inside the product: role-based access (owner, manager, worker, family) with the principle of least privilege. Workers don't see margins by default. Family members don't see employee payroll. Every role is configurable per-shop.
• For our team: production access is gated, audited, and time-boxed. No persistent superuser sessions. Every read of customer-tenant data triggers an audit row even for our own engineers.
• For integrations: third-party access is scoped per integration, revocable from the shop's settings.

Audit trail

Every state-changing action — bill created, draft approved, user added, role changed, export generated — produces an audit row that is timestamped, signed, and tamper-evident. The audit trail is exportable on demand and retained for the regulatory minimum of 8 years.

Authentication

• Phone-number OTP as the default sign-in for shop users. Optional password backup.
• Multi-factor enforced for the owner role and for any user accessing the financial export endpoints.
• Sessions expire after 30 days of inactivity. Active sessions can be revoked from any other signed-in device.
• Suspicious sign-in attempts (new device, new geography) trigger an in-app challenge and a notification to the owner.

Data isolation

A central design decision: no two shops share a table, a key, or a logical address space. There is no “global SKU table” in which a clever query joins across tenants. The product genuinely can't see across shops, because the architecture refuses to let it.

We don't train AI models on tenant data without written, separately-collected opt-in. Opt-in is never bundled with feature access. See privacy and DPDPA 2023.

Incident response

1. Detection. Continuous monitoring on auth anomalies, write-volume anomalies, exfiltration patterns, and infra health.
2. Triage. Severity assessed against documented criteria within 30 minutes of detection.
3. Containment. Affected surfaces taken offline, keys rotated, sessions invalidated as the severity warrants.
4. Notification. Affected shops contacted within 24 hours of confirmed impact. Material incidents reported to the Data Protection Board of India within 72 hours per DPDPA 2023.
5. Post-mortem. Public-facing post-mortem within 14 days for any incident that affected more than one shop. Linked from the status page.

Responsible disclosure

Found a security issue? Email [email protected] with subject line “Security disclosure.” We commit to:

• Acknowledging your report within 24 hours.
• Confirming severity and remediation plan within 5 business days.
• Crediting you publicly (if you'd like) once the fix is shipped.
• Not pursuing legal action against good-faith security research that follows reasonable responsible-disclosure norms.

We don't currently run a paid bug-bounty program. We do honor every responsibly-disclosed finding with a meaningful acknowledgment and, where merited, a real reward of our choosing.

What we're working on next

• SOC 2 Type I — audit scoping in progress, targeted for Q4 2026.
• ISO 27001 — scoping after SOC 2 closes, targeted for 2027.
• Hardware-key support for the owner role — on the roadmap for Q3 2026.
• Per-device signing for high-risk operations — design in progress.

What you can do today

• Turn on MFA for every owner-role user.
• Review your team's roles in Settings — revoke access for anyone who no longer needs it.
• Take an export quarterly. Even if you trust us, an offline copy is a good thing for a paranoid CA to have.