Data Processing Agreement (DPA)

Effective: June 2, 2026·Version: 1.0.0

This Data Processing Agreement ("DPA") concretizes the data-protection obligations between Bergbacher GmbH ("Processor") and the Customer ("Controller") in the context of using the Shrimp service. It supplements the Terms of Service as Annex 1.

§ 1 Subject and Duration of Processing

(1) The subject of this DPA is the processing of personal data by the Processor in the course of providing the Shrimp service pursuant to the Terms.

(2) This DPA applies for the duration of the main contract between the parties and terminates automatically with it, supplemented by the deletion or return obligations under § 10.

§ 2 Nature and Purpose of Processing

(1) Nature of processing: collection, storage, organisation, display, transmission, modification, retrieval, querying, deletion, and erasure of personal data to provide the Shrimp platform.

(2) Purpose of processing: providing the SaaS functionality contracted by the Customer (time tracking, timesheet management, leave and absence management, team availability, custom event tracking, reporting, notifications).

§ 3 Categories of Personal Data

The following categories of data are processed in particular:

  • Master data of workspace members (name, email address, role)
  • Time-tracking data (time entries with date, duration, project or client assignment, descriptions and notes)
  • Leave and absence data (leave type, dates, balances)
  • Availability and presence data (office / remote / on-leave status)
  • Custom event records (event type, timestamps, counts)
  • Client and project data, insofar as it contains personal data (e.g. contact names)
  • Authentication data of the Controller's staff (hashed passwords, passkey public keys, TOTP secrets)
  • Security metadata (IP addresses, user agent, login timestamps, audit logs)

Raw Activity Signals (e.g. window activity, git commits, calendar events) are processed exclusively on the member's device by the Shrimp macOS App and are not transmitted to or processed by the Processor. Only time entries confirmed by the member reach the Processor's systems.

§ 4 Categories of Data Subjects

  • Staff and agents of the Controller with workspace access (workspace members)
  • Contacts of the Controller's clients, insofar as the Controller enters such data into the service

§ 5 Obligations of the Processor

(1) The Processor processes data only on documented instructions from the Controller. The Controller's use of the service via the dashboard, the macOS App, and the API constitutes documented instructions.

(2) The Processor commits the persons involved in processing to confidentiality in writing, unless they are already subject to a statutory duty of confidentiality.

(3) The Processor maintains the technical and organisational measures (TOM) described in Annex A pursuant to Art. 32 GDPR.

§ 6 Sub-Processors

(1) The Controller grants the Processor general written authorisation to engage sub-processors pursuant to Art. 28 (2) GDPR.

(2) A current list of all sub-processors is publicly available at /en/sub-processors.

(3) If the Processor intends to engage a new sub-processor or replace an existing one, it announces this on the sub-processors page at least 14 days before it takes effect. The Controller may object within this period; the consequences of an objection are governed by § 11 of the Terms.

§ 7 Third-Country Transfers

(1) The application layer is operated in the EU (Frankfurt) by Vercel Inc., a US-based sub-processor. The transfer to the United States is based on the EU–US Data Privacy Framework.

(2) Logging and observability data are processed by Axiom Inc. (United States). Only security metadata (in particular IP addresses, user agent, timestamps, and status codes) are transmitted to Axiom; no time-tracking or master data. The transfer is based on the EU–US Data Privacy Framework.

(3) Insofar as other sub-processors transfer data to third countries, this is done exclusively on the basis of appropriate safeguards under Chapter V GDPR (adequacy decision, Standard Contractual Clauses Module 3, or Data Privacy Framework).

§ 8 Obligations to Assist

(1) The Processor assists the Controller in fulfilling data-subject rights (Art. 15–22 GDPR) by appropriate technical and organisational means, in particular through data-export and deletion functions in the dashboard.

(2) The Processor notifies the Controller without undue delay upon becoming aware of a personal-data breach in its area of responsibility, and assists with the notification obligations under Art. 33 and Art. 34 GDPR.

(3) The Processor assists the Controller with data-protection impact assessments (Art. 35 GDPR) and with prior consultation with the supervisory authority (Art. 36 GDPR), as required.

§ 9 Audit and Evidentiary Obligations

(1) The Processor provides the Controller with appropriate evidence of compliance with the TOM and the obligations under this DPA upon request (e.g. certifications, audit reports, self-assessments).

(2) The Controller may, after prior written notice with reasonable lead time and during normal business hours, conduct on-site audits or have them conducted by independent auditors, where self-assessments are insufficient for the specific audit situation.

§ 10 Deletion and Return after End of Contract

(1) After termination of the main contract, the Controller may export their data within 30 days (cf. § 11 (3) of the Terms).

(2) After the export period, the Processor deletes all of the Controller's personal data, unless statutory retention obligations apply.

§ 11 Liability

(1) Liability between the parties is governed by § 10 of the Terms; liability under Art. 82 GDPR remains unaffected.

Annex A — Technical and Organisational Measures (TOM)

The Processor implements the following measures pursuant to Art. 32 GDPR, in particular:

  • Data minimisation by design: Raw activity signals are processed exclusively on the member's device; only confirmed time entries are transmitted to the Processor's systems.
  • Encryption: TLS 1.3 for all connections; encryption at rest for the database via the hosting provider.
  • Access control: Role-based authorisation model (admin, manager, viewer) at workspace level; tenant isolation via separated workspaces.
  • Authentication: Password policy (minimum 12 characters), optional two-factor authentication (TOTP, email code), optional passkeys.
  • Secret management: API keys are stored only as cryptographic hashes; plaintext is shown once at creation.
  • Logging and monitoring: Audit logs for security-relevant events; central log aggregation.
  • Backups: Regular database backups via the hosting provider; restorability is testable.
  • Personnel measures: Confidentiality commitments from staff; access on a need-to-know basis.
  • Sub-processors: Pre-engagement review of new sub-processors for data-protection compliance; public sub-processor list with prior notification of changes.