Closebook · Legal
Security
How Closebook keeps one tenant out of another's data, what happens to connector credentials, and what we record. It starts with what we do not have, because that is what a security review needs first.
Last updated 10 September 2026
What we do not have
First, because it is what a security review wants to know and burying it would be a waste of your time: Closebook holds no SOC 2, ISO 27001 or equivalent certification. We are a small team and we have not been through an audit. There is no penetration test report to send you yet.
What follows is a description of practices you can verify by asking us to demonstrate them, not a claim someone else has signed off. If your procurement process requires a certificate, we will not pass it, and we would rather you knew that now.
Tenant isolation is enforced in the database
Every table carrying workspace data has row-level security enabled, and the policy on it checks workspace membership. A query for another tenant's rows returns nothing — not because application code remembered to add a filter, but because the database refuses.
This is the design decision we would defend hardest. The common way multi-tenant products leak is a missing WHERE workspace_id = … on one endpoint out of two hundred. Moving the fence into the database makes that class of bug structurally unavailable.
Cross-tenant reads exist for platform administrators only, and every one of those server functions re-checks administrator status against the caller's own restricted database session before it uses an elevated key.
Connector credentials
- API keys and OAuth tokens are encrypted at rest with AES-256-GCM before they reach the database.
- They are never sent back to a browser. The interface shows whether a credential exists, never the credential.
- Where a provider offers read-only scopes, Closebook asks for those. It has no ability to move money and never requests one.
- Disconnecting a source deletes the stored credential immediately.
- Rotating our encryption key is a supported operation and does not lose access to data encrypted under the previous key.
Who can see your data
Inside your workspace, you decide: owner, admin, member and viewer roles determine what each person can read and change, and you manage that list yourself.
On our side, access to production is limited to the engineers who operate it, used to investigate faults and keep the service running, and recorded. Administrative actions taken through the platform console are written to an append-only audit log with the operator, the target and the payload.
Everything that changes a record is recorded
Closebook keeps a workspace activity log of who changed which record and when, and a separate platform audit log of operator actions. This is not only a security control: in a finance tool, "who changed this number and when" is a question that gets asked in earnest, and an answer of "we don't log that" is not survivable.
Infrastructure
- Application — Frankfurt, European Union (Vercel, region fra1).
- Database — managed Postgres with Supabase, Frankfurt, European Union (Supabase, eu-central-1), encrypted at rest, with automated backups and point-in-time recovery on the managed plan.
- Transport — TLS everywhere; the application is served over HTTPS only.
- Secrets — held in the platform's encrypted environment configuration, never in the repository.
- Sub-processors — named publicly, so you can hand the list to whoever asks for it.
How changes reach production
- Every change goes through version control and a pull request; nothing is edited on a live server.
- Type checking, linting and a production build run before a change can ship.
- Database changes are append-only, numbered SQL migrations, applied in order — never an ad-hoc edit against production.
- Dependency installs enforce a delay on newly published package versions, which blunts the most common supply-chain attack.
Getting your data out, and deletion
Transactions, invoices and mappings export to CSV and Excel at any time, on every plan. On termination you have thirty days to export before deletion, or you can ask us in writing to delete sooner. Retention periods for everything else are itemised in the privacy policy.
If something goes wrong
If a breach affects your data we will tell you without undue delay, with what we know, what we are doing, and what you may need to do. Where a law sets a notification deadline we will meet it.
Reporting a vulnerability: email security@vizio.ai. Please give us a reasonable window before disclosing publicly. We will not pursue legal action against anyone who reports in good faith, stays within their own test data and does not exfiltrate anyone else's.
Security questionnaires
Send them to security@vizio.ai and a person will complete them. We will answer "no" where the answer is no. On Enterprise we will sign a data processing addendum and negotiate specific commitments.