Data Processing Agreement (DPA)

under Art. 28 of the General Data Protection Regulation (GDPR)

Last updated: 12 October 2026

This English version is provided for convenience. The German version is binding.

between the customer that uses DooDock under the Terms and Conditions (Terms), as controller (the "Controller"),

and Björn Juncker, sole trader trading as DooDigital, Am Kleesbrock 20, 33719 Bielefeld, Germany, as processor (the "Processor").

This agreement forms part of the Terms. It is concluded in electronic form when the Terms are accepted at signup (Art. 28(9) GDPR).

§ 1 Subject matter and duration

(1) The Processor provides and operates DooDock for the Controller under the Terms. In doing so, he processes the personal data that the Controller and its users store in the workspace or retrieve through connected services.

(2) The nature and purpose of the processing, the types of data and the categories of data subjects are set out in Annex 1.

(3) This agreement applies for the term of the Terms and beyond, until the Processor has returned or deleted all of the Controller's data under § 9.

§ 2 Instructions

(1) The Processor processes the data only on documented instructions from the Controller, including with regard to transfers to a third country, unless required to do so by Union or Member State law. In that case, he informs the Controller of that legal requirement before processing, unless that law prohibits this on important grounds of public interest.

(2) The Controller's instructions follow from the Terms, this agreement and the use of DooDock by the Controller and its users, for example when they create, change or delete data, change settings, connect accounts with third-party services or use an AI feature. The Controller gives further instructions in text form to info@doodigital.agency.

(3) If the Processor believes an instruction infringes data protection law, he informs the Controller without delay. He may suspend carrying out the instruction until the Controller confirms or changes it.

(4) For instructions that go beyond the scope of services under the Terms, the Processor may ask for reasonable remuneration.

§ 3 The Processor's obligations

(1) The Processor processes the data only to perform this agreement and not for his own purposes. He makes copies only where needed for operation and backups.

(2) Only the Processor himself has access to the data. If he engages other persons, he commits them to confidentiality before their first access, unless they are under a statutory obligation of confidentiality.

(3) The Processor takes the technical and organisational measures under Art. 32 GDPR described in Annex 2. He may develop them further as long as the level of protection does not decrease.

(4) The data is processed in Germany. Processing outside the European Union or the European Economic Area only takes place through the sub-processors listed in Annex 3, and only where the conditions of Art. 44 to 49 GDPR are met.

(5) The contact for data protection is Björn Juncker, info@doodigital.agency.

§ 4 The Controller's obligations

(1) The Controller is responsible for the lawfulness of the processing, in particular for a legal basis and for informing data subjects.

(2) It processes special categories of personal data (Art. 9 GDPR) in DooDock only where this is permitted.

(3) If the Controller notices errors or irregularities in the processing, it informs the Processor without delay.

§ 5 Sub-processors

(1) The Controller gives the Processor general authorisation to engage sub-processors (Art. 28(2) GDPR). The sub-processors listed in Annex 3 are deemed approved when this agreement is concluded.

(2) If the Processor wants to add or replace a sub-processor, he informs the Controller in text form at least four weeks in advance. Within this period, the Controller can object in text form on important data protection grounds. If the parties do not reach agreement, either party can terminate the contract with effect from the date the change is to take effect.

(3) If a sub-processor has to be replaced at short notice for security reasons, the Processor informs the Controller without delay; the right to object under paragraph 2 then runs from that notice.

(4) The Processor binds every sub-processor by contract to the data protection obligations of this agreement (Art. 28(4) GDPR). He is liable to the Controller for the sub-processor's compliance with these obligations.

(5) The following are not sub-processors:

• services that the Controller itself connects with its own accounts, such as Meta, LinkedIn, Google (Analytics, Ads, Search Console, Gmail, Calendar), Canva or its own mail server. The Controller has its own contract with these services; the Processor sends them data only on the Controller's instructions.
• providers of telecommunications services that only transmit data.

§ 6 Data subjects' rights

(1) DooDock offers features with which the Controller can view, correct, export and delete data. Where these features are not enough, the Processor helps the Controller fulfil data subjects' rights (Art. 12 to 22 GDPR).

(2) If a data subject contacts the Processor directly, he forwards the request to the Controller without delay and does not answer it himself, unless the Controller instructs him to.

§ 7 Personal data breaches and further assistance

(1) The Processor notifies the Controller of any personal data breach without undue delay, and at the latest 48 hours after becoming aware of it. As far as known, the notification contains the information under Art. 33(3) GDPR; what is not yet known, he provides in phases. He immediately takes the measures needed to secure the data and mitigate possible adverse effects.

(2) The Processor assists the Controller with data protection impact assessments and prior consultation of the supervisory authority (Art. 35 and 36 GDPR) by providing the information available to him.

(3) The Processor informs the Controller about inspections and measures by a supervisory authority that concern this processing.

(4) If the data at the Processor is put at risk by seizure, confiscation, insolvency proceedings or other events or measures by third parties, he informs the Controller without delay.

§ 8 Evidence and audits

(1) The Processor makes available to the Controller all information needed to demonstrate compliance with the obligations under Art. 28 GDPR, usually through this agreement, the description of measures in Annex 2 and written answers.

(2) The Controller, or an auditor appointed by it who is bound to confidentiality and is not a competitor of the Processor, can carry out audits. Audits must be announced at least four weeks in advance, take place during usual business hours, must not disrupt operations disproportionately and are usually limited to one per calendar year, unless a specific reason justifies a further audit. For the data centre, the Processor refers to the evidence provided by IONOS.

(3) Each party bears its own costs. For effort beyond one audit per calendar year that does not reveal a breach by the Processor, the Processor may ask for reasonable remuneration.

§ 9 Return and deletion

(1) When the services end, the Processor returns or deletes the data, at the Controller's choice (Art. 28(3)(g) GDPR). Return follows § 11 of the Terms: the Controller can request a complete copy of its data up to 30 days after the contract ends.

(2) After handing over the copy, and at the latest 30 days after the contract ends, the Processor deletes the workspace, with its database and files, from the server. It is gone from the encrypted backups at the latest twelve months later; until then, these copies are not used.

(3) Data the Controller deletes in DooDock during the term is deleted from the live system and is gone from all backups at the latest twelve months later. The deletion periods DooDock applies itself are set out in Annex 1.

(4) On request, the Processor confirms the deletion in text form.

§ 10 Liability

Liability towards data subjects is governed by Art. 82 GDPR. Between the parties, § 9 of the Terms applies.

§ 11 Final provisions

(1) In the event of conflicts between this agreement and the Terms, this agreement prevails on matters of data protection.

(2) Changes to this agreement follow § 14 of the Terms; changes of sub-processors follow § 5 of this agreement.

(3) Declarations under this agreement must be made in text form; an email is sufficient.

(4) The German version of this agreement is binding. The English version is provided for convenience only.

Annex 1: Subject matter of the processing

Nature of the processing

Collecting, storing, organising, retrieving, displaying, transmitting (for example by email or in the client portal), generating documents, backing up and deleting data.

Purpose

Providing DooDock under the Terms, including operation, security, troubleshooting, backups and support.

Types of data

The Controller decides which data is processed. DooDock is designed for the following data:

• Contact and master data: names, email addresses, phone numbers, companies, addresses, positions, notes.
• Contract and billing data: quotes, invoices, amounts, VAT identification numbers, payments, bank details.
• Acceptance records: time, IP address and browser identifier when a client accepts a quote bindingly.
• Project and content data: milestones, comments, feedback, files, knowledge base articles.
• Communication data: chat messages, emails sent through DooDock and, if the Controller connects a mailbox or calendar, their contents and appointments.
• User and access data: names, email addresses, roles and permissions, passwords only as hashes, sign-in times, a log of access changes.
• Employee data, if the Controller uses the employee portal: profiles, schedules, requests, documents and payslips with salary, tax and social security data. Payslips can reveal religious affiliation through the church tax entry; this is a special category of personal data (Art. 9 GDPR).
• Data from connected social media and advertising accounts: mostly aggregated figures, as well as posts and comments that the Controller retrieves or publishes through DooDock.
• Technical data: IP addresses and browser identifiers in server logs, error reports.

Categories of data subjects

• the Controller's users (employees and freelancers);
• the Controller's clients and prospects and their contact persons;
• client portal users;
• the Controller's communication partners;
• people who appear in the Controller's content.

Deletion periods DooDock applies itself

All other data remains stored until the Controller deletes it or the contract ends (§ 9).

Annex 2: Technical and organisational measures (Art. 32 GDPR)

Confidentiality

• Physical access: The server is in an IONOS SE data centre in Germany. IONOS controls and monitors physical access.
• Server access: Administrators sign in only with cryptographic keys; password logins are disabled.
• Management access: The central management system requires a password and a second factor. Only Björn Juncker has access. It communicates with the workspaces only through signed requests.
• Access to DooDock: Passwords are stored only as hashes (bcrypt). Password reset links are valid for one hour, invitation links for seven days; changing a password invalidates older links.
• Authorisation: Roles and permissions per person and module (view, edit, full). Every interface checks permissions on every request. Client portal users see only what has been shared with them. Access changes are logged.
• Separation: Each Controller has its own installation with its own database, file folder, processes and addresses. The applications run under their own system users without administrator rights. Test and demo environments contain only fictional data.
• Encryption: All connections are encrypted with TLS (HTTPS). Backups are encrypted on the server before they leave it; only Björn Juncker holds the key. Login details for the Controllers' mail servers are stored encrypted.
• Data minimisation in error reports: Email addresses, long strings of digits and access tokens are removed before storage.

Integrity

• Transmission: Data is transmitted only in encrypted form. Internal calls, for example to generate PDF documents, are secured with short-lived signatures.
• Input control: Quotes and invoices that have been sent are stored as unchangeable versions; every change creates a new version. The binding acceptance of a quote is logged with time, IP address and browser identifier. Access changes are logged.

Availability and resilience

• Backups: Every night at about 3:30 a.m., an encrypted backup of each installation to Google Drive; seven daily and twelve monthly backups are kept. A backup of the hosting system on the server is a second layer.
• Recovery: Restoring from backup was tested on 5 October 2026.
• Monitoring: The central management system continuously checks the availability and errors of all installations and alerts Björn Juncker to faults in production. Services that crash restart automatically.

Regular testing and evaluation

• Releases: Every new version first passes automated tests, including a check that every interface checks permissions, and then a test environment before it goes into production. Database changes are delivered as versioned migrations, with a backup before each migration.
• Separation: On every release, an automated test checks that the installations are separated from each other.
• Service providers: Sub-processors are checked for their data protection and security measures before they are engaged.

Annex 3: Sub-processors

Google cannot read the contents of the backups because they are encrypted before upload. Under its commercial terms, Anthropic does not use the content it receives to train AI models and generally deletes it within 30 days.