Security

Tenant isolation is enforced by the database

Every tenant-owned table carries PostgreSQL row-level security, and the application connects with a database role that cannot bypass it. Tenant context is set per transaction, never per session, so a connection returned to the pool carries nothing forward. Tenant resolution and provisioning use a second, narrowly scoped role; the owner role is used only for migrations.

The practical consequence: a query that forgets its tenant filter returns nothing rather than somebody else's rows. Isolation is a property of the data store, not a discipline the application has to remember.

The audit trail is append-only

Important actions are recorded with the actor, the tenant, the time, the outcome and the before-and-after state. Neither application role holds an UPDATE or DELETE grant on the audit table, and a database trigger refuses those statements for anyone who reaches the table another way. A correction is only possible by disabling that trigger inside a reviewed migration.

If an audit write fails, the action it describes fails with it. An unauditable action does not happen.

Audit payloads pass a redaction step before storage: credentials and personal attributes are removed and references kept, so the audit trail does not become the largest pile of personal data in the system.

Access to evidence is authenticated and recorded

Evidence files are streamed through an authenticated endpoint that checks the caller's permission and records the access. We deliberately do not issue pre-signed storage links: a link redeemed at the storage service cannot record who opened the file, and an evidence repository that cannot say who read it is not an evidence repository.

Identity and authorisation

• Authentication uses server-side sessions over secure, HTTP-only cookies.
• Accounts enrol a time-based one-time-password second factor.
• Authorisation is checked on the server for every request — identity, tenant, role, permission, resource, action. What the interface shows you is a convenience; what the server allows is the control.
• Authorisation denials are themselves audited events.

Where it runs

Production is hosted in India, in the Mumbai region. Our public evaluation environment is a separate host containing only synthetic data — no customer data is ever placed in it. The Act does not broadly mandate localisation today; we host in India because our customers ask, and because transfer restrictions may yet arrive for Significant Data Fiduciaries.

Regulatory content

Provisions, obligations and controls are versioned content with the source, the Gazette citation, the publication date and the retrieval date recorded against each item. Content that has not been reviewed by external counsel is marked as unreviewed in the product, and the platform refuses to run in production mode against unreviewed content.

What we do not claim

We would rather you learn this here than in a procurement questionnaire.

• No certifications. We hold no ISO 27001, SOC 2 or comparable certification today. Nobody has audited us, and we will not imply otherwise.
• No independent penetration test yet. When one has been done we will say so here, with its date.
• The audit trail is append-only, not a hash chain. Each record carries an integrity hash, but the records are not cryptographically chained to one another, so we do not describe them as tamper-proof. Append-only enforced at the grant and trigger level is a strong property; a hash chain is a different and stronger one, and we will claim it when we have built it.
• No single sign-on or SCIM yet. Both are on the roadmap for the Enterprise tier.
• No third-party sub-processor list published yet. It will be published before general availability.

Reporting a vulnerability

Write to [email protected] with enough detail to reproduce the issue. We will acknowledge within three working days, keep you informed, and credit you if you would like us to. Please do not test against any environment other than one we have agreed with you in writing.