> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getsmartalex.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Trust & Security
> How SmartAlex protects customer data on a multi-tenant B2B voice AI platform: encryption, tenant isolation, least-privilege access, incident response, and data retention.
SmartAlex is a multi-tenant, business-to-business platform on which our customers configure AI voice agents that place and receive calls, run campaigns, manage contacts, and view analytics. Because the platform records and transcribes voice, we design our controls for data that can be sensitive by nature, and we secure the application, the database, and the infrastructure beneath them while our customers secure their own accounts, users, and the lawfulness of their calling.
This page is a summary written for security, privacy, and procurement teams. The authoritative document is the [SmartAlex Trust and Security Overview](https://getsmartalex.com/legal/smartalex-trust-and-security). Where this summary and the full document differ, the full document prevails. Current version 1.1, effective 1 June 2026.
## Security at a glance
| Area | What we do |
| --------------------- | -------------------------------------------------------------------------------------------- |
| Encryption in transit | TLS 1.2 or higher, with HTTP Strict Transport Security on our web origins |
| Encryption at rest | AES-256-GCM, with an authenticated, envelope-encrypted vault for application secrets |
| Tenant isolation | Row-level security enforced at the database layer, so one tenant cannot reach another's data |
| Access control | Least privilege, multi-factor authentication, quarterly reviews, same-day offboarding |
| Voice and AI content | Never used to train our models, and excluded from our AI providers' model training |
| Monitoring | Application, infrastructure, and access logging with anomaly detection and audit trails |
| Incident response | Documented runbook, with customer notification without undue delay |
| Backups | Daily, encrypted, point-in-time recovery, stored in independent regional storage |
| Data residency | Hosted in the region named in our subprocessor list, with backups in the same region |
| Compliance posture | Working towards SOC 2 Type II readiness; we do not overstate our current position |
## Shared responsibility
Security on the platform is shared. We secure the platform and the infrastructure it runs on. Customers secure their own use of it: their account and users, their credentials and API keys, the lawfulness of their calling and recording, and the data they choose to load. For call content and contact data we act as our customer's processor and act on documented instructions. For account, billing, security, fraud-prevention, and product-analytics data we act as an independent controller.
## Organisational and technical measures
Connections between customer browsers, mobile apps, and the platform are encrypted with TLS 1.2 or higher using modern cipher suites, and HTTP Strict Transport Security is applied to our web origins. Connections to our subprocessors and internal service-to-service traffic are encrypted in transit as well. Customer data at rest is encrypted with AES-256-GCM through our infrastructure providers' storage-layer encryption, and backups use the same primitives. Application secrets are held in an authenticated encryption vault with envelope-encrypted keys, are never stored in source code or written to logs, and are injected into runtime only at deploy time.
Customer access is governed by per-tenant, role-based access control, and each organisation manages its own roles. Cross-tenant access is structurally prevented by row-level security policies enforced at the database layer, so one customer's queries cannot reach another customer's data even if an application-layer error occurs. Tenant isolation is a primary control and is exercised in our testing. Access by our own personnel follows least privilege: production access is limited to a small set of named engineers, gated behind multi-factor authentication, logged with the operator's identity and the records accessed, reviewed quarterly, and revoked on the day someone leaves. We access customer data only to deliver the services, troubleshoot a specific issue, prevent or address fraud or abuse, or comply with law, and we do not use the content of calls or transcripts to train our own models.
Customer authentication supports email and password, OAuth single sign-on, and time-based one-time-password two-factor authentication. Passwords are stored only as salted hashes. We strongly recommend that all administrators enable two-factor authentication, and it is mandatory on some enterprise plans. Session tokens are issued under cryptographically rotating signing keys, scoped to the tenant, and expire after a period of inactivity.
Live call media travels over our real-time voice infrastructure under encryption in transit, and recordings and transcripts are stored as confidential data under the controls above. Audio and transcripts sent to our speech and language AI providers are processed to deliver the services only. Those providers are contractually bound not to use customer call content to train their models, and data sent through their APIs is excluded from model training. Where voice is used to identify an individual it can constitute biometric data, which we process only on the customer's instructions. We do not make solely automated decisions that produce legal or similarly significant effects on end users, and customers must keep the disclosure that an end user is interacting with an AI system enabled.
We log application, infrastructure, and access events and retain them for operational and security purposes, using them to detect anomalous behaviour, investigate suspected incidents, and support audit. Administrative and production-data access is recorded with the operator's identity and the records touched, and we do not write secrets or full call content to operational logs. Every code change is reviewed before it reaches production, with automated static analysis, AI-assisted review, dependency-vulnerability scanning, secret-scanning, and duties separated so the author of a change is not the only person who can ship it. Dependency scanning and static analysis run continuously, independent penetration tests are conducted periodically and before major releases, and findings are triaged by severity and tracked to closure.
We maintain a documented incident response runbook covering detection, triage, containment, eradication, recovery, and post-incident review, with roles and escalation paths defined in advance. If we become aware of a security incident affecting customer data, we notify affected customers without undue delay and in line with the timelines in our Data Processing Addendum, and we provide the information customers reasonably need to meet their own obligations. Where required, we assist with statutory notifications, including the 72 hour supervisory-authority notification under GDPR Article 33 and any notification required under POPIA. Post-incident reviews focus on systemic causes rather than individual blame, and corrective actions are tracked to closure.
The platform runs on managed, resilient infrastructure with redundancy at the database, compute, and edge layers. The database is backed up daily, with point-in-time recovery within the retention window, and backups are encrypted and stored in regional storage independent of the primary cluster. Recovery procedures are tested as part of operational drills. We monitor availability and performance, schedule planned maintenance to minimise disruption, and communicate material incidents to affected customers. Specific availability commitments, where offered, live in the applicable order form or service-level terms. Recovery-time and recovery-point objectives are available to qualified customers under non-disclosure.
We retain customer data while an account is active and as needed to provide the services, then in line with the periods below. Where customer-configurable retention is available, customers may set shorter periods. On termination, customer data is deleted or returned in line with our Data Processing Addendum, subject to limited retention required by law and to removal from backups in the ordinary backup cycle.
| Data category | Retention |
| -------------------------------- | ------------------------------------------------------------------------------------------------- |
| Account and profile data | For the life of the account, then deleted or anonymised after closure, subject to legal retention |
| Call recordings and transcripts | For the period set by the customer, or the life of the account if none is set, then deleted |
| Contacts and knowledge bases | For the life of the account, or until deleted by the customer |
| Billing and transaction records | As required for tax, accounting, and audit obligations, typically several years |
| Security, access, and audit logs | For a limited period proportionate to security and operational needs |
| Backups | For the rolling backup window, after which data ages out of backup media |
## Data residency and environment separation
Customer data is hosted with our cloud infrastructure providers in the region identified in our subprocessor list, and backups are retained in the same region, independent of the primary cluster. Cross-border transfer safeguards, including the EU Standard Contractual Clauses, the UK International Data Transfer Addendum, and the Swiss addendum, are set out in our Data Processing Addendum. Production and staging environments are strictly separated: production credentials, secrets, and customer data never flow into staging or development, and test data used in non-production environments is synthetic.
## Compliance posture
Our compliance posture is in active development, and we describe it plainly. SmartAlex does not currently hold its own SOC 2 or ISO 27001 attestation, and we never imply that it does. We are working towards SOC 2 Type II readiness. The SOC 2 and ISO 27001 reports we can reference are those of our infrastructure providers, not our own. We design and operate the platform to support customer compliance with the GDPR, the UK GDPR and Data Protection Act 2018, Singapore's PDPA, applicable United States federal and state privacy laws, and POPIA. Our Data Protection Impact Assessment, vendor risk register, subprocessor security questionnaires, infrastructure providers' SOC 2 and ISO 27001 reports, penetration-test summaries, and recovery objectives are available to qualified customers and prospects under non-disclosure.
Found a vulnerability? We welcome good-faith reports at [security@getsmartalex.com](mailto:security@getsmartalex.com). We acknowledge reports promptly, work on a coordinated-disclosure timeline, and do not pursue legal action against research within the scope of our [Vulnerability Disclosure Policy](https://getsmartalex.com/legal/smartalex-vulnerability-disclosure).
## Explore the rest of the Trust Center
Our certification roadmap, the assurance we can share, and the frameworks we map to.
How we act as processor and controller, and the terms in our Data Processing Addendum.
The third parties in our supply chain, by category and role, and how to track changes.
How we handle call content and AI outputs, disclosure, and the limits on automated decisions.
The full set of terms, notices, and policies that govern the platform.