Security & compliance

Authentication

• Access tokens are short-lived JWTs (15 minutes), verified at the API gateway; refresh tokens live 30 days idle and 90 days at most, rotate on every use, and are stored in an HttpOnly, Secure, SameSite cookie. Reuse of a rotated refresh token revokes the whole chain.
• Signing keys rotate every 90 days with an overlap; public keys are published at /.well-known/jwks.json.
• Permissions are not embedded in tokens: they are read per request, so a role change takes effect immediately, and any session can be revoked centrally.
• Two-factor authentication (TOTP) can be optional, required for Owners and Admins, or required for everyone. Single sign-on with Google Workspace and Apple is available on every plan. SAML 2.0, passkeys and SCIM provisioning are planned and not available yet.
• API keys are shown once, stored as a SHA-256 hash, scoped from a closed catalogue, bounded by their owner’s permissions, and revocable instantly. See Authentication.
• Sign-in is rate-limited per IP and per e-mail; ten failed attempts lock the account for 30 minutes; failed attempts from one IP address are counted and recorded, but by default they do not block that address. Every sign-in, failure, refresh, permission change and admin action goes to the audit log.

Tenant isolation

Every row in every service carries the account it belongs to, and every query is filtered by it automatically; turning the filter off requires an explicit, allow-listed call used only by cross-tenant staff operations and covered by tests. Per-site roles add a site filter on top. A request for another account’s resource answers 404, never 403, so that IDs cannot be enumerated. Every write endpoint uses a strict field allow-list. A cross-account access test is mandatory for every new endpoint.

The X-Account-Id header on every request is checked against the token, so a client bug or a replayed token can never silently read another tenant.

Encryption

TLS 1.2 or newer to every public endpoint, mutual TLS between services, TLS to every datastore, encrypted volumes at rest, and per-account envelope encryption for sensitive fields. Public certificates are issued and renewed automatically; internal certificates are short-lived.

Secrets

All secrets, including your BYOK provider keys and webhook secrets, live in a dedicated secrets manager, encrypted, scoped per service, and audited. Nothing is in source control (enforced by scanning before every commit) or in container images (checked in CI). Developers have no production secret access by default; break-glass access needs two approvals, is short-lived and is logged to a channel that cannot be silenced.

Webhooks

Outbound deliveries are signed with HMAC-SHA256 over the timestamp and raw body, carry a nonce and an event ID, are rejected outside a five-minute window, and retry with backoff into a dead-letter queue. Secrets rotate with an overlap window and can be revoked instantly. Inbound provider webhooks are verified with each provider’s scheme before anything is processed. Details: Webhooks.

Rate limiting

Four layers: DDoS and bot protection at the edge network, per-IP limits at the reverse proxy, per-account and per-identity token buckets at the API gateway, and domain limits inside services. Limits are on the API overview.

Audit

Every mutation is written to an append-only, hash-chained audit log with two retention classes: general events and compliance events (data-subject requests, breach, sub-processor and KYC records). The classes are assigned when an entry is written; the log cannot be edited or deleted by anyone, and an automatic clean-up by class is not yet in operation. Owners and Admins can filter and export it. Passwords, tokens and keys are never logged; the logging layer redacts known-sensitive keys.

Data protection

• GDPR, UK GDPR, CCPA and LGPD data-subject requests (access, export, erasure) are received and tracked in the compliance console with deadlines. Erasure is carried out by RolChat staff, and the request is closed only when they confirm it; an automatic erasure across every module is not available yet.
• Data residency: data is stored in the EU. The region is not chosen by country at sign-up; the region setting in the account settings is only recorded and does not move data yet.
• Retention by plan: 1, 2 or 3 years. Deleting a conversation or a contact hides it until the end of that term; deleting an account is a request with 30 days to cancel, after which staff erase the data; an unpaid account is kept 90 days and then erased. The automatic clean-up that enforces these terms is being rolled out.
• A Data Processing Agreement, sub-processor list, privacy policy and cookie policy are published on rolchat.com; the DPA is accepted at sign-up.
• Breach notification within 72 hours as required by GDPR Article 33.

Vulnerability management

Dependencies are monitored continuously; lock files are committed; base images are pinned by digest; CI actions are pinned by commit. A third-party penetration test is scheduled annually from beta, covering the API, the widget and the public pages, plus an assumed-breach internal scenario. A private bug bounty follows at general availability. Report security issues to security@rolchat.com.

Availability

The platform runs on multiple nodes with automated failover for stateless services and managed replication for databases. Uptime targets by plan are set in your agreement.

Incident response

Runbooks for every service, an on-call rotation, an external pager that works when our own infrastructure does not, and customer notification obligations built into the process.