Compliance
What procurement can rely on today, what certifications do not exist yet, and which direction this is moving. No dates, no badges we have not earned.
The honest summary
CapyDB has no SOC 2 report, no ISO 27001 certificate, and no HIPAA eligibility today. If your compliance regime requires a third-party attestation before a vendor can touch your data, CapyDB does not clear that bar yet, and no sales conversation will change that. What exists instead is a set of verifiable technical controls, documented below, that you can evaluate directly.
What you can rely on today
Every item here is implemented and described elsewhere in these docs — none of it is roadmap:
| Control | Implementation |
|---|---|
| Encryption in transit | TLS required on every database connection (sslmode=require in every URL we hand out); API and dashboard are HTTPS-only; outbound webhooks are HTTPS-only and HMAC-SHA256 signed |
| Secrets at rest | Database credentials and integration tokens AES-GCM encrypted before they reach the metadata store; job payloads scrubbed of plaintext secrets after completion |
| API key handling | Keys are never stored — only a SHA-256 hash; plaintext shown once at creation; keys carry explicit scopes and can be confined to a single project |
| Access control | Destructive operations (project delete, production-overwrite restore, key management) require the org admin role; production overwrites additionally require an explicit confirmation flag; preview-to-production cutovers are operator-mediated |
| Audit trail | Every state-changing action recorded with actor and timestamp; events survive project deletion; see the audit log for the full catalog |
| Data residency | Dedicated single-tenant EU infrastructure; region fixed at creation (Regions) |
| Recoverability | Continuous archiving with point-in-time restore, nightly verified logical dumps, customer-controlled backup schedules (Disaster recovery) |
| Fail-closed operations | The backend refuses to start with development credentials outside explicitly insecure local modes; executors must be configured deliberately |
What is missing, stated plainly
- Third-party attestation. No SOC 2 Type I or II, no ISO 27001, no independent penetration-test report we can hand you.
- Regulated-data eligibility. No HIPAA BAA. Do not put PHI on CapyDB.
- Formal compliance paperwork on demand. There is no trust portal, no pre-filled security questionnaire library. Questions get answered by a human who works on the backend — accurate, but not instant.
For procurement
If you are evaluating CapyDB, the realistic basis for a decision today is: the technical controls above (all independently verifiable — connect with TLS off and watch it fail), EU residency, the audit trail, and the fact that your data is plain Postgres you can pg_dump out at any moment. Vendor lock-in risk is unusually low for the category, which matters more to some risk assessments than a badge.
Direction
The intent is to formalize what already exists — written security policies, independent testing, and eventually attestation — rather than to bolt on controls for an auditor's benefit. The technical groundwork (encryption, scoped access, auditability, fail-closed defaults) was built first deliberately. We will not publish target dates here, because a date on a certification we do not hold yet would be exactly the kind of claim this page exists to avoid. When something on the "missing" list stops being missing, it moves into the table above.
If a specific requirement is the only thing between you and using CapyDB, contact support and say so — knowing which attestations actual customers are blocked on is how the order of that work gets decided.