Security and trust
An honest look at how Jwalix keeps tenant data isolated and access under control.
Multi-tenant data isolation
Every request in Jwalix is scoped to your company through a tenant identifier tied to your own workspace database, keeping your data separated from other tenants.
JWT-based session security
Sessions use JWT access and refresh tokens. The app refreshes your session silently in the background, so you stay signed in securely without repeated logins or long-lived credentials sitting idle.
Granular, module-action permissions
Access is controlled with fine-grained permission strings like jobs.edit or candidates.delete, not just broad roles, so admins can grant exactly the access each teammate needs.
Enforced at the route and the request
Permission checks are enforced on the client through route guards, and are expected to be enforced again server-side on every request, so access control does not rely on the UI alone.
Have specific compliance requirements?
Every organization's requirements are different. Rather than list generic certifications here, tell us what you need and we'll give you a straight answer about what Jwalix supports today.
Common questions
Not today, and we would rather say so plainly than imply otherwise. What exists is described on this page and is verifiable in the product: per-tenant data isolation, JWT-based sessions, and module-action permissions enforced server-side. If a formal certification is a procurement requirement for you, tell us what you need and we will give you a straight answer about timing rather than a maybe.
Each tenant's records live in their own database rather than sharing tables behind a company-ID column. The tenant is resolved from the authenticated session on every request and the connection is scoped to it, so a query cannot accidentally reach another tenant's rows even if application code is wrong.
Permissions are module-action strings such as jobs.edit, candidates.delete or reports.view, assigned per user rather than bundled into a fixed role. That means read-only access to one module and full control of another is a normal configuration, not a special case. Checks run on the API route as well as in the interface, so hiding a button is never the only thing stopping an action.
Your records remain yours. Candidate, job and application data can be exported, and because each tenant is a separate database, removing a workspace removes that workspace's data rather than filtering it out of a shared table. Ask us for the specifics that apply to your agreement.
Ask us about your specific compliance requirements
Reach out and we'll walk through your security and compliance questions directly.