Data processing agreement (DPA)

This is an English convenience translation. The German version is binding.

As of 2026-07-09

This data processing agreement (the DPA) is an annex to the service description (the “main contract”) between the customer (controller) and the provider (processor). It details the parties’ obligations under Art. 28 GDPR for the processing in which the provider processes personal data on the customer’s behalf. It takes effect with the main contract; acceptance in the customer console includes this DPA.

Provider (processor): TODO(owner): legal entity name and address — see the imprint.

Preliminary note: where the provider is a processor — and where it is not

The allocation of roles follows the PaaSbox architecture and is deliberately narrow:

• Processing on behalf (this DPA). The provider holds each cluster’s control-plane state (etcd) and its continuous backups on platform infrastructure. That state contains the Kubernetes objects the customer creates (including Secrets, ConfigMaps, manifests) and may therefore contain personal data the customer places there. This planned storage on the customer’s behalf is processing on behalf under Art. 28 GDPR and the subject of this DPA (Annex 1).
• Not processed by the provider. The customer’s workload and application data (contents on worker nodes, in volumes and databases) live exclusively in the customer’s own Hetzner project and are not processed by the provider. The provider accesses the Hetzner project only on instruction, via the customer-supplied API token, to manage cluster resources; worker nodes, load balancers, and volumes are created there on the customer’s own Hetzner contract.
• Occasional support access. Short-lived admin credentials (kubeconfig, valid at most 8 hours) are issued on request; occasional, non-systematic sight of customer data for fault analysis does not, in itself, constitute separate processing on behalf, but is covered by this DPA and the confidentiality obligation (§ 3).

Processing for which the provider is the controller (account, team, billing via Stripe, support correspondence, server logs, website) is not the subject of this DPA; it is described in the privacy policy.

§ 1 Subject matter, duration, and specification

The subject matter, nature and purpose of processing, the types of personal data, and the categories of data subjects are set out in Annex 1 to this DPA and in the main contract. The term of this DPA follows the term of the main contract or of the respective cluster, save for obligations under this DPA that expressly survive.

§ 2 Scope and responsibility

(1) The provider processes personal data only on the customer’s documented instructions, unless required to process by Union or member-state law; in that case it informs the customer of the requirement before processing, unless the law prohibits this on important public-interest grounds. The provider does not process for its own purposes.

(2) The customer is solely responsible for the lawfulness of the processing and for safeguarding data subjects’ rights (controller within Art. 4(7) GDPR). The customer warrants that it places personal data into the cluster’s Kubernetes objects only where entitled to do so.

(3) Instructions are set by the main contract and this annex. The customer may thereafter change, supplement, or replace them in text form (e.g. by email to the contact named under § 3(7)) by individual instruction. Use of the portal’s self-service and API functions constitutes an instruction to that extent. Instructions not provided for in the main contract are treated as a request for a change of service; the provider may charge reasonable remuneration where the service goes beyond the assistance owed by contract or law.

§ 3 Obligations of the provider

(1) The provider processes the data only within the scope of the assignment and the customer’s instructions, save for a statutory exception (§ 2(1)).

(2) If the provider considers an instruction unlawful, it informs the customer without undue delay; it may suspend implementation until the instruction is confirmed or amended. It is not obliged to conduct a comprehensive legal review.

(3) Technical and organizational measures (TOMs). The provider implements the TOMs required to protect the data under Art. 32 GDPR. The agreed measures are described in Annex 2; the parties agree they ensure a level of protection appropriate to the risk. The provider may implement alternative, equivalent measures without falling below the agreed security level; it documents material changes and discloses them to the customer on request.

(4) The provider assists the customer, as far as technically possible, in fulfilling data subjects’ requests and claims (Chapter III GDPR); § 5 sets out the detail.

(5) The provider assists the customer, taking into account the nature of processing and the information available to it, in complying with Art. 32 to 36 GDPR. It ensures that persons involved in the processing are bound to confidentiality and that this obligation survives the end of the assignment.

(6) Notification of personal-data breaches. The provider informs the customer without undue delay after becoming aware of a breach of the security of the customer’s personal data, in time and completely enough for the customer to meet its obligations under Art. 33, 34 GDPR. The notification contains at least the information listed in Annex 4; missing information may be provided in phases without undue further delay.

(7) The provider names the customer a contact for data-protection matters: TODO(owner): data-protection contact/email (e.g. privacy@paasbox.com); appoint a data protection officer if required under Art. 37 GDPR.

(8) Deletion/return at end. After the assignment ends, the provider deletes the customer’s processed data unless a statutory retention duty applies. Concretely: the provider-held control-plane state (etcd) and its backups are deleted when the cluster is deleted or the contract ends; the customer can export them beforehand at any time via kubeconfig/API (clause 2.8 of the service description). Adopted servers are released to the customer and never deleted; their contents reside in the customer’s Hetzner project. Deletion is confirmed on request.

§ 4 Obligations of the customer

(1) The customer issues instructions within this DPA and is responsible for their lawfulness. It names the provider a contact for data-protection matters and keeps the details current. In the console this is normally the team administrator.

(2) The customer informs the provider without undue delay if it detects errors or irregularities in the processing.

§ 5 Data-subject requests

If a data subject approaches the provider with a request under Chapter III GDPR, the provider refers them to the customer without undue delay and forwards the request. The provider assists the customer, as far as technically possible and on instruction, in answering. The provider gives information to third parties only where legally obliged.

§ 6 Evidence and audit rights

(1) The provider demonstrates compliance with its obligations by suitable means and provides the customer, on request, the necessary information, in particular on the implementation of the TOMs under Art. 32 GDPR. Evidence may also be given by current attestations, reports of independent bodies, self-audits, or a suitable certification (e.g. ISO 27001, BSI C5). TODO(owner): name existing certifications/attestations or delete this option.

(2) On request the provider enables audits of the processing activities covered by this DPA at reasonable intervals or on indications of non-compliance, and contributes to them. On-site inspections are limited to one regular audit per calendar year and are conducted with reasonable notice during normal business hours; for-cause inspections are unaffected. Audits are conducted without disrupting operations and with regard to the provider’s security and confidentiality interests; each party bears its own costs.

§ 7 Further processors (sub-processors)

(1) The sub-processors listed in Annex 3 are deemed approved by the customer.

(2) General authorization with a right to object. The customer grants the provider general authorization to engage further sub-processors. The provider informs the customer, in text form, before adding or replacing a sub-processor. The customer may object within 14 calendar days on important data-protection grounds; absent an objection, approval is deemed given. In emergencies (e.g. urgent security risk, unforeseen outage) the provider may act without observing the period and informs the customer without undue delay.

(3) The provider maintains a current list of all sub-processors with name, address, sub-service, and place of processing (Annex 3) and makes it available by a durably accessible means.

(4) The provider binds each sub-processor to the same data-protection obligations under Art. 28(4) GDPR and is liable to the customer for their compliance.

(5) Delineation. For the resources created in the customer’s own Hetzner project (worker nodes, load balancers, volumes), Hetzner is not the provider’s sub-processor; there is an independent contractual relationship between the customer and Hetzner. Hetzner is the provider’s sub-processor only insofar as the provider’s platform and control-plane infrastructure (seeds, etcd) runs there (Annex 3). Pure ancillary services without access to customer data are not sub-processing.

§ 8 Transfers to third countries

Processing takes place exclusively in the Federal Republic of Germany, a member state of the EU, or another contracting state of the EEA (clause 4.4 SaaS Bitkom, clause 2.9 of the service description). No transfer to third countries takes place; such a transfer would require a documented instruction of the customer and compliance with Art. 44 et seq. GDPR.

§ 9 Liability

For liability between the parties, the liability regime agreed in the main contract and the incorporated Bitkom modules (in particular clause 6 AV Bitkom) also applies to this DPA. Towards data subjects, controller and processor are liable under Art. 82 GDPR.

§ 10 Information duties, form, governing law, precedence

(1) If the customer’s data with the provider is endangered by seizure, attachment, insolvency or composition proceedings, or other measures of third parties, the provider informs the customer without undue delay and advises those involved that authority over the data rests solely with the customer as controller.

(2) Amendments and supplements to this DPA require text form and an express statement that they amend this annex. This also applies to any waiver of this form requirement.

(3) In case of conflict between this DPA and the main contract, this DPA prevails on data-protection matters. If a provision of this DPA is invalid, the rest remains valid (severability). German law applies.

---

Annex 1 — Details of the processing

Controller (customer): the customer under the main contract. Processor (provider): the provider. TODO(owner): legal entity, see the imprint.

Subject matter. Operation of the managed Kubernetes control plane on the provider’s infrastructure, i.e. storing, backing up, restoring, and technically operating each cluster’s control-plane state (etcd) on the customer’s behalf, as described in the service description.

Nature and purpose. Storing, backing up (continuous backups), restoring, and managing the etcd state to provide the managed-Kubernetes service. No use for the provider’s own purposes; no analysis of the contents.

Categories of data subjects. Determined solely by the customer: the natural persons whose personal data the customer places into the cluster’s Kubernetes objects — typically the customer’s staff, end customers, or contacts. The provider does not determine these categories and usually does not know them.

Types of personal data. Determined solely by the customer: any personal data the customer places in the control-plane state (etcd) — e.g. credentials, tokens, configuration values, and object metadata in Kubernetes Secrets/ConfigMaps. Workload/application data on worker nodes and in volumes is not the subject of this DPA; it resides in the customer’s own Hetzner project. Special categories (Art. 9 GDPR): only insofar as the customer places such data into Kubernetes objects. The customer should avoid this; if it does place such data, it bears responsibility and alerts the provider to any heightened protection needs.

Duration of storage / deletion. The etcd state and its backups are deleted when the cluster is deleted or the contract ends (§ 3(8)). The customer can export the data beforehand at any time via kubeconfig/API.

Annex 2 — Technical and organizational measures (Art. 32 GDPR)

Confidentiality (access controls).

• The customer-supplied Hetzner API token is stored encrypted, never displayed again after validation (not in the console, the API, or to support), and is scoped to one Hetzner project; the customer can rotate it at any time or revoke it at Hetzner.
• Secrets are managed via write-only references and never echoed back.
• A single, gated write path (portal/API); no standing access in the customer’s project, no retained SSH access; nodes connect outbound-only to their control plane.
• Short-lived admin credentials (kubeconfig, valid at most 8 hours), minted on demand, not stored on the provider’s side, audited on issuance in the team’s activity log.
• API keys with least-privilege scopes, scoped per team (tenant separation: one Gardener project per team, one cluster per isolation unit).

Integrity and availability.

• Continuous backups of the etcd state (incremental deltas roughly every five minutes, periodic full snapshots) to an S3-compatible object-storage system in the EU, independent of the machines running the control plane.
• Restorability of the control plane from this backup chain.
• Never-delete invariant for adopted servers (no delete path; additionally Hetzner delete protection).

Place of processing. Data centers in the EU only (Hetzner, EU).

Encryption of the etcd state. TODO(owner): confirm and precisely describe encryption of the etcd state / Kubernetes Secrets at rest on the seeds.

Further measures. TODO(owner): specify logging/monitoring, a deletion concept, confidentiality undertakings of staff, resilience/recovery, and regular review of the TOMs.

Annex 3 — Sub-processors

Approved at contract conclusion:

Sub-processor	Sub-service	Location
Hetzner Online GmbH	Provision of the provider’s platform and control-plane infrastructure (seeds, etcd)	EU (Germany/Finland)
S3-compatible object storage (EU)	Storage of the etcd backups	EU

TODO(owner): name the exact provider of the etcd-backup object storage (e.g. Hetzner Object Storage or another EU provider) and confirm the Hetzner locations. Keep the list current and publish it at a durable URL.

Not sub-processors of this DPA:

• Hetzner for the resources in the customer’s own Hetzner project (worker nodes, load balancers, volumes) — an independent contractual relationship between the customer and Hetzner (§ 7(5)).
• Stripe (billing) and Mailjet (website newsletter) — they process data for which the provider is the controller; they are listed in the privacy policy as the provider’s processors, not as sub-processors of this DPA.

Annex 4 — Minimum content of a notification under § 3(6)

A notification of a personal-data breach contains, as far as possible:

1. a description of the incident and the nature of the breach;
2. the categories and approximate number of data subjects affected;
3. the categories and approximate number of data records affected;
4. the systems/procedures affected and the time (of occurrence and of detection);
5. the likely consequences of the incident;
6. measures taken or proposed to remedy it and mitigate the risk;
7. a contact point for further information.

This information may be provided in phases without undue further delay.