Continuity & bus-factor.

bsns.ccis run by a small team. That’s a feature for some of what we do (we move fast, we keep prices low) and a risk for others (what happens if the person running it is unreachable for a week?). This page is the honest answer.

Where your data lives

Customer data lives in a managed Neon Postgres database with point-in-time recovery. Snapshots are hourly, so the recovery point objective is ≤ 1 hour and the recovery time objective is ≤ 1 hour — the last restore drill completed end-to-end in under four minutes. A snapshot is taken automatically before every production deploy; milestone snapshots before major schema changes are retained as named branches for two weeks.

File artifacts (signed PDFs, attachments, executed contracts) live in managed Vercel Blob storage under private access — every fetch requires a bearer token, and customer emails link to authenticated app routes that stream the bytes rather than to the blob directly. The storage adapter sits behind an interface so we can swap providers without changing call sites.

Encryption key escrow

Fields holding PII (DOB, EIN, SSN, tax ID, driver license number, telematics tokens, IdP private keys) are AES-256-GCM encrypted with app-scoped key-encryption keys. Those keys are mirrored into two independent escrows:

• 1Password— operator access via emergency-access grants. An authorized contact can recover keys after a configured waiting period without needing the operator’s master password.
• Bitwarden— secondary escrow with key-fingerprint verification. A maintained escrow-sync script compares each key’s fingerprint against the manifest, warns loudly on drift, and refuses to proceed when two keys collide; running it is part of the key-rotation runbook.

Neither escrow is on the critical path of normal operation; they exist so that a recovering team can always re-derive the keys from a documented chain of custody.

Application code

The source code is in a private Git repository with full commit history. It is replicated to multiple developer machines and to a remote Git host. A documented build runbook lets a competent full-stack engineer recover a production-ready deployment from the repository within a day. There are no hand-rolled binaries or undocumented build steps.

The “what if” runbook

The operational runbook for operator-unavailable scenarios is maintained internally and distributed to a designated continuity contact. It covers: 1Password emergency-access activation, key escrow recovery, Neon database access recovery, DNS / domain rotation, Vercel project access transfer, and customer communication templates.

The runbook is reviewed and rehearsed quarterly. The first full backup-restore drill passed on May 25, 2026; the next cross-vendor restore drill is scheduled for August 25, 2026.

Your data is portable

The deepest form of continuity is being able to leave at any time with the records you put in. See Trust for the export surfaces the tenant apps expose — there is no proprietary format and the archives are designed for migration even when direct import needs support assistance.

Limits we are honest about

• We are not a SOC 2 audited shop yet. That engagement is on the roadmap; until then, we publish what we do and how we do it so you can evaluate it directly.
• We are not a HIPAA-eligible processor. Do not store PHI in the suite.
• We will tell you about any incident that affects your data within 72 hours of detection. We will tell you what we know, what we don’t, and what we’re doing about it.

Questions

If you need a longer continuity / portability commitment in writing for a procurement review or board meeting, contact us and we will share the operational runbook redacted of operator credentials.