SAVHN Security & Data FAQ | Multi-Tenant Isolation

Security claims are easy to write and hard to verify — "enterprise-grade" and "bank-level" don't tell you anything concrete. This FAQ describes specifically how SAVHN handles data isolation, access control, authentication, and credential storage, so you can evaluate the real mechanisms rather than take a marketing phrase on faith. Where a question would require a specific compliance certification or contractual commitment, this FAQ says so honestly instead of inventing one.

Data Isolation & Access Control

How does SAVHN keep my organization's data separate from other organizations?

Every organization on SAVHN is a tenant, and every database query is scoped to the caller's organizationId at the data layer — not filtered after the fact by an application-level check that could be forgotten on some endpoint. That means there isn't a cross-tenant query path that could accidentally expose one organization's data to another; isolation is structural, built into how the queries are written, rather than a policy that depends on every developer remembering to add a filter on every new feature.

Is my organization's data ever visible to other customers on the platform?

No. Because isolation happens at the data layer by organizationId, another organization's queries simply cannot reach your records — there's no shared view, no cross-tenant reporting surface, and no accidental overlap by design. This applies uniformly across every module, from CRM records to Payroll data to Documents.

How does role-based access control work inside my organization?

Within your organization, every authenticated API request resolves the caller's role and organization once, centrally, and checks that against real module entitlement before returning data — this isn't a scattered per-screen permission check that's easy to miss on some page. Module visibility can also be restricted per role by an admin, so, for example, Payroll and Finance can be limited to relevant roles even though the organization has both modules enabled, while a general employee role sees a narrower slice of what's licensed.

Can an admin see everything, or are there limits even for admins?

Admin roles typically have the broadest default access, but specific sensitive capabilities — like workforce activity monitoring — are gated behind their own dedicated grant separate from general admin rights, with their own audit trail of who viewed what. Access isn't a single all-or-nothing admin switch; sensitive functions get their own explicit permission layer on top of general admin status.

How is data isolation different from just filtering results in the application?

A lot of software isolates tenants by adding a WHERE organization_id = ? filter somewhere in application logic — which works until one code path forgets to add it. SAVHN's isolation is described as being at the data layer "by construction," meaning the query structure itself doesn't have an unscoped path to begin with, rather than isolation depending on every new feature remembering to apply the same filter correctly.

Authentication

How does authentication work?

Users authenticate with email and password to receive a bearer token. That token is sent as an Authorization: Bearer <token> header on subsequent requests — the same mechanism a browser session and a programmatic API integration both use, so there isn't a separate, less-scrutinized authentication path for automated access.

Is there a separate API key system?

No. There is no separate API-key system — the same bearer token issued at login is what any integration you build uses to call the API. That keeps authentication to one real, understood path rather than two systems with potentially different security postures, and it means any authentication improvement (like MFA) automatically covers programmatic access too, since it's the same credential.

Does SAVHN support multi-factor authentication?

Yes — real multi-factor authentication and WebAuthn (passkey) support exist for account protection, particularly relevant for admin accounts that warrant stronger protection than a password alone. This isn't a roadmap item; it's available for organizations to enable today.

Can a compromised session be shut down immediately?

Yes. Sessions are tracked by token ID, not just left to expire on a signed token's own built-in expiry, so a session an admin believes is compromised — a lost device, a departing employee, a suspicious login — can be revoked in real time without having to rotate every credential in the system to be safe. This real-time revocation is meaningfully different from systems where a stolen token remains valid until it naturally expires.

Credentials, Encryption & Audit

How are third-party integration credentials (API keys, tokens) stored?

Every third-party credential connected through SAVHN — communications channel tokens, ad-platform tokens, cloud storage tokens, and similar BYOP (bring-your-own-provider) credentials — is encrypted with AES-256-GCM before it's written to the database. Secrets are never returned to the client in any API response; the client only ever sees a configured true/false flag, never the underlying value, even to a logged-in admin viewing their own integration settings.

If SAVHN's database were ever exposed, would my integration credentials leak?

Because credentials are encrypted at rest with AES-256-GCM rather than stored as plaintext strings, even a full database export would not reveal a usable secret. This is a specific, checkable design choice rather than a general assurance — it's the difference between "we take security seriously" and describing exactly what's encrypted and how.

Is there an audit trail of who did what?

Yes. Platform and monitoring actions are recorded in audit logs with real actor identity, the action taken, and a timestamp — useful for compliance reviews that need proof of who approved or performed a specific action, such as a high-value financial approval or a change to a sensitive record.

Does SAVHN protect public-facing endpoints, like client approval links, from abuse?

Yes. Rate limiting is applied per key on every public-facing route — not just authenticated ones — since endpoints like client approval links or lead capture forms are reachable without a login and need their own abuse protection separate from the protection authenticated routes get from requiring a valid session in the first place.

Is data encrypted in transit as well as at rest?

Connections to SAVHN run over standard encrypted transport (HTTPS/TLS), consistent with how any credible SaaS platform handles data in motion between your browser or integration and the server, in addition to the AES-256-GCM encryption applied to sensitive credentials at rest in the database.

Specific certifications and formal compliance commitments are exactly the kind of concrete detail worth confirming directly with the team rather than assuming — reach out through /book-demo with your specific compliance requirement, and you'll get a real, current answer rather than a generic claim added to a marketing page that may not reflect where the platform actually stands on a given certification at any given time.

What does SAVHN not do around security that I should know about?

SAVHN doesn't claim to be a substitute for your organization's own operational security practices — how you manage who has account access, how you handle devices, and your own password hygiene remain your responsibility, same as with any SaaS platform. Any specific compliance certification, audit report, or contractual security commitment your organization needs should be confirmed directly with the team through /book-demo rather than assumed from general platform behavior — those are exactly the kind of specifics worth verifying rather than guessing.

Where can I see this described from the product side rather than a FAQ?

The Security platform page (in the product's platform section) walks through the same mechanisms — encryption, entitlement checks, tenant isolation, session revocation — in more depth, alongside the specific stats (like zero plaintext secrets stored) that back up each claim.

What kind of data does SAVHN store about my organization's employees, clients, and financial records?

The specific data stored depends on which modules your organization has enabled — HRMS stores employee records if you're using it, Finance stores financial records if you're using it, and so on. A module you haven't enabled simply doesn't store the corresponding data for your organization, since there's no reason to collect data for a capability you're not using. This is a natural consequence of the per-module licensing model rather than a separate privacy feature layered on top.

Can employees within my organization see each other's sensitive data, like Payroll or performance information?

Role-based access control governs this the same way it governs module visibility generally — Payroll and other sensitive modules can be restricted to specific roles (typically Finance and HR), so a general employee role doesn't automatically see colleagues' compensation or performance data just because the organization has the module enabled. This is a deliberate configuration an admin sets up, not an automatic default that opens sensitive data to everyone.

Does SAVHN log or monitor what my employees do inside the platform?

Workforce activity monitoring exists as a specific, dedicated capability — but it's gated behind its own dedicated monitoring-admin grant, separate from general admin rights, and it maintains its own audit log of who viewed monitoring data. This means monitoring isn't something that happens invisibly by default; it's an explicit capability with its own access boundary and accountability trail.

If an employee leaves my organization, how quickly can their access be cut off?

Because sessions are tracked by token ID and can be revoked in real time rather than left to expire naturally, an admin can cut off a departing employee's access immediately rather than waiting for a token to time out on its own — this is exactly the kind of scenario real-time session revocation is built for.

Account-level hygiene — strong passwords, enabling MFA where it matters, controlling who has admin access within your organization — remains your organization's responsibility, the same as with any SaaS platform. SAVHN provides the mechanisms (MFA, WebAuthn, real-time session revocation, role-based restriction) but using them appropriately for your organization's risk profile is a decision your admins make.

Does disabling a module also revoke access to the data that was in it?

Disabling a module removes it from navigation and stops new activity, but it doesn't delete the underlying data, and the same organizationId-scoped isolation continues to apply to that data whether the module is currently enabled or not — it's simply not reachable through the disabled module's interface until you re-enable it. No other tenant gains any access to it as a result of your organization disabling a module.

How does SAVHN prevent one employee from escalating their own permissions?

Permission and role assignment is itself an admin-level action gated by the same central role-and-entitlement check every other request goes through — a regular user account doesn't have a path to grant itself a higher role or broader module visibility, since that action requires the admin-level permission it doesn't have in the first place. This is the same "checked centrally, not per-screen" pattern applied to the permission system's own configuration.

What happens to my organization's data if we stop using SAVHN entirely?

Data retention and export practices after account closure are exactly the kind of concrete operational detail worth confirming directly through /book-demo before you commit, since a general FAQ answer isn't the right place to state a specific policy that carries real consequences for your organization's records.

Does SAVHN's security model change for larger enterprise deployments, or is it the same for every organization?

The core mechanisms described here — tenant isolation by organizationId, centrally-enforced role and module entitlement, AES-256-GCM credential encryption, real-time session revocation — apply uniformly regardless of organization size, since they're structural rather than a tier-gated feature. Specific enterprise-level requirements beyond these mechanisms, such as a formal compliance certification, are the kind of additional detail worth a direct conversation through /book-demo.

Curious to see role-based access and encrypted credentials in action rather than take this FAQ's word for it? Start a 7-day free trial — no card required — and configure the modules you want to evaluate through the Visual Pricing Configurator. For anything specific to your organization's compliance or security requirements, reach out to the developer team directly.

SAVHN Security & Data: Frequently Asked Questions