Security at Verc

Security and privacy at Verc

Security is at the core of everything we build. As a platform that processes sensitive call data and conversations, protecting our customers' information is our highest priority.

Last updated: September 2026

Governance

We establish security policies and controls, monitor compliance, and demonstrate our security posture to customers and auditors.

Our policies are based on the following foundational principles:

01.

Access should be limited to only those with a legitimate business need and granted based on the principle of least privilege.

02.

Security controls should be implemented and layered according to the principle of defense-in-depth.

03.

Security controls should be applied consistently across all areas of the platform and organization.

04.

The implementation of controls should be iterative, continuously maturing across the dimensions of improved effectiveness and increased auditability.

Compliance Roadmap

We are building our security program toward industry-recognized certifications. The following frameworks are on our compliance roadmap:

SOC 2ISO 27001HIPAAGDPR

Data protection

Data at rest
Our database runs on Neon, which encrypts storage at the volume level with AES-256. Call recordings and consumer documents are held in S3-compatible object storage, encrypted at rest by the storage platform. API access keys are kept only as SHA-256 digests, so a database disclosure does not yield a usable key. Not every stored credential is one-way, and the exception is stated rather than glossed: passwords that open a password-protected document sent to us must be replayed to open it, so they are held in readable form, under the same per-tenant row-level security as the documents themselves, and are excluded from API responses and from every log line.

Infrastructure security

We run on managed platforms — Railway, Vercel and Neon — so physical security and host hardening sit with providers who do it at scale, and our own controls concentrate on the layer that is ours: tenant isolation, least-privilege credentials, and an auditable record.

Cloud-native architecture
Our API runs as managed containers on Railway and our web application on Vercel. Both provide automatic scaling and platform DDoS protection, and neither requires us to operate server infrastructure. Every deployment is built from an immutable commit and is redeployable by its exact SHA.
Tenant isolation
Our database is Neon serverless PostgreSQL. Every tenant-scoped table carries a PostgreSQL row-level-security policy, and the role our application connects as holds no privilege to bypass it — a query issued on a request's behalf is filtered by the database itself, not by application code remembering to filter. Tenant context is set per transaction from the verified credential — the session token on a browser request, the resolved API key on a programmatic one — never from anything a client can supply, and all connections are TLS-encrypted.
Secure storage
Call recordings and consumer documents are held in separate S3-compatible object stores. Object keys are namespaced per tenant, and every read is checked against the caller's tenant before the object is fetched — a reference naming another tenant's prefix, or another bucket, is refused rather than followed. On the consumer-document store, the credential the application holds is scoped to objects only: it cannot read or change that bucket's versioning, object-lock or lifecycle configuration.
Resilience & recovery
Our primary PostgreSQL database — the system of record for accounts, consumers, arrangements and the audit trail — can be restored to any point in the preceding seven days with millisecond precision, and a restore preserves the pre-restore state so a mistaken recovery is itself reversible. That window is a database control and does not describe the object stores, which are a separate system. Schema changes ship as migrations gated behind a preflight, and any deployment can be rolled back to a specific commit rather than to whatever was last green.

Product security

Tenant isolation

Verc implements database-level row-level security (RLS) to enforce strict tenant isolation. Every database query is automatically scoped to the authenticated tenant's organization. This means customer data is isolated at the database layer, not just the application layer, providing defense-in-depth against data leakage.

The tenant context is set inside the database transaction that serves each request, derived server-side from the verified credential — a browser session token, or a resolved API key on a programmatic request — and never from anything the request itself carries. PostgreSQL RLS policies then enforce isolation regardless of application logic, so even in the event of an application-level vulnerability, cross-tenant data access is prevented by the database itself.

Vulnerability management

We employ multiple layers of security testing throughout our development lifecycle:

Authentication & authorization
Interactive access is handled by Clerk. Access tokens are short-lived JSON Web Tokens issued by Clerk that refresh automatically, and the application never persists one to localStorage or any other browser store. Every JWT signature is verified server-side against the issuer's published keys on every request — never parsed on the client to make an authorization decision. Programmatic access uses a second scheme: a tenant-scoped API key, presented as a bearer credential, resolved by an indexed prefix and then compared in constant time against a stored one-way hash, so the secret itself is never held at rest. A key may be given an expiry and can always be revoked, and it grants exactly one tenant. Both schemes resolve to the same server-side identity and to exactly one tenant. What they do not share is how far a caller reaches inside it: on the interactive path, organization-based role access control means a member reaches only the resources their membership grants, while an API key has no membership behind it and authorizes as an administrator of the single tenant it was issued for — which is why a key is scoped by issuing and revoking it rather than by a role.
Secure development
All code changes undergo mandatory peer review with security considerations as a primary review criterion. Our CI/CD pipeline enforces type checking, linting, and automated tests before any code reaches production. Branch protection rules prevent direct pushes to production branches.
API security
Every customer-facing route requires an authenticated caller, by one of two schemes, and under both the tenant is derived server-side from the verified credential rather than from anything the request itself says. A browser session presents a short-lived token whose signature is verified against the issuer's published keys. A programmatic integration presents a tenant-scoped API key, matched by an indexed prefix and then compared in constant time against a stored one-way hash, and refused if it has been revoked or, where it was given an expiry, has passed it. Edge middleware is never relied on alone, because server-rendered handlers can be reached without it. Three routes are deliberately open and return no customer data — the liveness, readiness and build-version probes a deployment platform polls. Inbound webhooks from our identity, telephony, messaging and document providers are a third path: they authenticate the delivery rather than a caller, verifying the provider's signature or shared secret over the payload before any of it is acted on, refusing the request outright when that secret is not configured, and resolving the tenant from the verified payload rather than from a field the sender chose. Links we send a consumer, such as one-click unsubscribe, carry a signed token that is verified the same way. Request and response shapes are validated at the boundary by typed schemas, and responses carry HSTS, a deny-by-default frame policy, a no-referrer policy and a restrictive permissions policy. Rate limits are applied to the expensive query surfaces, keyed on tenant, user and address — all resolved server-side, never from anything the client sends. Sign-in throttling is enforced by our identity provider.

Enterprise security

Access control
Access to production systems is restricted to authorized personnel only and requires multi-factor authentication. Employee access is provisioned based on the principle of least privilege using role-based access control (viewer, user, admin, superuser). Access is revoked immediately upon role change or offboarding.
Incident response
We maintain a documented incident response plan with defined severity levels, escalation procedures, communication protocols, and post-incident reviews. We respond rapidly to security events with clear ownership and accountability.
Security education
All team members receive security awareness training covering secure coding practices, phishing awareness, data handling procedures, and incident reporting. Engineering team members receive additional training on common vulnerabilities and secure development patterns.
Vendor security
Verc uses a risk-based approach to vendor security. All third-party vendors with access to customer data undergo security review. Factors that influence vendor risk assessment include:

Vendor security assessments are reviewed annually or when significant changes occur in the vendor relationship.

AI & data processing

As an AI-powered call analytics platform, we take special care to ensure responsible and secure processing of sensitive conversation data.

PII protection
Personally identifiable information (PII) such as names, phone numbers, and transcript content is never included in application logs. Our logging framework is designed to capture operational metrics using anonymized identifiers while excluding any sensitive customer data.
AI model governance
AI-generated outputs (analysis, scoring, summaries) are treated as probabilistic and validated before persistence. All AI results include model provenance tracking, linking each output to the specific model version and input data that produced it.
Transcript security
Speech recognition runs at our voice platform provider, under contract, over encrypted transport; we do not operate transcription infrastructure of our own. Transcripts are then stored in our database under the same row-level security policies as every other tenant-scoped record, and transcript content sits on the denylist that keeps it out of every log line, trace and error report we emit.

Data privacy

At Verc, data privacy is a fundamental commitment. We build privacy controls into our platform by design and maintain transparency with our customers about how their data is handled.

Data minimization

We only collect and process data that is necessary for providing our services. Customer data is retained only for the duration required by the service agreement, and deletion mechanisms are available to customers.

Regulatory compliance

Verc's security program is designed to meet requirements across multiple regulatory frameworks. We continuously evaluate updates to regulatory and emerging frameworks to evolve our compliance program accordingly.

Transparency & documentation

We maintain clear documentation of our data processing activities, privacy policies, and data protection agreements. Customers can request details about how their data is handled at any time.