Adopted September 28, 2026 · Next review by September 28, 2027
Security policy
A public summary of the information security policy Countorra works to. It describes what is enforced today, in the code, the database and the way changes are released, and says what Countorra does not claim. The short version is on the Security page.
What the policy is for
- Your financial data, bank connections, transactions, balances, tax figures and documents, can be read only from the workspace that owns it.
- Credentials for financial providers are never stored in plain text and never leave the server.
- Someone who gets into one workspace's session cannot reach another workspace.
- Security-relevant events are recorded in a trail that whoever caused them cannot edit.
Signing in
Authentication
Sessions are managed through Supabase Auth and refreshed on every request at the routing layer, so a session is never trusted from what the browser holds alone. A request to any part of the app without a valid session is sent to sign in before a page renders.
Two-step verification
You can turn on two-step verification with an authenticator app (TOTP), in Settings under Security. From then on every sign-in asks for a code after your password, and nothing in the product opens until it is entered: the check runs on the server, for every page and action. The secret is generated and held by Supabase Auth; Countorra never stores it and never records a code, and code attempts are limited. There are no backup codes. If you lose your authenticator, choose “Email me a link to remove it” at the code step: the link works once, for 15 minutes, in the browser where you entered your password, and it removes the authenticator and signs you out everywhere, so you can sign in and set up a new one. Neither your password nor your inbox alone is enough.
Signing out after inactivity
If you leave Countorra open for 10 minutes without using it, you are signed out and asked to sign in again. The server enforces this on every request, so it doesn't depend on the open page; the screen is covered at the same moment, so a computer left unattended doesn't keep showing your records.
Your records
Data isolation
Every table that holds financial data carries a row-level security policy scoped to the workspace. A query from one workspace's session cannot return another workspace's rows, whatever the application code asks for.
Authorization
What a signed-in person can do in a workspace is checked on the server and again in the database. Nobody can give themselves more access than they were granted: the database blocks it, not only the application.
Encryption in transit
Every connection to Countorra is HTTPS, and browsers are told (HSTS) to use nothing else for two years.
Private documents
Uploaded documents are stored privately, under a path that belongs to one workspace and has its own access policy. The storage is never public: only someone signed in to that workspace can ask for a document, and the link they receive expires within minutes.
Auditability
Changes to financial records write to an append-only audit log. The table itself refuses edits, and any deletion before an entry's retention period ends, at the database level: a change can be superseded by a new entry, never altered after the fact. Entries are kept for 24 months, then deleted automatically. Account-level events, such as turning two-step verification on or off and failed codes, are recorded separately, and only the server can write them.
AI action control
The assistant can read, analyze and calculate. Every calculation runs through a deterministic engine on the server, so the model never invents a figure. Anything that would write or delete a record waits as a proposal until you confirm it.
Connections and providers
Bank connections
Bank sign-in happens in Plaid's window: Countorra never receives your bank username or password. The access key Plaid issues for a connection is encrypted with AES-256-GCM before it is stored, with the workspace and the connection bound into the encryption, under a key held only in the server environment and never in the database, in a table no member role can read. It is never sent to the browser. Returning from a bank's own sign-in page uses one fixed address for everyone; which workspace you return to comes from an encrypted, server-issued session tied to your sign-in, never from the address itself.
Provider credentials and webhooks
Credentials for Plaid, Stripe and Countorra's other providers are held as environment variables on the server and never committed to the code. Modules that use them are marked server-only, so none is ever included in what your browser downloads. Messages Plaid and Stripe send to Countorra are verified against their signatures before anything in them is acted on, and a message delivered twice is processed once.
Background work
Bank imports run in a background worker on the server. It can be started only with a deployment secret, it is rate limited like any other caller, and every job it runs is bound to one workspace, so it cannot read or write another's data. It stops itself well inside its time limit, and work interrupted part-way is picked up again without being duplicated.
Monitoring
Errors and security-relevant events, such as refused sign-ins, rate limits, rejected webhooks and the background worker's health, are recorded through one filter that removes passwords, tokens, email addresses, amounts and the content of AI questions before anything is written.
Providers
Every provider that receives data, and what it receives, is listed on the subprocessors page and in the Privacy Policy.
Building and releasing
Secure development
Countorra is written in TypeScript in strict mode. Before a release, the type checks, the linter, the automated tests and a production build must pass. The tests include row-level security and workspace-isolation tests run against a real Postgres database. Database changes ship as numbered migrations and are checked against the live database after they are applied. Secrets are never committed.
Change management
Every change runs on a preview deployment before it is promoted to production. If a release is wrong, the last good one can be promoted back in one step, without a rebuild.
Incidents
Countorra keeps a written incident response plan. It covers how an incident is detected, how serious it is, how it is contained, the order in which credentials are rotated, working out who is affected, keeping evidence, telling the people affected, and a review afterwards.
To report a security issue, see responsible disclosure.
Leaving Countorra
Deleting your account
Account deletion is self-serve and requires your password again. First, Countorra cancels the Stripe subscription of every workspace being deleted and confirms with Stripe that nothing can be charged again; if that cannot be confirmed, nothing is deleted. Then it asks Plaid to end its access and destroys every stored bank access key; if a key cannot be destroyed, nothing is deleted. Documents are removed from storage, then the workspaces you alone use, then your sign-in. A workspace cannot be deleted directly from the browser, and the database refuses to delete one whose subscription can still be charged.
What Countorra does not claim
Countorra has not been audited or certified by a third party: there is no SOC 2 report, ISO 27001 certification, PCI DSS certification or independent penetration test. Card payments are handled entirely by Stripe, so card numbers never reach Countorra. No system is perfectly secure.
Review
The policy was adopted on September 28, 2026. It is reviewed every year, and whenever the architecture or the providers change in a way that matters. The next review is due by September 28, 2027.