Security & governance

Built to be examined.

Certvian handles claim files: PII, payment records, sometimes medical information, sometimes privileged attorney communication. Our stance is that controls should be structural: enforced by the schema, the database role, and the approval chain, so they hold whether or not anyone is watching. This page is written for the people who review vendors. Forward it to your security team.

We complete security questionnaires and walk through controls live as part of every procurement.

Data classification

We know what we’re holding.

Every document is classified at ingestion and handled according to its class, including the recognition that ingested documents are adversary-influenced input, not trusted content.

ClassExamplesHandling
PIINames, addresses, plates and VINs, policy and claim numbersEncrypted at rest and in transit; access-logged
PHIMedical records in bodily-injury subrogationFlagged at ingestion; HIPAA-aligned handling with stricter access and retention
FinancialPayment records, settlement amounts, recovery figuresEncrypted; export-restricted
PrivilegedAttorney communications, internal strategyAccess-controlled and flagged; excluded from any model-improvement data
OperationalTimelines, scores, case metadataStandard tenant-isolated handling

Platform controls

Structural, not procedural.

The controls below are properties of the system (database roles, schema constraints, append-only tables) rather than policies that depend on someone following them.

01

Tenant isolation

  • Every business row carries the organization's identity, and Postgres row-level security is the backstop: the application connects as a non-superuser role that cannot read across tenants, even if a query forgets to filter.
  • Object storage is namespaced per organization, and files are served only through short-lived signed URLs minted after an authorization check.
  • Retrieval for AI analysis is scoped to a single case; the model cannot reach other cases, let alone other tenants.
02

Identity & access

  • Single sign-on via OIDC against your identity provider; password auth is delegated to managed infrastructure, never stored by us in production.
  • Five roles from owner to read-only viewer, with a permission matrix governing members, settings, billing, and case access.
  • Invitations use single-use tokens stored only as SHA-256 hashes; the raw token is emailed once and never persisted.
03

Encryption & secrets

  • TLS on every path: web, API, inbound email gateway, and connections to model and storage providers.
  • Encryption at rest across the relational store, object store, and backups.
  • Provider keys and tenant secrets live in a secrets manager and are injected server-side only. Nothing sensitive reaches the browser.
04

Audit & retention

  • An append-only audit log records every consequential action (logins, role changes, case and document access, exports, approvals, sends) with actor, before-and-after, and context. Entries cannot be edited after the fact.
  • Retention is configured per organization (seven years on closed recovered cases by default) and applied automatically; deletions cascade across stores and are themselves audited.
  • Backups are encrypted and tenant-recoverable; restores are audited.

AI governance

The AI is the most constrained user in the system.

Most vendor AI questions reduce to three fears: our data leaks into a model, the model makes something up, the model does something unauthorized. Certvian’s architecture answers each one structurally.

Your data doesn't train third-party models

Model access runs under zero-retention, no-training provider configurations. Privileged content is additionally excluded from any internal evaluation set unless your organization explicitly opts in.

Models cannot act

The AI layer has read-only, case-scoped tools. It cannot send email, reach other cases, or touch anything outside the file it is analyzing, so a compromised generation cannot exfiltrate or act.

Ingested documents are treated as hostile

A forwarded PDF may carry prompt-injection. Documents are handled as untrusted data: no instructions in them are followed, a grounding judge verifies every quoted claim, and unverifiable claims are quarantined and labelled.

Every run is reproducible

Each model call records its model, prompt version, cost, and output. For any AI-drafted demand, we can answer the regulator's question (which model, which prompt, which evidence) years later.

Nothing sends without a human

An outbound email structurally cannot exist without a recorded human approval: a database constraint, a trigger, an API check, and a send-worker re-check stand between a draft and a send. Approvals pin the exact version reviewed.

Every claim carries a citation

No AI statement is presented without a link to the exact source span it came from. Absence is reported too: 'no witness statement on file' comes with a record of what was searched.

Compliance posture

Controls first. Certificates as they’re earned.

We won’t claim a certification we don’t hold. Here is exactly where each framework stands.

SOC 2 Type II

The control families SOC 2 examines (access control, audit logging, encryption, change management) are built into the platform from day one, so the evidence trail already exists. Certification is staged on our roadmap ahead of enterprise deployment; we share current control status openly in security reviews.

HIPAA

Medical records in bodily-injury files are flagged as PHI at ingestion and handled with stricter access and retention. PHI is not sent to any sub-processor without a BAA in place.

State insurance regulations

Record retention and audit requirements vary by state. Both are configurable per organization and jurisdiction, and data flows are documented for regulator questions.

Sub-processors

Who touches the data.

Certvian runs on a deliberately short list of infrastructure providers. Data region defaults to the US.

Supabase

Managed Postgres and authentication

US

Resend

Email intake and delivery

US

OpenRouter

AI model access, under zero-retention / no-training configuration

US

The current sub-processor list, and notice of changes to it, is available to customers on request.

Threat model

We’ll name our risks before you ask.

A vendor that can’t tell you its threat model hasn’t thought about it. These are the ones we engineer against.

Cross-tenant data leak

Row-level security backstop, org-namespaced object keys, case-scoped retrieval

Prompt injection via ingested documents

Documents treated as untrusted; models have no action tools; grounding judge quarantines unverifiable claims

Unauthorized outbound communication

Outbound structurally requires an approved approval, with four independent enforcement layers

Malicious attachments

Scanning and a file-type allow-list on ingest; quarantine for anything that fails

Secret exposure

Secrets manager, server-side injection only, short-lived signed URLs, nothing sensitive in the browser

Insider misuse

Least-privilege roles, export restrictions, and an append-only audit trail of every access

For your security review

Ask us the hard questions.

We’ll complete your security questionnaire, walk your reviewers through the controls on a live system, and put the answers in writing.