What we can verify, stated plainly
This page lists the access-control and audit capabilities that exist in the product today, and says clearly where we don't yet have something (like a third-party certification) rather than implying we do.
Who can do what
Permissions are granted through roles drawn from one catalog, not scattered checks across the codebase.
-
Role-based access control (RBAC)
Every action in the platform is gated by a permission key of the form module.resource.action, drawn from a single permission catalog - access is granted through named roles, not hard-coded by job title.
Available -
Token-based authentication
Platform sign-in uses bearer access tokens verified on every request, not long-lived shared credentials.
Available -
Platform vs. business-module scoping
Platform-administration permissions (running the SaaS/white-label shell itself) are modeled separately from the business modules your staff use day to day.
Available -
Progressive rollout & feature flags
New capabilities can be enabled for a percentage of users or an explicit pilot cohort before a general rollout, so changes are validated on a controlled group first.
Available
What's recorded, and how
Every significant action - not just logins - is written to an audit trail that nothing in the application can edit or delete.
-
Append-only security & business audit log
Authentication, permission changes, record changes, approvals, exports, configuration and integration events write to a single append-only audit collection - no route updates or deletes these rows.
Available -
Actor, before/after state & correlation ID
Each audit event carries who did it, what changed (before and after), where from (IP, user agent) and a correlation ID so a multi-step action can be traced end to end.
Available -
Dedicated period-close audit trail (Accounting)
Accounting period-close actions are additionally recorded in their own closing-specific audit trail.
Available
How customer data is separated
Isolation comes from deployment architecture, not row-level tenant filtering in a shared database.
-
Dedicated, single-tenant deployment
Each customer runs a dedicated deployment rather than sharing one database with other customers - there is no shared multi-tenant data store to isolate within.
Available -
White-label configuration
Branding and domain are configured per deployment, so your customers only ever see your brand.
Available -
Independent security certification (SOC 2, ISO 27001, etc.)
We have not completed an independent third-party security certification or audit. Treat any claim of a specific certification as false until we publish one here.
Planned -
Formal data-residency commitments
A documented, contractual data-residency guarantee per region is not yet in place.
Planned
Our approach to claims on this page
Every control above is labelled Available or Planned based on what exists in the codebase and product today, not what's on a roadmap slide. We deliberately don't list encryption standards, uptime SLAs or compliance certifications we haven't verified or earned. If you need something specific for a security review - a data-flow diagram, a permission-catalog export, or a pen-test summary once one exists - ask us directly and we'll tell you plainly whether we have it.
Frequently asked
Is this a multi-tenant SaaS with data isolated by row-level permissions?
No. Each customer runs a dedicated, single-tenant deployment - there is no shared database that requires row-level tenant isolation. This is a deliberate architecture choice, not a limitation we're working around.
Do you have SOC 2 or ISO 27001 certification?
Not yet. We'd rather tell you that directly than let a badge imply otherwise. If a formal certification is a requirement for your evaluation, tell us and we'll be upfront about timeline.
Can we see who changed a record and when?
Yes - the append-only audit log records the actor, the before/after state, and a timestamp for record changes, permission changes, exports and configuration changes.
How are roles and permissions managed?
Through a single permission catalog (module.resource.action keys) assigned to named roles. Platform-administration permissions are modeled separately from the business-module permissions your staff use.
Ask us a specific security question
Talk to us before your evaluation - we'll tell you plainly what's verified and what isn't.