Security Overview

• The platform is multi-tenant: each customer has an organization, and every data-access path is scoped to the organization of the authenticated principal.
• Isolation is enforced in the data-access layer on every read and write. Database row-level security policies, under which a query without a tenant context returns nothing rather than everything, are written across the schema and switched on in staging since 24 September 2026, but not yet in production.
• Global identity records (users, organizations and memberships) are addressed by identity, never by an unbounded lookup.
• Permissions are role-based, with field-level restrictions and sharing rules. An API key never holds more than its creator holds at the time of use, and the Agent in a conversation works within the permissions of the person using it. Workflows and scheduled agents act under their own identity, with rights an administrator grants, and every act is logged.

• In transit: TLS on every connection, with HTTP Strict Transport Security on the application and on this website.
• At rest: encryption of the database, object storage and backups by the infrastructure providers.
• Stored third-party credentials, such as mailbox passwords, connector headers, and 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 through signed links that expire after 60 seconds, issued after a permission check. Images on published web pages and the logo on quotes and invoices are public by design.
• 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.

• Production access is held by the people who operate the service and is revoked when their role ends.
• In the product, administrative and agent actions are logged with actor, time and target.
• Customer-side controls: roles, granular permissions, field-level restrictions, API keys that can be revoked (the public API itself is not live yet), and approval rules that hold an act until the right people approve it.
• Login attempts are limited per account, and every failed login gets the same answer. Registration still says whether an address already has an account, and is rate limited.

• Protection against framing, 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 sign-in, registration, password reset, form ingestion and analytics ingestion.
• Secrets are held in the deployment platform's secret store.
• An automated suite of gates covers type safety, tenancy, permission boundaries, data retention and privacy invariants. Passing it is not yet required before a release (see below).

The primary database is in the European Union (Frankfurt, Germany); object storage is in the European Union; the application runs in Frankfurt, Germany, behind a global edge network that routes and caches requests and checks sign-in sessions close to the visitor. Providers are listed on the Subprocessors page, each operating certified data centres with their own physical security and compliance programmes.

Production and staging run on separate databases with separate encryption keys. The application refuses to run with row-level security switched on but without the restricted database role, and refuses to store a credential in plain text when no encryption key is configured.

• Point-in-time recovery on the primary database, with a documented recovery procedure.
• Object storage is replicated by the provider.
• 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 and erase personal data in their organization without contacting us, and can mark a contact as not to be emailed, called or marketed to.
• 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.

Report a vulnerability to start@salexhub.com 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 organization, 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; enterprise service levels are agreed separately.
• Changes are not yet required to pass a second person's review or the automated gates before they are released.
• Our recovery procedure has not yet been exercised in a restore drill, and recovery point and recovery time objectives are not yet defined.
• Database row-level security is switched on in staging but not yet in production; isolation there rests on the data-access layer.
• Default retention periods are not yet enforced automatically: the scheduled housekeeping that would enforce them is not running.
• Every organization's data is stored in the European Union. The product records a data region for each organization, but only the EU region is provisioned, and a customer cannot choose another yet.

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.