Security at VenGuard
VenGuard is built by a security practitioner and holds the data you'd least like to leak: your vendor list, your spend, your audit reports, and your vendors' security posture. This page describes how we protect it — specifically, not generically. If you have questions this page doesn't answer, email security@venguard.io.
Tenant isolation
Every customer runs in an isolated workspace on its own subdomain. Isolation is enforced in the database using PostgreSQL row-level security: every table row carries an organization ID, and policies verify your membership on every read and write. This is not application-code filtering — a bug in our application cannot return another tenant's rows, because the database refuses to produce them.
We verify isolation with cross-tenant tests: accounts in different organizations attempting to read each other's data receive empty results and 404s, at both the application and API layers.
Encryption
All data is encrypted in transit (TLS 1.2+, HSTS with preload across all subdomains) and at rest (AES-256 on our database and file-storage provider). Uploaded compliance documents live in private storage: they are never publicly addressable, and every download uses a signed URL that expires within 60 seconds.
Authentication & access
Password sign-in with a 12-character minimum, optional TOTP two-factor authentication for every user, and admin-enforced MFA: workspace owners can require MFA of any member, with enrollment enforced at the application layer — an un-elevated session on an enrolled account cannot access workspace data. MFA resets are performed by your workspace owners, not by us.
Payment cards are handled entirely by Stripe; VenGuard never sees full card numbers. The card metadata you store about your vendors is limited by design to brand and last four digits.
Application security
Strict Content-Security-Policy, frame-ancestors denial, and standard hardening headers on every response. Rate limiting on authentication-adjacent and public endpoints. All input validated server-side; vendor questionnaire links are single-use, 122-bit random tokens that expire in 30 days.
Monitoring & operations
Independent uptime monitoring with a public status page, plus error monitoring and daily automated checks. And we practice what the product preaches: our own vendors are tracked in VenGuard, reviewed on the same cadence we recommend to you, and monitored by the same breach signals. Dependencies are minimal and listed below.
Subprocessors
Third parties that process data on our behalf:
| Provider | Purpose | Location |
|---|---|---|
| Vercel | Application hosting and delivery | USA (functions in us-east-1; global edge network for delivery) |
| Supabase | Database, authentication, file storage | USA (AWS us-east-1) |
| Stripe | Subscription billing and payments | USA |
| Resend | Transactional email delivery | USA |
| Upstash | Rate limiting (client IP addresses only) | USA |
| Sentry | Error monitoring (stack traces and request metadata; PII collection disabled) | USA |
| Anthropic | AI features: breach-headline classification, vendor autofill suggestions, and compliance-report analysis of documents you submit for analysis | USA |
| Slack / Microsoft | Alert notifications — only if your workspace connects a Slack or Teams channel | USA |
We'll notify workspace owners by email before adding a subprocessor that handles customer data.
Data retention & deletion
Your data is yours. Deleting a vendor removes its records and uploaded documents. Deleting your workspace (contact us) removes all organization data. We retain operational logs for a limited period for security and debugging.
What we don't claim (yet)
We don't hold a SOC 2 report today — it's planned as the business grows, and we'd rather tell you that plainly than imply otherwise. In the meantime we'll gladly complete your security questionnaire, or send you our completed CAIQ-style self-assessment: email security@venguard.io.
Responsible disclosure
Found a vulnerability? Report it to security@venguard.io and we'll respond within two business days. We ask for reasonable time to fix before public disclosure, and we won't pursue action against good-faith research.
Last updated July 2026. Material changes to this page are noted here.