Security and trust
Last updated: 18 May 2026
Taulu is built by a small team in Helsinki. Your boards are where your team’s thinking lives, so the bar for keeping them safe has to be the same one you would set for your own inbox. This page describes what we do today, what we plan to do next, and the things we cannot yet promise.
Where your data lives
Application servers, the Postgres database, S3-compatible object storage, and the voice routing server all run in Helsinki, Finland on UpCloud’s fi-hel1 region. Encrypted offsite backups go to a second UpCloud region inside the EU. We do not replicate Customer Content outside the EU.
The full sub-processor table, including which providers handle billing, transactional email, error monitoring, and the optional photo-import OCR, is published in the Privacy notice. We tell you 30 days before adding or replacing any sub-processor.
Encryption
- All traffic between your browser and Taulu uses TLS 1.2 or newer.
- Object storage (your uploaded files, board attachments, exports) is encrypted at rest.
- Postgres snapshots used for backup are encrypted before they leave the primary region.
- Voice rooms layer SFrame end-to-end encryption on top of SRTP and TLS. Symmetric keys are generated per room, distributed only to clients holding a valid board-membership token, and held in memory only. Our routing server forwards ciphertext and cannot decrypt audio. Voice state never persists to disk; a server restart resets it.
Authentication and sessions
Sign-in is by magic link (Brevo transactional email) or OAuth with Google or GitHub. We do not store passwords. Session cookies are HttpOnly and SameSite, and the optional “remember me” token extends a sign-in for up to 90 days before requiring a fresh proof. You can revoke active sessions and remove linked OAuth identities at any time from Settings.
Audit logging and support access
Every administrative mutation is recorded in an append-only audit log. When you ask for debugging help you can grant a time-boxed (24-hour or 7-day) read-only session to a named support agent for a specific board. The grant is scoped, expirable, revocable, and audit-logged.
Operators also have a break-glass observer path for incident response. It is never silent: every session is logged and reviewable.
Incident response
If we become aware of a personal-data breach affecting Customer Content we notify affected customers without undue delay and in any event within 72 hours of becoming aware. The notice describes the nature of the breach, the categories and approximate volume of records concerned, the likely consequences, and the measures taken. The detail lives in §12 of the DPA.
Retention
| Data | Window |
|---|---|
| Account data | While your account exists; deleted on request |
| Board content | While the board is live; soft-deleted boards are hard-purged shortly after |
| Inactive organisations | Notified at 12 months of no activity, hard-deleted at 24 months |
| Audit events | Indefinite, for the integrity of the audit trail |
| Error reports (scrubbed) | 90 days |
| Encrypted database backups | 14 days locally, longer offsite per ops process |
Things we deliberately do not do
- We do not sell, share, or train external models on your content.
- We do not set marketing or third-party analytics cookies. Analytics is opt-in. The full cookie list is on the Cookies page.
- We do not record voice. The Egress feature in our SFU is disabled at the server configuration level.
- We do not allow silent observers in voice rooms. Every participant appears in the room list.
What we do not yet have
Honesty serves you better than a polished claim.
- No SOC 2 report. We are too small for the cost of the audit to be a defensible expense yet, and we would rather invest in product safety than in a certification. We will revisit when team size or customer demand makes it worthwhile.
- No published external penetration test report. Customers on the Enterprise tier can request a summary under NDA.
- No open-source client builds yet. Web applications load fresh JavaScript on every page view; you implicitly trust the code we serve. We are working towards Subresource Integrity hashes and reproducible client builds so that the code in your browser can be verified.
- No native apps yet. The same fresh-JS surface applies on the web; native distribution would let us narrow it.
Reporting a vulnerability
If you have found something we should fix, email [email protected] with the word “security” in the subject line. We acknowledge in one working day, keep you updated through triage, and credit you in the release notes for the fix unless you prefer to stay anonymous. We do not run a paid bug bounty programme yet.
Contact
For security or privacy questions: [email protected] with “security” or “privacy” in the subject line.
sampsa.dev oy Fredikanterassi 7 C 120 00520 Helsinki Finland