Trust Center / SOC 2 readiness
SOC 2 readiness
The controls Prova operates today, mapped to the SOC 2 Trust Services Criteria. Use it to pre-fill a vendor review while the formal audit is underway.
Status
Readiness, audit not startedProva is not SOC 2 attested yet. This is a readiness self-assessment: the controls below are in place and operating today, and they are what a Type 1 audit would examine. We begin that audit with our first design partner. We will not claim a certification we do not hold.
Scope
Security (the Common Criteria) is required in every SOC 2 engagement. We also map Availability, Confidentiality, Processing Integrity, and Privacy, because Prova operates controls in each. Processing Integrity is the strongest: a signed, tamper-evident receipt for every AI decision is the control the whole product is built around.
Common Criteria (Security)
Control environment
Least-privilege RBAC with five defined roles and a permission matrix. Privileged changes need a second person.
Evidence: Five roles (owner, developer, security, audit, contractor) in lib/auth/roles.ts; the two-person approval gate on policy changes in lib/policies/versions.ts.
Communication and information
Security posture, processing terms, and subprocessors are published. Every privileged action is recorded.
Evidence: This Trust Center, the DPA, the subprocessor list, and the self-audit log in lib/audit/operational.ts.
Risk assessment
A vulnerability-disclosure channel is open, and the product itself scores AI risk for customers.
Evidence: security.txt and security@cobound.dev; the AI Risk Score methodology in lib/risk/score.ts. A formal annual company risk assessment is in progress.
Monitoring activities
Per-request latency and error rates are recorded against published SLA targets, with a public status surface.
Evidence: SLO recorder in lib/slo/recorder.ts, aggregation in lib/slo/aggregate.ts, surfaced at /status and /api/v1/status.
Control activities
Permissions are enforced on every dashboard page and every mutating action. Policy changes require a separate approver.
Evidence: ensurePermission / requirePermissionAction in lib/auth/guard.ts; the two-eyes promotion gate (TwoEyesViolationError) in lib/policies/versions.ts.
Logical and physical access
Row-level security on all tables, hashed API keys, role-scoped keys, TLS in transit, AES-256 at rest, and an optional HSM/KMS signing backend.
Evidence: RLS on every table; API keys stored as SHA-256 hashes only; the audit role is read-only; HSM/KMS signing in lib/receipts/signers/kmsHttp.ts. Physical security is inherited from Vercel, Supabase, and Render (each SOC 2 attested).
System operations
Tamper-evident receipts detect integrity problems, SLO sampling detects degradation, and the self-audit log records operations.
Evidence: Ed25519-signed receipts in lib/receipts/sign.ts; SLO sampling on ingest and gateway-check; the operational audit trail. A formal incident-response runbook is in progress.
Change management
Customer policy changes go through a pending-review then approval gate. Code and schema changes are version-controlled and reviewed.
Evidence: Policy versioning in custom_policy_versions (migration 021) with a separate approver; Git-based code review; migrations tracked in MIGRATIONS.md.
Risk mitigation
Subprocessors are inventoried and contracted, and the self-hosted option removes Prova from the data path entirely.
Evidence: The subprocessor list and DPA; self-hosted and air-gapped deployment (docker-compose and Helm).
Availability, Confidentiality, Processing Integrity, Privacy
Availability
SLA targets are encoded and measured, with a public status page and multi-region cloud hosting.
Evidence: 99.9% uptime, 250ms ingest p95, and 200ms gateway-check p95, recorded by lib/slo/recorder.ts and shown at /status.
Confidentiality
Encryption, least-privilege access, data-minimization guidance, EU residency, and a self-hosted option for full control.
Evidence: Send only what you need recorded; EU data residency on Enterprise; self-hosted keeps every receipt inside your own perimeter. See data practices.
Processing integrity
Every AI decision is recorded as a canonical, Ed25519-signed, tamper-evident receipt that anyone can verify offline against the public key.
Evidence: Canonical JSON plus a SHA-256 hash signed with Ed25519 (lib/receipts/sign.ts); independent verification walkthrough at /docs/audit. This is the control Prova is built around.
Privacy
Data minimization, defined retention and deletion, and PII detectors that flag sensitive content in the pipeline.
Evidence: Only a hash of your API key is stored; account data is deleted within 30 days of closure; the pii_leak and pii_in_retrieved_context detectors screen payloads. See the Privacy Policy.
What an auditor would sample
- +Permission matrix and role definitions (lib/auth/roles.ts), with enforcement on every page and mutating action.
- +Self-audit log of privileged actions: API key create/revoke, policy and detector toggles, member invite/role-change/remove, audit export, SSO link.
- +Signed-receipt corpus: every AIDecisionEvent with its Ed25519 signature, independently verifiable against the published public key.
- +SLO samples and the public status history for availability and latency against stated targets.
- +Two-person approval records on custom policy changes (custom_policy_versions).
- +Subprocessor list, DPA, and the security questionnaire prefill.
Not yet in place
- ·No completed SOC 2 report yet. The Type 1 audit begins when we onboard our first design partner.
- ·Formal security-awareness training, background-check policy, an annual third-party penetration test, a documented risk assessment, and an incident-response runbook are being formalized.
- ·This page is a readiness self-assessment of controls in place today. It is not an auditor opinion, and it does not assert SOC 2 compliance.
Running a vendor security review?
The questionnaire prefill, DPA, and subprocessor list are available now. We respond to enterprise security reviews within one business day.