Skip to main content

Compliance

Krios is built on top of certified infrastructure (Vercel, Neon, Supabase). The application-level controls below combine with those provider certifications to give a comprehensive audit posture.

For the canonical security review document, see docs/SECURITY-MODEL.md in the repo. This page is a high-level overview.

GDPR​

  • Audit logging covers every mutation, supporting the right to access and rectification.
  • Soft delete + physical delete supports the right to erasure (Article 17). Soft delete preserves the row for recovery; physical delete is what removes data from the live database.
  • Data export via the management API (/api/v1/projects/{p}/entries), the GraphQL delivery API, and krios content export.
  • PII flagging via FieldDefinition.isSensitive (V2 — masking + restricted export; V3 — full PII handling).
  • DPA template not yet published; customer-specific DPAs negotiated case-by-case.

SOC 2​

  • Infrastructure providers (Vercel, Neon, Supabase) are SOC 2 Type II certified. Their reports are available under NDA on request from the providers.
  • Krios application controls are documented in docs/SECURITY-MODEL.md.
  • Formal SOC 2 audit of Krios itself has not been conducted; targeting late 2026.

HIPAA​

  • Krios is not currently HIPAA compliant.
  • Compliance would require BAAs with Vercel, Neon, and Supabase, plus additional access controls (audit log of every read of a sensitive field, encryption keys not held by the platform, restricted geographic data residency).
  • Customers handling PHI should not use Krios for PHI today.

ISO 27001​

  • Krios is not ISO 27001 certified.
  • Many controls in the security model align with Annex A (access control, cryptography, operations security, communications security, supplier relationships) but a formal gap analysis has not been performed.

Other standards​

  • PCI DSS — Krios does not process cardholder data and is out of scope.
  • FedRAMP / IL5 — not in scope. Krios is not deployed in GovCloud or equivalent.

Data residency​

Each project records a dataRegion field surfaced via the admin Settings UI and, when a region is configured, the X-Krios-Data-Region header on /api/v1 responses — resolved from the project's dataRegion, falling back to the KRIOS_DATA_REGION deployment default, and omitted when neither is set. Routing is provider-driven: Neon's region (selected at database creation) bounds the database; Supabase Storage's region bounds object storage; Vercel's serverless runs in the configured region.

Data does not cross region boundaries within a single Neon database or Supabase Storage project. Customers needing region pinning beyond provider defaults should request a dedicated tenant — see Multi-tenant.

Encryption​

SurfaceAt restIn transit
Postgres (Neon)AES-256 (provider-managed)TLS 1.3 (sslmode=require)
Object storage (Supabase)AES-256 (provider-managed)HTTPS
Applicationbcrypt cost 12 (passwords), SHA-256 (API key hashes), AES-256-GCM (per-tenant DB URLs in V3)TLS 1.3
Webhooksn/aTLS 1.3 + HMAC-SHA256 over body (sha256= header)

Disclosure​

  • Security disclosures: security@konabos.com.
  • Customer security questionnaires: same address.
  • 90-day coordinated disclosure window before public release of vulnerability details.

Audit log​

Append-only audit_logs table. The schema and API expose no update or delete path for these rows. Every mutation is recorded with:

  • userId (or null for system / API-key-only operations)
  • apiKeyId (when authenticated by an API key; in metadata)
  • action, entityType, entityId
  • Before / after JSON snapshots
  • metadata (request ID, IP, user agent, action-specific fields)
  • createdAt (server clock)

Audit logs cannot be updated or deleted through the API or admin UI.