Security at Venvera

Tenant isolation, enforced by the database

Every tenant table in Venvera is protected by PostgreSQL row-level security in enforced mode. The application connects as a restricted, non-superuser database role that cannot bypass those policies, so a query can only ever see the rows of the organization it runs for. This is not an application-layer filter that a bug could skip: even if application code forgot a WHERE clause entirely, the database itself would return nothing that belongs to another tenant.

We verify this continuously with cross-tenant isolation tests that attempt, as the runtime role, to read and write another organization's records. A release does not ship if any of those attempts succeed.

Encryption: in transit, at rest, per tenant

• All traffic is encrypted in transit with TLS.
• Uploaded evidence and documents are encrypted at rest with AES-256-GCM using a separate encryption key for each tenant. Compromise of one tenant's key exposes nothing of any other tenant.
• Database backups are encrypted with AES-256 using key-derivation hardening (PBKDF2) before they leave the database host.
• Customer AI API keys (bring your own key) are stored encrypted and are only ever used for that tenant's own requests.

Identity and access control

• Single sign-on via Microsoft Entra ID, with the option to enforce SSO for the whole organization.
• Two-factor authentication that admins can make mandatory for every user in the tenant.
• Allowed email domain restrictions, so accounts can only be created on your corporate domain.
• Granular role-based access control: permissions are explicit per user, revocation is real and immediate, and every permission change is written to the audit log.
• Server-side session records with expiry, so a session can be revoked centrally at any time.

Zero standing access for support and administrators

By default, nobody at Venvera can read your tenant data. Not support, not engineering, not platform administrators. When a support case genuinely requires access, the engineer must request it, state what they need and why, and your administrator approves or declines from the dashboard or by email. Access is time-boxed, revocable at any moment, and every step is written to your own audit log where you can review it.

We described exactly how this works, including what the engineer has to ask for, in this engineering write-up.

EU data residency

Venvera runs in European Union datacenters. Customer data, uploaded evidence, and backups stay in the EU. We act as a data processor for the data you store in the platform, under a data processing agreement; see our privacy policy for the full picture of what we process and why.

Network and infrastructure security

• Host-level intrusion prevention with behavioral attack detection: exploit attempts, SQL injection and path traversal probing, credential brute force, and vulnerability scanning are banned automatically at the firewall.
• A continuously updated community threat intelligence feed preemptively blocks tens of thousands of known-malicious IPs before they reach the application.
• Hardened Linux hosts with a default-deny firewall and automated security patching.
• Segmented services: the public website, the application, and the database run isolated from one another.

Application security

• A full audit trail: creates, updates, and deletes on compliance records are logged with who, what, and when, and are visible to your admins in the platform.
• Vendor questionnaires are protected with a unique cryptographic token plus a separate access code delivered out of band, expire automatically, and log every access attempt.
• All state-changing API routes enforce authentication, tenant context, and per-framework permissions server-side.
• Regular internal security audits of the platform, with findings tracked to closure.

We run Venvera on Venvera

Our own compliance programme, spanning ISO 27001, SOC 2, and GDPR, is managed inside our own production tenant: the same controls, the same evidence workflows, the same audit trail we sell. When we ship a security feature, we are our own first user.

Reporting a vulnerability

If you believe you have found a security issue in Venvera, we want to hear about it. Email privacy@venvera.com with the details and steps to reproduce. We acknowledge reports promptly, keep you informed while we investigate, and do not pursue good-faith researchers.