Security

VartaDesk is a production, multi-tenant SaaS CRM that handles customer contact data, message content, and messaging provider credentials. This page describes the security controls the platform is engineered around. It is a trust overview, not a substitute for a signed security addendum or the Data Processing Addendum.

The platform separates tenant-owned data from platform-level data, and routes asynchronous work (message sends, webhooks, automation, follow-ups) through durable queues processed by a dedicated worker, rather than performing them inline in request handlers. This keeps a slow or failing downstream provider from blocking the request path or leaking work across tenants.

Messaging and channel provider API keys (WhatsApp, SMS, RCS, email, and AI provider credentials) are encrypted at rest using AES-256-GCMwith a unique 96-bit nonce per encryption, via a dedicated encryption service, before they are persisted. Credentials are never logged and never returned to the client in plaintext. Settings APIs expose a masked or “configured” indicator only.

Data in transit is protected with TLS (HTTPS) between your browser or integrations and the VartaDesk API. Application encryption keys are supplied from the environment, not stored in source control. Rotating the application encryption key invalidates ciphertext written under the previous key, so rotation is a planned operations event rather than an automatic cadence we publish here.

Access within a tenant is governed by three roles — Super Admin, Admin, and Agent — enforced through route guards and permission checks on the server, not only by hiding controls in the UI. Agents are scoped to their own leads and conversations. Platform-administration capability is never reachable from a tenant-facing route.

Sign-in uses email and password. Sessions use a short-lived access token (15 minutes by default) and a refresh token (14 days by default). VartaDesk does not currently offer single sign-on (SSO) or enforced multi-factor authentication (MFA) as a platform control.

Inbound webhooks from messaging providers are verified against the provider's signature before the payload is trusted. Webhook handlers are designed to be idempotent so provider retries do not double-process an event or double-count usage. Inbound lead-ingestion API keys are matched by a hashed key rather than a plaintext comparison.

Production traffic is served over HTTPS. Sends, webhooks, automation, and follow-ups run through durable queues and a dedicated worker so a downstream provider outage does not take down the request path or mix work across tenants.

We do not currently publish a numbered uptime SLA or a public status page. For an incident affecting your workspace, contact us at the address below. Document and media files are stored with Amazon S3; see the Sub-processors page.

VartaDesk does not currently claim a third-party security certification such as SOC 2 or ISO 27001, and this page is not an audit attestation. How we handle personal data as a processor is described in the Privacy Policy and the Data Processing Addendum. Vendors we use to deliver the service are listed on Sub-processors.

If you believe you have found a security vulnerability in VartaDesk, please report it to info@sevendmobility.com with enough detail to reproduce the issue. We ask that you do not publicly disclose a suspected vulnerability until we have had a reasonable opportunity to investigate and respond. We do not currently run a public bug-bounty program.

We may update this Security page as the platform's architecture, controls, or compliance posture evolve. Material changes will be reflected here with an updated “Last updated” date.

For security questions, or to request a customer-facing security questionnaire response, contact us: