Data Processing Agreement

Last updated: October 21, 2026

This Data Processing Agreement ("DPA") forms part of the agreement between the customer ("Controller" or "Customer") and Evernow GmbH ("Processor") governing the use of docket.

The DPA is concluded upon acceptance of the Terms when the workspace is registered; no separate signature is required. On request we provide it as a PDF or in a version signed by us ([email protected]). It applies for the term of the contract on the use of docket and beyond, for as long as we process Customer Data.

1. Purpose and Scope

This DPA applies where Evernow GmbH processes personal data on behalf of Customer in connection with the docket platform.

The parties intend this DPA to satisfy the requirements of Article 28 GDPR and applicable data protection laws.

2. Definitions

Terms such as "personal data", "processing", "controller", "processor", "data subject", "personal data breach", and "supervisory authority" have the meanings given in the GDPR.

"Customer Personal Data" means personal data processed by Evernow GmbH on behalf of Customer through the docket platform.

3. Roles of the Parties

Customer acts as controller of Customer Personal Data.

Evernow GmbH acts as processor of Customer Personal Data.

For account administration, billing, support, security, and its own business operations, Evernow GmbH may act as controller as described in the Privacy Policy.

The Customer is responsible for the lawfulness of the processing of Customer Data in docket – in particular that a legal basis exists and that the data subjects, including its employees whose time entries are recorded in docket and evaluated per project and ticket, are informed under Art. 13 and 14 GDPR. It configures the roles and permissions of its users and assesses whether docket is suitable for its processing activities.

Instructions to the Processor are given by the Customer's administrators; notices from the Processor under this DPA go to their email addresses.

4. Subject Matter of Processing

The subject matter of processing is the provision of the docket SaaS platform, including project management, ticket management, time tracking, contact management, quotations, invoices, reporting, file storage, collaboration, transactional emails, monitoring, and the integrations and AI app connections that Customer sets up.

5. Duration of Processing

Processing continues for the duration of the customer relationship and any post-termination period during which data is retained for export, backup, legal compliance, or dispute resolution.

6. Nature and Purpose of Processing

Processing may include:

• hosting;
• storage;
• retrieval;
• transmission;
• organization;
• structuring;
• display;
• modification;
• deletion;
• backup;
• support access where necessary;
• monitoring and error analysis.

The purpose is to provide, maintain, secure, and support the docket platform according to Customer's instructions.

7. Categories of Data Subjects

Customer Personal Data may relate to:

• Customer's employees;
• Customer's contractors;
• freelancers;
• customer contacts;
• prospects;
• suppliers;
• service providers;
• business partners;
• other individuals whose data is entered into docket by Customer or users.

8. Categories of Personal Data

Customer Personal Data may include:

• names;
• email addresses;
• telephone numbers;
• business addresses;
• company affiliations;
• roles and job titles;
• project information;
• ticket content;
• comments and notes;
• time entries;
• work logs;
• billing and invoice information;
• quotation information;
• uploaded documents and attachments;
• communication records;
• metadata and technical identifiers.

9. Special Categories of Personal Data

docket is not intended for the intentional processing of special categories of personal data. However, because the platform includes free-text fields and file uploads, Customer may technically submit such data.

Customer is solely responsible for ensuring that any processing of special categories of personal data is lawful and subject to appropriate safeguards.

10. Customer Instructions

Processor shall process Customer Personal Data only on documented instructions from Customer, including with regard to transfers to third countries, unless required to do so by applicable law.

Customer's instructions include:

• these Terms;
• this DPA;
• settings and configurations chosen in the platform;
• user actions within the platform;
• third-party integrations that Customer sets up in the platform, such as Atlassian Jira, including the transfers of Customer Personal Data to and from those services that the integration performs;
• AI apps (for example Claude or ChatGPT) that Customer allows and its users connect to the platform through the Model Context Protocol, including the data those apps read and the time entries they write on a user's behalf;
• written instructions accepted by Processor.

If Processor believes an instruction infringes applicable data protection law, Processor shall inform Customer unless prohibited by law.

11. Confidentiality

Processor shall ensure that persons authorized to process Customer Personal Data are bound by confidentiality obligations or are subject to appropriate statutory confidentiality obligations.

12. Security Measures

The Processor implements the technical and organisational measures under Art. 32 GDPR that, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing and the risk to data subjects, ensure an appropriate level of protection.

The measures in place at the time the contract is concluded are described in Annex 3. The Processor reviews and develops them regularly; the level of protection of the measures described in Annex 3 must not be undercut. Material changes are communicated to the Customer on request. Third-party evidence – such as penetration test reports or certificates – supplements this Annex as documentation but does not replace it; the Annex itself is changed towards the Customer only under section 32 of the Terms.

13. Subprocessors

Customer provides general authorization for Processor to engage subprocessors for the provision of the service.

Processor shall maintain a current list of subprocessors, including their processing purpose and general processing location.

Processor shall impose on subprocessors, by contract, the same data protection obligations as set out in this DPA (Art. 28(4) GDPR), in particular sufficient guarantees for appropriate technical and organisational measures.

Processor remains responsible for the performance of subprocessors as required by applicable data protection law.

Third-party services that Customer connects to docket itself, such as Atlassian Jira, Tempo Timesheets or AI apps connected through the Model Context Protocol (for example Claude or ChatGPT), are not subprocessors of Processor. Customer selects them, uses them under its own agreements with their providers, and the exchange of data with them takes place on Customer's instruction (section 10). Such integrations are never active by default: they require manual setup by Customer's administrator and, for sending a user's time entries or connecting an AI app, by that user.

Distinct from this is the reconciliation of the Atlassian account IDs stored in docket with Atlassian, by which Evernow GmbH fulfils its own obligations as the provider of an Atlassian app: here it acts as controller (Privacy Policy, section 7.11); that processing is not subject to this DPA.

14. Changes to Subprocessors

The general authorization under section 13 covers the subprocessors named in Annex 2. Where Processor intends to engage a further subprocessor or replace an existing one, it informs Customer by email to Customer's administrators and updates the list on the website. The notice names the subprocessor, the purpose and location of the processing, and the safeguard for any third-country transfer.

The notice is given at least 30 days before the new subprocessor processes Customer Personal Data. Where that is exceptionally not possible – for instance because a subprocessor fails at short notice – it is given without undue delay, and Customer may then object within 30 days of receipt.

Customer may object to the engagement within this period in text form and should state its reasons. Where Customer does not object within the period, the new subprocessor is deemed approved; Processor points this out in the notice.

Where Customer objects, the parties seek a solution in good faith, such as not using the subprocessor for Customer's data. Where that fails, Customer may terminate the contract before the new subprocessor is engaged for its Customer Personal Data; fees already paid for the period after termination are refunded.

15. Assistance with Data Subject Requests

Taking into account the nature of processing, Processor shall reasonably assist Customer with responding to requests from data subjects exercising their rights under applicable data protection law.

If Processor receives a request directly from a data subject relating to Customer Personal Data, Processor may refer the request to Customer unless legally required to respond.

16. Assistance with Security, DPIAs, and Consultation

Taking into account the nature of processing and information available to Processor, Processor shall reasonably assist Customer with:

• security obligations;
• personal data breach notifications;
• data protection impact assessments;
• prior consultation with supervisory authorities;
• information reasonably required to demonstrate compliance.

17. Personal Data Breaches

Processor shall notify Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data – by email to Customer's administrators, in time for Customer to meet its own notification deadline under Art. 33 GDPR. Where not all information is available yet, Processor shall provide it without undue delay as it becomes available.

The notification shall include information reasonably available to Processor, which may include:

• nature of the breach;
• affected data categories;
• affected data subjects, where known;
• likely consequences;
• measures taken or proposed to address the breach.

Processor's notification is not an acknowledgement of fault or liability.

18. Return and Deletion

Customer's administrators can download a complete export of Customer Personal Data at any time (section 20 of the Terms). When the subscription ends, they can still sign in for 30 days, solely to download this export, and receive a reminder email before deletion.

30 days after the subscription ends, Processor deletes the workspace and all Customer Personal Data in it completely, unless retention is required by law.

Customer is responsible for exporting Customer Personal Data before the end of this 30-day period.

Backups are kept for 10 days; deleted Customer Personal Data is therefore gone from the backups no more than 10 days after deletion.

The provision of processing services ends with the subscription. The following 30 days are a transition phase in which Processor processes Customer Personal Data only for the export and the deletion; no other use takes place.

Customer makes its choice under Art. 28(3)(g) GDPR upon concluding this DPA: return through the export, which its administrators download themselves (CSV, JSON, PDF and the uploaded files in a ZIP file), and deletion once the 30 days have elapsed. Customer may change this choice at any time in text form, in particular request deletion before the 30 days have elapsed; return in any form other than the export is not owed.

Processor logs the deletion (time, workspace, number of deleted records per table, without content) and confirms it to Customer in text form on request. Backups serve solely to restore the system as a whole; deleted Customer Personal Data is not reused from a backup. Should the system as a whole have to be restored from a backup that still contains it, Processor deletes it again.

19. Audits and Information Rights

Processor shall make available information reasonably necessary to demonstrate compliance with this DPA.

Customer may request audits where required under applicable data protection law. Audits must be:

• limited to what is necessary;
• conducted during normal business hours;
• subject to reasonable prior notice;
• subject to confidentiality;
• designed to avoid disruption of Processor's operations;
• limited to systems and processes relevant to Customer Personal Data.

Processor may satisfy audit requests by providing documentation, policies, summaries, third-party reports, or written responses where appropriate.

20. International Transfers

Processor may transfer Customer Personal Data outside the EEA only where permitted under applicable data protection law.

Where required, Processor shall rely on appropriate transfer mechanisms such as:

• adequacy decisions;
• Standard Contractual Clauses;
• the EU-U.S. Data Privacy Framework where applicable;
• other lawful transfer mechanisms.

21. Liability

Towards data subjects, each party is liable under Art. 82 GDPR for the damage it causes by infringing the Regulation; Processor only where it has not complied with the obligations of the GDPR specifically directed to processors or has acted contrary to Customer's lawful instructions (Art. 82(2) GDPR).

Where one party has paid full compensation, it may claim back from the other the part corresponding to that party's share of responsibility for the damage (Art. 82(5) GDPR).

Between the parties, sanctions such as administrative fines under Art. 83 GDPR are borne by the party responsible for the breach of duty on which the fine is based; where both parties are at fault, they bear them in proportion to their respective share of causation. This allocation affects neither responsibility towards the competent supervisory authority or other authorities nor the claims of data subjects under Art. 82 GDPR. Otherwise, the two preceding paragraphs apply accordingly.

Between the parties, the liability provisions of the Terms otherwise apply, unless mandatory data protection law provides otherwise.

22. Order of Precedence

In the event of conflict between this DPA and the Terms concerning the processing of Customer Personal Data, this DPA shall prevail to the extent of the conflict.

Annex 1 — Processing Details

Subject Matter

Provision of the docket SaaS platform.

Duration

For the duration of the customer relationship and any post-termination retention period.

Nature and Purpose

Hosting, storage, processing, transmission, organization, retrieval, deletion, support, and monitoring of Customer Personal Data to provide docket, and, where Customer sets up integrations such as Jira or allows AI apps, the exchange of data with the services Customer and its users connect.

Categories of Data Subjects

Employees, contractors, freelancers, customer contacts, prospects, suppliers, service providers, business partners, and other individuals whose data is entered into docket.

Categories of Personal Data

Names, contact details, business information, project data, ticket content, time entries, invoice data, quotation data, uploaded files, comments, notes, and technical metadata.

Special Categories

Not intended, but technically possible through free-text fields and uploads. Customer is responsible for lawful use.

Annex 2 — Authorized Subprocessors

The authorized subprocessors are listed in the Subprocessor List.

Annex 3 — Technical and Organisational Measures (Art. 32 GDPR)

Measures in place at the time the contract is concluded. docket is developed and operated by Evernow GmbH; the infrastructure is provided by the subprocessors named in Annex 2: the application, database, files and cache in data centres in Frankfurt am Main, with requests reaching them through Cloudflare's network. Evernow GmbH operates no servers of its own.

1. Confidentiality

Physical access control. The data centres are operated by Fly.io and Amazon Web Services; physical access is governed by and evidenced through their security programmes. Evernow GmbH staff have no physical access to the systems.

Access control (authentication). Every user signs in with a personal account; passwords (at least 8 characters) are stored only as a hash (bcrypt). Accounts are locked after repeated failed attempts, and sign-in attempts are rate-limited per address and per email address. Every user can enable two-factor authentication (TOTP); administrators can enforce it for the whole workspace. A session ends after four hours without activity. Changing or resetting a password and archiving a user end all of that user's sessions and access tokens. Access by connected AI apps is limited to one hour per token, and tokens are stored only as hashes.

Access control (authorisation). Permissions follow fixed roles (administrator, project manager, basic user, time tracker) and are checked server-side for every action; the rules are defined in one place, and the interface, the API and AI connections derive from them. Access by Evernow GmbH staff to production systems is limited to a few named persons, happens through personal accounts with two-factor authentication, and only where operations or support require it.

Separation control. Every record carries the identifier of its workspace; every database query is restricted server-side to the workspace of the request. Automated tests verify on every change to the software that no workspace can reach another's data. Development, test and production are separate environments; no production data is used in development or test.

Encryption. All connections – browser, APIs, email delivery, connections to subprocessors – are encrypted with TLS, including the way between Cloudflare and our servers; unencrypted requests are redirected. The database and the file store are encrypted at the storage level by the hosting providers. Credentials for the Customer's services (Jira and Tempo tokens, two-factor secrets) are additionally encrypted at the application level; database backups are encrypted.

Pseudonymisation. Error reports from the browser contain no user identifier, email address or name. The website's visitor statistics work without cookies and with truncated IP addresses. Exports contain no password hashes, tokens or secrets.

2. Integrity

Input control. Issued quotes and invoices can no longer be changed, only cancelled; changes to the rates of customers, projects and services are logged with time and author; events on tickets and documents are shown in their history. Database changes run in transactions.

Transfer control. Data leaves docket only over encrypted connections. Data is transmitted to the Customer's services (Jira, Tempo, AI apps) only after the Customer's manual setup, and only within the permissions of the respective user. Download links for files are signed and time-limited.

Development and operations. Changes to the software are version-controlled; before every deployment, automated tests (more than 3,000) and security checks run: static code analysis, dependency checks for known vulnerabilities, scanning for accidentally committed secrets, and a check of the API against known attack patterns. The application enforces a Content Security Policy and rate-limits requests per address. Dependencies are kept up to date.

3. Availability and Resilience

Backups. The database is backed up automatically every day; backups are kept for 10 days at the hosting provider in the same region. Files are held in the Amazon Web Services object store (Frankfurt), which replicates them redundantly across several sites. Restoration is performed from these backups.

Monitoring. Errors, response times and background jobs are monitored continuously (AppSignal); the team is alerted on errors. The availability of the infrastructure is monitored by the hosting providers; Cloudflare fends off overload attacks (DDoS).

Security incidents. Incidents are assessed, contained, remedied and documented by the team. Affected Customers are notified under section 17. Compromised credentials are replaced immediately; all sessions of a workspace or of the whole platform can be ended centrally.

4. Procedures for Regular Review

Organisation. Staff with access to personal data are bound to confidentiality; their access ends when they leave. Data processing agreements are in place with all subprocessors. Requests from data subjects and Customers are received at [email protected].

Deletion. Deletion periods are set out in the Privacy Policy (section 12) and applied automatically: workspaces 30 days after the subscription ends, export files after 7 days, inbound emails after 30 days, unconfirmed registrations after 14 days, backups after 10 days.

Review. The measures are reviewed at least annually and whenever the software or infrastructure changes materially. Security advisories for the components in use are evaluated continuously.