Security and access
Access is granted, never assumed. Authority is checked twice.
One customer organization is one tenant, one collaboration boundary and one billing boundary. Membership is created by invitation, resolved on the server, and enforced again in the database beneath the application.
What follows describes the architecture and where each boundary is enforced. It is written as capability, not as certification.
Tenant boundary
One organization, one tenant
Every record has one owner. Assessments, evidence, exports and audit events always carry an organization identifier. Projects and portfolios organize work inside a tenant; they never quietly become security boundaries of their own.
Isolation is a configuration of the tenant, not a rewrite of the product. A pooled organization shares a database and schema behind row-level security. Where a contract requires more, the same domain model runs on a dedicated schema or a dedicated database with separate credentials. Region and residency boundaries are contractual, so they are agreed with you rather than asserted on this page.
-
No personal production workspace
Production work happens inside a customer organization. There is no individual workspace sitting outside that boundary.
-
Demo tenants are visibly synthetic
An optional demo tenant holds system-seeded synthetic records only. It disables evidence upload, integrations and content export, carries a persistent synthetic-data marker, and is reset on a schedule.
-
Support has no standing access
Platform support is not a tenant role. It uses a separate privileged identity plane with approval, a time limit and complete audit capture.
Invitation-controlled access
No public sign-up
Purchase is not authority. Completing a commercial agreement produces an entitlement and a workspace. It does not produce a member. Every membership begins as a deliberate invitation from someone accountable inside your organization.
- 01
An administrator issues the invitation
An organization administrator supplies the email address, the proposed role and any project scope. Membership starts as an act by someone already accountable inside your organization.
- 02
Only a hash of the token is stored
The service keeps a hash of the invitation token and sends a one-time link that expires. The stored record cannot be replayed to reconstruct the link.
- 03
The invitee authenticates first
Authentication happens through the identity connection your organization requires, or an allowed bootstrap method, before membership exists.
- 04
The identity must match the invitation
The service checks that the authenticated identity is permitted to accept the invited address. Wrong-account attempts are blocked and audited rather than quietly redirected.
- 05
Acceptance creates the membership
Role authority comes from the invitation record, never from a field the browser submitted. The invitation then becomes immutable accepted history.
Rule A verified email domain is not a membership grant. Automatic joining by verified domain is disabled, and just-in-time membership can only ever be turned on as an explicit organization policy.
Enterprise identity
Identity without authority
A dedicated enterprise identity broker gives each customer organization its own OIDC and SAML connections and, in a later phase, directory synchronization. Your provider proves who someone is. What they may do is decided here.
Provider role claims are deliberately ignored as application authority. Internal roles are reloaded from the database on every session, and a membership-version mismatch invalidates the session. The broker is reached through an internal adapter and provider identifiers are never used as primary keys, so the identity layer stays replaceable.
- Single sign-on
- Per-organization OIDC and SAML connections move through a defined lifecycle from draft to verifying, active, degraded, disabled and retired. You confirm domains and test the connection before enforcement, and a recovery administrator must remain available whenever enforcement changes.
- Multi-factor authentication
- Required for privileged roles, and enforceable through your own identity provider or through broker policy. Privileged settings additionally require recent authentication rather than an old session.
- Directory synchronization
- A defined later phase, introduced once invitation and single sign-on flows are stable. Deprovisioning suspends membership and revokes sessions; it does not delete audit history or assessment authorship.
- Sessions
- Short-lived first-party sessions carry only the minimum authority needed. Cookies are secure, HTTP-only and same-site restricted, with cross-site request protection on mutations. Session records hold correlation identifiers, never provider access or refresh tokens.
Authorization
Two authorization gates
Identity is global; authority is tenant-specific. The application decides whether an action is permitted, and the database independently limits which rows that action can ever touch.
- 01 Context
Edge
TLS, web application firewall, rate limits and request-size controls. Nothing arriving from a browser is treated as authoritative, and edge headers are context rather than proof of identity.
- 02 Context
Session
The server validates issuer, audience, signature, expiry and revocation on a short-lived first-party session, then reads the active organization, membership and membership version from it. Privileged settings require recent authentication.
- 03 Enforcement
Permission policy
The application checks the requested action against the permissions held by that membership. Tenant, actor, role and approval authority are never accepted from a request body.
- 04 Context
Tenant resolver
The server-derived organization is applied as a transaction-local setting on the database connection, so the boundary travels with the query rather than with the caller.
- 05 Enforcement
Row-level security
PostgreSQL row-level security filters every tenant-owned table using that verified context. The application connection role is not a table owner and cannot bypass the policy.
Roles carry the authority, and duties stay separated
Permissions are attached to roles, and the approval service enforces policy such as author-not-approver, legal-review independence and dual approval for identity-policy changes. Hiding a button in the interface is not enforcement, and is not treated as any.
- Organization administrator
- Members, authentication policy, configuration, integrations and retention. Cannot automatically approve their own assessments.
- Framework manager
- Proposes and manages control, source, mapping and baseline releases.
- Assessor
- Creates assessments, records control decisions and attaches evidence.
- Control owner
- Responds to assigned controls and remediation actions.
- Reviewer
- Reviews decisions, evidence and remediation, and approves where independent.
- Legal reviewer
- Approves legal role, classification and obligation decisions that require qualified review.
- Auditor
- Reads approved snapshots, evidence metadata and the tenant audit history.
Audit
Append-only audit records
Audit is tenant-scoped and written with the change. Audit events are immutable application records held separately from mutable assessment history. A sensitive mutation and its audit event are committed in the same transaction, so an action cannot succeed without leaving its record.
What produces an event
- Authentication changes and workspace switches
- Invitations, membership and role changes
- Access decisions and approvals
- Identity connection and directory changes
- Assessment and evidence mutations
- Evidence downloads and exports
- Retention and deletion operations
- Break-glass platform access
What every event carries
- organization_id
- occurred_at_utc
- actor_type, actor_id
- session_id, request_id
- source_ip_hash
- action, outcome, reason_code
- object_type, object_id
- before_summary, after_summary
- auth_strength
Reading the audit history and exporting it are separate permissions. Audit records are visible only within the organization that owns them, under the same row-level policy as every other tenant-owned table.
Data and platform
Boundaries under failure
These are the boundaries that have to hold when something goes wrong.
-
Evidence governance precedes evidence upload
Evidence is never a database blob. The design authorizes an upload for one assessment in the active organization, quarantines the object, validates and scans it, calculates a hash, records classification, and only then makes it linkable. Downloads use short-lived authorization and create access events. Private storage, scanning, hashing, retention, access logging and verified deletion are release gates that must be met before attachment is enabled.
-
Secrets and telemetry stay separate from content
Secrets live in the platform secret store and never appear in application records or telemetry. Logs carry request, organization and actor identifiers, but not control evidence, legal reasoning or tokens.
-
Environments do not share anything
Development, test, staging and production use separate accounts, databases, identity environments, storage buckets, keys and webhook secrets. Production data never seeds a lower environment.
-
Background work re-checks authority
Queued jobs carry a signed envelope with organization and request identifiers, then reload membership and resource authority before acting. Webhooks are signature-validated, replay-protected and idempotent.
Verification
How to verify this
Take none of it on trust. The statements on this page describe the architecture and its enforcement points. They are not certifications, audit opinions or compliance attestations, and they should not be read as any.
Formal assurance evidence, including independent test results and the current implementation status of each boundary described here, is provided during procurement review.
- Cross-tenant isolation, authorization and object-key tests are mandatory release gates rather than periodic exercises.
- Independent penetration testing is required before public multi-tenant availability.
- Availability, recovery-point and recovery-time objectives are agreed contractually, together with retention, legal hold and verified deletion commitments.
- Backup restoration is demonstrated against the agreed objectives rather than assumed from configuration.
Next step
Bring your security review
Review the architecture rather than a brochure. Security, procurement and legal questions are handled as part of the access request.