Trust · Security posture

Built for the people auditors ask first.

Compliance is the product, so security is the floor. Every claim on this page maps to a control, an attestation, or a document we'll send under NDA. If it isn't here yet, we say so honestly on the roadmap below.

Last reviewedAugust 2026
Ownersecurity@zovos.ai
Disclosure/.well-known/security.txt
Attestations · 00

Where we stand today.

We won't post a badge we haven't earned. Below is the live status of each one, with dates.

01
SOC 2 Type I
Not started
We have not engaged an auditor or opened an audit window. We hold no completed third-party security attestation of any kind. If your vendor-risk process requires one, we do not meet that bar today.
02
SOC 2 Type II
Planned
Type II observation period begins immediately following Type I issuance.
03
ISO 27001
On roadmap
A gap assessment is scheduled for 2027. We track it alongside Type II.
04
GLBA · Safeguards
Aligned
Our controls are mapped to the GLBA §501(b) safeguards. The mapping is live in customer attestations.
Posture · at a glance

The one-screen summary.

Cloud
AWS · us-east-1 · single region at launch
Tenancy
Schema-per-tenant · per-tenant CMK issued by Zovos · no BYOK
Encryption (transit)
TLS 1.2+ · HSTS · TLS required to the database
Encryption (rest)
AES-256 · per-tenant CMK for object storage · environment key for the database
Identity
SAML 2.0 · OIDC · SCIM · MFA delegated to your IdP
Access
6 system roles + custom roles · 53-permission frozen catalog
Session
30-minute idle timeout · absolute lifetime set by the owner, 8 hours by default (1 to 12) · examiner sessions 4 hours by default, maximum set by the owner
Audit log
Append-only at the database · 400-day archive lock
Network
Per-tenant IP allowlisting · maker-checker gated
Backups
Multi-AZ · point-in-time recovery · 30-day
Pen testing
Scheduled pre-launch · not yet performed
Practices · in depth

How we actually run security.

01

Data handling & residency

Customer data is processed and stored in a single AWS US region (us-east-1). A cross-region standby is on the roadmap but is not in place today, so we publish no multi-region commitment. Each tenant gets its own database schema. Isolation comes from schema separation plus transaction discipline. Each tenant also gets its own customer master key (CMK) in AWS KMS, issued and managed by Zovos, which encrypts the files stored for that tenant. Bring-your-own-key (BYOK) is not supported. The database is encrypted with a single environment-level key rather than a per-tenant one. Vendors in this market routinely overstate "per-tenant encryption keys," and we would rather state it narrowly. At offboarding, we erase database content by dropping the schema and erase object storage by destroying the tenant key. That happens on a 60-day timeline behind a blocking legal-hold gate. We do not transfer customer data outside the United States, and we do not currently market to the EEA or UK.

Region
AWS us-east-1 (N. Virginia) · single region
Cross-region DR
Roadmap · no commitment today
Data classification
Customer-confidential by default
Retention
7-year default · a storage floor, not a cryptographic lock
Deletion
60-day: schema drop for the database, key destruction for objects
02

AI & model governance

Zovos runs Anthropic Claude models through AWS Bedrock, inside our own AWS account and US region. No customer data leaves our cloud boundary to reach a model provider. Amazon Bedrock does not store prompts or completions or use them to train models, and Zovos does not train on customer data. Model outputs are cited back to the source regulator paragraph and version, and every agent action is logged and reviewable. Anywhere a model proposes a control mapping, a policy change, or an exam classification, a human confirms it before it counts.

Inference
Anthropic Claude via AWS Bedrock (in-region)
Model provider retention
None · Bedrock keeps no prompts or completions · your records follow your tenant retention settings
Training on customer data
Never. Contractually prohibited.
Human-in-the-loop
Required for any policy, control, or exam decision
Output provenance
Citation to regulator paragraph + version
03

Authentication & access

Single sign-on via SAML 2.0 or OIDC is supported on every paid tier, and we do not gate it behind an enterprise upcharge. MFA is delegated to your identity provider rather than enforced by us. Put plainly, if your IdP does not require MFA, we will not catch it. SCIM directory sync keeps membership current, and deprovisioning takes effect on the next request. Inside the product, role-based access control mirrors the four-eye principle compliance teams already follow. There are six system roles plus your own custom roles. Every role is intersected against a frozen 53-permission catalog bound in code, so a stray database row can never grant an authority the code does not define.

SSO providers
Okta · Entra ID · Google Workspace · any SAML 2.0 IdP
Directory sync
SCIM · membership and deprovisioning
MFA
Delegated to your IdP · we do not enforce it ourselves
Sessions
30-minute idle timeout · 8-hour absolute by default, owner-configurable
RBAC
6 system roles + custom roles · fail-closed on unknown role
Audit log access
Read-only to all admins · export to SIEM
04

Tenant network controls

Institutions that restrict where their compliance system can be reached from can pin Zovos to their own egress ranges. The allowlist is a governed object rather than a settings toggle. A change is staged, approved by a second person, and only then enforced. A change that would exclude the submitter’s own address is refused unless the lockout risk is explicitly acknowledged. The allowlist is checked on every authenticated request, ahead of any permission evaluation.

Scope
Per tenant · IPv4 / IPv6 CIDR
Change control
Maker-checker · staged, approved, then enforced
Lockout guard
Self-excluding change refused without confirmation
Recovery
Out-of-band admin console on a private network
Enforcement point
Before authentication, on every request
05

Supervisory information & examiner access

Confidential supervisory information is segregated by the agency it came from, and the rule fails closed. An examiner grant that names no agency unlocks nothing at all. An FDIC examiner cannot see an OCC-sourced finding or engagement. Examiner sessions are read-only apart from a closed set of fieldwork actions. They are scope-limited, re-checked for revocation on every request, and can be pinned to an IP range. They are also time-boxed to four hours by default, and your workspace owner sets the maximum. The exam-preparation workspace is the examiner’s deliverable, so it is readable within the grant. Mock exams, board governance and minutes, the decision register, the launch delta and credit review are management work product and are refused to an examiner outright.

CSI model
Agency-scoped · unnamed agency grants nothing
Examiner session
Read-only apart from fieldwork actions · optional IP pin · 4-hour cap by default, owner-configurable
Revocation
Re-checked on every request
Exam workspace
Readable within the examiner grant · mock exams refused
Internal audit wall
In-progress IA work withheld from the auditee
06

Evidence integrity

The record an examiner relies on has to be one nobody could have quietly edited. The database itself enforces the audit log as append-only. The table has no update or delete grants, and the product has no edit affordance. On top of it sits a per-tenant hash chain with Merkle-tree proofs, so a specific event can be proven to have existed, unchanged, at a point in time. The verifier is a standalone tool, so you can check the proofs without trusting our word or our running system.

Audit log
Append-only enforced at the database
Proof ledger
Per-tenant hash chain · Merkle proofs
Verification
Standalone verifier · independent of the platform
Forwarding
Splunk · Microsoft Sentinel · generic SIEM
Archive
Object-lock (WORM) · 400-day lock
07

Vulnerability management

Every pull request runs static analysis and secret scanning, and dependency updates are raised and merged continuously. Infrastructure changes also pass through policy-as-code, where 24 Sentinel rules run against every Terraform plan. The rules block the apply outright on findings such as unrotated KMS keys, public ingress, unencrypted databases, and secrets in environment variables. That control is preventive rather than detective, and prevention is the part examiners ask about. A third-party penetration test is scheduled against the production stack before launch. None has been performed yet, and we will not claim one until it has.

Pen test
Scheduled pre-launch · not yet performed
SAST + secret scanning
Every commit · gating on critical findings
Dependency scanning
Continuous · auto-PR remediation
Infrastructure policy
24 Sentinel rules · block the Terraform apply
Disclosure
security@zovos.ai · /.well-known/security.txt
08

Business continuity

Infrastructure is deployed across multiple Availability Zones in a single US region, with continuous backup and point-in-time recovery. We are deliberately not publishing recovery-time commitments yet. A cross-region standby does not exist today and a restore drill has not been run, so any RPO/RTO number would be a design target rather than a measured one. Our launch service level is 99.5% uptime, stated in the Terms. Live status and incident history are published on our status page, measured by an external monitor. Both numbers move once the drill is done, and this page will say so.

Availability zones
Multi-AZ within us-east-1
Backup cadence
Continuous · point-in-time recovery
Backup retention
30 days standard
Restore drill
Not yet run · scheduled pre-launch
Service level
99.5% uptime at launch
Status page
zovos.ai/status.html (Instatus, external monitor)
09

Subprocessors

Four third parties touch customer data, and they are listed below in full. Customers receive 30 days notice before any new subprocessor processes customer data. We also disclose the operational vendors that support the business without processing customer content, because omissions read as concealment in a vendor review. They are GitHub for source control and CI, Google Workspace for our own corporate email, Resend for the Regulatory Radar mailing list on our marketing site, Cloudflare for bot protection on our marketing site forms and DNS for zovos.ai, and Instatus for our public status page and external uptime monitoring. The current list is published on our subprocessors page and sent on request.

Hosting + email
Amazon Web Services · us-east-1 (incl. SES)
Model inference
Anthropic Claude via AWS Bedrock (in-region)
Identity
WorkOS (SSO + SCIM directory sync)
Admin network
Tailscale (admin plane only, not the app path)
Operational vendors
Cloudflare · GitHub · Google Workspace · Resend · Instatus (no customer content)
Notice
30 days before any new subprocessor
Documents · under NDA

Request the artifacts your procurement team asks for.

We share a security one-pager that separates what is built from what is merely provisioned, our questionnaire responses, and our DPA under a mutual NDA. The current subprocessor list is public. Anything we have not produced is listed as not held rather than promised. Most teams hear back within a week.

  • ASecurity one-pager · built vs. provisionedPDF · NDA
  • BVendor security questionnaire responsesPDF · NDA
  • CEvidence-integrity proof packPDF · NDA
  • DSubprocessor list (current)Public
  • EData Processing AddendumDraft · DOCX
  • FSOC 2 report · penetration test summaryNone held
Request documents →Talk to the team