Skip to content
/ HelpLogin

Trust

How we handle your data.

bsns.cc is built around a simple promise: your business records belong to you, not to us. This page lays out the mechanics behind that promise so you can verify it instead of taking our word for it.

Data portability — you can leave

There is no proprietary lock-in. Tenant apps expose structured exports for the records they own. If you cancel, you walk out with the operational data you put in.

  • The tenant app suite ships one-click tenant data exports at Settings → Data export. A tenant admin gets a zip containing JSON rows, flat CSVs for spreadsheet-friendly entities, a manifest.jsonwith counts and schema version, and a README. Same shape, same envelope, across the tenant apps — so a customer who learns one app’s export knows the pattern.
  • Documents signed in pact retain a downloadable executed PDF plus a tamper-evident audit chain (per-tenant chain hash, advisory-locked writes, replayable signature ledger). Both ride in the pact export.
  • Customer-facing message history (SMS and email) is exportable from loop as the canonical timeline. The same conversation can also be replayed from the audit log.
  • There is no proprietary export format. Everything that leaves the suite leaves as CSV, JSON, iCal, or PDF. The archives are structured for migration and support-assisted import; direct CSV import is available where the source app currently ships an importer.
  • Capability tokens (booking links, magic links, signed media URLs) are redacted on export — a leaked archive can’t be replayed against the live system. Sensitive encrypted fields are either excluded or kept only as envelope ciphertext when the app manifest explicitly says the ciphertext is needed for migration.
  • Programmatic export is available where it matters: crew exposes per-resource v1 endpoints (employees, employment history, time entries) gated by personal-access tokens for HR systems that want to pull on a schedule.

Access & tenant isolation

Who can see what is enforced at the database, not the application code. The application layer can have bugs; row-level security is the backstop.

  • Per-tenant row-level security gates every cross-app read and write. A bug at the application layer that forgets to set the tenant scope returns zero rows instead of leaking another tenant’s data.
  • Auth is auth-first: one login, MFA-enforced (TOTP or passkey), session shared across apps via signed JWTs scoped to .bsns.cc.
  • Per-user personal-access tokens (pat_*) for /api/v1 — scoped, revocable, hashed at rest, shown once at creation. Service-to-service traffic uses env-scoped API keys; the two are distinct.
  • View as / impersonation is gated and logged: every launch writes an ImpersonationEvent audit row, tenant-admin sessions are same-tenant and peer-protected, and target users can review session history.

Audit & tamper evidence

For the surfaces where “what happened?” matters most — signed contracts, payments, and cross-app side effects — the suite ships tamper-evident audit trails out of the box.

  • Document signing is anchored by a per-tenant tamper-evident chain (SHA-256 hash of the prior entry). Re-walking the chain detects any modification or deletion after the fact.
  • Every write that touches the chain is wrapped in a Postgres advisory lock so concurrent signers can't fork the chain.
  • Cross-app side effects (notifications, tasks, emails) carry idempotency anchors at the schema level: a duplicate write hits a unique constraint and returns P2002 instead of silently double-firing.
  • Webhook receivers (Stripe, Telnyx, signing) are signature-verified and idempotent against provider event IDs.

Security testing

  • Internal adversarial security reviews were run on 2026-05-25 and again after the late-May planner, AI, RSVP, Hive, and billing changes. Launch-blocking findings from that pass were fixed before the current build.
  • External pen-test engagement is deferred until revenue or an enterprise buyer funds it. The planned scope specifies multi-tenant personas (operator, customer, vendor, super-admin) so cross-tenant leaks are explicitly in scope.
  • PII at rest: DOB, EIN, SSN, tax ID, driver license number, telematics keys, and IdP private keys are AES-256-GCM encrypted with per-app key-encryption keys held in 1Password plus Bitwarden escrow.

Sub-processors & security questionnaire

The full list of third parties that process customer data on our behalf — with purpose, region, and DPA status — lives at /security/sub-processors. Pre-filled answers to the most common prospect security questions (CAIQ-aligned) are at /security/faq. Both pages are maintained in source; a change is a pull request.

Continuity

A separate concern from security: what happens to the suite if the person running it gets hit by a bus? We wrote that out on its own page — see Continuity & bus-factor.

System status

Live incidents and the last 30 days of resolved ones are posted at /status. For business-impacting events we also contact affected customers directly.

Questions, disclosures, incidents

For vulnerability reports, suspected incidents, or anything you want a human to look at, see Support.