Isolation
Your data is yours — no other customer can ever see it. Enforced by the database itself, not just by the app.
Every request is tied to one organisation, and the database itself checks that each row it returns belongs to that organisation. The check fails closed: a request that is not tied to an organisation gets nothing back, never someone else's data.
- Isolation rules enforced by the database on every table that holds customer data
- Every request runs inside its own organisation's context
- Fails closed: a request with no organisation sees no rows at all
- Checked automatically before every release
Authority
Two layers of control: what your role lets you do in general, and what's allowed for this specific request — in this specific department, at this specific amount.
Your role decides the set of things you can do — a fine-grained permission system with clean separation between administrative and operational capability. A second layer then checks the specific request: can the submitter approve their own document, is the Head of Department acting within their department, does the amount exceed their threshold.
- A fine-grained permission system with clean separation between administrative and operational capability
- Separation of duties — submitters cannot approve their own requests
- Department scope — Heads of Department act only on their own department
- Amount thresholds — high-value requests auto-escalate to the MD
Session integrity
When a role changes or a user leaves, their active sessions are invalid within seconds.
Every session is checked on every click. A role change, deactivation, password change, access expiry, or a company-wide sign-out means signing in again on the next click. Two-factor sign-in accepts a passkey, an authenticator app, or a one-time code by email or SMS, with secured recovery codes behind them. Per-tenant IP allowlisting (both IPv4 and IPv6) is available as a hard sign-in gate.
- Active sessions end within seconds of a role change, deactivation, or password change
- Two-factor sign-in by passkey, authenticator app, email code or SMS — required for everyone or for the roles you choose
- Per-tenant IP allowlist (IPv4 and IPv6) available as a hard sign-in gate
- Single sign-on via OpenID Connect (OIDC) or SAML 2.0, which a company can require; one sign-in per person across every company they work in
Audit trail
Every action recorded and sealed. Every export, regulator-ready.
The audit log records who did what, when and from where, for every meaningful event. Role changes and board-access lifecycle events have their own dedicated trails. Each entry is chained to the one before it, and edits and deletions are refused by the database. Lawful retention purges leave a verifiable marker in the chain. Every night the chain is sealed with a signed fingerprint your auditor can check without trusting Novorit.
- Every approval, query, and role change written to an append-only log
- Dedicated trail for role changes, capturing who changed what and why
- Board-access lifecycle fully tracked — provisioning, approval, expiry, renewal, revocation
- One-click regulator-ready export for any period
Access lifecycle
People come and go — access keeps up. Joiners get what they need; leavers lose access within seconds.
User provisioning flows in automatically from your identity provider (Okta or Microsoft Entra). Auditor and board-level guests get a clear start date and expiry — access is withdrawn on the dot without manual clean-up. Document retention follows your plan; the audit trail itself is never purged while the account is active.
- Automated user provisioning (SCIM) with Okta and Microsoft Entra
- Directory groups mapped to roles — anything beyond staff access waits for a person in your organisation to approve it
- Time-bound access for auditors and provisional board members, with automatic revocation
- Per-plan document retention, with the audit trail itself never purged
- Attachments served through short-lived, per-upload URLs
Encryption & infrastructure
Encrypted in transit and at rest — and again on top of that, for the most sensitive pieces like two-factor codes and single sign-on tokens.
All traffic is encrypted with modern TLS. The application database is encrypted at rest, with automated daily snapshots. Sensitive application secrets — two-factor codes, single sign-on tokens — are encrypted again at the application layer before being written, so even a database leak would not expose them. Attachments live in encrypted object storage and are delivered through short-lived, per-upload URLs.
- Modern TLS in transit, with strict browser-side policies
- Database encrypted at rest, with daily snapshots
- A second layer of encryption for sensitive fields, with keys per company
- Encrypted object storage with short-lived, per-upload delivery URLs