We are not SOC 2 certified, and we will not imply otherwise
Vendorroll is an early-stage product. We have not completed a SOC 2 audit, and we are not going to describe ourselves as “SOC 2 aligned” or “audit ready” to blur that. If your procurement policy requires a vendor SOC 2 report, we will not pass it today.
What we can offer instead is this page, a signable DPA, and a self-hosted deployment where your vendor data never touches our infrastructure at all. If none of that clears your bar, we would rather tell you now than waste your evaluation cycle.
Tenant data isolation
Vendorroll is multi-tenant: several organisations share one database. Isolation is enforced by Postgres row-level security, not by application code. That distinction matters — a bug in a query, an API route or a React component cannot expose another organisation's rows, because the database itself refuses to return them.
Every policy is anchored to a single function, get_my_org_id(), which resolves the organisation of the authenticated session. Policies are written per operation, so read, insert, update and delete are each constrained separately rather than sharing one broad rule.
These are live counts taken from the production database on 2 October 2026, not aspirational figures. If you would like to verify them during an evaluation, ask and we will walk you through the policy definitions.
The service role, and how we contain it
Some server-side operations — background jobs, scheduled monitors — use a Supabase service-role credential that bypasses RLS by design. This is the sharpest edge in the system, so we are explicit about it: the service role is never exposed to the browser, is never used in a user-facing request path without an explicit organisation filter, and is held only in server environment configuration.
Vendor portal links
Your vendors do not create accounts. They receive a link containing a single-use access token. That design removes a password from the equation entirely, which means the token itself has to be handled carefully.
- Stored hashed. Tokens are hashed with SHA-256 before storage. The database holds the hash, never the token. Anyone with a database dump still cannot open a vendor portal.
- Scoped to one vendor. A token grants access to a single vendor record within a single organisation, and nothing else.
- Time-limited. Tokens carry an expiry — 48 hours by default for portal invitations.
- Revocable, and revoked on reissue. Issuing a fresh link automatically revokes the vendor's previous token, so an old email cannot be replayed.
- Validated server-side. Every action taken through the portal re-checks the token before touching data.
Subprocessors
These are the third parties that process customer data on our behalf. We will update this list before adding a new one.
| Subprocessor | Purpose | Data it can access |
|---|---|---|
| Clerk | Sign-in, sessions and account security | Members' names and email addresses, and sign-in details such as device and IP address |
| Supabase | The database and file storage that hold your organisation's data and uploaded documents, and the scheduled jobs that send reminders | All application data, including uploaded vendor documents |
| Vercel | Application hosting | Data in transit through the application runtime |
| Resend | Sending transactional email | Recipient addresses, and the vendor and requirement names that appear in emails |
| Amazon Web Services (Amazon Bedrock) | Reading uploaded documents and contracts to suggest their type, issuer, dates and key terms | The text of documents that are analysed |
How AI processing works
This deserves its own section, because it is the part buyers most often discover late.
When a document is analysed — a SOC 2 report, a certificate, a contract — its extracted text is sent to Amazon Web Services (Amazon Bedrock) to identify issuer, document type, expiry dates and key contract terms. That means document content leaves our infrastructure and is processed by Amazon Web Services (Amazon Bedrock).
Analysis runs asynchronously in a queue rather than during your request, results are written back to your organisation's rows, and extracted values are surfaced as suggestions with a confidence score rather than being treated as ground truth.
If that is not acceptable
AI analysis is driven by an API key held in configuration. On a self-hosted deployment you can simply omit it — the platform runs without AI extraction, and documents are stored and tracked normally. Nothing is sent for analysis.
Access control and audit
- Role-based access. Preset roles (Admin, Operations, Compliance, Security, Finance, Legal, Member) plus organisation-defined custom roles.
- Audit trail. Vendor lifecycle events, approval decisions, evidence submissions and automated messages are recorded with actor and timestamp.
- Approval traceability. Multi-stage approvals record who decided what and when; the sequence is enforced rather than advisory.
- Authentication. Sign-in is handled by Clerk: a one-time code sent to your email, or your Google account. There are no passwords to leak or reuse.
Data handling, export and deletion
- In transit. All traffic is served over TLS.
- At rest. Encryption at rest is provided by our infrastructure providers for both the database and file storage.
- Export. Vendors, requirements, evidence metadata and the audit trail can be exported to CSV at any time, without asking us. Uploaded documents remain downloadable in their original format.
- Deletion. On request we delete your organisation's data, including stored documents, within 30 days. Ask and we will confirm in writing when it is done.
- No secondary use. We do not sell customer data, and we do not use your vendor documents to train models.
What we do not have yet
Most vendor security pages are written to avoid this section. We would rather you find out here than three weeks into a procurement review.
- Row-level tenant isolation on every table
- Hashed, expiring, revocable portal tokens
- Full audit trail
- Role-based access control
- Data export and deletion on request
- Self-hosted deployment option
- SOC 2 Type I or Type II
- ISO 27001
- Third-party penetration test
- SAML / SSO and SCIM provisioning
- Customer-managed encryption keys
- Contractual uptime SLA
- Bug bounty programme
We are a small team, and each of those has a real cost. We will add them as the business supports it, and we will update this page when we do — not before.
Self-hosted deployment
If your policy will not permit vendor compliance evidence in a third-party system that lacks a SOC 2 report — which is a defensible position — you can run Vendorroll inside your own cloud account.
- Deploys as a container to your own Azure or AWS environment
- Connects to a database you control
- Your vendor data and documents never reach our infrastructure
- AI extraction is optional; omit the API key and nothing is sent for analysis
- We provide setup, updates and support
DPA and documentation
We will sign a Data Processing Addendum. Rather than publish a generic template here, we send the current version on request so you receive the one our counsel has reviewed.
We can also complete a security questionnaire — including CAIQ — as part of an evaluation. Given what this product does, it seems only fair that we answer one too.
Request a DPA or security review pack
Email privacy@oopsie.tech and tell us what your review requires. We will tell you honestly whether we can meet it.
Reporting a vulnerability
If you believe you have found a security issue, please report it to privacy@oopsie.tech. We will acknowledge within two business days and keep you updated until it is resolved.
We do not currently run a paid bug bounty, and we will not threaten legal action against anyone who reports a genuine issue in good faith and gives us reasonable time to fix it.