Security.
What we do, and what we don't yet.

§ 01Where your data lives

Your boards and files stay in the EU. The application and its Postgres database run in Helsinki, Finland on UpCloud, a Finnish provider. The database is reachable only over a private network. Attachments and backups sit in UpCloud object storage in the EU (Finland, Sweden and Germany). Videos are stored in Frankfurt, replicated to Stockholm, and served, like image thumbnails, through Bunny.net edge servers restricted to the EU. Voice rooms run on our own media server in Helsinki.

Apart from sign-in and import services you choose to connect, three services reach outside the EU, and none of them sees your boards: payments (Paddle, UK/US) receive billing details; once per account, a hash of your email is checked against Gravatar (US) for a profile picture, which you can turn off in Settings › Privacy; and the meeting notetaker (Recall.ai) keeps call audio in its Frankfurt deployment but is operated by a US company, so it hears only the calls you invite it to. We tell you in advance before any of this changes.

§ 02Encryption

In transit: TLS everywhere, with HSTS (preload directive included) on taulu.app. The application talks to its database over TLS and verifies the provider's certificate.

At rest: the managed database runs on fully encrypted volumes (UpCloud). Every attachment is written with server-side AES-256 encryption. Nightly database dumps are encrypted with age before they leave the server; the decryption key lives in our password manager and is never on a server. Connected-tool tokens, two-factor secrets and single sign-on client secrets are stored encrypted with AES-256-GCM under a rotating key that exists only in the runtime environment. Payment card data never reaches us at all; Paddle handles it.

Voice rooms are end-to-end encrypted. Each time you join, your browser mints a fresh key pair and the room key is handed to you wrapped for that key alone. Our media server relays audio it cannot decrypt, our application server never holds a room key, and the key rotates whenever someone leaves. Two honest limits: the signalling, the rooms list and room chat travel over TLS but are not end-to-end encrypted, and keys are not yet pinned to accounts, so there are no safety numbers to compare. Recording is the one exception to our servers never hearing a room: only if everyone in the room agrees does the room key also go to our recorder in Helsinki, which decrypts the call so it can be transcribed and then deletes the audio. The meeting notetaker is separate from voice rooms: it joins an external Meet, Zoom or Teams call as a visible participant, and its recording is deleted at Recall.ai as soon as we have fetched it and here once the memo lands.

§ 03Signing in

There are no passwords to leak. You sign in with a one-time email link that works once and expires after 60 minutes, or with a passkey, or through Google or GitHub. Optional two-factor adds an authenticator app with eight single-use recovery codes, and a passkey can stand in for both. Once you have a second factor, adding or removing a passkey or deleting your account asks for it again, and setting up your first authenticator or passkey, removing your last passkey or turning two-factor off first asks you to confirm by email, so a stolen session cannot plant a way back in.

Sessions are bearer tokens, never cookies. They are stored hashed, expire after 90 days or 30 days of disuse, are capped at 20 per account, and every one is listed in Settings › Sessions where you can revoke it. Sign-in and every API endpoint are rate-limited, and asking for a link never reveals whether an address has an account.

Organizations can bring their own identity provider. Any OpenID Connect provider works: you prove you own your email domain with a DNS record, test the connection, and from then on your people sign in through your provider and land in your organization. Turn on Require SSO and every other way in closes for everyone at those domains — email link, Google, GitHub, passkey — except your own admins, who keep every way in so a broken provider cannot lock you out. Switching it on ends the sessions it now covers, and everyone gets an email. Configured, tested, required, removed: all of it is written to your organization's log. We match people on the subject your provider issues, never on an email address alone. SAML and SCIM are not available; removing someone at your provider stops new sign-ins, and you still remove their membership in Taulu.

§ 04Who can see a board

Only people you gave a role to. There are no public boards and a board link on its own opens nothing. Access comes from an org role, a team, or a direct grant, and the database itself refuses a grant that would cross organizations. Every permission check runs through one server-side policy, on every edit, and a revoked role disconnects the editor live.

Every change to who can do what is written to an append-only audit log that the database will not let anyone edit or delete. Our staff see organizations masked by default, and our admin tools have no way to open board content. We look at content only when it's reported for abuse or the law requires it, then only at what was reported, and we tell the org's admins unless the law forbids it. Opening an org's name for support takes either your admin's time-boxed permission or a logged emergency unmask that lasts 24 hours and emails every admin of that org. Staff need two-factor to reach the console at all, and must confirm it again before an emergency unmask.

§ 05Backups and recovery

Two independent layers. The managed database keeps point-in-time recovery, and a nightly encrypted dump lands in a separate bucket that the application can only write to, never read or delete, so a compromised server cannot destroy the copies that would undo it. Dumps are kept for 30 days. A watcher outside our servers checks every morning that a fresh, encrypted dump arrived and raises an alarm if it did not.

What we don't claim yet: a full restore drill has not been run. It is on the checklist before the public launch, and this page will say so when it has.

§ 06How we build

Every board edit passes through a single server-side gate that validates it against a throwaway copy before anything is applied, so a malformed or hostile update is rejected before it reaches your team. Every build audits its dependencies for known vulnerabilities and refuses to ship with one; dependency updates wait a cooldown so a yanked release rarely lands. The compiler treats warnings as errors.

A strict content security policy forbids inline scripts on every page, and inline styles everywhere except the one exception our payment provider's checkout needs, and a lint step bans the browser and server APIs that make injection possible. Tests enforce that every route is either authenticated or explicitly justified, that every API route is rate-limited, and that no personal data can reach our alerting. Releases are immutable images that boot against a fresh database before they deploy, and a failed health check rolls the previous image back automatically. Long-running containers drop every Linux capability they don't need, and the operating system applies security updates on its own.

§ 07Monitoring and incidents

Errors and performance are tracked in AppSignal with tokens, emails and secrets filtered out before anything is sent. An external monitor watches the readiness endpoint, and internal alerts reach us with ids only, never names, emails or board content. Uptime is best-effort without a formal SLA, and we tell affected users about significant incidents by email. There is no public status page yet.

§ 08Sub-processors

Every company that receives data from us. Paddle and Gravatar act as independent controllers (below); the others are our sub-processors, and we email org admins 30 days before adding one.

What each of them is certified for, and where to read their data processing agreement. Only UpCloud publishes its certificate; the others share certificates and audit reports on request through their trust centers. Paddle, as merchant of record, and Gravatar decide how they use what they receive, so they act as independent controllers rather than under a processing agreement with us.

§ 09Reporting a vulnerability

Found something? Email support@taulu.app and it lands with the people who wrote the code. Tell us what you found, how to reproduce it, and what you think it affects. You will get a reply within three business days and a fix or an honest timeline after that. The machine-readable version is at /.well-known/security.txt.

Good-faith research is welcome and we will not take legal action over it. Please stay inside your own account and test data, don't read or change other people's boards, don't run denial-of-service or brute-force tooling against us, and give us a reasonable time to fix before publishing. We don't run a bug bounty; we do say thank you in the changelog if you'd like the credit.

§ 10Certifications

None of our own yet. Taulu is a small company and we would rather spend on the controls above than on a badge nobody has asked for. What we inherit: UpCloud, which runs everything, holds ISO/IEC 27001:2022 for its cloud service and follows the CISPE Data Protection Code, and card payments are handled entirely by Paddle under PCI DSS. Every other provider's certifications are listed under sub-processors. If your procurement needs a security questionnaire answered, email support@taulu.app; we fill them in ourselves, within a week.