Security

Complycheck is built for customers whose regulators ask hard questions. This page describes how we protect tenant data, our certifications roadmap, and how to report security issues.

Architecture and tenant isolation

• Row-Level Security at the database. Every tenant-scoped table is ENABLED and FORCED for PostgreSQL RLS. Policies restrict reads and writes to the current tenant context, set transaction-locally on every request. The table owner role itself cannot bypass policies.
• Three database roles. Standard application traffic uses an RLS-bound role. SuperAdmin operations use a separate role with `BYPASSRLS`. Migrations use a third role used only by the deployment pipeline. The roles are operationally distinct.
• Cross-tenant lookups are audited. Any code path that reaches across tenants uses the admin role through a clearly named helper. Every privileged operation writes to an append-only audit log with actor, action, target, before/after state, IP, and timestamp.
• Per-tenant object storage prefixes. Files are stored under a tenant-prefixed key and accessed through signed URLs scoped to that prefix. Per-tenant encryption keys are on the roadmap to enable cryptographic deletion.

Authentication and session security

• Passwords are hashed with Argon2id (memory cost 64 MiB, time cost 3, parallelism 4). New passwords are checked against the HaveIBeenPwned breach corpus using the k-anonymity range API — we never transmit the full password or the full hash.
• Session tokens are short-lived access JWTs (15 minutes) signed with EdDSA and opaque refresh tokens (7 days) stored as SHA-256 hashes. Refresh tokens rotate on every use; a previously redeemed token invalidates the entire token family — a deliberate signal-of-theft behavior.
• Every sign-in from a previously unseen device or IP subnet triggers a one-time passcode delivered to the user's email. The platform recognizes devices via a hash of the user agent, accept-language, client-supplied screen and timezone hints, and a network subnet (/24 IPv4, /48 IPv6) so mobile users on carrier ranges are not re-challenged constantly.
• Corporate-email enforcement: consumer providers are denied and accepting domains must have valid MX records. Google sign-in is Workspace-only and the hosted-domain claim is verified server-side on the ID token.

Edge protections

• All traffic terminates at Cloudflare with TLS 1.2+ (1.3 preferred), DNSSEC at the registrar, HSTS with preload, and the OWASP Core Rule Set enabled on the Web Application Firewall.
• Authentication endpoints carry an additional per-IP rate limit at the edge and an application-layer limit per user.
• The SuperAdmin interface lives on a separate origin behind Cloudflare Access with an IP allowlist and an identity-provider-enforced second factor. SuperAdmin activity never shares infrastructure or authentication with tenant users.

Operational security

• Secrets are managed through a dedicated secrets manager and rotated on a defined schedule. JWT signing keys are rotated with a grace period that keeps prior tokens valid until expiry.
• Continuous integration runs dependency audits and OWASP-ruleset static analysis on every pull request. High-severity findings block merges.
• Application logs are structured JSON. Passwords, tokens, JWTs, refresh tokens, and session cookies are redacted at the logger layer and never appear in log output.
• Every log entry, metric tag, and trace span carries tenant and user context where applicable, enabling tenant-scoped incident investigation.

Certifications roadmap

Complycheck is preparing for third-party attestations:

• SOC 2 Type II — readiness assessment in progress. We expect to begin our observation window once the platform reaches general availability. TODO: target date.
• ISO/IEC 27001 — Information Security Management System scoped to the platform's production environment. We intend to pursue certification after SOC 2 Type II is in place. TODO: target date.

Customers under regulatory pressure can request our current questionnaire responses and architecture overview by contacting [email protected].

Responsible disclosure

If you believe you have found a security vulnerability in Complycheck, please contact us at [email protected]. Our preferences:

• Tell us how to reproduce the issue.
• Give us a reasonable window to remediate before public disclosure.
• Do not access tenant data beyond what is necessary to demonstrate the issue, do not exfiltrate data, and do not disrupt the service.
• We will acknowledge receipt within 2 business days and keep you updated on remediation progress.

This contact is also published at /.well-known/security.txt per RFC 9116.

Status and incidents

Live uptime and incident history is published at status.complycheck.services. Subscribe there for notifications.