Trust centerv2026-10
Security &compliance.
The channel data you upload — VAR org trees1, rep emails2, account ownership3 — is some of the most sensitive in your business. Here's exactly how we protect it.
Last reviewed · October 2026 · SOC 2 Type II in progress; not yet audited or certified.
Pillars
How your data is protected.
Encryption controls
Browser and API traffic uses HTTPS, while managed storage and application-level encryption protect stored data as described below.
- HTTPS is enforced for browser and API traffic
- Hosted Postgres uses Supabase's managed at-rest storage controls
- CRM OAuth credentials encrypted at rest (AES-256-GCM, application layer)
- Platform secrets are supplied through server-side environment variables rather than application source; CRM OAuth app credentials entered in-app are stored in the database encrypted at the application layer (AES-256-GCM)
- Automated secret scanning runs in continuous integration on every pull request and on every push to main, scanning the full git history; a build that introduces a credential fails
- Dependencies are pinned, and an automated posture check runs daily in continuous integration against known advisories; advisory overrides are documented and reviewed
- A written incident-response plan is maintained covering detection, triage, containment, customer notification, and post-incident review; personal-data breach notification is committed contractually at 72 hours in our Data Processing Addendum
Tenant isolation
Tenant-owned reads and writes are scoped by organizationId, with database constraints protecting workspace boundaries.
- Tenant-owned business records carry organizationId; global identity and control-plane records are kept separate
- Interactive application requests resolve the active organization before tenant data is read or changed
- A continuous-integration check fails the build when a bulk query (list, count, aggregate, bulk update, or bulk delete) or raw SQL on a tenant table is written without an organization scope; single-record reads and writes are outside that check and follow a scoped-lookup-then-act-by-id convention
- An independent runtime backstop is implemented and ships with the application; it currently runs inert and moves to warn-then-enforce as a separate, production-watched step — there is no staging environment, so warn mode will be observed on live production traffic once that observation is instrumented. Database-level row-level security is a separate follow-up, gated on a persistent staging target that does not exist yet
- Composite foreign keys protect key cross-workspace relationships at the database boundary
- Composite indexes on (organizationId, …) make scoping the fast path
- Tenant-owned cache keys include organizationId
Identity & access
Clerk handles authentication. Every user can enroll a TOTP authenticator app as a second factor; organization-wide MFA enforcement is implemented but is not enabled today.
- Password storage and credential verification are handled by Clerk
- Every user on every plan can enroll a TOTP authenticator app as a second factor
- Organization-wide MFA enforcement — requiring it of every member — is built and tested but is NOT enabled today; we will notify customers in advance of enabling it
- The enforcement gate, when enabled, verifies both account enrollment and second-factor evidence for the current session
- Enterprise pack: SCIM provisioning for joiner / mover / leaver workflows
- Per-org roles: Administrator and Member. Administrators manage settings, integrations, channel-data imports, team membership, and API credentials, and are the only role that can create, edit, merge, reassign, or delete resellers, people, and accounts. Members can view and export channel data (the partner portfolio review and the full-workspace data export are admin-only) and work it through watchlists, follow-up actions, the collateral library (including collateral imports), QBR briefs, and partner deal registrations (file imports, manual entry, edits, removal, and confirming or clearing their links; re-running registration matching is admin-only), but cannot change reseller, people, or account records or organization settings. A read-only Viewer role is on our roadmap
Audit logging
The app records tenant audit history for imports, server-built data exports (workspace, per-person, audit-log, account-list and rep-packet CSV), role changes and new memberships, and API key and webhook changes, among other sensitive operations, plus best-effort session and access-denial markers.
- Mandatory audit writes are atomic with high-impact data mutations
- Structured actor, action, and entity context with minimized, sanitized request metadata
- There is no in-app control to write, edit, or delete an individual audit record, and the application edits existing records only for privacy: a data-subject erasure request or a full-workspace data wipe redacts personal data from the metadata of existing records so the ledger cannot be used to reconstruct erased personal data. The record, its actor, its action, and its timestamp are preserved, and the erasure is itself audited (GDPR Article 17). Removing a team member keeps their attribution on the records they wrote (under a 90-day or 1-year retention setting, until that window has passed since their removal); if a person's sign-in account itself is deleted, the actor link is cleared while the action, entity, timestamp, IP address, and user agent remain. Records are deleted only by the retention window you configure (by a daily sweep, or when an administrator runs cleanup) and with the workspace itself when it is deleted. Every retention purge leaves its own proof record, naming the administrator when one ran it on demand; the sweep never removes those proof records or the record of each retention-window change, whose IP address and user agent are cleared once it is older than the window
- Configurable retention (90 days / 1 year / indefinite)
- CSV export with full filter support for evidence collection
- Best-effort PERMISSION_DENIED markers when a non-admin is refused an admin page or an admin-only change (merges, match reviews, and partner-claim confirmations included), throttled to one marker per person per page or action every 10 minutes so repeated attempts cannot flood the log
Frameworks
Compliance posture, honestly stated.
| Framework | Status | Detail |
|---|---|---|
| SOC 2 Type II | In progress | Program in progress. VAR Conduit has not yet completed a SOC 2 audit and is not certified. |
| GDPR | Controls available | DPA template available for review. Per-person erasure + organization-wide data-wipe tooling built into the product. (EU representative not yet appointed.) |
| CCPA / CPRA | Controls available | Same erasure + portability tooling as GDPR. Privacy policy enumerates data categories. |
| ISO 27001 | Roadmap | On the roadmap after SOC 2 Type II — not yet started. Listed for transparency, not as a current control set. |
Documents
The document library.
Privacy policy
What we collect, why, and how we protect it — written to match how the product actually works today.
Read the documentTerms of service
The terms governing your access to and use of VAR Conduit.
Read the documentData Processing Addendum
How we process personal data on your behalf; reach out to execute a countersigned copy for procurement.
Read the documentSecurity overview one-pager
A draft trust summary for vendor review; deployment-specific details are confirmed during procurement.
Draft available for review via security@varconduit.com
CAIQ-Lite questionnaire
A draft CAIQ / SIG-Lite style self-assessment — honest gaps included and customer-specific details confirmed on review.
Draft available for review via security@varconduit.com
Disclosure & contact
Found a vulnerability or have a compliance question? We'd rather hear from you than read about it later.
Last reviewed · October 2026