Talisk holds two of the most sensitive things a business has: its email and its financial records. The architecture was built around that fact from day one. This page describes the measures in place.
01Account isolation, enforced by the database
Every Talisk account's data — mail, contacts, books, documents — lives in its own isolated database schema. Your data and another customer's data are never in the same tables. On top of that physical separation, PostgreSQL Row-Level Security policies are enforced by the database engine itself, so isolation does not depend on application code being bug-free: even a hypothetical application-layer flaw hits a database that refuses to return another account's rows.
The database also carries defence-in-depth guards against destructive operations (engine-level triggers that block bulk deletion of user data outside a deliberate, audited procedure).
02Encryption
- In transit: all connections to the Service use TLS (HTTPS). Traffic passes through Cloudflare's network, which filters attacks, and travels on to our server over a second TLS connection that verifies our certificate.
- At rest: personal content — email bodies, contact details, financial documents — is encrypted at rest with a per-account encryption key (Fernet, AES-based). Uploaded files such as receipt images and attachments are encrypted at rest as well.
- Credentials: passwords are stored as salted hashes. OAuth tokens for connected services are encrypted at rest.
- Passwords saved in the desktop app: on a Mac, the app can save the password of a website you keep open as a tab. It is stored in that Mac's Keychain, with the sites of the app window it was saved in, and never sent to our servers. Only the Talisk app can read it without asking you (Keychain Access shows it after your Mac password). It is filled only into the exact site it was saved for, and only after Touch ID or the Mac password. The small script that saves and fills runs apart from the website's own code and never inside a frame embedded in the page.
- Amounts and dates: stored as plain numbers inside your account's own isolated database schema, so the database can total them for your reports. Like everything else in your schema, they are never readable from another account.
- Key custody: per-account keys are derived from a master key held on the application server, because the app needs it to show you your data. The application encrypts your content before it is ever written to disk, so it does not rely on the storage underneath to keep it private. Your content stays protected in any copy of the database or a backup, and the server itself is locked down: SSH-key-only access and two-factor sign-in on our hosting and code accounts. Backups use a separate key that is never kept on the server (below).
03Backups
Nightly database backups are GPG public-key encrypted before they leave the server and stored off-site in object storage. The decryption key is not stored with the backups (key custody is split between separate locations). Backups are restore-tested automatically every day, and expire within 90 days. Separately, our hosting provider takes monthly full-server snapshots, which are kept for 12 months; they are protected by the provider's access controls.
04Access control
- Two-factor authentication is available on every account, and we recommend it. It is required before you connect a bank.
- Application database access runs under a dedicated role subject to the row-level security policies above — not a superuser account.
- Human access to customer content is governed by the Limited Use commitments in our Privacy Policy: nobody reads your data except with your consent, for security investigation, or where the law requires.
05Payment security
Subscription payments are processed by Stripe, a PCI-DSS Level 1 certified payment processor. Your card number and verification code go directly to Stripe — Talisk never stores full card details.
06Service providers
The small set of providers that run parts of the Service (hosting, AI, payments, transactional email), what each receives, and where they are located is published at taliskhq.com/subprocessors. AI processing is covered in the Privacy Policy: our AI provider is contractually barred from training on your data.
07Data retention and deletion
You can delete your account yourself from Settings. The account locks at once, and seven days later its entire schema — mail, contacts, books, documents — is erased from the live system unless you sign in and keep it. Encrypted database backups then expire within 90 days, and monthly full-server snapshots within 12 months. The off-site mirror of uploaded documents is additive; an erased account's documents are removed from it 12 months after erasure, once the last backup that could hold the account has expired. Details in the Privacy Policy.
08Assessments
Talisk's CASA (Cloud Application Security Assessment) is underway. It is the security assessment Google requires of every app that accesses Gmail data. This page will be updated when it completes.
09Reporting a vulnerability
We welcome reports from security researchers and anyone else who spots a problem. If you believe you have found a vulnerability in Talisk, email security@taliskhq.com with enough detail for us to reproduce it. We will acknowledge your report promptly and keep you updated on our progress. Good-faith research that respects user data and avoids disrupting the service is covered by our safe harbour: we will work with you, never against you.