Data Processing Agreement

0. Read this first — who needs this document

If you use Blurt as an individual, for yourself, you do not need this page. In that case Blurt is the controller for the managed Cloud plan and our Privacy Policy is the document that describes your rights.

This agreement applies when you use Blurt as an organisation — a company, a practice, an authority, a freelancer with staff — and your people dictate content that contains personal data for which you are the controller. Then, for that content, you are the controller and Blurt is your processor.

Two roles run side by side, and it is worth being precise about them:

• Content you dictate — audio and transcripts sent through the managed Cloud plan: you are controller, Blurt is processor, and the providers on our processor list are sub-processors.
• Account and billing data — the email address of the person who signs up, payment records, usage counters, security logs: Blurt remains an independent controller, because we need those to run and bill our own business. They are described in the Privacy Policy, not here.

1. How this agreement is concluded

This agreement forms an integral part of the Terms of Use and is concluded together with them, at the moment you subscribe as an organisation. No separate signature is required, and there is no form to request. It is between:

• Controller: you, the customer identified by the account and billing details you gave us.
• Processor: Ivan Chabanenko, Lutherstraße 12, 39112 Magdeburg, Germany (see Impressum), trading as Blurt.

If your own procurement process requires a signed paper copy, or your own DPA template, write to support-blurt@chbnk.one and we will sign it if its content is compatible with this one. Where a separately signed agreement exists, it prevails over this page.

We keep the version number and date at the top of this page. Where a change materially reduces your protection, we notify you at least 30 days before it applies, and you may terminate free of charge before it takes effect.

2. Subject matter, duration, nature and purpose (Art. 28(3) GDPR)

• Subject matter: automatic speech recognition and automatic text clean-up, formatting, editing and translation of content you send through the managed Cloud plan.
• Duration: for as long as your subscription runs. It ends with the subscription.
• Nature and purpose: receiving audio, relaying it to a speech-to-text provider, receiving the transcript back, relaying the transcript to a language-model provider for clean-up, and returning the result to the user's Mac. The processing is transient: nothing of the content is stored on our systems after the request completes.
• Types of personal data: whatever your people dictate. Because that is speech, it can in principle contain any category of data, including special categories under Art. 9 GDPR — you control what is dictated, and it is your responsibility to instruct your people accordingly. Also: the voice recording itself, and the resulting transcript.
• Categories of data subjects: your employees and other users of your account, and any person mentioned in what they dictate.

If your use case regularly involves special-category data — health, biometric identification, criminal matters — we advise fully local processing instead: install and select both local speech and clean-up models, and verify that both stages show as local in Blurt. Local speech alone is insufficient: when local clean-up is unavailable, the transcript may be sent to the cloud. Account and billing data remain separate from dictation content.

3. Processing on documented instructions (Art. 28(3)(a))

We process personal data only on your documented instructions, including as regards transfers to third countries, unless required to do otherwise by EU or Member State law — in which case we inform you of that requirement before processing, unless the law prohibits it on important grounds of public interest.

Your instructions consist of: this agreement, the Terms, the settings your users choose in the app (which speech and clean-up model to use, whether history is stored), and any further instruction you give us in writing or by email. We will tell you if we consider an instruction to infringe the GDPR or other data protection law (Art. 28(3), final sentence), and may suspend the affected processing until it is resolved.

4. Confidentiality (Art. 28(3)(b))

Blurt is operated by one natural person, who is bound to confidentiality directly and permanently. There are no employees or contractors with access to your data. Should that ever change, any additional person will be bound by a written confidentiality undertaking that survives the end of their engagement, and will be trained in data protection before being granted access.

5. Security of processing (Art. 28(3)(c), Art. 32)

We implement appropriate technical and organisational measures. They are set out in full on our security page, which is Annex II to this agreement and is incorporated by reference. The measures include, in summary: TLS on every connection, no storage of audio at rest, hosting of backend and database in Germany, scrypt password hashing, hashed refresh tokens, container hardening, rate limiting, off-site backups with a rehearsed database restore, and no third-party analytics, telemetry or crash-reporting SDKs. Blurt's own usage analytics is off unless the individual user switches it on, contains no content of any kind, and is processed with analytics software we run ourselves (OpenFrog) on the same German infrastructure — it engaged no analytics provider and introduced no sub-processor of its own, though those events are copied, like every other row of our data, to the off-site backup now named in Annex III. With the user's consent and while they are signed in, it is linked to their account identifier; it contains no name, email address or other contact data either way. The same switch also governs optional crash reports, likewise off unless the individual user switches them on. A crash report contains no content of any kind and no identifier of any kind — a fault or exception name, stack frames from Blurt's own binary, and the application and operating-system version — so it identifies no data subject. It is written to the user's own device at the moment of a crash and posted to our German backend at the next launch; our backend, not the user's device, then forwards it to our own crash panel, which runs on Cloudflare's Workers platform, so the report reaches that panel from our server and carries no address or identifier belonging to the user. Field-by-field detail is in Section 7f of the Privacy Policy.

Correction, 1 September 2026 (version 1.1). Version 1.0 of this section listed encrypted backups among the measures, and Annex II described the off-site database dumps as stored encrypted. Neither was accurate: the encryption had been written but was never installed. This is a correction of an inaccurate description, not a reduction of the measures actually applied — what protects your data is unchanged by this edit. It is recorded here rather than silently amended, because you may have accepted version 1.0 in reliance on it. Encryption of those dumps is the next measure to be added; Annex II is the list in force at any time and will show it, with the date it started.

Correction, 1 September 2026 (version 1.3). Versions 1.0 to 1.2 of this section summarised the measures as including "off-site backups with a rehearsed restore", and Annex II said that losing the machine which runs Blurt does not lose your data, and that the restore had been rehearsed end to end. Two things there reached wider than the facts. The off-site copy does exist and does survive that machine — but the credentials that read it are held only on the machine itself, so until a second copy of them is kept elsewhere, losing the server is also losing access to the backups. And the rehearsal of 1 September 2026 covered the restore of the database from a real dump, with a table-by-table comparison against production; it did not cover rebuilding the service around it, which has never been performed. Annex II now states both points that way, and our internal recovery runbook says the same, so the two documents no longer disagree. As with version 1.1, this is a correction of an inaccurate description, not a reduction of the measures actually applied — nothing about the backups themselves changed on this date. It is recorded here rather than silently amended, because you may have accepted version 1.0, 1.1 or 1.2 in reliance on it.

The security page also states plainly what we do not have — no SOC 2, no ISO 27001, no third-party penetration test — so that your own risk assessment starts from the truth.

6. Sub-processors (Art. 28(2) and (4))

You give us a general written authorisation to engage sub-processors. The current list, with what each one receives, where it is and on what basis data may leave the EEA, is on our processor page, which is Annex III to this agreement.

We will inform you of any intended addition or replacement of a sub-processor normally at least 30 days in advance by updating that page and, if you have asked to be notified, by email. You may object on reasonable data-protection grounds within that period. If we cannot accommodate your objection, you may terminate the subscription with effect from the date the change takes effect, and we refund the unused part of what you have paid.

Where a sub-processor fails, withdraws its service, or has to be replaced at short notice to maintain the service or to address a security risk, we may make the change before the notice period has run. In that case we inform you without undue delay, stating the provider, the date and the reason, and your right to object and to terminate under the previous paragraph applies from that moment instead. This exception exists for genuine emergencies and will not be used to shorten the ordinary notice period.

We impose on each sub-processor, by contract, data protection obligations that are equivalent to those in this agreement, and we remain fully liable to you for their performance. One entry in Annex III is an exception and we will not let this sentence cover it: the mailbox our support address delivers into is an ordinary consumer Google account, for which no Art. 28 agreement exists and none has been concluded by us. Our liability to you is unaffected — but the contractual chain behind that one recipient is missing, and you are told so here rather than discovering it in an audit.

Correction, 1 September 2026 (version 1.2). Until this date Annex III did not name Cloudflare, which holds the daily off-site copy of our database, routes mail sent to our support address, and runs the panel in which support tickets are read; nor Google, in whose mailbox that mail is kept. Both were in use throughout; what was missing was the disclosure, and a general authorisation to engage sub-processors is worth what the list is worth. Neither receives the data this agreement covers — your users' audio and transcripts are not stored after a request completes, so nothing of them reaches a backup or a mailbox, unless a person pastes such text into a support message and it becomes support data. The omission is recorded here rather than corrected silently, because you may have relied on version 1.0 or 1.1 of this page in your own record of processing activities, and because the fix for it is the list, not this paragraph.

7. Assisting you with data subject rights (Art. 28(3)(e))

Because we do not store the content after a request completes, there is normally nothing on our side to search, correct or export for a data subject. Where a request nevertheless requires our help, we assist you by appropriate technical and organisational measures, insofar as possible, and we do not answer a data subject directly on your behalf — we refer them to you and tell you about the request without undue delay.

8. Assisting you with Art. 32 to 36 (Art. 28(3)(f))

• Breaches. We notify you without undue delay after becoming aware of a personal data breach affecting your data, with the information you need for your own Art. 33 notification. We have a written internal procedure for this, including the 72-hour deadline.
• Impact assessments. We support your data protection impact assessment and any prior consultation with a supervisory authority, by providing the information we have — this page, the security page, and the processor list are usually sufficient.

9. Deletion or return at the end (Art. 28(3)(g))

At the end of the provision of services you choose whether we delete or return the personal data. In practice deletion is the default and is largely automatic, because content is never stored: what remains is account data, which is deleted when the account is deleted. Copies we are required by EU or Member State law to keep — chiefly billing records under § 147 AO and § 257 HGB — are retained for that period only, and blocked from any other use.

10. Information and audits (Art. 28(3)(h))

We make available to you all information necessary to demonstrate compliance with Art. 28, and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

In the first instance we answer in writing and by providing the documentation on this site. Where that is not sufficient, an on-site or remote inspection may be carried out on reasonable notice, during business hours, no more than once a year unless there is a concrete reason, and subject to confidentiality. Blurt is a one-person operation: we will not pretend an audit programme exists that does not, but we will answer your questionnaire honestly and promptly.

11. International transfers

Several sub-processors are established in the United States; the processor page states for each one whether the transfer rests on the EU–US Data Privacy Framework adequacy decision (Art. 45) or on the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor) (Art. 46(2)(c)) — and, where neither is in place, which today is the case for the mailbox our support address delivers into, says so instead of choosing the nearer of the two. The page also records that the off-site backup bucket at Cloudflare is not pinned to Cloudflare's EU jurisdiction.

Where the Standard Contractual Clauses apply between you and us — for example because your own establishment is outside the EEA — the Clauses in that same version are hereby incorporated into this agreement by reference, with Annexes I to III below, and prevail over this agreement in the event of any conflict.

12. Liability and order of precedence

Liability follows Art. 82 GDPR and section 10 of the Terms of Use. Where the Standard Contractual Clauses apply, their liability provisions prevail over this agreement in respect of the processing they cover. In the event of a conflict, the order of precedence is: a separately signed data processing agreement, then the Standard Contractual Clauses, then this agreement, then the Terms of Use.

13. Governing law

German law applies. If any provision of this agreement is invalid, the rest remains in force and the statutory rules take the place of the invalid provision.

Annex I — Description of the processing

Annex I.C — competent supervisory authority. Landesbeauftragte für den Datenschutz Sachsen-Anhalt, Otto-von-Guericke-Straße 34a, 39104 Magdeburg, Germany.

Annex II — Technical and organisational measures

The measures set out on our security page, as amended from time to time, form Annex II to this agreement. We do not maintain a second, divergent copy of them — one document, kept current, is what keeps this accurate.

Annex III — Sub-processors

The providers listed on our processor page, as amended in accordance with section 6, form Annex III to this agreement.

Related

See our Terms of Use, Privacy Policy, security page and processor list.