Trust

Security

The controls we run to keep your data — and ours — safe.

  • TLS everywhere

    Status: implemented

    All API, CDN, and dashboard traffic is served over TLS 1.2+.

  • Encryption at rest

    Status: implemented

    Postgres and object storage volumes are encrypted at rest.

  • Strict tenant isolation

    Status: implemented

    All control-plane data is scoped by organisation/workspace membership and role checks.

  • MFA and RBAC

    Status: implemented

    Role-based access control (owner/admin/publisher/reviewer/read-only) with MFA available on accounts.

  • Signed site configurations

    Status: implemented

    Site configs are signed with asymmetric ECDSA P-256 / SHA-256; the loader verifies and fails closed.

  • Signed consent receipts

    Status: implemented

    Every consent receipt is signed with ECDSA P-256 / SHA-256 as it is recorded, and you can check one without us: export it from Reports, fetch our public keys from /v1/public/receipt-signing-keys, and verify. The signature covers the receipt's canonical form — all object keys sorted ascending, serialised as JSON with no whitespace, encoded as UTF-8. Receipts recorded before signing was introduced are permanently unsigned and are labelled as such; we do not sign them after the fact, because back-dating a signature onto an old record is exactly the thing a receipt exists to rule out.

  • Key rotation

    Status: implemented

    The config-signing key, the receipt-signing key and the HMAC subject key are rotatable; see the key-rotation runbook. Retired receipt-signing public keys stay published for ever, so a receipt signed under an old key can still be verified.

  • Rate limiting and WAF

    Status: implemented

    Public ingestion and config routes are rate limited and fronted by a WAF.

  • Dependency scanning

    Status: implemented

    Every CI run executes pnpm audit and osv-scanner against the dependency graph.

  • Software bill of materials

    Status: implemented

    CI generates a CycloneDX SBOM artifact for each build.

  • CSP-compatible runtime, no eval

    Status: implemented

    The browser runtime uses no eval or unsafe dynamic code and is CSP-compatible.

  • Immutable audit logs

    Status: implemented

    Privileged actions write to an append-only audit log that rejects updates and deletes at the database.

  • Database backups and disaster recovery

    Status: implemented

    Automated Postgres backups with point-in-time recovery; restore drills per the backup/DR runbook.

  • Incident-response process

    Status: implemented

    A documented incident-response runbook covers severity, on-call, comms, and status-page updates.

  • Penetration testing

    Status: planned

    Independent penetration testing is planned before general availability; not yet completed.

  • Data retention controls

    Status: implemented

    Retention windows are configurable; an automated job deletes expired consent receipts.

  • Regional hosting options

    Status: in_progress

    EU hosting is available; additional regions are on the roadmap.

  • Subprocessor management

    Status: implemented

    A maintained subprocessor list with change notification.

  • DPA and Standard Contractual Clauses

    Status: implemented

    A DPA with controller/processor roles and SCC/IDTA reliance for transfers is available.

  • DSAR and deletion workflow

    Status: implemented

    An audited per-subject erasure workflow keyed by anonymous subject key (MVP scope; not full cross-system orchestration).

  • Status page

    Status: implemented

    A public status page reports live component health.

  • Public security documentation

    Status: implemented

    This page.

Security · ConsentCook