Security Overview

• The platform is multi-tenant: each customer has a workspace, and every data-access path is scoped to the workspace of the authenticated principal.
• Isolation is enforced in the data-access layer on every read and write. Database row-level security is implemented across the schema and enabled on deployments configured for it, so that a query without a tenant context returns nothing rather than everything.
• Global identity records — users, organisations, memberships — are addressed by identity, never by an unbounded lookup.
• Permissions are role-based, with field-level restrictions and sharing rules. An automated actor — API key, automation, agent — inherits the permissions of the principal it acts for and can never exceed them.

• In transit: TLS 1.2 or higher for all connections, with HTTP Strict Transport Security on the application.
• At rest: encryption of the database, object storage and backups by the infrastructure providers.
• Stored third-party credentials — mailbox passwords, connector headers, webhook and provider secrets — are encrypted with an envelope key held outside the database, so a database copy alone does not yield them.
• Passwords are hashed with bcrypt at a work factor of 12; we never store them in a recoverable form.
• Files live in private object storage and are served only through short-lived signed URLs.
• Payment card data never reaches our systems; it is handled by our payment processor.
• Website visitor identifiers are pseudonymous hashes from a daily rotating salt, with no IP address stored.

• Individual named accounts for all personnel; no shared production credentials.
• Production access is limited to those who need it, granted on a least-privilege basis, and revoked on role change or departure.
• Administrative and agent actions are logged with actor, time and target.
• Customer-side controls: roles, granular permissions, field-level restrictions, scoped API keys that can be revoked, and per-action approval requirements for automated actors.
• Login attempts are rate limited per account, and failures are indistinguishable from one another so that an attacker learns nothing about which addresses exist.

• Content Security Policy, a restrictive permissions policy, and same-site, HTTP-only session cookies.
• All input validated at the boundary; database access through a typed query layer rather than string-built SQL.
• Rate limiting on authentication, the public API, form ingestion and analytics ingestion.
• Secrets held in the deployment platform's secret store, never in the repository; automated secret scanning in continuous integration.
• Every change is code-reviewed and passes an automated gate suite covering type safety, tenancy, permission boundaries, data-retention and privacy invariants before it can be released.

The primary database is in the European Union (Frankfurt, Germany); object storage is in the European Union; application compute runs on a globally distributed platform with edge regions including Frankfurt, Dubai and Washington, D.C.. Providers are listed on the Subprocessors page, each operating certified data centres with their own physical security and compliance programmes.

Environments are separated between development, test and production. Production configuration refuses to start in an unsafe state — for example, with a tenancy or encryption setting that would silently weaken isolation.

• Point-in-time recovery on the primary database, with a documented recovery procedure and defined recovery point and recovery time objectives.
• Object storage is replicated by the provider.
• Restore procedures are documented and periodically exercised.
• Customers can export their own data at any time; an export is not a substitute for our backups, and our backups are not a substitute for the customer's own records.

• Security events are triaged on discovery; containment takes priority over analysis.
• We notify affected customers of a personal data breach without undue delay and within seventy-two (72) hours of becoming aware of it, as set out in the DPA.
• Notice describes what happened, what data was involved, what we have done, and what the customer should do.
• Material incidents are followed by a written cause analysis for affected customers.

• Customers can export, correct, restrict, suppress and erase personal data in their workspace without contacting us.
• Erasure takes effect immediately in the product; physical removal, including from derived stores and search indexes, completes asynchronously.
• Suppression records prevent an erased contact from being silently re-imported.
• Default retention periods are enforced by scheduled housekeeping rather than left to manual cleanup.

Report a vulnerability to start@salexhub.ai with the subject “Security”. Include enough detail to reproduce it.

We will acknowledge within two business days, keep you informed, and credit you if you wish. We will not pursue legal action against researchers who act in good faith: test only against your own workspace, do not access, modify or retain another party's data, do not degrade the service, and give us reasonable time to fix an issue before disclosing it.

We do not currently operate a paid bug bounty programme.

Stated plainly, because a security programme is judged by what it admits as much as by what it lists:

• We do not hold SOC 2 or ISO/IEC 27001 certification. Our infrastructure providers do, and their reports are available from them.
• We have not commissioned an independent third-party penetration test to date.
• We do not operate a 24/7 staffed security operations centre.
• We do not offer a contractual uptime commitment during early access; enterprise service levels are agreed separately.
• Regional data residency is configurable in the product but not yet provisioned as separate regional storage; all workspaces are currently served from the location above.

Where a requirement in this list is a condition of your purchase, tell us — some are on our roadmap and can be prioritised against a commitment.