TEC World Trust and Security

Compliance status

• SOC 2: readiness in progress, no report yet. We do not claim a certification until an auditor's report is issued.
• Our security policies are written and are drafts awaiting formal adoption.
• A Data Processing Addendum (DPA) is drafted and pending review by counsel.
• The providers that host the service, Vercel and Supabase, have their own SOC 2 reports; those reports are available from the vendor.
• Our draft policies, control matrix and evidence are available to customers under a non-disclosure agreement, on request.

Hosting and architecture

• The application runs on Vercel, with its server functions in Vercel's US West (Oregon) region.
• The database, sign-in and file storage run on Supabase (PostgreSQL), in AWS us-west-2 (Oregon, United States).
• Each customer is a separate workspace. Every record carries its workspace, and every request is scoped on the server to the signed-in user's own workspace, never to a workspace named by the browser. The one exception is our support access, described under Access control and sign-in.
• Uploaded documents and attachments are virus-scanned before the service accepts them, on a scanning server we operate. The file is held in memory only for the scan and is not stored on that server. Logo images, training videos and voice recordings are checked for their file type but are not virus-scanned.

Tenant isolation

• Isolation is enforced in the application's data layer and, as defense in depth, by database Row-Level Security policies.
• Automated cross-tenant isolation tests run in the checks every change must pass before it can merge.

Encryption

• In transit: all traffic is served over HTTPS (TLS), with HTTP Strict Transport Security and a Content Security Policy.
• At rest: customer data and stored files are encrypted at rest by our hosting providers.
• Secrets such as API keys and tokens are kept in the hosting platform's encrypted environment settings, not in source code.

Access control and sign-in

• Two-step verification is required for every user of the web application, with an authenticator app or a text-message code.
• A user who has already set up two-step verification can instead ask for a one-time code sent to their own confirmed email address, and can keep a sheet of single-use backup codes for a lost device. Using a backup code emails the user first, signs out their other sessions and has them set up two-step verification again (if that cannot be done at once, the device is trusted for 30 days instead).
• A database-level two-step check, which would also cover the mobile app and direct database-API sessions, is built and not yet switched on.
• Access is role-based: member, admin and super admin tiers with role presets, and admin-configured Sharing Rules that grant read, edit or manage access per module. In an open workspace, a module with no Sharing Rule is available to every member, so customers who want least privilege add a Sharing Rule for each module.
• Non-admin members see their own records, their reports' records (for managers) and unowned records in the main lists, and can be limited further to chosen territories and manufacturers. The application server enforces these limits; the database enforces the workspace boundary, so the mobile app and direct database-API access are limited to the workspace, not to these finer rules.
• Support access: named members of our support staff can enter a customer's workspace to help, at member, admin or super admin level, only after recording a reason. A visit lasts until the staff member exits, and payroll stays closed to them at every level. The workspace's admins are notified in the app when it starts, and each entry and exit, and the changes made during it, are recorded in the workspace's own audit log under the staff member's name, marked as our staff, whatever the workspace's audit switches say. Support access is part of the service and cannot be switched off in the workspace's settings.
• Quarterly reviews of our own administrative access are being set up and have not yet run.

Audit logging

• State-changing actions are written to an append-only audit log: who, what, the before and after values, and when. A database trigger blocks edits to audit rows and blocks deletes outside a retention purge.
• The audit log lives in the same database as the data it describes. An off-platform, tamper-evident copy is built and not yet switched on.
• The audit log also records web-app sign-ins with their IP address and browser, wrong-password attempts, lockouts, completed two-step checks, sign-outs and record opens.

Backups and recovery

• The production database is covered by our database provider's managed backups. A restore of it to a new project was rehearsed on 2026-07-07.
• Uploaded files are not part of the database backups. A separate copy of them (except voice recordings) is made every night with a second provider, encrypted by us before it is sent, and locked against deletion or overwriting for 30 days.
• Recovery-time and recovery-point targets are drafted and not yet adopted, and recovery time has not yet been measured in a drill.

Secure development

• Every change goes through version control and pull-request review, with required automated checks (type checking, a production build and a security and functional test suite) before it can merge. Direct pushes to the production branch are blocked.
• Dependencies are scanned for known vulnerabilities in those required checks.
• A third-party penetration test is planned.

Data handling and retention

• We process customer data only to provide the service.
• We support data export and deletion requests.
• When a user deletes a company, contact or other main record, it is hidden and can be restored for 30 days. A nightly purge then erases it permanently, along with the rows that belong only to it. Audit logs and records the law requires us to keep are retained.

AI features

• Business-card scanning is on in every workspace, and a workspace admin can turn it off: when a user scans a card, the card photo is sent to OpenAI. We do not store the photo, and the user checks the fields before saving.
• AI statement reading is on for every workspace: a commission statement PDF a user uploads or chooses to read is sent to Anthropic, and a person reviews every row it reads before it is saved.
• Report summaries are on for every workspace, and a workspace admin can turn them off: an uploaded manufacturer report is sent to Anthropic, and a person reviews the summary before it goes to anyone.
• The voice assistant (Ginger) is available in every workspace whose plan includes it. A recording needs the user's confirmation that everyone recorded consented, every change it proposes is checked against the user's own workspace and access, and the user reviews each change before it is saved. It never deletes or merges records, changes money or deal stages, or sends messages.
• Every AI request the application makes passes one check in our code, except a company chat site's own key (below): it goes only to a provider our subprocessor list names for that feature, and only while our records show our account with that provider as active. Marking a provider suspended there stops every request to it from the next release. A workspace that adds its own Anthropic API key for its company chat site (Settings → AI Chat) uses its own Anthropic account: that site's requests, and the one request we make to check the key when it is saved, are outside this check.
• What each AI feature sends, and to whom, is on our subprocessor list.

Email capture

• If a workspace connects its reps' Outlook or Gmail mailboxes, we read each new Inbox and Sent message's subject, participants, times and the mail provider's short preview, never the full body or attachments, and keep it as an activity only when an outside participant is already a contact.

AI apps you connect

• Members can connect an AI app of their own to their workspace through our Model Context Protocol (MCP) server. The app receives only the records that member can see. Its provider is your own vendor, chosen by your organization, not our subprocessor.

Subprocessors

• The vendors that process customer data for us, what each receives and when, are on our subprocessor list.

Reporting a vulnerability

• Our security policy says how to report a suspected vulnerability, what is in scope and what to expect. The contact is also in our security.txt file.
• Please ask before you test: our Terms of Service do not allow testing the service without our prior written consent. Do not access data that is not yours or degrade the service.

Changes to this page

• 2026-10-22: Support access: named staff, up to super admin level, until they exit; payroll stays closed; it can no longer be switched off.
• 2026-10-22: Two-step verification: email codes and backup codes. Backups: the nightly encrypted copy of uploaded files is running.
• 2026-10-22: AI features: the voice assistant (Ginger) is available to every workspace whose plan includes it.
• 2026-10-20: AI features: a company chat site that uses the workspace's own Anthropic key is named as outside the provider check.
• 2026-10-19: AI features: every AI request goes only to a provider whose account with us is active.
• 2026-10-19: Support access: switching it off now also ends a visit already in progress.
• 2026-10-19: Reporting a vulnerability links our security policy and asks you to get our consent before testing.
• 2026-10-14: First version of this page.