Data processing agreement for Sayable Team

How the agreement is entered into

• The agreement is part of the terms for Sayable and applies to all customers who use Sayable Team. It applies from the moment the customer starts using Team, and for as long as we process personal data for the customer.
• The customer is the organisation that uses Team. The owner of the Team account accepts the agreement on behalf of the organisation, and the customer is listed as the controller in Annex I.
• If you need a signed copy, write to hei@sayable.no with the organisation's name, registration number, address and contact person. We fill in Annex I and send a copy signed by A-JOB AS. The content is the same as here.
• The agreement consists of the EU standard contractual clauses, the additional clauses and Annexes I to IV. In the event of a contradiction, the standard contractual clauses prevail, as Clause 4 states.
• A retention period, export and deletion of the members' data, and deletion of the team's data when the agreement ends require the owner of the Team account to have turned on company control (“Bedriftsstyring”) in Sayable (Annex II and additional clause D).
• The date at the top shows when the agreement was last changed. We give notice of new or replaced sub-processors under Clause 7.7(a), see Annex IV. We give notice of other changes to the additional clauses and the annexes by email to the owner of the Team account at least 30 days before they apply, unless the change only strengthens the protection of the data or is required by law.

Standard contractual clauses

These are the EU standard contractual clauses between controllers and processors under Article 28(7) of the General Data Protection Regulation, laid down in Commission Implementing Decision (EU) 2021/915. The text is reproduced word for word. Where the clauses ask the parties to choose, only the chosen option is shown: Regulation (EU) 2016/679, general written authorisation for sub-processors with 30 days' notice, and the docking clause in Clause 5.

Source: Official Journal of the European Union L 199, 7.6.2021, p. 18.

Additional clauses

These clauses are added to the standard contractual clauses, as Clause 2(b) allows. They do not limit the standard contractual clauses, and in the event of a contradiction, the standard contractual clauses prevail.

A. No use for model training

1. The processor shall not use personal data or other content processed under this agreement, such as audio, recordings, transcripts, summaries and notes, to train, improve or develop machine learning or artificial intelligence models, whether its own or anyone else's.
2. The processor shall ensure that the sub-processors in Annex IV do not use such data for this purpose either, and shall on request document how this is ensured for each of them.
3. Points 1 and 2 do not prevent the abuse monitoring that Microsoft carries out in Azure OpenAI, as described in Annex IV. It is not used for training.

B. Requests from public authorities

1. If the processor receives a legally binding request from a public authority to disclose personal data processed under this agreement, the processor shall notify the controller immediately, unless the law prohibits it.
2. The processor shall assess whether the request is lawful before anything is disclosed, and shall not disclose more than the request legally requires.

C. Audits

1. The controller may request information under Clause 7.6(c) in writing to hei@sayable.no. The processor responds within 15 working days, with written answers, documentation of the measures in Annex III and the sub-processors' own audit reports and certifications, to the extent the processor has access to them.
2. Audits and inspections under Clause 7.6(d) are notified at least 30 days in advance, and take place at most once per calendar year, unless there has been a personal data breach or there are indications of non-compliance. An independent auditor shall be bound by confidentiality.
3. The controller bears the costs of the audit, unless the audit reveals material breaches of this agreement.
4. The sub-processors' premises and systems are audited through their own audit schemes and reports.

D. Deletion and return on termination

1. With company control, the team is wound down when the agreement ends, whether the subscription ends or the owner closes the team. The wind-down lasts 30 days from when everyone in the team has received an email about it. During that time, the team's owner and administrators can export the members' data, and the owner can restart the subscription, which stops the wind-down.
2. The controller chooses return by exporting the data during the wind-down. Otherwise the data is deleted.
3. After 30 days, the processor deletes all accounts in the team with their content, including the owner's. The owner can also choose to delete everything at once. The owner gets an email when everything has been deleted, and the processor confirms the deletion in writing when the controller asks for it.
4. Copies in the backups at Railway are deleted when the backups expire, at the latest 27 days after the data was deleted from the service, and until then are only used to restore the whole service. If a backup is restored, the server carries out the deletions made after the backup again.
5. Copies on the members' own devices, for example meetings recorded on Mac or Windows, are not deleted by the service. They are the controller's responsibility.
6. Without company control, the members control their own accounts, and the data stays there when the team ends. For the processor to delete everything on termination, company control must be turned on.

E. Duration, liability and governing law

1. The agreement applies for as long as the processor processes personal data for the controller through Sayable Team, and thereafter until the data has been deleted or returned under Clause 10(d) and additional clause D.
2. Liability between the parties is limited as stated in the Sayable terms, section 7: to what the customer has paid for the service in the last 12 months. The limitation does not apply to liability towards data subjects, nor to liability that cannot be excluded under Norwegian law.
3. The agreement is governed by Norwegian law, with Oslo District Court (Oslo tingrett) as the venue.

Annex I – List of parties

Controller

• The customer (the owner of the Team account on behalf of the organisation).
• Name, address and contact person: the organisation and the contact details on the Team account. The contact person is the owner of the Team account, unless the customer names someone else to hei@sayable.no.
• Data protection officer: the customer's own, if the customer has one.
• Signature and accession date: the agreement applies from the moment the customer started using Team. In a signed copy, the name, registration number, address and contact person are filled in, and the customer signs.

Processor

• A-JOB AS, organisation number 836 280 652 (Norway).
• Address: Lysaker torg 35, 1366 Lysaker, Norway.
• Contact: The Sayable team, hei@sayable.no.
• Data protection officer: A-JOB AS does not have a data protection officer.
• Signature: in a signed copy, a person authorised to sign for A-JOB AS signs.

Annex II – Description of the processing

Company control

The owner of the Team account turns on company control (“Bedriftsstyring”) in Sayable. If the team has other members, it applies 14 days later, and the members get an email with the date. Once it applies, everything on the members' accounts belongs to the customer: meetings, recordings and video, transcripts, summaries, tasks, notes, dictionary and own summary templates. A member can then not leave the team themselves, and a deactivated member cannot sign in.

Without company control, each member controls their own account. The customer can then not set a retention period or export and delete the members' data, and when the team ends, the data stays on the members' accounts. The instructions on retention period, export and deletion below, and additional clause D, require company control.

Categories of data subjects

• The members: the customer's employees and others invited into the team.
• Participants in meetings a member records or transcribes, both internal and external, for example customers, partners and candidates.
• People mentioned in recordings, transcripts, summaries and notes.
• People who contact Sayable's support on behalf of the customer.

Categories of personal data

• The account: email address, role in the team (owner, administrator or member), when the account was created and last used, which apps it is used from, the names of the devices, and the sign-ins with app and time. With sign-in through a work account, also a fixed ID for the account and the organisation's ID at Microsoft or Google, and when the connection was made and last used.
• The content: recordings (audio, and video when selected), transcripts with timestamps and speakers, the names the member gives the speakers, summaries, notes, tasks, meeting titles (also from the calendar when it is turned on), dictionary and summary templates.
• Metadata: date, duration, processing status, what has been shared in the team archive and by whom, and public sharing links.
• The team's audit log: sign-ins and sign-outs, changes to the team and shares, with who, what and when, but never content from the meetings.
• Usage: minutes transcribed, storage space and number of AI calls.
• Technical data: IP address and times in the server's operational logs and in the traffic through Cloudflare, and error reports without content.
• Support: what is sent to hei@sayable.no.

Sensitive data

The service is not designed for sensitive data, but recordings and transcripts may contain such data if it is said in the meeting, for example health data or trade union membership. The customer decides whether such meetings are recorded, and whether they are processed locally or in the cloud. These restrictions and safeguards apply:

• Speaker separation computes voice features while the meeting is processed, and discards them with the job. No voiceprints are stored, voices from one meeting are never matched against another, and there is no biometric identification.
• A member's meetings are only available to the member, and to the team when the member has shared them. The team's owner and administrators cannot read unshared meetings in Sayable. With company control, the owner can set a retention period, and the owner and administrators can export and delete the data of a deactivated member. The export is the only exception: it is recorded in the team log, and the member gets an email before it is made.
• A-JOB's admin panel never shows the content of the meetings.
• In local mode on Mac, Windows, iPhone and Android, the content is not sent to A-JOB or the sub-processors (see “Local processing and the cloud” below).

Nature of the processing

Collection through the apps for Mac, Windows, iPhone and Android, the Chrome extension and Sayable on the web; storage; transcription and speaker separation; text processing with a language model (summaries, chat, insights, tasks and tidying up dictation); sharing in the team archive and by link when the member chooses to; sending email and notifications; export and deletion.

Purposes and documented instructions

The personal data is processed only to provide Sayable Team to the customer, according to these instructions:

• Store meetings, notes and settings for the members, and sync them between their devices.
• Transcribe audio, separate speakers and produce summaries, chat, insights and tasks when the member uses the cloud.
• Share meetings in the team archive and by link when the member chooses to, within what the team's owner and administrators have allowed for public links.
• Give the team's owner and administrators the team's audit log and the overview of the members' public links, and let them revoke links, restrict the team to the organisation's email domains and deactivate members.
• With company control: delete meetings and notes older than the retention period set by the team's owner, counted from the meeting's date, including meetings the member has not shared, normally at the latest a day after the period has passed. A new or shorter period applies after 14 days, with an email to the members.
• With company control: export or delete the data of a deactivated member when the team's owner or an administrator asks for it, without the member having to sign in (the owner for everyone, the administrators for regular members), and wind down the team under additional clause D when the agreement ends.
• Use the sub-processors and the transfers in Annex IV.
• Provide support when the customer or a member asks for it.
• Delete according to “Duration of the processing” below, and otherwise on the customer's instructions.

A-JOB AS does the following as a controller itself, and it is not covered by this agreement: invoicing and payment, account security and abuse prevention, accounting, A-JOB's own operational logs and error reports, email about the account, and following up the customer relationship, including figures for how the accounts are used, never content. This is described in the privacy policy.

Duration of the processing

For as long as the customer uses Sayable Team, and thereafter until the data has been deleted or returned under Clause 10(d) and additional clause D. Within the term of the agreement:

• Meetings, transcripts and summaries are stored until the member deletes them, or, with company control, until they are older than the retention period set by the team's owner.
• Export files are deleted 7 days after they were made.
• The deletion list is kept for 100 days, see “Availability and recovery” in Annex III.
• The text from a cloud transcription of a meeting stored only on the computer is kept by A-JOB until the app has fetched it, normally for at most a day.
• Dictation sent from the phone to the Mac is deleted after about an hour.
• The team's audit log is deleted after 13 months.
• Error and crash reports are deleted after 90 days.
• If a member deletes their account, the content, the recordings and the jobs at Gladia are deleted. What is kept is stated on the page about deleting the account.
• Copies in the backups remain for at most 27 days, see additional clause D, point 4.

Local processing and the cloud

• Mac: two switches, transcription and text AI, each on its own. With both set to local, transcription, speaker separation and summaries happen on the Mac. In the cloud, dictation is streamed to Gladia, meetings are sent as whole files to A-JOB, which sends them to Gladia, and text AI goes to Microsoft.
• Windows: one switch. In local mode, transcription, speaker separation and summaries happen on the PC, and nothing is uploaded. In the cloud, the recording is sent to A-JOB and stored in the cloud, or only transcribed and stored on the PC, depending on the “only on this computer” choice.
• iPhone and Android: in local mode, transcription and summaries happen on the phone. In the cloud, as on Mac.
• The Chrome extension: always the cloud.
• Even in local mode, the following goes to A-JOB when the member is signed in: the sign-in, the number of minutes transcribed, the dictionary, summary templates the member has chosen to sync, the notes when note sync is on (on by default for Team on Mac and Windows), the message that the Mac is recording with the Mac's name, and error reports without content.
• The default in the apps is the cloud. Each member chooses for themselves, and the customer cannot lock the choice today.

Annex III – Technical and organisational measures

The measures below are in use. What is planned is not listed here. Sayable has no certifications such as ISO 27001 or SOC 2.

Encryption

• All traffic to sayable.no, app.sayable.no, api.sayable.no and dl.sayable.no is encrypted (TLS) to Cloudflare, which forwards it to the server at Railway. The server tells the browser to use only encrypted connections (HSTS).
• The database at Railway and the recordings in Cloudflare R2 are encrypted at rest by the providers.
• Text in Sayable, such as meetings, transcripts, summaries, notes, tasks and the dictionary, is also encrypted with a separate key for each customer (AES-256-GCM). The keys are wrapped with a master key in Azure Key Vault, with HSM, in Sweden. The server decrypts the text when it is displayed or processed. The recordings (audio and video) do not have this arrangement yet.
• The apps do not encrypt the meetings on disk. On Mac and Windows, the computer's disk encryption (FileVault, BitLocker) protects them, and the customer manages it. The sign-in is stored in the keychain on Mac and in Credential Manager on Windows.

Sign-in and access

• No passwords. Sign-in with a link or a six-digit code by email, valid for 15 minutes and once. The code is stored hashed and can be tried five times. Limits per IP address and per email address.
• The owner or an administrator can prove with a DNS record that a domain belongs to the organisation, and connect it to the organisation's account at Microsoft Entra ID or Google Workspace. The owner can then require everyone with an address on the domain to sign in with the work account. The organisation's own two-factor authentication and access rules then apply, and sign-in with a link or code by email is closed for them. Sayable only asks for the email address and gets no access to email, calendars or files.
• On the web and in the apps for Mac, Windows and Android, the link and the code only work in the browser or on the device that requested them.
• Each sign-in is a separate session with a fixed lifetime that is not extended. The member sees their sessions and can sign out of one or all of them. If the member signs out on the web, or signs out a session from the list, the session becomes invalid on the server.
• The team has the roles owner, administrator and member. The owner and administrators invite and remove members. Invitations are valid for seven days.
• The owner and administrators can restrict the team to the organisation's email domains. Then no one outside the domains can be invited or join.
• The owner and administrators can deactivate a member. The member immediately loses access to the team and the team archive, and is signed out on all devices. The same happens when a member is removed. With company control, a deactivated member cannot sign in either.
• A member only sees their own meetings and what others have shared to the team archive. The owner and administrators only see what has been shared, and cannot read members' unshared meetings in Sayable. The exception is the export of a deactivated member's data with company control.

Sharing

• Public link only when the member chooses it. The link has a random 16-byte key. The page shows the title, date, duration and summary, never the transcript. The recording is only included when the member has chosen it, and is played through addresses valid for 15 minutes.
• The owner and administrators can turn off public links for the whole team, set a maximum lifetime for new links, see the members' active links without title and content, and revoke them.
• The sharing pages ask search engines to stay away, send no referrer onwards, and accept at most 60 requests per minute per IP address.
• Locked meetings cannot be shared. A link stops working when the member revokes it, when it expires, or when the meeting or the account is deleted.

Logging

• The team's audit log shows the owner and administrators when the members sign in and out, changes to the team (invitations, members, roles, seats, domains, sharing settings, company control and retention period), shares and exports, with who and when, but never content. Deletions under the retention period are only recorded as numbers. The log is deleted after 13 months.
• A-JOB's own actions in the admin panel are recorded in a separate audit log, and sign-ins to the admin panel are notified by email.
• The server's operational logs are stored at Railway in the USA.

A-JOB's own access

• The admin panel has no access to the meeting store and never shows recordings, transcripts or summaries.
• Only A-JOB has access to operations, the database and keys on our side. Secrets are kept in Railway's environment variables and are not shared in chat or email.
• The source code goes through pull requests and automated tests before it is put into use.

Data minimisation

• 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.
• Text AI only goes to approved addresses in the EU (Azure OpenAI in Sweden Central). The server stops calls to all other addresses before anything is sent.
• Live sessions at Gladia are created in Gladia's EU region.
• We ask Gladia to delete audio and text once the text has been stored, and on errors. A daily job cleans up anything left behind.
• Notifications to iPhone do not contain the meeting title, unless the member has turned that on.
• The error reports never contain recordings or text. Crash reports from the apps are only sent after the user says yes.

Deletion

• When a member deletes a meeting, the title and content are emptied immediately, tasks and shares are removed, and the recording files in R2 are deleted. R2 has no versioning, so a deleted file cannot be recovered.
• With company control and a retention period, meetings and notes older than the period are deleted the same way automatically, normally at the latest a day after the period has passed.
• After the deletion, only a marker remains with the meeting's ID and technical timestamps, without title, date, duration or content, so that the apps know the meeting has been deleted.
• Copies on the members' own computers and phones, for example meetings recorded on Mac or Windows, are not deleted by the service. They are the customer's responsibility.
• When a member deletes the account, the account, the meetings, the recordings and the jobs at Gladia are deleted. What is kept is stated on the page about deleting the account.
• Fixed deletion periods: dictation sent to the Mac after about an hour, export files after 7 days, error and crash reports after 90 days, the deletion list after 100 days, the team's audit log after 13 months, and the email log after 12 months.

Availability and recovery

• The database is backed up at Railway every day and every week. The daily copies are kept for 6 days and the weekly copies for 27 days.
• The backups are only used to restore the whole service after an accident, never one customer's data. Every deletion of a meeting, a note or an account is also written to a deletion list in R2, outside the database, without titles, content or email address. If the database is restored from a backup, the server carries out the deletions on the list again when it starts and every hour after that, so that deleted data does not come back. The list is deleted after 100 days.
• A-JOB does not take its own backups in addition. The recordings in R2 have no backups.

Assistance to the customer (Clause 8)

• Requests from data subjects and from the customer are sent to hei@sayable.no. We respond within 5 working days.
• Access and data portability: the member can download transcripts, summaries and recordings in Sayable on the web. With company control, the team's owner and administrators can export the data of a deactivated member as a zip file with the meetings (transcript, summary and recording), the notes, the dictionary and the summary templates. The member gets an email when the export is ordered, the link works for 15 minutes, and the file is deleted after 7 days.
• Deletion: the member deletes meetings or the account themselves. With company control, the team's owner can set a retention period, and the owner and administrators can delete the account of a deactivated member.
• Data protection impact assessment: we make this agreement, the pages about subprocessors and security, and answers to security questions available.

Personal data breach (Clause 9.2)

• We notify the customer without undue delay and at the latest 48 hours after we became aware of the breach, by email to the contact person in Annex I.
• The deadline also applies to breaches at a sub-processor, counted from when we learned of it.
• We have a written incident procedure, and keep a log of all breaches, including those that are not notified.

Annex IV – List of sub-processors

The customer has authorised these sub-processors. The list is the agreed list in Clause 7.7(a), and the same list is on the page about subprocessors.

We give notice of new or replaced sub-processors by email to the owner of the Team account at least 30 days before they are engaged. If a sub-processor changes its own sub-processors, we give notice as soon as we have learned of it, and at the latest five working days after. The customer can object by replying to the email or writing to hei@sayable.no. If we find no solution, the customer can terminate Team before the change applies.

Railway Corporation · USA

Cloudflare, Inc. (R2) · USA

Cloudflare, Inc. (DNS and proxy) · USA

Gladia SAS · France

Microsoft (Azure OpenAI) · USA

Plus Five Five, Inc. (Resend) · USA

Apple Inc. (Apple Push Notification service) · USA

Microsoft (Microsoft 365) · USA

Duration

• Railway, Cloudflare, Resend and Microsoft 365: for as long as the agreement runs, and until the data has been deleted.
• Gladia: until we have deleted the job, normally when the text has been stored, otherwise within a day through the daily clean-up.
• Microsoft (Azure OpenAI): the request is processed and not stored, except content flagged by the abuse monitoring.
• Apple: until the notification is delivered. If it cannot be delivered at once, Apple may hold the latest notification for up to 30 days.

Not sub-processors

• Stripe, the App Store and Google Play: the payment. There, A-JOB AS, Apple or Google is the controller itself.
• Hugging Face and GitHub: the models that run on the device are downloaded from there. No audio, text or account information is sent there.
• OpenAI, xAI and Gladia with own API keys: a member who owns a Sayable Local licence personally can use their own keys. Audio or text then goes straight to the provider under the member's own agreement, without going through us. The customer cannot block this today.
• Google Analytics, Google Ads and Meta: only concern the website sayable.no, with consent.

See also the privacy policy, the terms and how we secure the service. Send questions to hei@sayable.no.