Security and trust

Every row of data belongs to exactly one organization, and isolation is enforced in the database itself with PostgreSQL row-level security, not just in application code. Policies are org-scoped on every table; QuickBooks connection secrets live in a table with no client access path at all.

This is tested, not assumed: an automated suite of over a hundred isolation checks runs a full cross-tenant matrix: every tenant table against reads, writes, updates, and deletes from another tenant and from unauthenticated clients, including lookups by guessed primary key. The suite includes a schema manifest check that fails the build when a new table is added without isolation probes, so no future table can quietly ship unprotected.

Customer data is encrypted at rest with AES-256 and in transit with TLS. Backups are encrypted at rest with AES-256 as well. Encryption keys are generated per project and protected by keys held in FIPS 140-2 compliant hardware security modules.

The most sensitive values get an additional application layer: QuickBooks OAuth tokens are encrypted with AES-256-GCM using a key that lives only in our server environment, never in the database, never in the browser. Our own nightly backups are additionally encrypted with AES-256 before they leave our infrastructure.

Connections use Intuit’s OAuth flow; we never see or store QuickBooks passwords. Tokens are stored encrypted in a dedicated table that application users cannot query under any circumstances, and they are decrypted only server-side, only after the requesting user’s access to that specific client has been verified. The application reads your clients’ books and never writes to them. You can disconnect a client from inside AboveBoard, which revokes our token with Intuit and deletes it from our systems, or from the QuickBooks side, which invalidates it at the source. Either way syncing stops and the client shows a reconnect banner rather than silently serving stale data.

Data is stored with Supabase on AWS in the United States (us-east-2). The application runs on Vercel in the United States (us-east-2), pinned in our deployment configuration.

AboveBoard is operated by a single person. That means the honest answer to “who can access customer data” is: one operator, through provider dashboards and service credentials, for operations, support, and debugging. Nobody else. Every material action in the application (syncs, report generation, AI drafts, edits, approvals, finalizations, configuration changes) is written to an audit log. Error reports are scrubbed before leaving our servers so that financial figures and client names never reach the error-tracking service, a behavior we verify with automated tests.

The database is backed up nightly, and additionally before every schema change. Backups are AES-256 encrypted before upload and retained for 90 days. Every nightly backup is proven restorable before it counts: an automated job restores the fresh archive into a disposable database and fails loudly on any row-count or content mismatch. We have performed and documented a full restore test, and run restore drills quarterly.

Recovery objectives, stated plainly: we can lose at most 24 hours of data (nightly backup cadence), and restoring service takes 15–60 minutes depending on the scenario. Financial data synced from QuickBooks is additionally re-derivable from the source at any time, so the real exposure is same-day edits to reports, forecasts, and settings. As the product moves out of early access we plan to add managed point-in-time recovery to bring the data-loss window to minutes.