The German version is legally binding.

Data Processing Agreement (Art. 28 GDPR)

Version 2026-10, version date: 13 October 2026.

This agreement (hereinafter the “DPA” (ADV)) applies between the Customer and the provider of todo.monster named in the legal notice (Impressum). The Customer is the controller (Art. 4 No. 7 GDPR): the Customer decides which data end up in todo.monster and for what purpose. The Provider is the processor (Art. 4 No. 8 GDPR): the Provider stores and processes these data only for the Customer. Who the parties are and who represents them follows from the contract for the use of todo.monster (hereinafter the “Main Contract”: the General Terms and Conditions together with the booked plan, or a pilot agreement).

Scope and Order of Precedence

(1) todo.monster is directed only at entrepreneurs (§ 14 BGB (German Civil Code)). This DPA is concluded upon registration together with the General Terms and Conditions. It takes effect as soon as data of other persons are located in the Customer's projects, company areas, mailboxes or calendars, for example the name of a prospect in a task, a supplier as the sender of an e-mail or the participants of an appointment. If the Customer processes only its own data there, this DPA does not give rise to any obligations.

(2) For some matters, the Provider is itself the controller and not a processor: for the user account of each individual person, the login, billing, the logs of consents, the security and abuse prevention of the Service, the pilot and onboarding programme and the system e-mails to account holders. These processing operations are not part of the commission; they are set out in the privacy policy.

(3) If this DPA and the Main Contract contradict each other, this DPA prevails in matters of data protection. A pilot agreement may supplement this DPA but may not weaken any obligation arising from it.

(4) Only the German version is binding. Translations assist understanding; in the event of discrepancies, the German text applies.

(5) The Customer concludes this DPA electronically (Art. 28 (9) GDPR) by confirming it upon registration. If the Customer later books a company plan or a pilot agreement, it confirms the version applicable at that time once more. For each confirmation, the Provider stores the version, the time and a checksum of the confirmed text.

§ 1 Subject Matter and Duration

(1) The Provider makes todo.monster available to the Customer as software via the Internet. This includes: tasks and projects, time tracking, comments and attachments, company mailboxes as well as mailboxes and calendars that the Customer or its users connect, notifications, the AI conversion of an e-mail into a task (only when a user triggers it) and error reports with screenshot. Processing here means: storing, displaying, transmitting to the counterparts chosen by the Customer (for example sending a reply via the connected mailbox), backing up, placing in the recycle bin and assisting in support. What exactly happens with which data is set out in Annex A.

(2) This DPA runs for as long as the Main Contract. It ends only once the data have been returned or deleted in accordance with § 11.

§ 2 Nature and Purpose of the Processing, Types of Data, Data Subjects

What the Provider does with which data, for what purpose, which types of data are involved and which persons are affected is set out in Annex A, organised by the functions of the Service.

§ 3 Instructions

(1) The Provider processes the Customer's data only in order to provide the Service in accordance with the contract, and only as the Customer directs via this agreement, the Terms and Conditions and the use of the Service. Every input, setting and triggering of a function in the Service is deemed an instruction. Only if a law of the EU or of Germany obliges the Provider to process differently, for example to disclose data to an authority or to retain invoice data, may the Provider deviate from this. In that case, the Provider informs the Customer beforehand, unless the law prohibits this.

(2) Instructions are, for example: creating, changing or deleting a task; inviting a member or a guest; connecting a mailbox or a calendar of a third-party provider; starting the AI function for a single e-mail; sending an error report with screenshot; starting a data export. The Provider then does exactly what the function promises, and nothing beyond that.

(3) If the Customer wishes something that no function in the Service covers, for example the restoration of a project it can no longer find in the recycle bin, it sends the instruction in text form to support@todo.monster. Instructions are issued by the Customer itself; for a company in todo.monster, by its owner and the administrators designated in the company administration. The Provider confirms receipt and records what it executed and when.

(4) Restoration: Deleted projects, modules, tasks, mailboxes and calendars are kept in the recycle bin for the period stated in Annex B, item 3. There, the Customer and its authorised users retrieve them themselves. If the Customer asks the Provider for a restoration, this is an instruction under paragraph 3. The Provider executes it if the data are still technically available; it cannot promise a deadline or a successful outcome. Which data the Provider sees in doing so is set out in Annex B, item 5.

(5) If the Provider considers an instruction to infringe the GDPR or another data protection law, it tells the Customer immediately. Until the Customer confirms or changes the instruction, the Provider may leave it unexecuted.

§ 4 Obligations of the Customer

(1) The Customer is responsible for being permitted to process the data at all: it needs a legal basis, informs the data subjects and answers their requests. Example: if an employee of the Customer creates a task containing the name and telephone number of a prospect, the Customer must be able to justify this to the prospect, not the Provider.

(2) If the Customer operates a company in todo.monster, it assigns the roles (owner, administrator, member, guest) itself and withdraws them when someone leaves. It tells its users that their contents in company areas belong to the company.

(3) If the Customer or one of its users connects a mailbox or a calendar of a third-party provider, for example a Microsoft account, the Customer has chosen that recipient. It bears the responsibility for the data being permitted to go there, even if the third-party provider processes them outside the European Economic Area (§ 13 (3)).

(4) The AI function converts an e-mail into a task only if a user triggers this for exactly that e-mail; every user can switch the function off for themselves. The Customer decides whether its users may use it and is responsible for the legal basis vis-à-vis its users and the senders of the e-mails. The Provider describes its own role in this in the privacy policy.

(5) Not intended for todo.monster are special categories of data (Art. 9 GDPR, such as health data), data relating to criminal offences (Art. 10 GDPR) and data subject to professional secrecy (§ 203 StGB (German Criminal Code), such as client files of a law firm). If the Customer nevertheless wishes to have such data processed, it agrees this with the Provider beforehand in text form.

(6) The Customer keeps the e-mail address of its account up to date; for a company, that of the company owner. The notifications under § 7 and § 10 are sent to this address.

§ 5 Confidentiality

All persons at the Provider who are able to handle the Customer's data are bound to confidentiality in writing or are subject to a statutory duty of secrecy (Art. 28 (3) (b) GDPR). The obligation continues to apply after the end of their activity. In any event, they access the Customer's contents only in the cases exhaustively listed in Annex B, item 5.

§ 6 Technical and Organisational Measures

(1) The Provider protects the data by means of the measures in Annex B (Art. 32 GDPR), for example through encrypted storage of task texts and through a role model that checks every request on the server side. These measures are the minimum standard on which the parties agree when concluding the contract.

(2) The Provider may develop the measures further as long as the protection does not become worse as a result. It records material changes; the current version of Annex B is available on this page.

§ 7 Sub-processors

(1) The Provider may engage the companies named in Annex C, section 1, for example the hosting provider on whose systems the database runs. By registering, the Customer approves this list (general authorisation, Art. 28 (2) GDPR).

(2) If the Provider wishes to add a further company or replace one, it first sends the Customer a system e-mail to the address under § 4 (6) and updates Annex C. The Customer has 30 days from receipt to object in text form on data protection grounds. The change does not take effect for the Customer before then.

(3) If the Customer objects, it may terminate the Main Contract with effect from the date on which the change takes effect. Return and deletion are governed by § 11.

(4) A change of the service that provides the language model for the AI function is also a change under paragraph 2, even if the Provider merely changes a setting for this.

(5) The Provider imposes on each sub-processor by contract the same data protection obligations that it itself has under this DPA, above all sufficient protective measures (Art. 28 (4) GDPR). If a sub-processor fails in some respect, the Provider is liable to the Customer for this as for its own failure.

(6) The recipients in Annex C, section 2, which do not receive any data from the commission, and the services in Annex C, section 3, which the Customer or its users connect themselves, are not sub-processors.

§ 8 Assistance with the Rights of Data Subjects

(1) If a person asks the Customer for access to, rectification, erasure, restriction or portability of their data, or objects to the processing (Chapter III GDPR), the Provider assists the Customer in responding to the request (Art. 28 (3) (e) GDPR). The first means are the functions of the Service: search and display, editing and deleting contents, removing members and guests, and the data export (§ 11 (3)). Example: if a former business partner requests access, the Customer itself searches its projects and mailboxes for that person's name. If this is not sufficient, the Provider assists upon request in text form; for this it may demand reasonable remuneration based on effort, unless the request is attributable to an error of the Provider.

(2) If a person contacts the Provider directly and the matter concerns data that the Provider processes for the Customer, the Provider forwards the request to the Customer immediately and does not answer it itself. It tells the person that it has forwarded the request.

§ 9 Assistance with the Obligations under Art. 32 to 36 GDPR

The Provider assists the Customer in fulfilling its obligations under Art. 32 to 36 GDPR (Art. 28 (3) (f) GDPR): with the security of processing through the measures in Annex B, with data breaches through the notification under § 10, and with information about the processing when the Customer carries out a data protection impact assessment or must consult its supervisory authority beforehand. In doing so, it takes into account what it knows about the processing and how it is carried out. Requests are sent in text form to support@todo.monster.

§ 10 Notification of Personal Data Breaches

(1) If the Provider becomes aware of a personal data breach affecting the Customer's data, such as unauthorised access to the database or a leak in a backup, it notifies the Customer without undue delay at the address under § 4 (6) (Art. 33 (2) GDPR). It notifies quickly enough for the Customer to be able to meet its own 72-hour deadline vis-à-vis the supervisory authority (Art. 33 (1) GDPR).

(2) The notification contains, insofar as the Provider already knows it: what happened, which types of data and approximately how many persons and records are affected, what consequences are likely, what the Provider has done and proposes, and who the contact person at the Provider is (Art. 33 (3) GDPR). What it does not yet know, it supplies as soon as it knows it.

(3) The Provider secures the data immediately, limits the damage and coordinates the further steps with the Customer.

§ 11 End of the Commission, Return and Deletion

(1) For a company, the commission ends when the company plan or the pilot agreement is terminated or otherwise ended without another company plan following directly, or when the company is dissolved (hereinafter “End of Contract”). A switch between company plans or from the pilot agreement to a company plan does not end the commission. For a Customer without a company, the commission ends when the Customer deletes its account; the privacy policy describes the procedure.

(2) After the End of Contract, the company owner can still read and export the company's data for 30 days. During this time, the owner retrieves the data via the company export. If the Customer instead wishes the data to be deleted immediately, it notifies the Provider in text form; the Provider then deletes without undue delay. In this way, the Customer has the choice between return and deletion (Art. 28 (3) (g) GDPR).

(3) The company export is the means of return: the company owner downloads an archive in common, machine-readable formats (JSON, CSV) containing projects, modules, tasks, comments, time entries, assignments, tags, recurrence rules, change history and attachments. Not included are the contents of company mailboxes and connected mailboxes, calendars and appointments, invoices and receipts, and the profiles of other persons. If the Customer needs mailbox or calendar contents, it requests them in text form within the 30 days under paragraph 2; the Provider makes them available within 30 days of receipt, insofar as they still exist. Customers without a company use the personal data export with the same scope for their own projects.

(4) Invoices and receipts that the Provider has issued to the Customer as controller remain retrievable in the account at any time; they are not part of the commission.

(5) 60 days after the End of Contract, an automatic clean-up run deletes the company's data including the recycle bin, unless a law requires longer retention. In the hosting provider's backups, the data are overwritten within a further 30 days. A backup containing deleted data is restored only after an outage; afterwards, the Provider carries out deletions that have already taken place once again.

(6) The personal accounts of members and guests remain unaffected by the End of Contract; their own data outside the company remain in their accounts. Data that the Provider must retain as controller are not deleted: invoices and receipts (§ 147 AO (German Fiscal Code), § 257 HGB (German Commercial Code)), logs of consents and audit logs without content data. After the End of Contract, these data are no longer governed by this DPA but by the privacy policy.

(7) Upon request, the Provider confirms the deletion in text form. Until return and deletion have been completed, this DPA continues to apply.

§ 12 Evidence and Contributions to Audits

(1) The Customer may verify whether the Provider complies with this DPA (Art. 28 (3) (h) GDPR). The Provider gives the Customer all necessary information for this purpose and contributes to audits carried out by the Customer itself or by an auditor mandated by the Customer and bound to confidentiality.

(2) The audit is conducted on the basis of documents: upon request, the Provider makes available the current version of Annexes B and C, a self-assessment regarding the measures in Annex B, the evidence, reports and certificates of its hosting provider and its other sub-processors, as well as answers to the Customer's questions in text form. An on-site audit at the Provider or at its sub-processors is not envisaged. The Provider continues to cooperate with audits by a supervisory authority without change.

(3) The Provider may protect trade secrets and the data of other customers and may limit the information to the systems and documents that concern the Customer.

§ 13 Place of Processing and Third Countries

(1) The Provider and its sub-processors in Annex C, section 1 process the Customer's data exclusively in Germany.

(2) The Provider does not transfer anything to a country outside the EU and the European Economic Area on its own decision. Should it ever wish to do so, this would be a change under § 7 (2), and the requirements of Art. 44 et seq. GDPR would have to be met.

(3) The situation is different for services that the Customer or its users themselves connect to todo.monster (Annex C, section 3): mailboxes via IMAP and SMTP, calendars via CalDAV, and Google and Microsoft calendars. The Provider transmits to them only what the function requires, for example an appointment created in the Service to the connected calendar. Whether such a service processes data outside the European Economic Area depends on the chosen service; with Google and Microsoft, processing in the USA is to be expected. The Customer is responsible for ensuring that this transfer is permissible and that the necessary safeguards are in place (§ 4 (3)).

§ 14 Liability and Final Provisions

(1) The liability of the parties is governed by the liability clause of the General Terms and Conditions. Statutory liability towards data subjects under Art. 82 GDPR remains unaffected by this.

(2) Amendments to this DPA require text form. The Provider may amend it if the processing, the sub-processors or the legal situation change; it informs the Customer by system e-mail at least 30 days in advance. For Annex C, § 7 (2) applies.

(3) German law applies. The place of jurisdiction is Berlin if the Customer is a merchant (Kaufmann), a legal entity under public law or a special fund under public law.

(4) If a provision of this DPA is invalid, the remaining provisions remain valid; the statutory provision takes its place.

Annex A: Subject Matter of the Processing

1. Functions and Purposes

The Provider processes the Customer's data in order to provide the following functions for the Customer and its company. A function processes data only if the Customer or its users use it.

2. Categories of Data Subjects

• The Customer itself as well as the owner, administrators and members of its company (employees, contractors, agents).
• Project guests and invited external persons: persons without their own seat in the company whom the Customer or its users invite into projects, including those whose invitation is still pending. Their contents in the Customer's projects are data of the Customer. With regard to their own user account at todo.monster, they are users of the Provider; the privacy policy applies to this.
• Senders and recipients of e-mails in company mailboxes and connected mailboxes, as well as persons named in messages.
• Participants of calendar appointments.
• Customers, business partners, suppliers and other third parties whose data the Customer's users record in tasks, comments, attachments, time entries, application notes or screenshots.

3. Duration

The processing lasts for as long as the Main Contract, until return or deletion in accordance with § 11. During the term, the periods in Annex B, item 3 apply to the recycle bin and to logs.

Annex B: Technical and Organisational Measures (Art. 32 GDPR)

The measures are described according to their location: in the Service (developed and operated by the Provider), at the hosting provider (by the sub-processor in Annex C, section 1) or organisationally at the Provider. The Provider commits only to measures that are in place.

1. Confidentiality

• Physical and logical access at the hosting provider: The servers are located in data centres of the hosting provider in Germany with physical access protection and access control in accordance with its security concept; the Provider makes it available as evidence upon request (§ 12). The Provider itself has no physical access.
• Access to the Service: Login with e-mail address and password or via a login link sent to the e-mail address on file. Passwords are stored only as a hash; new passwords must meet minimum requirements and are checked against known data leaks without the password leaving the Service. Login attempts are limited per sender address and per account. Sessions expire after two hours without activity; session cookies are valid only via HTTPS and are inaccessible to scripts. Access tokens of the mobile app and the programming interface expire after 30 days and can be revoked at any time.
• Access within the Service: Role model per company (owner, administrator, member, guest) and per project; the server checks every read and write access to tasks, projects and companies against central authorisation rules. An administrative account of the Provider cannot read descriptions, comments, attachments, mailbox and calendar contents; what it sees is exhaustively set out in item 5.
• Separation: The data of all customers are located in a shared database and are logically separated by their assignment to company and project; the server sets this assignment and never takes it over from a request. Development, testing and production are separate systems; the development environment is additionally protected by an access barrier and contains no production data.
• Encryption of stored data: Titles and descriptions of projects and tasks, comments, subject and text of e-mails, appointment contents and access credentials of connected mailboxes and calendars are stored encrypted on the server side (AES-256); passwords are stored only as an Argon2id hash. This is server-side encryption, not end-to-end encryption: the Provider is technically able to access the data; when it does so is set out in item 5.
• Encryption in transit: The Service is reachable only via HTTPS (redirection and HSTS); connections to mailboxes, calendars, the language model, the reporting server and the payment service are transport-encrypted.
• Confidentiality of persons: All persons at the Provider who have access to production systems are bound to confidentiality in writing.

2. Integrity

• Input control: Changes to tasks are recorded in a history with editor, time, old and new value. Administrative actions in the company (roles, invitations, mailboxes, dissolution) are recorded in the company's audit log. Logins are recorded with time, sender address and client. Accesses by the Provider under item 5 are logged.
• Protection of the application: Protection against forged requests (CSRF) by means of session tokens; server-side sanitisation of formatted input; consistent escaping of output; security headers against embedding in third-party pages and against type sniffing, and to control the referrer. Attachments are accepted only if the file extension and the detected content type match; they are stored under random names outside the web root and are delivered with an isolating security policy. Profile photos are re-encoded without metadata.
• Transfer control: Data leave the Service only to the parties named in Annex C and only to the extent described there; no attachments are sent to the language model, no content data to the payment service; the Provider's accounting and bank data do not leave the system. Administrative and database accesses by the Provider are carried out via the hosting provider's administration interface and encrypted connections.
• Development process: Every change to the Service passes through automated tests before delivery, including contract tests for authorisation rules, encryption and module boundaries, and is merged in a traceable manner. Delivery is reproducible as a container image; error messages are never output in the browser in production.

3. Availability, Resilience and Deletion

• Data backup: The hosting provider backs up the database and file storage; backups are retained for up to 30 days and then overwritten.
• Recovery: The application runs as a container stack with separate processes for web, scheduling and background work; a maintenance mode halts the Service in a controlled manner during a recovery. A health endpoint allows monitoring.
• Resilience: Limitation of requests per sender address and account for login, registration, invitations, write accesses via the programming interface and administrative functions; size, number and storage limits for attachments; monthly quotas for the AI function.
• Recycle bin: Deleted projects, modules, tasks, mailboxes and calendars are initially only marked as deleted and are permanently removed only after a configured period (default 30 days, minimum one day); deleted e-mails remain in the mailbox's recycle bin for 45 days. Until then, authorised users retrieve them themselves. Orphaned attachment files are removed daily.
• Log and deletion periods: Notifications 30 days; logs of mailbox and calendar synchronisation three days, seven days in the event of errors; export archives 24 hours; login logs 90 days; usage log of the AI function 90 days; audit logs of the company and of restoration three years, the billing audit log ten years (tax retention); IP address of consents until the End of Contract plus three years; screenshots from error reports 90 days; application logs 30 days.
• Availability commitment: The availability of the Service is governed by the General Terms and Conditions, not by this DPA.

4. Procedures for Regular Review

• Regular automatic check that data to be stored encrypted are stored encrypted, and regular reconciliation of the attachment storage with the database.
• Automated tests with every change; documented procedures for delivery, key rotation, maintenance mode and incidents.
• Changes to the measures in this Annex are documented (§ 6 (2)).
• Data protection by default: the AI function runs only when a user triggers it for an e-mail and can be switched off per user; error reports with screenshot are sent only when triggered by the user; mailboxes and calendars are connected only if a user connects them; profile photos are visible only to persons with a shared project or a shared company.

5. Access by the Provider to the Customer's Data (Access Rule)

Employees of the Provider do not routinely look at the Customer's contents. A human accesses them only if there is a reason (an instruction from the Customer or a security or operational incident), only as far as necessary, and every access is logged. The automatic processing by the Service under Annex A remains unaffected by this. There are no accesses beyond the following:

• Restoration (§ 3 (4)): At the Customer's request, an administrative account of the Provider with the restoration right sees the user name, e-mail address, status and time of deletion of the affected user, as well as the names of their projects and modules, the titles of their tasks and the deletion times of deleted records. Not visible are descriptions, comments, attachments, time entries, and mailbox and calendar contents. Every restoration is logged with the executing person and the time.
• Support diagnosis: At the Customer's request, an administrative account of the Provider sees the company's memberships, invitations and mailbox connections (host names, status, time of the last retrieval), not the contents of messages. Every diagnosis is recorded in the company's audit log before it is displayed.
• Error reports: Screenshots and descriptions that a user sends via the error reporting function are seen by the Provider in order to fix the reported error; they are deleted after the period in item 3.
• Operations and security: Access to the database, file storage and logs in order to resolve an incident, investigate a security incident or execute an instruction. The reason is documented; the Provider sees the Customer's contents only to the extent the reason requires.

Annex C: Sub-processors and Other Recipients

1. Sub-processors (§ 7 (1))

2. Recipients outside the Commission

The following parties do not receive any data from the Customer's commission. The Provider uses them as controller for its own purposes; they are listed here only for delimitation, and details are set out in the privacy policy. The Provider's accounting and bank data are processed within the Service and are not transmitted to any further recipient.

• Mollie B.V., Keizersgracht 126, 1015 CW Amsterdam, Netherlands: payment processing for paid plans. Mollie receives the name and e-mail address of the billing account and the payment data, no content data; Mollie acts as an independent controller in payment processing.
• EU-Captcha (Myra Security GmbH, Munich): bot protection during registration and in the contact form; the IP address, browser identifier and captcha token of the registering or writing person are transmitted. The check is a processing operation of the Provider as controller.
• Have I Been Pwned (api.pwnedpasswords.com, operated by Troy Hunt, Australia): when a password is set, a short fragment of a hash value is transmitted, never the password and no identifier of the person; attribution to a person is not possible.

3. Third-party Services Commissioned by the Customer

If the Customer or a user of the Customer connects one of the following services to todo.monster, the Customer has chosen that service itself and has its own contractual relationship with it. The service is not a sub-processor of the Provider; the Provider transmits to it only what the function requires and retrieves from it what the user has authorised (§ 13 (3)).

• Mailboxes via IMAP and SMTP at the e-mail provider of the Customer or user: retrieval and sending of messages using the access credentials that the user stores.
• Calendars via CalDAV (for example Nextcloud or Fastmail): synchronisation of appointments using the access credentials that the user stores.
• Google Calendar (Google LLC or Google Ireland Limited): the user signs in directly with Google and grants authorisation there; the Provider reads appointments from the selected calendars and transmits appointments created or changed in the Service to Google. Processing regularly also takes place in the USA. Available only insofar as the Provider has enabled the function.
• Microsoft Calendar (Microsoft Corporation or Microsoft Ireland Operations Limited) for personal Microsoft accounts: the user signs in directly with Microsoft and grants authorisation there; the Provider reads appointments from the selected calendars and transmits appointments created or changed in the Service, together with their participants, to Microsoft, which may send invitations. Processing regularly also takes place in the USA.

For Google and Microsoft the following applies: which safeguards secure the transfer to the USA depends on the contractual relationship that the Customer or its user has itself with the respective service (§ 4 (3)).

If the user disconnects the connection, the Provider deletes the access credentials and access tokens; messages and appointments already retrieved remain in the Service until the user deletes them or the account or the company is removed.