--- title: "Security Overview" description: "The technical and organisational measures protecting customer data, and a plain statement of what we do not yet have." url: "https://salexhub.com/legal/security" updated: "2026-10-05" --- # Security Overview The technical and organisational measures protecting customer data, and a plain statement of what we do not yet have. Last updated: October 5, 2026 This overview describes how SalexHub protects customer data. It is referenced by Annex II of our [Data Processing Agreement](https://salexhub.com/legal/dpa) and is intended to answer most security questionnaires without further correspondence. ## 1. Architecture and tenancy - 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. ## 2. Data protection - **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. ## 3. Access control - 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. ## 4. Application security - 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). ## 5. Infrastructure and location 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](https://salexhub.com/legal/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. ## 6. Backups and continuity - 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. ## 7. Incident response - 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](https://salexhub.com/legal/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. ## 8. Privacy tooling - 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. ## 9. Responsible disclosure Report a vulnerability to [start@salexhub.com](mailto:start@salexhub.com?subject=Security) 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. ## 10. What we do not claim 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. --- The same page for people: https://salexhub.com/legal/security. Index of this site for agents: https://salexhub.com/llms.txt