Security & Compliance Overview

This page summarizes the security model underlying SAVHN, drawing together concepts covered in more detail elsewhere in this documentation. It's a useful starting point for a security review or a compliance questionnaire response.

Identity and authentication

Every user authenticates with a single identity (see Platform Architecture Overview) via email/password or, where configured, your organization's single sign-on provider.
API and integration access uses bearer tokens obtained via POST /api/auth/login or via dedicated API keys issued from the Developer Portal (see Developer Portal Overview). Every request outside the browser session must present a valid Authorization: Bearer <token> header.
Tokens are time-limited; expired tokens are rejected with 401 Unauthorized and require re-authentication rather than silently extending.

Role-based access control (RBAC)

Access within an organization is governed entirely by RBAC, described fully in Role Management & Permissions:

Every action is checked against the requesting identity's resolved permission set — role permissions combined with any user-level overrides.
Enforcement happens server-side on every request, not only in the UI — hiding a button does not substitute for a permission check, and no client-side control is treated as the security boundary.
Record-level scoping (e.g. a manager seeing only their direct reports' data) is layered on top of module-level permission, so having access to a screen doesn't imply access to every record within it.

Per-organization data isolation

SAVHN's multi-tenant model isolates data by organization structurally, not merely through query filters that could be bypassed by a bug in one code path:

The authenticated token determines the organization context for every request; there is no client-suppliable organization parameter that could be manipulated to reach another tenant's data.
Cross-tenant queries do not exist in the normal product or API surface. The only identity type with any cross-tenant reach is the separate superadmin operator layer (/api/superadmin), which is not obtainable through normal organization login and is used solely for platform operations like tenant provisioning and support diagnostics.
Module enablement, role definitions, custom fields, and all business records are entirely private to the owning organization by default; nothing is shared across tenants unless a feature explicitly implements cross-tenant sharing (for example, a Client Portal user from another organization being granted scoped visibility into specific shared records — itself governed by RBAC, not a data-isolation exception).

Admin audit basics

Administrative and security-relevant actions are recorded to an organization-scoped audit trail, available to Org Admins from Admin Console → Audit Log. Typical events captured include:

Role and permission changes (who changed what, and when).
User invitations, activations, deactivations, and role reassignments.
Module enablement/disablement.
API credential creation and revocation.
Login events, including failed login attempts, useful for spotting credential-stuffing patterns.

Use the audit log routinely — not only when investigating an incident — as part of periodic access review, particularly after any offboarding event, to confirm that access was revoked as expected and that no unexpected role changes occurred in the interim.

Practical security checklist for admins

Area	Recommendation
Admin accounts	Maintain at least two Org Admin accounts; never rely on a single admin identity
Password/SSO	Enforce SSO where your organization has an identity provider, rather than relying solely on platform passwords
API credentials	One dedicated key per integration, named descriptively, revoked promptly when no longer needed
Role review	Review custom roles and user-level overrides quarterly against your current org chart
Offboarding	Deactivate departing users immediately; don't rely solely on role removal
Audit log	Review periodically, not only during incident response
Client Portal	Keep external users strictly in Client-family roles; never grant Admin Console access to an external identity
Webhooks	Verify signature headers on every inbound webhook call before trusting the payload (see Building Integrations with SAVHN)

Transport and application-layer basics

All traffic to SAVHN, whether from the web application or the API, is expected to occur over HTTPS; clients should reject or refuse to fall back to an unencrypted connection.
Bearer tokens should be treated as sensitive credentials for the duration of their validity — never logged in plaintext by an integration, never embedded in a URL (which risks exposure via server access logs or browser history), and always transmitted only in the Authorization header.
Webhook payloads carry a signature header specifically so a receiving endpoint can distinguish a genuine SAVHN-originated request from a spoofed one; treat any webhook receiver as a public endpoint that must independently authenticate its inbound traffic rather than trusting network position alone.

Segregation of duties

For organizations with compliance obligations around segregation of duties (common in Finance and Payroll workflows), SAVHN's RBAC model supports separating "can edit" from "can approve" on modules that expose that distinction, so the same user cannot both create and approve the same transaction. Configure this deliberately when defining Finance- and Payroll-related roles rather than assuming it's the platform default — a role given "Full Access" bundles both capabilities together unless narrowed.

How this maps to common compliance questionnaire topics

Typical question	Where the answer lives in this documentation
How is tenant data isolated?	Platform Architecture Overview — multi-tenant model section
How is access controlled?	Role Management & Permissions
How is API access authenticated?	Developer Portal Overview
Is there an audit trail of administrative actions?	Admin audit basics, above
How are environments and credentials separated?	Deployment & Environments Overview

Data handling and retention

Disabling a module hides it from navigation but does not delete its underlying data, preserving continuity if the module is re-enabled later (see Module Marketplace: Enabling & Configuring Modules).
Deactivating a user preserves their historical record attribution (e.g. as the author of past Chat messages or the assignee of past closed Tickets) while immediately revoking their ability to authenticate.
Deletion of records generally follows a soft-delete/archive pattern rather than immediate hard deletion, to protect against accidental data loss — consult module-specific settings for retention behavior where it matters for your compliance obligations.

Principle of least privilege in practice

Least privilege shows up throughout this security model rather than as a single setting to configure:

Roles: grant the minimum module and action access a function genuinely requires, and use user-level overrides for narrow exceptions rather than widening a whole role.
API credentials: scope each integration's identity to only the domains it actually needs, and prefer read-only access wherever an integration only consumes data.
Client Portal: share only the specific records a client needs visibility into, rather than broad module-level access, since external identities warrant the tightest scoping in the entire permission model.
Superadmin operations: kept structurally separate from any organization-level identity, so that even a fully-privileged Org Admin token cannot reach cross-tenant operator functions — least privilege applied at the platform architecture level, not just the role configuration level.

Applying this consistently is less about any single control and more about treating every new role, credential, or share as an opportunity to grant only what's needed rather than defaulting to broad access for convenience.

Reporting a security concern

If you believe you've found a security vulnerability or observe suspicious activity in your organization's audit log that you can't explain, escalate to your Org Admin immediately and, for platform-level concerns, to SAVHN's support channel rather than attempting to investigate by directly probing production endpoints.

Role Management & Permissions — the full RBAC model.
Platform Architecture Overview — how tenant isolation and identity are architected.
Deployment & Environments Overview — credential and environment separation practices.