Security & governance
The controls a buying committee actually asks about.
Every mechanism below is real and implemented — not a compliance-page template. Where something isn't yet enforced, this page says so plainly instead of implying it.
Governance foundation
Seeded roles with scoped permission packages.
Structural isolation
Tenant and company boundaries enforced below the UI.
Scoped access
Time-bound roles at company, branch, or department level.
Immutable history
Audit records reject update and deletion at the database layer.
Maker-checker
Sensitive actions block self-approval by construction.
Connected modules
What security means here
Vercentlabs' security architecture is built on structural tenant isolation, a real role-based access model with time-bound and scoped assignments, a database-trigger-enforced immutable audit trail, and governed maker-checker approvals — the controls a buying committee actually asks about, explained plainly rather than as a generic security-policy page.
Controls buyers can verify
Isolation, identity, audit, and approval—explained plainly.
Implemented mechanisms and current limitations are separated clearly.
Tenant isolation
Structural, not just filtered
Every tenant's data is isolated at the database layer, enforced on every query — not assumed by application-layer convention.
Multi-company data isolation
Company and branch scoping is structural, matching the same discipline as tenant isolation.
Authentication
Login hardening
Failed-attempt lockout and password history are enforced.
MFA — schema-ready, not yet enforced
MFA columns exist in the schema, explicitly described in-product as an 'MFA-ready foundation.' MFA is not yet an enforced control today — stated plainly, not implied as active.
Device-bound mobile auth
Fingerprint-required login, secure-store tokens, and biometric re-lock after 15 seconds background on mobile.
Roles, record-level, and field-level access
12 seeded system roles
With framework-neutral, per-module permission-key packages.
Time-bound and scoped assignments
A role assignment can expire automatically and be scoped to a specific company, branch, or department — not all-or-nothing.
Margin and cost redaction
Sales margin figures are redacted from roles that shouldn't see them, consistently across every view, not just the ones someone remembered to gate.
Audit history
Database-trigger-immutable
A Postgres trigger rejects UPDATE/DELETE against the audit table, even from an application bug — enforced below the application layer.
Approval controls
Governed maker-checker
A reusable command registry enforces separation of duties across Accounting, Sales, CRM, HR, Assets, Projects, POS, and Support.
Self-approval blocked by construction
Not a policy reminder — the system itself prevents the preparer of a sensitive action from also approving it.
Data retention, encryption, and backup
Session governance
Session lifetime and idle timeout are enforced platform-wide.
Document integrity
Uploaded documents are SHA-256-hashed and moved through a quarantine lifecycle before being trusted.
Controls in context
Governance applied to sensitive operational modules.
Straight answers
Questions about security & governance
Is multi-factor authentication available?
MFA columns exist in the schema as an 'MFA-ready foundation,' but MFA is not yet an enforced control today. We state this plainly rather than implying it's active.
How is one tenant's data kept separate from another's?
Isolation is structural — enforced at the database layer on every query — not an application-layer filter that a bug could bypass.
Can someone approve their own transaction?
No, for every governed action across Accounting, Sales, CRM, HR, Assets, Projects, POS, and Support — self-approval is blocked by the system itself, built on a shared, reusable command registry, not a per-module policy someone could forget to implement.