Security & trust

Security controls for tenant isolation, field payments, and customer records

Thorbis security starts with company-scoped data, Row-Level Security, processor-delegated card handling, signed customer links, and reviewable trust documentation for buyers who need proof before rollout.

Security posture Reviewed
01

Row-Level Security on every table

Tenant isolation at the DB engine

Enforced
02

Encryption in transit and at rest

Documented control area

Required
03

SOC 2 readiness

Trust Services Criteria mapped

In progress

RLS

Tenant isolation

TLS

In transit

Backups

Recovery path

Trust center workflow

Security review without the scavenger hunt.

Buyers should be able to request documentation, review controls, and monitor uptime from clear, named paths.

Request

Security packet, questionnaires, and NDA-protected documentation start with security@thorbis.com.

Review

Buyers can review infrastructure, subprocessors, payment handling, and data isolation in one place.

Monitor

Status, incident updates, and postmortems keep operational trust visible after launch.

Foundations

Security pillars

Managed infrastructure

Thorbis uses managed database, storage, and web delivery providers so core controls such as access, encryption, backups, and monitoring can be reviewed as part of the security packet.

Secure development lifecycle

All code changes undergo peer review, automated testing, and static analysis. Secrets management, least privilege access, and dependency scanning are mandatory.

Compliance readiness

Thorbis maps security controls to common buyer-review areas such as SOC 2 readiness, privacy requests, subprocessors, SMS consent, and payment-data handling.

Customer data ownership

You control your data. Export and deletion workflows are part of the account lifecycle, and security review materials explain how requests are handled.

Data lifecycle

How customer data moves through Thorbis.

Security is easier to evaluate when the lifecycle is explicit: scope, access, storage, export, and deletion.

  1. 1 Business data is scoped to a company record
  2. 2 User access is constrained by role and Row-Level Security
  3. 3 Files and customer portal links use private storage or signed URLs
  4. 4 Exports and deletion paths are available when the account ends
Managed infrastructure

Infrastructure

Thorbis uses managed infrastructure for database, storage, web delivery, and operational workflows so buyers can review security responsibilities clearly instead of guessing where controls live.

Database and tenant isolation

  • Row-Level Security (RLS) enabled on every table, tenant isolation enforced at the database engine, not just the application layer
  • Application queries are scoped to the authenticated company and role
  • Privileged service-role access is limited to server-side jobs that require it
  • Backups and recovery procedures are documented for security review

Web delivery and transport security

  • Public marketing and application traffic is served over HTTPS
  • Managed certificate handling reduces manual renewal risk
  • Security headers and robots/canonical handling are reviewed as part of release work
  • Operational status and incident communications have a clear public destination

Encryption

  • Data in transit is protected with HTTPS/TLS
  • Sensitive data storage uses managed-provider encryption controls
  • Private files and customer portal links use access controls or signed links
  • Secrets are kept in server-side environment configuration, not client bundles

Availability & Resilience

  • Status updates and incident notes are routed through the public status page
  • Monitoring and alerting paths are part of the incident response plan
  • Recovery procedures cover database backups, file access, and customer communications
  • Release checks are designed to catch metadata, schema, and routing regressions before launch
Access control

Authentication & access control

We use Supabase Auth for all authentication flows, with short-lived tokens, secure cookie storage, and role-based access controls scoped to your company.

JWT tokens with short expiry

Supabase Auth issues JWTs with a 1-hour expiry. Refresh token rotation is enabled, each use issues a new token and invalidates the old one, limiting the window for stolen token abuse.

Multiple authentication methods

Email/password with bcrypt hashing, magic link (passwordless email), and OAuth providers (Google, Microsoft). Passwords are never stored in plaintext.

HttpOnly secure cookies

Session tokens are stored in httpOnly, Secure, SameSite=Lax cookies, not localStorage. This prevents JavaScript from reading the token, blocking the most common XSS token theft vector.

Role-based access control (RBAC)

Five built-in roles: Owner, Admin, Dispatcher, Technician, and View-Only. Each role has a narrowly scoped permission set. Technicians cannot access financial data or customer payment methods.

Row-Level Security on every query

Every Supabase query is automatically scoped to the authenticated user's company_id via RLS policies. Even if application code contained a bug, the database engine would reject cross-tenant queries.

Service role key never exposed to clients

The Supabase service role key (which bypasses RLS) is stored only in server-side environment variables and is never included in client-side bundles or API responses.

Tenant isolation

Data isolation

Your data is never commingled with another company's data. Isolation is enforced at the database engine level, not just by application code.

Company-scoped at the schema level

Every table that stores business data includes a company_id column. There is no shared table that mixes data from different tenants without strict filtering.

Database-enforced, not application-enforced

RLS policies are defined directly in PostgreSQL. The application layer cannot issue a query that returns another company's data, the database rejects it at the engine level before any results are returned.

Defense in depth

Even if an application bug, misconfigured query, or compromised dependency attempted to access cross-tenant data, the RLS policy would block it. Isolation does not depend on a single layer being correct.

Supabase service role access is restricted

Only background workers that require privileged access (such as migration scripts and scheduled jobs) use the service role. All user-facing API routes use the authenticated client, which is subject to full RLS enforcement.

Payments

Payment security

Thorbis payment workflows are designed so raw card handling stays with the configured processor. The app should keep processor tokens, payment references, and audit records instead of raw card numbers.

Processor-handled

Field payment processor

Field payment workflows delegate raw card handling to the configured payment processor. Thorbis should store payment references and operational records, not raw card numbers.

Tokenized

Subscription billing processor

Subscription billing is routed through a billing provider so card entry, tokenization, and processor compliance remain outside Thorbis application servers.

Signed events

Webhook signature verification

Incoming payment webhooks are expected to be verified before processing. Unsigned or incorrectly signed events should be rejected immediately.

Messaging

Communication security

SMS, email, and customer-portal access need clear authentication, consent, opt-out, and access-control paths. Customer portal links use signed-token patterns instead of exposing sensitive data in URLs.

SMS, Twilio A2P 10DLC

  • Outbound SMS setup uses A2P 10DLC registration where required for US application-to-person messaging
  • STOP, HELP, and CANCEL keywords are handled automatically, and opt-outs are honored promptly as required by TCPA
  • Message content and delivery records are access-controlled and scoped to the account

Email authentication

  • Outbound email domains should be authenticated with DKIM so receiving servers can verify message authenticity
  • SPF records should restrict which servers are authorized to send on behalf of each domain
  • DMARC policy can be configured to guide handling for unauthenticated messages
  • Email sending configuration is part of onboarding and support review

Customer portal security

  • Customer portal links use time-limited signed tokens, links expire after 72 hours by default
  • No sensitive data (payment amounts, personal details) is included in URL parameters
  • Portal sessions are scoped to a single customer record and cannot be used to access other customers' data
Certifications

Certifications & compliance

Security reviews usually ask about SOC 2 readiness, privacy requests, SMS consent, payment-data handling, access control, and subprocessors. This page explains the control areas without claiming certifications that are not published. Ongoing hardening across auth, row-level data access, and admin operations is tracked in development on the public roadmap.

SOC 2 readiness

In progress

Controls are mapped to the SOC 2 Trust Services Criteria. Formal report availability should be confirmed during security review before procurement relies on it.

Privacy requests

Documented

Security review materials describe the workflow for access, deletion, portability, subprocessors, and data-processing questions.

CCPA / state privacy

Reviewed

Thorbis does not sell personal data, and privacy-request handling is documented for buyers who need a legal or procurement review.

TCPA / SMS consent

Operational control

SMS workflows require consent handling, opt-out support, and clear message-frequency disclosures before customer messaging is enabled.

PCI DSS scope

Processor-delegated

Cardholder data handling is delegated to payment processors. Thorbis should retain tokens, references, and audit records rather than raw card numbers.

Security testing

Risk-based

Testing, vulnerability review, and remediation are handled on a risk-prioritized schedule. Available summaries can be requested as part of the security packet.

Employee security controls

  • MFA required for all employee accounts
  • SSO enforced for all internal tooling
  • Least-privilege access, employees only see what their role requires
  • Production access requires explicit approval
  • Security awareness and data-handling expectations are documented
  • Offboarding checklist revokes access when a team member leaves
When something breaks

Incident response

We define three severity tiers with documented response times, communication requirements, and postmortem obligations. Security issues can be reported to security@thorbis.com.

P1

Data breach / security incident

  • 0-15 min Automated detection and on-call alert
  • Triage Scope affected systems, data types, and customer impact
  • Contain Disable affected access paths and preserve evidence
  • Notify Notify affected customers when impact is confirmed and legally required
P2

Full service outage

  • 0-30 min Detection and incident opened on status page
  • Updates Status page updated as investigation and recovery progress
  • Resolution Post-incident summary prepared when customer impact warrants it
P3

Degraded performance

  • 0-1 hour Detection and investigation begins
  • Review Logged to status page when customer impact is material
  • Resolution Status page updated when performance returns to normal

Report a security vulnerability

Email security@thorbis.com with details. Reports are triaged through the incident process, and good-faith coordinated disclosure is welcome.

FAQ

Frequently asked questions

How is my customer data isolated from other companies?

Every table that stores business data includes a company_id column. Row-Level Security (RLS) policies in PostgreSQL enforce that every query, regardless of what the application code does, only returns rows matching your company_id. This means isolation is enforced at the database engine level. Even a bug in our application code could not cause your data to be returned to a different company.

What happens to my data if I cancel?

You can request an export of your core account data before cancellation is finalized. Security review materials describe the export, deletion, and backup-retention process so legal or procurement teams can confirm the current operational policy.

Do technicians have access to financial data?

No. The Technician role has access to job details, schedules, customer contact information, and field notes, but not to payment methods, invoice amounts, or financial reports. Role permissions are enforced at both the application layer and via RLS policies in the database. Owners and Admins can further restrict what each technician sees within the platform settings.

Can I get a security review or complete a security questionnaire?

Yes. Email security@thorbis.com with your questionnaire or requirements. Available security documentation, subprocessors, data-flow notes, and control summaries can be shared as part of a buyer review.

What are your backup and recovery policies?

Backup and recovery procedures are documented for security review. The review packet explains what data is covered, how restores are handled, and which operational recovery paths apply to customer records, files, and service availability.

Where is data stored?

Data-residency and storage questions are handled through the security review packet because the answer can depend on the product surface, provider configuration, and customer requirements.

How do you handle subprocessors?

Thorbis maintains a subprocessor review process covering database, infrastructure, billing, payments, messaging, email, analytics, and support providers. Buyers can request the current list with data categories and processing purposes.

Do you conduct penetration tests?

Security testing and vulnerability review are handled on a risk-prioritized schedule. Available summaries, scope notes, and remediation context can be requested during procurement or security review.

How do you handle incidents?

Thorbis maintains incident severity tiers for security issues, outages, and degraded performance. The process covers detection, triage, containment, customer communication, and follow-up review. Security issues can be reported to security@thorbis.com.

Is employee access to customer data logged?

Yes. All administrative access to production data is logged with the employee identity, timestamp, and action taken. Access to customer data by Thorbis employees requires an active support session initiated by the customer or an escalation approved by the customer. Logs are retained for 12 months and are available for review upon request.

Still have security questions?

Our security team can complete questionnaires, provide documentation under NDA, or schedule a technical review call for larger buyer reviews.

Built for operators

A shared operating layer behind every page

Whether a buyer starts on an industry, feature, migration, or tool page, Thorbis routes the conversation back to the same product system: jobs, money, customers, and team work in one place.

01

One workspace

CRM, dispatch, estimates, invoices, payments, and reporting stay connected.

02

Unlimited users

Bring owners, office staff, dispatchers, techs, and managers into the same system.

03

Guided switch

Migration planning, validation, and cutover support are built into the buying path.