Security

• Multi-tenant by design. Every database row carries a tenant ID and is filtered on every read and write. There is no path through the application to read another tenant's data.
• Server-side authorisation. Roles (Owner, Admin, Manager, Cashier, etc.) are enforced on the server; the UI is a hint only.
• Type-safe data layer. Schema is defined in Prisma; mismatches between code and database are caught at build time.
• Money in integer minor units. No floating-point rounding errors in invoices or ledgers.

2.1 Encryption

• TLS 1.2+ for everything in transit. HTTPS-only with HSTS preload pending.
• Encryption at rest for the primary database (managed PostgreSQL).
• Backups encrypted at rest.

2.2 Authentication

• Passwords stored as bcrypt hashes with a strong work factor.
• Email + password and (where enabled) magic-link sign-in.
• Sessions are short-lived and tied to a per-tenant cookie.
• Multi-factor authentication is on the roadmap.

2.3 Audit logging

Every sensitive action is recorded with the user, timestamp, IP, and key metadata — rate changes, invoice edits and voids, payment entries, settings changes, plan changes, billing-detail changes, role changes. The audit log is visible in-app to Owners and Admins.

2.4 Backups & recovery

• Automated daily backups with point-in-time recovery for the primary database.
• Backups retained as described in our Privacy Policy.
• Periodic restore drills to verify backups are usable.

• Application hosted on managed infrastructure with India-region primaries.
• Database hosted on managed PostgreSQL with continuous replication.
• Cloudflare in front for DDoS protection, edge filtering, and DNS.
• No production data on developer laptops; strictly-limited access via short-lived credentials.

• All inputs validated server-side with Zod schemas.
• Server actions for mutations — no DOM-form submissions to public endpoints.
• CSRF protection on state-changing requests.
• Content Security Policy and standard hardening headers.
• Dependencies scanned for known vulnerabilities; security patches applied promptly.
• Code review on every change before it reaches production.

The current list of sub-processors and what they do is in our Data Processing Addendum. We give 30 days' notice before adding a new sub-processor.

If we ever discover a personal-data breach affecting your Workspace, we will:

• Contain the breach as fast as possible.
• Notify affected Workspace Owners within 72 hours, with what we know and what we're doing.
• Notify the Data Protection Board of India where required by DPDPA 2023.
• Publish a post-incident summary once the immediate response is complete.

What we ask:

• Don't access, modify, or delete data that doesn't belong to you.
• Don't run automated scans against the production app without prior agreement.
• Give us reasonable time to fix the issue before public disclosure (generally 90 days).

What we'll do:

• Acknowledge your report within 1 business day.
• Keep you updated on triage and fix status.
• Credit you in our security acknowledgements page (if you want) once a fix ships.
• Not pursue legal action against good-faith researchers who follow this policy.

You can help keep your Workspace secure by:

• Using a unique, strong password.
• Giving each staff member their own login (don't share credentials).
• Removing users promptly when staff leave.
• Reviewing the audit log periodically for unusual activity.
• Keeping your billing email up to date so you receive renewal and security notices.

Security-related questions or reports — security@aurexerp.com.