CyberIQ holds itself to the security expectations of the customers who layer it onto their stack. Here’s the detail — data residency, encryption, multi-tenant isolation, identity, retention, compliance posture, and how to reach our security team.
Customer data lives in the region you choose when your tenant is created and does not leave that region without an explicit, customer-initiated configuration change. Two regions today — Frankfurt for the EU default and Virginia for US-resident customers.
All new tenants default to the EU region. Database, file storage, edge compute and telemetry remain in EU infrastructure under our managed-Postgres provider’s Frankfurt presence. GDPR-resident by default; no transfer to the US unless the tenant administrator opts in to a US tenant at sign-up.
US-resident customers can elect Virginia at tenant creation. Once chosen, the region is fixed for the lifetime of the tenant. Cross-region migration is a deliberate, contracted operation — never automatic, never silent, never as a result of routine platform work on our side.
We rely on industry-standard providers for the encryption layer and configure to their strongest settings. Where the provider supports stricter posture than the default, we take it.
All client traffic to cyberiq.cc and the platform API is terminated over TLS 1.3. Older protocol versions and weak cipher suites are disabled at the edge. HSTS is enabled for the production domain.
The underlying Postgres tier and object storage are managed by an industry-standard provider with AES-256 encryption on disk. Backups are encrypted with the same posture. Customer file uploads (avatars, report exports) inherit the same encryption.
Row-Level Security is enabled on every table that carries customer data. Cross-tenant reads are denied at the database layer, not at the API surface — meaning a bug in a route handler cannot grant access to another organisation’s rows.
Every table that stores profile, organisation, session, telemetry, results, or policy data has RLS enabled and a deny-by-default posture. Migrations that introduce new tables are required to ship with RLS policies as part of the same change.
Platform Admin / Org Owner / Manager / Player. Roles are derived from organisation membership and evaluated inside RLS policies — the same policy decides what an Org Owner can see and what a Player cannot. The frontend cannot loosen this; the API surface cannot loosen this.
Tenant isolation is enforced by the database row policy, not by an application filter on top of an open query. A misrouted request, a logic bug, or a stolen JWT cannot return another tenant’s rows — the wall is one layer deeper than the API.
A typical policy from the live schema: a row in profiles is visible to a caller only if the caller is a member of the organisation that owns that profile. There is no escape hatch in the API layer above.
Representative policy. The full set is reviewable under a signed engagement and is regression-tested by an internal RLS assertion pack on every release.
Enterprise customers get federated identity and automated provisioning. Standalone customers get a passwordless flow that’s simpler than rolling your own. Multi-factor is available on every tier.
Federate identity with your IdP and let the platform reflect joiners, movers and leavers automatically. No shadow user lists. No quarterly reconciliation spreadsheet.
Passwordless by default — a one-time link to the registered email address. Password sign-in is supported for customers whose policy requires it. Either way, multi-factor is available.
We hold the minimum data we need to evidence competency. Session-level telemetry rolls off on a default 365-day window; aggregates that have been anonymised are kept for model calibration.
Session-level telemetry — question responses, timing, miss-tracking, score deltas — is retained on a 365-day rolling window. After that, the row-level data is purged. The aggregate Cyber IQ Score continues forward.
Enterprise tenants can tighten or extend retention to match their internal records policy. Common windows are 90 days, 180 days and 730 days. Configured in the admin surface; effective on the next nightly roll.
A written request from a verified org admin triggers a hard delete of the named subject’s personal data within 30 days. GDPR Article 17 right-to-erasure; mirrored for CCPA where applicable. The request and its completion are logged in the audit trail.
Two things are easy to conflate: the audit evidence CyberIQ produces for our customers, and the audits we run on ourselves. The first is what the product does. The second is where we are on our own roadmap. We split them here so you can see both clearly.
CyberIQ is designed to produce the per-employee competency evidence your auditors are looking for. Mapped 1:1 to:
CyberIQ itself is not yet third-party audited. Here’s honestly where we are:
The complete list of processors that may touch customer data on our behalf. Reviewed and updated quarterly; material changes communicated in advance to tenant admins.
List complete as of today. The current version is always available at /sub-processors.
We follow a 90-day coordinated-disclosure window. Send a clear write-up and a reproducer to the inbox below; you’ll hear back within two business days. We don’t run a paid bug bounty yet, but we credit researchers in our hall of fame once a finding is remediated and disclosed.
Talk to Sales. We’ll set up a security-led call with the people who run this platform day-to-day — not a deck.
Security inbox · 2-business-day response · 90-day disclosure window