Security at Leadiosa

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.

• 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.

• 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.

• 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.

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 six months on the live system; older entries are aggregated for forensics before being deleted.

• Hosted in the EU on Hetzner data centres in Helsinki, Finland and Nuremberg, Germany, 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 daily and shipped to off-site object storage, with restoration available within the 30-day retention window.
• Dependency updates run through automated PR review (Dependabot / Renovate). Critical security patches are applied out of band.

• 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).

• 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.

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 configured embedding provider (OpenAI by default) 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.

• 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.

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.

Found something? We'd much rather hear about it before the internet does.

• Email legal@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.

• 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.

Vulnerability reports, breaches and urgent security concerns, vendor questionnaires (SIG / CAIQ / VSA), DPA requests, and privacy / data-subject requests all go to legal@leadiosa.com.