Where we are, stated plainly
VouchSite is a pre-launch product. We are building toward general availability and we are not yet serving customers or holding customer data in production.
We are publishing this page now rather than at launch because our Terms of Service and Privacy Policy refer to it, and a document that points at a page which does not exist is not worth much. But that means being straight about what is in place today versus what is scheduled before the first customer is onboarded.
This page distinguishes the two, and it is dated. Sections 2 and 3 describe controls that are live now. Section 4 lists what is scheduled and when. Nothing in section 4 is described as though it already exists.
This page will be replaced with a version describing the tested production state before we onboard any customer.
1. What we are protecting
Certificates of insurance and the records that prove what was on file and when. Business contact details for subcontractors and their insurance brokers. General contractor account information.
We do not hold Social Security numbers, driver's license numbers, financial account numbers, health information, or biometric information. We never receive or store payment card data — payments are handled entirely by our payment processor's hosted checkout.
All processing and storage is in the United States. We do not process or store customer information outside the United States, and we do not use offshore contractors.
2. Account and access security — in place today
Multi-factor authentication is enabled on every administrative account we hold, including our application platform, cloud infrastructure, domain and DNS, payment processing, messaging provider, email, and banking.
Credentials and API keys are held in a password manager. They are not stored in documents, spreadsheets, or code.
Our cloud root account is secured and not used for daily work. Administration runs through a separate least-privilege identity with its own multi-factor device. Unused identities and access keys inherited from earlier work have been audited and removed.
Development and production are separated at the platform level, with distinct API keys and distinct provider projects and subaccounts for each environment.
A sealed recovery document exists covering the accounts on which the business depends, stored physically outside those accounts, with a named trusted party who knows they are named. It is reviewed quarterly.
Spending limits and balance controls are set on every metered service, with automatic top-up disabled, so that a runaway process or an abuse attempt cannot silently consume the business.
3. Product and infrastructure security — in place today
Our marketing site carries no tracking. It is served as static files. There are no advertising cookies, no third-party tracking or advertising pixels, and no visitor identification or identity-resolution services.
Data is encrypted in transit and at rest at the platform level. Our application platform states that data is safeguarded in transit with TLS and at rest with AES-256 encryption. Transport encryption is in force across our site, our application, and every provider connection.
What that encryption does and does not do. Platform encryption protects data from someone outside the system. It does not, on its own, control what one user of an application can see of another user's data. That boundary is drawn by access rules we write, and it is our responsibility rather than our platform's. Those rules are being authored and independently tested before we accept production customer data — see section 4, Days 10 and 14. We would rather state that distinction than let an encryption claim imply a separation it does not provide.
We do not train artificial intelligence models on customer information, and the vendor that performs automated document reading for us does not train its models on our data either.
Messaging is registered with the carriers under the A2P 10DLC framework, with an approved brand under our legal entity.
4. Scheduled before launch
The following are being built and are not yet in place. Each is listed with the date it is scheduled. This page will be updated as they land, and replaced entirely once they have been tested.
| Control | Scheduled |
|---|---|
| Soft delete throughout, with no hard deletes and an attributed log entry for every removal | Day 9 |
| Removal of anonymous data-access rules, and the platform's public data API disabled entirely | Day 10 |
| Token-validating endpoint with per-address rate limiting and lockout, and a durable security event record | Day 11 |
| Private document storage with public access blocked, encryption, versioning, and least-privilege access scoped to a single bucket | Day 12 |
| Direct-to-storage uploads and short-lived expiring read links, so documents are never publicly reachable by URL | Day 13 |
| First full security regression — anonymous reads, link enumeration, cross-organization access, direct object access | Day 14 |
| Named user accounts with roles, so every evidentiary action is attributable to a person rather than a shared login | Days 30 and 31 |
| Error handling and failure alerting across every automated process | Day 35 |
| Nightly backup of database and documents, with a restore actually performed and verified | Day 38 |
| Production security re-test after the production cutover | Day 43 |
Until the items above are complete, VouchSite is not accepting production customer data.
5. Our providers
VouchSite runs on established platforms rather than infrastructure we operate ourselves. A current list of every provider that can access customer information, and what each can see, is published at vouchsite.com/subprocessors.
Our application platform, Bubble, holds SOC 2 Type II certification, audited by Sensiba LLP. Our cloud storage runs on Amazon Web Services. Payments run on Stripe, a PCI Level 1 Service Provider — the highest certification available — audited annually by an independent qualified security assessor.
We use Stripe's hosted checkout, so card data never reaches our servers. We do not capture, store, or transmit card numbers at any point, and we hold only Stripe's customer and subscription identifiers.
What our providers' certifications do not do. A provider's certification covers that provider, not us. Stripe's own guidance is explicit that using Stripe does not make a business compliant by default and that each business remains responsible for its own environment; the same principle applies to our application platform's encryption and its SOC 2. VouchSite itself holds no SOC 2 or comparable attestation, and we will say so plainly rather than let a provider's certificate imply one. Our own obligations — including the payment-card self-assessment appropriate to a business that never touches card data — are ours to meet, and are listed in section 4 where they are not yet complete.
6. If you find a security problem
Email security@vouchsite.com with the details. We will acknowledge within two business days.
We will not pursue legal action against anyone who reports a genuine issue to us in good faith, who does not access or modify data beyond what is needed to demonstrate the problem, and who gives us a reasonable opportunity to fix it before publishing.
We do not currently run a paid bug bounty.
7. Incidents
If we discover a security incident affecting customer information, we will investigate, contain it, and notify affected customers without undue delay and consistent with applicable state notification laws. We will tell affected customers what happened, what information was involved, and what we are doing about it.
We have had no security incidents. If that changes, this page will say so.
8. Changes to this page
This page is reviewed at least annually and whenever we add a provider that stores customer information, change where documents are stored, or complete a scheduled control listed in section 4. The date at the top is the date it was last reviewed.
9. Contact
VouchSite LLC\ 522 W Riverside Ave STE N\ Spokane, WA 99201
Security reports: security@vouchsite.com\ Everything else: support@vouchsite.com