DocsTrust & data

Security overview

Updated 2026-10-07

Compliance is the product, so security is the floor. This page explains the posture in the terms a compliance officer needs for day-to-day use and for a vendor-risk file. The live status of every attestation, with dates, is on our security page, and nothing here is stronger than what that page says. Where the two could drift apart, we point you to that page instead of repeating a number.

Customer data is processed and stored in a single AWS region in the United States. We do not transfer customer data outside the United States, and we do not currently market to the EEA or the UK. A cross-region standby is on the roadmap and 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. Bring-your-own-key (BYOK) is not supported.

Traffic is encrypted in transit, including to the database. At rest, object storage is encrypted under a per-tenant key and the database under an environment-level key. "Per-tenant encryption keys" is routinely overstated by vendors, and we would rather state ours narrowly than let a reviewer assume more than is true.

Single sign-on over SAML 2.0 or OIDC is available on every paid tier at no extra charge. SCIM directory sync keeps membership current, so deprovisioning in your identity provider takes effect here. Multi-factor authentication is delegated to your identity provider and is not enforced by us. To be plain about what that means, if your provider does not require it, we will not catch that.

Inside the product, access is role-based and fails closed on an unknown role. There are six system roles plus any custom roles you define, and every role is intersected against a frozen permission catalog bound in code, so a stray database row cannot grant an authority the code does not define. Access groups can also limit a member's permissions to the records they own or to chosen business units, and those scoped reads and writes are enforced on the server. A session ends after 30 minutes without activity. It also has an absolute lifetime that your workspace owner sets between 1 and 12 hours, with 8 hours as the default. An examiner grant lasts 4 hours by default, and your workspace owner sets its maximum, between 1 and 24 hours. An administrator can also see a member's live sessions from the team roster, including the device, where the session started, when it was last active and when it expires. The administrator can end one of those sessions or all of them. A revoked session stops working on its next request instead of staying valid until it expires. A vendor-risk reviewer asks for this control by name for the day someone leaves mid-day or a laptop goes missing. Roles and permissions covers who can do what.

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, not a simple 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. Once in force, the allowlist is checked on every authenticated request, ahead of any permission check.

Two exemptions are deliberate, and we name them here so a reviewer does not have to discover them. An examiner session does not run against your allowlist, because regulators arrive from networks you do not control. It honors only the IP range pinned on its own grant. Keys issued for third-party automation are exempt for the same reason, since the automation platform's egress is not yours either. The compensating control there is the key itself, which is scoped to one surface and individually revocable.

Confidential supervisory information is segregated by the agency it came from, and the rule fails closed. A grant that names no agency unlocks no supervisory material at all. It does not unlock all of it. An examiner from one agency cannot see another agency's findings or engagements.

Examiner sessions are read-only apart from a closed set of fieldwork actions. They are also scope-limited and time-boxed, they are re-checked for revocation on every request, and they can be pinned to an IP range. Some whole areas refuse an examiner outright because they are management work product. Those areas include the mock exam, board governance and minutes, the live decision register, the launch delta and credit risk review. The AI assistant connector refuses an examiner session as well. Your exam-preparation workspace is the deliberate exception in the other direction. It is the examiner's deliverable, so it is readable in an examiner session, and you should keep that in mind when you decide what to put there. In-progress internal audit work is withheld from the auditee by the same access mechanism. See Exam management and Internal audit.

The record an examiner relies on has to be one nobody could have quietly edited. The audit log is append-only, and the database itself enforces that. There are no update or delete grants on the table. Database triggers refuse an update, a delete or a truncate of the table outright. There is no edit affordance anywhere in the product. On top of the log sits a per-tenant hash chain with proofs, so you can show that a specific event existed, unchanged, at a point in time. The verifier is a standalone tool, so you do not have to trust our running system to check a sealed artifact. The audit log is archived each month under a 400-day compliance-mode object lock, so no one, Zovos included, can delete an archived month before the lock expires. Audit events can be forwarded continuously, through the SIEM forwarder you configure on the Integrations tab of Settings, to Splunk, Microsoft Sentinel, or a generic collector. Audit trail and exports has the detail.

We hold no completed third-party security attestation of any kind. There is no SOC 2 report, no auditor is engaged, and no audit window is open. ISO 27001 sits behind SOC 2 on the roadmap. A third-party penetration test is scheduled against the production stack before launch and has not been performed, and we will not claim one until it has. A restore drill has not been run, so we publish no recovery-time commitment. Any such number today would be a design target, not a measured result.

If your vendor-risk process requires a completed attestation, we do not meet that bar today. The security page carries the current status with dates, and lists the documents we send under a mutual NDA. That list also states plainly which artifacts we do not hold.

Email security@zovos.ai. Reports skip the normal support queue, and we work to coordinated disclosure with credit if you want it. The commitments we publish for critical issues are on the support page, and our current posture is on our security page. Good-faith research is authorized. Please do not run load-generating scanners, test denial of service, or access data that is not your own test data. There is no paid bug-bounty program today. Product problems and outages go to support instead.