01 — Our approach
Security is treated as a continuous practice, not a checkbox. We aim for defence in depth: assume any single layer can fail and design so the next one catches it. We don't publish internal topology, version pinning, or specific thresholds — but we also don't hide behind "security through obscurity". The principles and controls below are real and honest.
02 — Encryption
- In transit — TLS 1.2 minimum, modern cipher suites, HSTS enforced on the marketing domain and dashboard.
- At rest — full-disk encryption on the underlying infrastructure.
- Database — Postgres with provider-level encryption. Sensitive columns (refresh-token hashes, 2FA secrets, webhook secrets) are additionally hashed or encrypted application-side.
- Backups — encrypted; restoration is rehearsed.
- Passwords — never stored in plaintext or with reversible encryption. We use a modern memory-hard hash with per-account salt; the operating parameters meet the OWASP recommendations current at the time of writing.
03 — Authentication and access
- Operators sign in with email and password. We rate-limit credential attempts per IP and per account.
- Two-factor authentication (TOTP) is available to every operator. Workspaces can require 2FA for all members.
- Sessions issue a short-lived access token and a refresh token with rotation on use. Compromised refresh tokens are invalidated server-side.
- API keys for the public REST API are scoped to a single workspace and can be rotated or revoked from the dashboard.
- Switching between workspaces invalidates the previous session context and re-fetches authorisation.
- Internal admin access uses a separate role hierarchy and is recorded in the audit log.
04 — Workspace isolation
- Every persistent row carries a workspace ID. Application code never queries without a workspace scope; this is enforced at the data-access layer, not just by convention.
- API requests carry an operator identity from which a workspace context is derived. Cross-workspace reads return 404 — not 403, so the existence of resources in another tenant is never leaked.
- Real-time channels (Socket.io rooms) are namespaced per workspace and per conversation. Joining a room you don't belong to is rejected before any data is emitted.
- AI features and embeddings are isolated per workspace — there is no shared vector store.
05 — Audit logging
Every state-changing operator action is recorded in an immutable audit log: sign-in, sign-out, message sent, contact erasure, workspace settings change, billing event, AI feature toggle, integration created or revoked. The log retains:
- Timestamp (UTC) at second precision.
- Actor (operator ID, IP address, user agent).
- Target (record ID, type).
- A structured payload describing the change.
Operators with the appropriate role can view the audit log inside the dashboard. The log is retained for twelve months on the live system; older entries are aggregated for forensics before being deleted.
06 — Infrastructure
- Hosted on ThemeREX-managed infrastructure via Coolify, with separate environments for development and production.
- Each service (API, dashboard, Postgres, Redis) runs in an isolated container. Inter-service traffic is on a private network; only the dashboard and widget are exposed publicly through a TLS-terminating reverse proxy.
- Databases are not directly reachable from the internet. Administrative access goes through a hardened bastion path that requires both SSH key and operator-account authorisation.
- Automated, encrypted backups are taken on a daily basis with point-in-time recovery available within the retention window.
- Dependency updates run through automated PR review (Dependabot / Renovate). Critical security patches are applied out of band.
07 — Application security
- Input validation is enforced at the API boundary via schema validators — no raw JSON ever reaches business logic.
- Database access goes through Prisma; queries are parameterised. SQL injection is structurally prevented.
- React escapes output by default. We never use dangerouslySetInnerHTML for user-generated content.
- CSRF is mitigated by token-based authentication on state-changing endpoints; cookies use SameSite=Lax and Secure.
- Content Security Policy is set on the dashboard. The widget runs in an isolated origin so a compromised host page cannot read it.
- Webhooks outbound from Leadiosa carry an HMAC-SHA256 signature so consumers can verify origin and integrity.
- Inbound webhook receivers (e.g. Freemius) verify their own provider signatures before processing.
- Rate limiting is applied per IP and per authenticated user on sensitive endpoints (auth, password reset, AI calls).
08 — Operational security
- Production access is limited to a small set of engineers; every action is audit-logged.
- Secrets live in environment variables managed by the deployment platform — never in source control.
- Pull requests require review before merging to the production branch. CI runs typecheck, lint, and tests on every change.
- Vendor management: every subprocessor is reviewed before onboarding, listed publicly, and re-reviewed annually.
09 — AI subprocessor security
When a workspace enables the AI agent or AI analytics, conversation content is sent to the configured large-language model provider. Some commitments around that:
- Platform-managed AI tokens are routed through OpenRouter, OpenAI, or Anthropic — providers whose API terms contractually exclude training on customer-provided content.
- Bring-your-own-key (BYOK) puts you in direct contract with the LLM provider; the provider's policies apply to that traffic, not ours.
- Knowledge-base embeddings are computed by the embedding provider chosen per workspace and stored in our database, not on the provider.
- AI requests are not sent for workspaces where the AI agent is turned off — the feature is opt-in.
10 — What we don't yet claim
- SOC 2 Type II — on the roadmap. Not yet attested.
- ISO 27001 — not yet certified.
- HIPAA — Leadiosa is not designed for protected health information. Do not enter PHI.
- PCI DSS — not applicable; we do not store or process card data. Freemius handles billing.
- Penetration test — internal review only at this stage; an independent third-party penetration test is planned.
We'll update this section as those statuses change rather than wait for a quarterly press release.
11 — Customer responsibilities
A secure platform still needs secure operators. Things we can't do for you:
- Use long, unique passwords and enable 2FA — especially for workspace admins.
- Limit operator seats to people who actually need access. Revoke promptly when someone leaves.
- Pick a conversation retention window that matches your legal obligations and your visitors' expectations.
- Review the audit log periodically.
- Rotate API keys when a teammate with knowledge of them leaves the team.
- If you build a custom integration with our REST API or webhooks, treat the secrets as production credentials.
12 — Vulnerability disclosure
Found something? We'd much rather hear about it before the internet does.
- Email security@leadiosa.com with a clear description, reproduction steps, and an estimate of impact. Encrypted email is welcome; PGP key on request.
- We acknowledge within 72 hours.
- We aim to patch critical issues within 7 days, high-severity within 30 days, low-severity within 90 days.
- We commit to a 90-day disclosure window from the date of initial report. We will not pursue legal action against researchers acting in good faith within that window.
- We do not currently run a paid bug-bounty program, but we credit responsible reporters in our changelog when permitted.
- Out of scope: denial-of-service testing against production, social engineering of staff, physical attacks on infrastructure, attacks that require already-compromised user accounts.
13 — Incident response
- An on-call engineer is paged automatically by our monitoring on availability incidents.
- Live availability is published on the status page; we update it as incidents progress.
- For incidents that touch personal data, we follow the breach-notification flow described on our GDPR page.
- After significant incidents we publish a post-mortem covering what happened, what we changed, and what we still owe.
Status: /status — refreshed every thirty seconds with real probe data.
14 — Contact
- Vulnerability reports, breaches, urgent security concerns: security@leadiosa.com
- Vendor questionnaires (SIG / CAIQ / VSA) and DPA requests: legal@leadiosa.com
- Privacy / data-subject requests: privacy@leadiosa.com