KP
GOES X-Ray
Run Queue
Idle

Portfolio TIV

VaR 99.5%

TVaR 99.5%

Capital Headroom

⚠ MODELED — MODEL CARD v0 (DRAFT) · NOT INDEPENDENTLY VALIDATED

Trust Center

Security, reliability, compliance, and operational readiness for QRS Terminal.

Compliance Roadmap

Honest about what's done, what's in audit, and what's planned.

  • SOC 2 Type I

    EvidenceCompleted

    Type I readiness achieved. Policy set, access controls, change management, and monitoring in place.

  • SOC 2 Type II

    In Progress

    In audit window with designated auditor (track selected Q1 2026). Type II report expected post six-month observation window.

    Target: 2026-Q3

  • Penetration Test (External)

    Planned

    Annual external pen test to be commissioned post-Series A.

    Target: 2026-Q3

  • Vulnerability Scanning (Continuous)

    EvidenceCompleted

    Dependabot enabled; pip-audit + npm audit run in CI on every PR.

  • Vendor Security Review Packet

    EvidenceIn Progress

    Standard vendor security questionnaire responses + DPA template prepared. Available on request via support@qrsrisk.com.

  • GDPR / Data Processing Agreement

    In Progress

    DPA template drafted, legal review queued. Tenant data export endpoint planned for next sprint.

    Target: 2026-Q2

  • Backup & Disaster Recovery

    In Progress

    Database backups enabled; first restore drill executed 2026-07-02, quarterly cadence adopted. Drill results and detailed recovery posture (frequency, retention, RPO/RTO) are shown to signed-in customers.

    Target: 2026-Q3

Security Controls

Maps to SOC 2 Common Criteria categories.

Encryption

  • Encryption at Rest

    AES-256 for PostgreSQL (Fly managed), S3 ledger objects (SSE-S3), and Redis persistence. KMS-backed envelope encryption for sensitive fields.

    In Place
  • Encryption in Transit

    TLS 1.3 enforced on api.qrsrisk.com and app.qrsrisk.com. HSTS enabled. Internal service mesh TLS for backend-to-backend.

    In Place

Access Control

  • Role-Based Access Control (RBAC)

    Admin / Modeler / Analyst / Approver / Viewer roles. Per-user rate limits. Tenant-scoped data access on every authenticated endpoint.

    In Place
  • Multi-Factor Authentication (MFA)

    Password reset flow live. TOTP MFA enrollment + verification queued. Required-MFA tenant policy planned.

    In Progress
  • SSO / SAML

    OIDC SSO via Auth0 configured in production, with per-tenant SSO config and client secrets encrypted at rest. SAML available via Auth0 federation. Social sign-in staged behind flags (off by default).

    In Place

Key Management

  • API Key Rotation

    SHA-256 hashed at rest. Create / list / rotate / revoke endpoints. Lifecycle events logged to audit trail.

    In Place
  • Webhook Signing

    HMAC-SHA256 signature on every webhook delivery for verifiable provenance.

    In Place

Audit + Monitoring

  • Immutable Lineage Ledger

    Every run input, model version, parameter change, approval, and output hashed and chained under SHA-256. Hardware provenance (Braket job IDs) captured.

    In Place
  • Security Audit Log

    Login attempts, API key lifecycle events, and data exports are recorded with actor, IP, user-agent, and outcome. Queryable per-tenant via /audit/trail and the Enterprise Admin console.

    In Place
  • Application Monitoring

    Sentry frontend (capture + release tracking). Structured JSON logging on backend. Synthetic monitor every 30 min on auth journey.

    In Place

Network

  • IP Allowlist

    Per-tenant IP allowlist for sensitive endpoints. On the Series A roadmap.

    Planned

Identity

  • SCIM Provisioning

    Will accompany SSO/SAML work for enterprise lifecycle management.

    Planned

Subprocessors

Third-party data processors. Required by GDPR Article 28.

SubprocessorPurposeData TypeRegionDPA
Fly.ioApplication + database hostingAll tenant data (encrypted at rest)US-East (IAD) Signed
AWSObject storage (S3) + Braket QPU accessLedger PDFs, ELT files, quantum job metadataUS-East-1 Signed
IonQ (via Braket)Quantum Processing Unit executionAnonymized quantum circuit metadata onlyUS Signed
Auth0Authentication (enterprise SSO / OIDC)User identities: email, name, login metadataUS Signed
UpstashManaged Redis (task queue, rate limits, live events)Queued engine-run payloads (incl. customer exposure data), rate-limit counters, event streamsUS Signed
SentryFrontend error monitoringStack traces (PII scrubbed)US Signed
ResendTransactional email (approvals, invites)Email addresses, message bodiesUS Signed
GitHub ActionsCI/CD pipeline + synthetic monitoring + daily database backup jobBuild metadata; the daily encrypted database backup transits the backup runner en route to S3US Signed
NOAA SWPCSpace weather telemetry (Kp, X-ray)Public catastrophe telemetry onlyUS Public data
USGSEarthquake telemetryPublic catastrophe telemetry onlyUS Public data
Planet LabsSatellite imagery (per-customer opt-in)Geocoordinate queries, no PIIUS Signed

Not listed above: Stripe (payments). Stripe receives billing-contact details (e.g. account email) and payment data as an independent controller — it does not process customer portfolio data on QRS’s behalf, so it is not an Article 28 sub-processor. Noted here for transparency.

Model Cards

Per-peril documentation: intended use, data sources, performance, limitations, and verification status. Procurement and model-validation reviewers start here.

  • Florida hurricane (US-FL coastal)
    In Progressv0 DRAFT

    Hybrid quantum-classical FL hurricane peril model. Numeric claims pending independent K=30 benchmark-lab signoff.

Other perils (CA wildfire, EQ, flood) are on the roadmap. Full model cards are available under NDA / public release pending.

Reproducibility Seal

Every engine run carries a cryptographically signed seal you can verify offline. The seal records the engine commit, the exact dependency set, the inputs, and the outputs — all bound by an ECDSA P-256 signature from QRS’s AWS KMS key.

Per-run seals

One seal per engine run. Verify the signature against the QRS KMS public key and check the lineage chain head + output hash on your end. The badge on each run-detail page surfaces the current seal status.

Release-bundle meta-seals

Every engine release tag (engine-v*.*.*) also produces a release meta-seal — one signed JSON document that binds the K=30 benchmark-lab protocol run to that specific release. Verifying a meta-seal verifies every constituent per-run seal in one call.

# The open-source verifier (qrs-replay) ships with the gated GA rollout;
# it is not publicly installable yet. Once published, verifying a meta-seal
# is a single command:
qrs-replay verify-meta-seal --meta-seal ./engine-v1.0.0.json \
    --api-token "$QRS_API_TOKEN"
# Expected: META_SEAL_VERIFIED tag=engine-v1.0.0 constituent_runs=30 rollup=sha256:...
  • First signed release meta-seal ships with engine-v1.0.0. Until then, see the verification spec for how meta-seals are verified.

Support & Vendor Reviews

Standard vendor security review packets, DPA templates, SOC 2 Type I report, and the latest audit attestation are available on request.

support@qrsrisk.com