How Verazo protects what you give it

Security posture

Encryption

Verazo encrypts every long-lived integration credential it stores, a read-only GitHub, AWS, Okta, or Google Workspace token a customer explicitly provisions, with AES-256-GCM.

GCM is authenticated. Decryption verifies the credential's authentication tag before returning any plaintext, so a tampered or corrupted ciphertext fails outright instead of silently returning corrupted data.

The encryption key is a dedicated 256-bit secret, separate from the key that signs the audit ledger and the key that signs a user's session. A leak of one never automatically compromises the other two.

All production traffic is served over HTTPS. A plain HTTP request receives a permanent redirect to HTTPS, every response carries a one-year HTTP Strict Transport Security header, and Verazo's own routing layer terminates every connection under a real certificate issued by Let's Encrypt.

Tenant isolation

Verazo derives the acting organization from the signed-in session on the server, never from a value the browser sends.

Server Actions sampled across policy drafting, control-check management, and vendor records each re-derive this organization id from the session, then scope every database read and write to it. This is confirmed for a representative sample of Server Actions, not yet audited across the entire codebase.

Personal data and Verazo AI

Verazo AI has ten real jobs across the product: parsing a natural-language request into a known control, narrating a finished check's result, drafting a first-pass policy, drafting a first-pass answer to a security questionnaire from an organization's own self-reported context, answering a question on this trust center from what is already published here, answering a remediation-guidance question about a specific control or task, drafting an illustrative first-pass fix for an accessibility violation, drafting a first-pass mobile test file from an organization's own already-selected source, making one structured yes/no judgment call about a single accessibility candidate, and driving a sandboxed browser session for the rare control with no API.

Before any free-text field reaches Verazo AI, a deterministic filter -- plain pattern matching, not a model call -- strips six structured categories of personal data it can reliably detect: email addresses, phone numbers, credit card numbers, IBAN numbers, IP addresses, and US Social Security numbers. This runs at every one of the ten jobs above. It is not a general-purpose scrubber: it does not catch a person's name, a physical mailing address, or a non-US national ID number in free text, since no reliable pattern exists for those in unconstrained natural language.

Verazo AI usage limits

A platform operator can pause every Verazo AI call for one organization immediately, a hard kill switch for a runaway or compromised tenant, set only by a deliberate human action, never automatically.

A platform operator can also set a monthly token budget for an organization, tracked against that organization's real usage and shown as a percentage on its own billing page. Once an organization reaches its budget for the current calendar month, further Verazo AI calls for that organization are blocked until the next month, or until a platform operator raises the budget.

Separately, Verazo flags an organization whose usage on a given day exceeds three times its own trailing seven-day average, surfaced on the platform-admin usage page for a person to review, not an automated alert yet.

Every individual request to Verazo AI is also capped at 20,000 characters of free text, rejected outright before the request is sent, as a backstop against an accidental or malicious oversized input.

Audit logs

Every audit-ledger entry is hash-chained.

Each entry's hash covers the previous entry's hash and its own content, so editing or deleting a past entry breaks every entry chained after it. Each entry also carries an HMAC-SHA256 signature under a dedicated signing secret that is never stored in the same database as the ledger itself.

Writing to this table is only possible through one function. A database-level guard rejects any direct update, delete, or upsert against it, even from an account with raw database access. A verification pass walks an organization's entire chain and reports the exact entry where a break first appears.

Subprocessor oversight

Verazo names the vendors that process customer data on its behalf, and the region each one operates in, in the subprocessor table below.

Data handling

What Verazo stores

The compliance records a customer creates in the product: control-check evidence and screenshots, policies, the risk register, vendor and subprocessor due-diligence records, security-questionnaire answers, incident records, and the audit ledger itself. Any long-lived integration credential a customer explicitly provisions is encrypted as described above.

Data residency

Verazo's production infrastructure is hosted with Hetzner, entirely within the EU. No AWS infrastructure and no Canadian infrastructure is used anywhere in Verazo's production environment.

Retention

An accessibility violation's screenshot is kept for 10 years from the day it is captured, even after the violation is fixed. Verazo's evidence model exists to prove a violation existed and was remediated, and an auditor can sample evidence from an arbitrary past date.

A single published retention period covering every other record type Verazo stores does not exist yet.

Export and deletion rights

A general self-serve export of an organization's own data, and a self-serve account-deletion flow, do not exist yet.

Infrastructure

Verazo runs its own bundled Postgres database and its own bundled Redis instance, each reachable only from Verazo's own isolated Docker network, never a shared or third-party managed database service. Neither has a port published to the public internet.

Verazo runs its own Traefik instance for routing, separate from any other project on the same physical server, in front of which a system-level nginx terminates every TLS connection.

Deploys are blue-green. A new version starts in an idle slot, is smoke-tested at its own internal address, and only takes over live traffic once Verazo's own routing layer confirms it is healthy, while the previous version keeps serving traffic unchanged until that confirmation happens. This process has run in production with a confirmed zero-downtime traffic swap.

Subprocessors

A subprocessor is another company that processes customer data on Verazo's behalf. Verazo names four.

Anthropic is named here as a matter of GDPR sub-processor transparency. Everywhere else on this site, Verazo's AI capability is described as Verazo AI.

Uptime and reliability

Verazo publishes a Service Level Agreement. A public status page does not exist yet.

The blue-green deploy process described above is the real mechanism behind every release: the previous version is never retired until the new one is proven live, at both the application layer and the routing layer.