Skip to content
readerr
PricingUse casesFAQHelpBlogContactLog inStart free trial
Menu
PricingUse casesFAQHelpBlogContactLog inStart free trial
1. Who this agreement is between and how it applies2. Definitions3. Roles and scope4. Your responsibilities5. Instructions (GDPR Art. 28(3)(a))6. Confidentiality (GDPR Art. 28(3)(b))7. Security (GDPR Art. 28(3)(c) and Art. 32)8. Sub-processors (GDPR Art. 28(2), 28(3)(d) and 28(4))9. Help with data subject requests (GDPR Art. 28(3)(e))10. Help with security, breaches and impact assessments (GDPR Art. 28(3)(f))11. End of processing (GDPR Art. 28(3)(g))12. Audits and information (GDPR Art. 28(3)(h))13. Our own purposes: the Pronunciation Dictionary and service statistics14. International transfers15. Liability16. Duration and changesAnnex 1 - Description of the processingAnnex 2 - Technical and organisational measures

Data Processing Agreement

Version: 2026-10-15

In short

When you use Readerr, you send us the text of your articles, and we turn it into Audio that plays on your site. Those articles can mention people, so we process personal data for you. You decide what we process and why; we act only on your instructions. This agreement sets out the rules required by Article 28 of the GDPR: how we keep the data safe, who helps us, how fast we tell you about a breach (within 48 hours) and how we delete everything when you leave. It has one exception you should know about: we keep a shared Pronunciation Dictionary of how words are read, without any link to you or your articles (section 13).

1. Who this agreement is between and how it applies

1.1. This Data Processing Agreement ("DPA") is between you, the Customer, and us, IT Busters Marcin Rybak, a sole proprietorship registered in Poland, ul. BolesÅ‚awa Chrobrego 12, 38-400 Krosno, Poland, NIP 6842342603, REGON 368728920, contact: [email protected].

1.2. This DPA is part of the Terms of Service. You accept it when you accept the Terms. You do not need to sign it separately.

1.3. This DPA applies whenever we process personal data on your behalf while providing Readerr. That includes Customers who are Consumers, to the extent they act as controllers of the personal data in their content.

1.4. If you process the personal data for another controller (for example, you run a site for a client), you represent and warrant that you have that controller's authority to engage us as your sub-processor, to give us instructions and to agree to this DPA, including the Sub-processors and transfers it describes. You remain our only point of contact.

1.5. If this DPA and the Terms conflict on a data protection matter, this DPA prevails.

2. Definitions

2.1. Words in capitals that are not defined here have the meaning given in the Terms, for example Account, Audio, Customer Content, Integration, Listener, Player, Publisher Site and Pronunciation Dictionary.

2.2. In this DPA:

  • GDPR means Regulation (EU) 2016/679.
  • Customer Personal Data means personal data that we process on your behalf while providing Readerr, as described in Annex 1.
  • Listening Events means the short reports the Player sends after a Listener presses play, as described in Annex 1.
  • Sub-processor means a third party we engage to process Customer Personal Data.
  • Personal Data Breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
  • controller, processor, data subject, processing and supervisory authority have the meaning given in the GDPR.

3. Roles and scope

3.1. You are the controller of Customer Personal Data. We are your processor.

3.2. The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are described in Annex 1.

3.3. This DPA does not cover personal data for which we are the controller. That includes the data about you and your users that we need to run your Account, billing records, website visitors and our emails. Our Privacy Policy describes that processing.

3.4. We use data derived from Customer Content for our own purposes in two cases only: the Pronunciation Dictionary and aggregated service statistics that contain no personal data. Section 13 describes both. We do not use Customer Personal Data for any other purpose of our own. In particular, we do not use it, and we do not let our Sub-processors use it, to train AI models.

4. Your responsibilities

4.1. You are responsible for the lawfulness of the processing you instruct us to carry out. This includes having a legal basis for it and giving data subjects the information the law requires.

4.2. To help you inform Listeners, we provide a template for your privacy policy. You are responsible for adapting it and publishing it.

4.3. You decide what text you send to Readerr. Articles may contain any personal data you choose to publish, including special categories of personal data or data about criminal convictions. You represent and warrant that you have a legal basis to publish that data and to have it processed by us and our Sub-processors as described in this DPA, including its transfer outside the European Economic Area under section 14. Readerr does not need such data to work.

4.4. Your instructions must comply with the law.

5. Instructions (GDPR Art. 28(3)(a))

5.1. We process Customer Personal Data only on your documented instructions. This also applies to transfers of Customer Personal Data to a third country or an international organisation.

5.2. Your documented instructions are:

  • the Terms and this DPA;
  • your configuration of Readerr, for example the settings of your Integrations, the voice you choose and the sites you connect;
  • your use of Readerr, for example publishing, updating or deleting an article on a Publisher Site, requests you or your Integrations send to Readerr, and actions you take in the customer panel;
  • any other written instruction you send us by email that we confirm.

5.3. An instruction by email must be consistent with the Terms and with how Readerr works. If we cannot follow it, we will tell you. You may then stop using the affected part of Readerr or end the contract under the Terms.

5.4. If the law of the European Union or of an EU Member State requires us to process Customer Personal Data in another way, we will tell you about that requirement before processing, unless that law prohibits it on important grounds of public interest.

5.5. We will tell you immediately if, in our opinion, an instruction infringes the GDPR or other data protection law of the European Union or of an EU Member State.

6. Confidentiality (GDPR Art. 28(3)(b))

6.1. Only persons we authorise may access Customer Personal Data, and only as far as they need to provide Readerr.

6.2. Every such person is bound by a written duty of confidentiality or by a statutory duty of confidentiality. That duty continues after their work for us ends.

7. Security (GDPR Art. 28(3)(c) and Art. 32)

7.1. We apply the technical and organisational measures described in Annex 2. They are designed to give a level of security appropriate to the risk, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing.

7.2. We may change these measures as technology and Readerr develop. A change must not lower the overall level of protection of Customer Personal Data.

8. Sub-processors (GDPR Art. 28(2), 28(3)(d) and 28(4))

8.1. General authorisation. You give us a general written authorisation to engage Sub-processors. The current list, with each provider's name, purpose, location, data and transfer mechanism, is on our Subprocessors page.

8.2. Notice of changes. Before we add or replace a Sub-processor, we will email the owner of your Account at least 30 days before the new Sub-processor starts processing Customer Personal Data. We will update the Subprocessors page at the same time.

8.3. Urgent changes. Sometimes we may need to replace a Sub-processor at short notice, for example because the provider stops offering its service or because of a security risk. In that case we may make the change sooner. We will notify you as soon as possible, and you have the same right to object as under section 8.4.

8.4. Objection. You may object to a new or replacement Sub-processor on reasonable grounds relating to data protection. Send your objection to [email protected] within the notice period (or, for an urgent change, within 30 days of our notice), with your reasons.

8.5. What happens after an objection. We will discuss your objection with you in good faith and look for a solution, for example a change in how we use that Sub-processor for your data. If we cannot resolve your objection, you may terminate the contract, or the part of Readerr affected by the change, by notice to us. We will then give you a proportional refund of the prepaid fees for the unused part of the paid period. We arrange the refund through Link, as described in the Terms. If you do not object within the period, the change takes effect.

8.6. Obligations passed on. We engage each Sub-processor under a written contract. That contract imposes data protection obligations that give Customer Personal Data the same level of protection as this DPA, in particular sufficient guarantees that the Sub-processor applies appropriate technical and organisational measures.

8.7. Our liability. We remain fully liable to you for the performance of each Sub-processor's obligations.

9. Help with data subject requests (GDPR Art. 28(3)(e))

9.1. Most requests can be handled by you directly in Readerr. For example, when you delete an article, or your Integration tells us that you deleted or unpublished it on your site, we delete that article's title, Audio and related records (Annex 1, section 6).

9.2. If a data subject contacts us with a request about Customer Personal Data, we will forward it to you without undue delay. We will not answer it ourselves, except to tell the data subject that we have passed the request to you. This does not apply to requests about the Pronunciation Dictionary, which we handle ourselves as controller (section 13).

9.3. Taking into account the nature of the processing, we will give you reasonable help, through appropriate technical and organisational measures, to respond to requests from data subjects to exercise their rights under Chapter III of the GDPR.

10. Help with security, breaches and impact assessments (GDPR Art. 28(3)(f))

10.1. Taking into account the nature of the processing and the information available to us, we will give you reasonable help to meet your obligations under Articles 32 to 36 of the GDPR. These cover security, notifying Personal Data Breaches, data protection impact assessments and prior consultation with a supervisory authority.

10.2. Breach notification. We will notify you of a Personal Data Breach without undue delay, and no later than 48 hours after we become aware of it. We will send the notice to the email address of your Account owner.

10.3. The notice will include, as far as the information is available to us:

  • the nature of the breach, including, where possible, the categories and approximate number of data subjects and of personal data records concerned;
  • a contact point where you can get more information;
  • the likely consequences of the breach;
  • the measures we have taken or propose to take to address the breach, including measures to reduce its possible adverse effects.

10.4. If we cannot provide all of this information at once, we will provide it in phases without further undue delay.

10.5. We will take reasonable steps to contain the breach and reduce its effects. We will not notify a supervisory authority or data subjects about a breach of Customer Personal Data on your behalf unless you ask us to or the law requires us to.

10.6. Notifying you of a breach is not an admission of fault or liability.

10.7. Impact assessments. On request, we will give you the information about Readerr that you reasonably need for a data protection impact assessment or a prior consultation. This DPA, its Annexes and the Subprocessors page are a starting point.

11. End of processing (GDPR Art. 28(3)(g))

11.1. At the end of the contract we delete Customer Personal Data. We do not return it. There is little to return: we delete the text of each article once its Audio is ready (Annex 1, section 6).

11.2. List of Audio files. Before your Account is deleted, you may ask us for a list of the addresses of your Audio files, so that you can download them. Send the request to [email protected]. We will send you the list before we carry out the deletion.

11.3. When deletion happens. Your Account is deleted when you ask for it in the customer panel, or automatically 30 days after the end of the Grace Period. We carry out a requested deletion within 30 days. Deletion covers our database and the Audio files in storage and in the content delivery network.

11.4. Any Customer Personal Data still held in our live systems is deleted within 30 days after the Account deletion is carried out. Copies in database backups expire no more than 30 days after that. Machine snapshots are kept for no more than 30 days.

11.5. We keep Customer Personal Data after the end of the contract only if the law of the European Union or of an EU Member State requires us to store it.

11.6. Entries in the Pronunciation Dictionary are not Customer Personal Data and stay after the contract ends (section 13).

12. Audits and information (GDPR Art. 28(3)(h))

12.1. We will make available to you all information necessary to demonstrate compliance with Article 28 of the GDPR. We will allow for and contribute to audits, including inspections, conducted by you or by another auditor you mandate.

12.2. Documents and questions first. You agree to start with documents and written questions. This DPA, its Annexes and the Subprocessors page describe the processing. We will answer your reasonable written questions about how we protect Customer Personal Data within a reasonable time.

12.3. Inspections. If the documents and answers are not enough to show compliance, or if a supervisory authority requires it, you may carry out an inspection, on site or remotely. The following conditions apply:

  • you give us at least 30 days' written notice, with the proposed scope and date;
  • no more than one inspection in any 12-month period, unless a supervisory authority requires another;
  • you bear the costs of the inspection, including your auditor's costs;
  • the inspection takes place during normal business hours in Poland and must not disrupt Readerr or expose other Customers' data;
  • the auditor is bound by confidentiality and is not a competitor of ours.

12.4. Our Sub-processors run their own facilities. Where their terms allow, we will give you the audit reports or certificates they provide to us instead of arranging an inspection of their premises.

13. Our own purposes: the Pronunciation Dictionary and service statistics

13.1. Readerr reads names, foreign words and abbreviations better over time because it keeps a shared Pronunciation Dictionary, described in section 11 of the Terms. Each entry is a pair: a fragment of text and how to read it, for example a place name, a foreign word or an abbreviation.

13.2. Your authorisation. You authorise us to extract such fragment and reading pairs from Customer Content while we prepare pronunciation, to keep them in the Pronunciation Dictionary, and to keep the records of refused proposals described in section 13.3. You confirm that you may make these fragments available to us for this purpose; they come from content you publish.

13.3. What we keep and what we do not.

  • An entry is stored without any link to the article it came from or to you.
  • We exclude names of private individuals from the Pronunciation Dictionary. They are used only to read the current article. The exclusion is automated and works as far as is technically possible; if such a name is kept by mistake, we delete it as soon as we learn of it.
  • Before a new entry is added, an automated check confirms that it is plausible and not an attempt to manipulate the Pronunciation Dictionary. When the check refuses a proposal, we keep a record of the refusal (the fragment, the proposed reading, the language and the Publisher Site it came from) for up to 90 days after the proposal was last seen, only to detect and stop such attempts. We delete these records earlier when the fragment is blocked after an objection or when your Account is deleted.
  • We may also add entries ourselves.

13.4. Our role. For the Pronunciation Dictionary we are an independent controller, not your processor. Our Privacy Policy describes this processing, its legal basis and how anyone can ask us to delete an entry.

13.5. Not Customer Content. Pronunciation Dictionary entries are not Customer Content. They are used across Readerr for all Customers. They stay after your contract ends.

13.6. Service statistics. You also authorise us to derive aggregated statistics about how the Service works from our processing - for example processing times, error rates or how often text needed special reading. These statistics contain no Customer Content and no personal data. We use them to maintain and improve the Service.

13.7. This section survives the end of the contract.

14. International transfers

14.1. We store Customer Personal Data in the European Union: our servers, our backups and the Audio files are located in the EU. The countries are listed on the Subprocessors page.

14.2. Some Sub-processors process Customer Personal Data outside the European Economic Area, for example a provider of an AI language model we use to prepare text for reading, or a content delivery network that serves each Listener from a location near them and carries traffic to our servers.

14.3. We transfer Customer Personal Data outside the European Economic Area only to Sub-processors on the Subprocessors page, and only on the basis stated there for each of them: an adequacy decision of the European Commission (including the EU-U.S. Data Privacy Framework for certified recipients) or the European Commission's standard contractual clauses.

15. Liability

15.1. Each party's liability under this DPA is subject to the limits and exclusions in the Terms.

15.2. Those limits do not restrict either party's liability to data subjects under Article 82 of the GDPR, or any liability that the law does not allow to be limited or excluded.

16. Duration and changes

16.1. This DPA applies for as long as we process Customer Personal Data. It ends when all Customer Personal Data has been deleted under section 11. Sections 11 and 13 survive the end of the contract.

16.2. We may change this DPA in the same way as the Terms: by email at least 30 days before the change takes effect. You may end the contract before that date and receive a proportional refund of the prepaid fees for the unused part of the paid period. Changes required by law, or changes only in your favour, may take effect sooner.

16.3. Changes to the list of Sub-processors follow section 8, not this section.

16.4. This DPA is governed by the law and the courts set out in the Terms.


Annex 1 - Description of the processing

1. Subject matter and duration

We process Customer Personal Data to provide Readerr to you under the Terms. Processing lasts for the term of the contract and until deletion under section 11 of this DPA.

2. Nature and purpose

What we doWhy
Receive the title and text of articles from our Integrations (currently the WordPress plugin and the API)To create Audio of your articles
Prepare pronunciation: rules, the Pronunciation Dictionary and a large language model read the text and return reading hints; the text itself is not rewrittenTo read numbers, names, foreign words and abbreviations correctly
Synthesise speech on our own servers and store the Audio fileTo produce and keep the Audio
Deliver the Player script and Audio files through a content delivery networkTo play Audio to Listeners on the Publisher Site
Receive Listening Events and turn them into daily totalsTo show you listening statistics in the customer panel
Check Audio automatically and, where a check flags a problem, let our operator review the article and the AudioTo avoid publishing faulty Audio
Delete texts, old Audio versions and deleted articlesTo keep only what is needed (section 6 below)

3. Categories of data subjects

  • People mentioned in the articles the Customer sends.
  • Authors and other people named in the article text or title.
  • Listeners: visitors to the Publisher Site who load the Player or press play.

4. Types of personal data

Article text and titles. They may contain any personal data the Customer chooses to publish, such as names, roles, opinions and events. They may include special categories of personal data or data about criminal convictions. What the articles contain is the Customer's responsibility (section 4.3 of this DPA). The WordPress plugin does not send the author field. It sends the article address, which we do not store.

Audio. A spoken version of the article text, with the same personal data.

Listener requests to the content delivery network. When a Listener's browser loads the Player script or an Audio file, the content delivery network processes the Listener's IP address and user agent to deliver the file. This happens transiently at the network provider. We do not store this data.

Listening Events. After a Listener presses play, the Player sends a short report for each of these moments: play, and 25%, 50%, 75% and 95% of the Audio heard. Each report contains only:

  • the event type;
  • the path of the Audio file;
  • the language;
  • the article's identifier on the Publisher Site;
  • the host name of the Publisher Site.

The report does not contain an IP address, a user agent, a cookie or any identifier of the Listener or the page view. The Player does not store anything on, or read anything from, the Listener's device. The request that carries the report reaches our provider's network, which sees the IP address and user agent in order to receive it. Neither is written to the stored event.

5. Frequency

Continuous, for as long as the Customer uses Readerr: each time an article is published or changed on a Publisher Site, and each time a Listener loads the Player or presses play.

6. Retention

DataHow long we keep it
Article textDeleted when synthesis finishes. If an article has a problem, kept until the problem is resolved, for no more than 30 days.
Article title, Audio files and their metadataUntil the article is deleted (the plugin reports deletion or unpublishing of the post) or the Account is deleted.
Previous version of an Audio file after a change of text or voice7 days after it is replaced.
Text fragments and Audio in the cache of our speech synthesis serviceText fragments 3 days; Audio 7 days.
Raw Listening Events3 months.
Daily totals of Listening EventsUntil the Account is deleted.
Listener requests to the content delivery networkNot stored by us.
Technical logsRotated; kept for no more than 30 days.
Database backupsNo more than 30 days.
Machine snapshotsNo more than 30 days.
All Customer Personal Data after the contract endsDeleted within 30 days after the Account deletion is carried out; backups expire no more than 30 days after that (section 11).

7. Sub-processors

See the Subprocessors page.


Annex 2 - Technical and organisational measures

This Annex describes the measures we apply to Customer Personal Data. Readerr is run by a small business. We do not hold a security certification. We describe here what we actually do.

1. Data minimisation

  • We delete the text of each article when its Audio is ready. An article with a problem keeps its text until the problem is resolved, for no more than 30 days.
  • The WordPress plugin sends only what synthesis needs: the article's identifier, language, title, text and the chosen voice. It does not send the author. We do not store the article address it sends.
  • Audio files carry technical tags and a digitally signed C2PA manifest that mark them as AI-generated. They do not carry the article title or any other content of the article.
  • Listening Events have a fixed format with no IP address, user agent, cookie or identifier. Our endpoint rejects any report that does not match that format exactly, as well as oversized reports. Request logging on that endpoint is switched off.
  • The Player and the listening statistics store nothing on the Listener's device: no cookies, localStorage, sessionStorage or IndexedDB.
  • The Audio file loads only after the Listener presses play (preload="none").

2. Encryption

  • All public connections to Readerr use TLS: the website, the customer panel, the API, the content delivery network and the listening statistics endpoint. TLS ends at the network of our content delivery and network security provider, which passes the traffic to our servers through an encrypted tunnel; our servers accept no other public connections.
  • Traffic between our servers runs over a private network with end-to-end encryption (WireGuard).
  • Connections to our Sub-processors use TLS.
  • The object storage that holds Audio files encrypts them at rest (AES-256), as provided by the storage provider.

3. Access control

  • Each connected site has its own API key. We store only a hash of the key. A key can be rotated or revoked at any time, and the old key stops working at once.
  • Sign-in to the customer panel uses one-time links sent by email. We store only hashes of sign-in links and sessions. A sign-in link is valid for 15 minutes and a session for 7 days.
  • Repeated sign-in attempts are rate-limited. The counters are keyed by a hash of the IP address or email address, not the address itself.
  • Our admin panel is reachable only after authentication through an access gateway.
  • We administer our servers over the private network, under an access policy that limits which machines may connect to which.

4. Least privilege and separation

  • Each part of Readerr runs as a separate service with only the credentials it needs. For example, only the background worker holds the credentials that can write to or delete from Audio storage.
  • Each Customer's data is separated logically by Account and site. Audio files for each site are stored under that site's own path.
  • Database backups are readable only by the system administrator account.

5. Availability and backups

  • The database is backed up every night. Backups are kept for no more than 30 days.
  • Snapshots of our servers are stored in a data centre in Finland, separate from the servers in Germany that hold the database.
  • We have tested restoring a database backup.
  • Synthesis jobs sit in a queue with automatic retries, so a temporary failure does not lose an article.

6. Vulnerability and change management

  • Every release goes through automated tests and a security gate that checks container images, dependencies, secrets and build workflows for known vulnerabilities.
  • The images that are actually running are scanned for known vulnerabilities every night.
  • We keep dependencies and base images up to date and review each update before it is released.
  • Releases are versioned. If a release fails its health checks, it is rolled back automatically.

7. Logging and accountability

  • Actions taken in our admin panel are recorded in an administrative log. When an Account is deleted, personal data is removed from its log entries.
  • Technical logs are rotated and kept for no more than 30 days.

8. Deletion

  • When an article is deleted on the Publisher Site, the plugin tells us. We delete its records, delete its Audio files from storage and remove cached copies from the content delivery network.
  • A previous version of an Audio file is deleted 7 days after it is replaced.
  • Account deletion follows section 11 of the DPA.

9. Sub-processor management

  • We choose providers that offer data processing terms under Article 28 of the GDPR and, where available, storage in the EU.
  • We check each provider's terms before engaging it and list it on the Subprocessors page.

10. Incident response

  • We handle Personal Data Breaches under section 10 of the DPA: we contain the breach, assess it and notify you within 48 hours of becoming aware of it.
  • We document every Personal Data Breach, including its facts, effects and the remedial action taken.

11. People

  • Only persons we authorise may access Customer Personal Data, and only as far as their work requires.
  • Each of them is bound by confidentiality (section 6 of the DPA).
readerr

Product

  • Pricing
  • Integrations
  • FAQ
  • Help

Use cases

  • Use cases
  • News portals
  • Magazines & blogs
  • Company & expert sites

Company

  • Blog
  • Contact

Legal

  • Privacy
  • Terms
  • Imprint
  • Cookies
  • Acceptable use
  • DPA
  • Subprocessors
  • Report content
  • How to check audio
  • Withdraw from contract here