Datavrn
Security

Security & data handling

Last updated: 7 July 2026

Datavrn handles financial data, so this page says plainly how that data is stored, isolated, and protected — and, because we are pre-launch, it is equally plain about what does not exist yet. The same three commitments are enforced mechanically on every change we ship: test coverage, tenant isolation, and the audit trail.

Where your data lives

The database runs on managed PostgreSQL in Mumbai (AWS ap-south-1), and the application is deployed to the same region. Residency is enforced in code: a runtime gate refuses to run against a database outside the region, so keeping customer data in India is a property of the system, not a policy document. Error telemetry is routed separately and carries no customer data.

Tenant isolation

Your organisation's data is isolated at two independent layers. The application derives your organisation from the authenticated session — never from a request parameter — and scopes every query. Beneath that, PostgreSQL row-level security is the backstop: even a bug in application code cannot cross tenants, because the database itself refuses. Every tenant-scoped table is listed in a registry, and an automated check proves, table by table, that a user in one organisation reads zero rows from another. Those isolation tests run on every change.

Encryption

Data is encrypted in transit (TLS) and at rest (managed PostgreSQL). Connector credentials — such as Zoho OAuth tokens — are additionally sealed with AES-256-GCM envelope encryption with versioned keys, so even a hypothetical raw read of the database would yield only ciphertext. If an encryption key is missing or malformed, the server refuses to start rather than degrade silently.

Access control

Sign-in is passwordless (one-time codes), with optional TOTP two-factor authentication; repeated failed attempts trigger an escalating lockout, and every attempt is audited. Inside an organisation, five roles govern what each person can see and do, and approvals enforce separation of duties — the person who submits a report cannot approve it. Internal access by us is read-only, gated behind mandatory two-factor authentication, and every such access is recorded in the affected organisation's own audit log, where its administrators can see it.

The audit trail

Every state-changing action writes an append-only audit record — who, when, what changed, before and after — in the same database transaction as the change itself, so the two can never drift apart. Database triggers reject any update or deletion of audit rows, for every role including the database owner. A gate blocks any new feature that mutates data without writing to the audit log.

Your data is yours

Uploads are retained verbatim as immutable, versioned snapshots and can be rolled back. Your mappings and methodology export as CSV and round-trip back in; report output leaves as standard files. Deleted entities carry a 30-day recovery window. No AI model touches customer data in v1; any future AI capability will be opt-in, disabled by default, and audited per invocation.

How we test it

The codebase carries over a thousand automated tests across four tiers, including a dedicated tenant-isolation suite that runs against real PostgreSQL. A standing adversarial review probes built code with hostile scenarios; the defects it has surfaced were remediated and locked behind regression tests — found in testing, never in production.

What we don't have yet

We are pre-launch, and some things honestly do not exist yet. We hold no SOC 2 or ISO 27001 certification; an external security audit is budgeted ahead of pilot exposure, and periodic third-party review is intended as standing practice. Point-in-time recovery and automated in-region backups come with the managed database; formal recovery-time objectives are part of pre-launch hardening. Automated hard deletion beyond the 30-day recovery window is designed but not yet built — deletion requests in the meantime are handled manually and confirmed in writing.

Questions

Security questions, or anything this page should answer and doesn't: hello@datavrn.com. See also the privacy policy and FAQ.