Security

How we secure the service

Here are the security measures in use in Sayable today. We only describe what is actually in place. If a measure is not listed here, do not assume it exists.

Last updated 6 November 2026

In short: You can transcribe and make summaries entirely locally on Mac, Windows, iPhone and Android. What you put in the cloud goes over an encrypted connection and is stored with providers that encrypt it on disk. Sign-in is passwordless, and the team's administrators only see the meetings the members have shared themselves.

Local processing

In local mode on Mac, Windows, iPhone and Android, the audio, the transcripts and the summaries stay on the device. If you are signed in, some things still go to your account, for example the dictionary, summary templates and notes when syncing is on. The privacy policy says exactly what.

The Mac app stores the meetings in a folder that only your user account can access. The apps do not encrypt the meetings on disk themselves. It is the encryption of the computer, FileVault on Mac and BitLocker on Windows, that protects them if the computer goes missing. Your sign-in is stored in the keychain on Mac and in Windows Credential Manager.

Encryption

All traffic to sayable.no, app.sayable.no, api.sayable.no and dl.sayable.no goes over an encrypted connection (TLS) to Cloudflare, which forwards it to our server. The server tells the browser to use only encrypted connections (HSTS).

The database with Railway and the recordings with Cloudflare R2 are encrypted on disk by the providers. Text such as meetings, summaries and notes is also encrypted with a separate key for each customer. The same key arrangement for audio and video files is the next step.

Sign-in

Sayable has no passwords. You sign in with a link or a six-digit code sent by email. The link and the code work for 15 minutes and only once, the code is not stored in plain text, and it can be tried five times. There are limits on how many attempts can be made from one IP address and against one email address.

On the web and in the Mac, Windows and Android apps, the link and the code only work in the browser or on the device that asked for them, so others who see the email cannot use them.

Each sign-in is a separate session with a fixed lifetime that is not extended automatically. Under “Aktive økter” (active sessions) in Sayable on the web, you see your sessions and can sign out of one or all of them. If you sign out on the web, or sign out a session there, it stops working on the server at once. With “Logg ut alle enheter” (sign out of all devices), you make all sign-ins on the account invalid.

A team can also sign in with its work account at Microsoft or Google, so the organisation's own two-factor authentication and access rules apply. The owner or an administrator first proves with a DNS record that the domain belongs to the organisation, and then connects it to the work account. The owner can then require everyone with an address on the domain to sign in with the work account. Links and codes by email then no longer work for them. Sayable only asks for the email address and gets no access to email, calendars or files.

Access within the team

A team has three roles: owner, administrator and member. The owner and the administrators can invite and remove members. An invitation is valid for seven days.

Each member decides which meetings are shared to the team archive, and whether the recording comes along. The owner and the administrators only see what has been shared, never the meetings a member has not shared. If a member is removed, the member's shares disappear from the team archive, and the meetings stay on the member's own account. In a team with company control, the owner and the administrators can export and delete the data of a deactivated member, and the owner can set a retention period. This is described in the privacy policy.

The owner and the administrators can restrict the team to the organisation's email domains, so that no one outside can be invited or join. They can also deactivate a member, who then loses access to the team and is signed out on all devices. The same happens when a member is removed.

The owner and the administrators can read the team's audit log: sign-ins and sign-outs, invitations, members, roles, seats, domains, sharing settings and shares, with who and when, but never content from the meetings. The log is deleted after 13 months.

Shared summaries

If you share a summary as a link, the link contains a random key that cannot be guessed. The page shows the title, date, duration and summary, never the transcript. The recording is only included if you have chosen it, and is played through addresses that stop working after 15 minutes. The pages ask search engines to stay away, the address is not passed on to other websites, and the number of requests per IP address is limited.

The link works until you withdraw it, until it expires, or until you delete the meeting or the account. In a team, the owner and the administrators can turn off public links, decide how long new links are valid, and see and revoke the members' links, without seeing the title or the content.

Our own access

The admin panel we use for customer support and operations never shows the content of the meetings: neither recordings, transcripts nor summaries. What we do in the panel is recorded in a log.

The server uses no third-party tools for logging, analytics or error tracking. The Mac and Windows apps have no built-in third-party analytics or advertising tools.

Deletion and backups

If you delete a meeting, the content, the tasks and the shares are removed at once, and the recording files are deleted. If you delete your account, everything on it is deleted, including the recordings and the jobs at Gladia.

The database has backups with Railway: daily ones, kept for 6 days, and weekly ones, kept for 27 days. What you delete is gone from the backups within 27 days. The page on deleting your account says what is kept.

Subprocessors

The companies that process data for us, what they receive and where it happens are listed on a separate page.

Found a security issue?

Write to hei@sayable.no. Describe what you found and how we can see it for ourselves.

See also the list of subprocessors and the privacy policy.