Data Processing Agreement (DPA)

Preamble and parties

This agreement governs the processing of personal data on behalf of a controller under Art. 28 GDPR between

• the customer who uses the kloq services and is called Controller below, and
• [FIRMA], [ANSCHRIFT], [FIRMENBUCHNUMMER/HANDELSREGISTER], [UID], represented by [GESCHÄFTSFÜHRUNG], contact: [KONTAKT], data protection contact: [DATENSCHUTZKONTAKT], called Processor below.

The Controller's details result from the account at contract conclusion. Under SPEC §17.1.4 the agreement is concluded with the account. Annexes 1 to 4 form part of the agreement.

§1 Subject matter and duration

1. The subject matter is the provision of the software services kloq. time, kloq. people, kloq. pay and kloq. mobile as hosted services (cloud). Which products the Controller uses follows from its account; every product can be used on its own (ADR-016).
2. In doing so the Processor processes personal data solely on behalf of and on documented instruction from the Controller.
3. kloq pay is a payroll pre-capture tool. It does not calculate wages and reports nothing to authorities (SPEC §7). The Processor does not provide payroll accounting.
4. The duration of this agreement equals the term of the contract for use of the kloq services. It ends automatically with that contract, subject to the obligations under §7.
5. Operation of kloq by the Controller itself (self-host) is not covered by this agreement (see Open points, no. 4).

§2 Nature and purpose of processing, types of data, data subjects

1. Nature and purpose of processing: storage, calculation, provision, transmission and deletion of data for time recording, absence and shift planning, person and access management, and payroll pre-capture, expense and receipt management, in each case according to the Controller's settings.
2. The categories of data subjects and the categories of personal data are described conclusively in Annex 1.
3. Special categories of personal data (Art. 9 GDPR) are processed only to the minimal extent described in Annex 1. The Processor does not process biometric data.
4. The Controller remains responsible for the lawfulness of the processing, the choice of legal basis and the fulfilment of its co-determination and information duties. With the co-determination gate (ADR-019) the Processor provides a notice mechanism; it does not replace legal review and does not block.

§3 Obligations of the Processor

1. Binding instructions. The Processor processes data only on documented instruction from the Controller (Art. 28(3)⁠(a) GDPR), including with regard to transfers to third countries, unless required to do so by Union or Member State law. In that case it informs the Controller beforehand, unless that law prohibits this. Instructions follow from Annex 4.
2. Unlawful instructions. If the Processor considers an instruction unlawful, it informs the Controller without undue delay and may suspend execution until the instruction is confirmed or changed (Art. 28(3) subpara. 2 GDPR).
3. Confidentiality. The Processor uses only persons who are committed to confidentiality or subject to a statutory duty of secrecy (Art. 28(3)⁠(b) GDPR) and who have access only to the extent necessary.
4. Technical and organisational measures. The Processor takes the measures under Art. 32 GDPR described in Annex 2 (Art. 28(3)⁠(c) GDPR). Annex 2 states per measure whether it is implemented, partly implemented or planned. The Processor may further develop the measures provided the level of protection does not fall. It documents material changes and communicates them on request.
5. Records. The Processor keeps records of processing activities under Art. 30(2) GDPR.
6. Data protection contact. The Processor names a data protection contact ([DATENSCHUTZKONTAKT]). Whether it is obliged to appoint a data protection officer it assesses on its own responsibility.
7. Separation. Data of different controllers is logically separated (tenant separation, Annex 2).
8. No own use. The Processor does not process the data for its own purposes, in particular not for profiling, performance or behaviour assessment of employees, and not for training models.
9. Logging of access. Access by the Processor to the Controller's data for maintenance and support takes place only with the Controller's approval and is logged (see Annex 2, Open points no. 17).

§4 Sub-processors

1. The Controller grants general authorisation for the use of the sub-processors named in Annex 3 (Art. 28(2) GDPR).
2. The Processor informs the Controller of any intended addition or replacement of a sub-processor 30 days (proposal, see Open points no. 8) before it takes effect, in text form and by updating the list in Annex 3 (register of sub-processors, SPEC §17.1.4).
3. Within that period the Controller may object for an important data protection reason. If it objects, the parties seek a solution (e.g. waiving the service, alternative provider, switching off the affected feature). If no reasonable solution is possible, the Controller may terminate the affected service for cause. The details are to be confirmed (Open points no. 8).
4. The Processor contractually imposes on every sub-processor the same data protection obligations as set out in this agreement (Art. 28(4) GDPR) and remains liable to the Controller for their compliance.
5. Certain sub-processors are used only at the Controller's initiative (e.g. AI receipt recognition, which the Controller must activate). Without activation no data flows there.
6. There is no sub-processing relationship for services which the Controller commissions itself (e.g. SSO providers such as Microsoft Entra or Google Workspace, payroll office, target systems of the connectors). These are the Controller's own contracts (docs/legal/datenschutz-mitbestimmung.md §3.10, side cases).

§5 Assistance to the Controller

1. Data subject rights. The Processor assists the Controller with technical and organisational means in answering requests under Chapter III GDPR (access, rectification, erasure, restriction, portability, objection). For this kloq provides data subject requests with deadline tracking and export (SPEC §17.1.1). If a data subject contacts the Processor directly, the Processor forwards the request to the Controller without undue delay and does not answer it itself unless the Controller instructs it to.
2. Access and export. Access and export decrypt with the person key as long as it exists (ADR-018). After the key is destroyed the affected content can no longer be recovered.
3. Data protection impact assessment. On request the Processor assists with data protection impact assessments and prior consultations (Art. 35, 36 GDPR) and provides information on functions, data flows and measures, in particular on location, health and access-log functions (docs/legal/datenschutz-mitbestimmung.md §6 nos. 6, 15).
4. Personal data breaches. The Processor notifies the Controller of any personal data breach affecting the Controller's data without undue delay after becoming aware of it, so that the Controller can meet the 72-hour deadline under Art. 33 GDPR (SPEC §17.1.2). The notification contains, as far as known: nature of the breach, affected data categories and approximate number of data subjects, likely consequences, measures taken and proposed, contact person. Missing details follow later. Notification address and contact person are in Annex 4.
5. Notification by the Controller. Notification to the supervisory authority (Art. 33) and communication to data subjects (Art. 34) are the Controller's task. The Processor does not notify supervisory authorities or data subjects itself unless it is subject to its own statutory duty.
6. Other assistance. The Processor assists the Controller in complying with Art. 32 to 36 GDPR, taking into account the nature of processing and the information available to it (Art. 28(3)⁠(f) GDPR).
7. Assistance within the standard functions is free of charge. Effort beyond the standard may be remunerated reasonably (Open points no. 10).

§6 Evidence and audit rights

1. On request the Processor makes available to the Controller all information necessary to demonstrate compliance with this agreement (Art. 28(3)⁠(h) GDPR).
2. Evidence is provided primarily by documentation: Annex 2, the records under Art. 30(2) GDPR, the list of sub-processors and, where available, audit reports (e.g. the result of a penetration test under SPEC §4.2.8).
3. After timely notice (at least [30] days, proposal) and during normal business hours, the Controller or an auditor mandated by it and bound to confidentiality may carry out audits including inspections. The audit must not disrupt operations disproportionately and must not disclose data of other customers.
4. Audits take place as a rule at most once a year, except in case of a data breach or a justified suspicion.
5. The allocation of audit costs is open (Open points no. 10).
6. The Controller has access to the access log of its tenant (audit log), which contains writing admin actions, sign-ins, exports, views of sensitive fields and access by the payroll office (SPEC §17). Access by the Processor with the service role is logged separately (Annex 2).

§7 Deletion and return after the end of the contract

1. Export before deletion. Before the contract ends the Controller can export its data. The Processor provides the export in a common, machine-readable format. The Controller is responsible for carrying it out in time. The export period after the end of the contract is [30] days (proposal, to be confirmed).
2. Deletion. After the export period the Processor deletes the Controller's data, unless a statutory retention duty exists (Art. 28(3)⁠(g) GDPR). Deletion follows the deletion concept of ADR-018. Personal reference in immutable (append-only) tables exists only through pseudonyms (subject_ref, actor_ref). Personal payload is encrypted with one data key per person. Deletion works by destroying the person key and removing the mapping of pseudonyms to the person (crypto-shredding). Short-lived raw data (e.g. device reads, raw location values) sits in time-partitioned tables and is removed by partition drop, not by individual deletions.
3. Retention classes. Periods follow the retention classes per country and data class (Annex 4, SPEC §17.2). The Controller can configure them within plausibility limits. For persons with several countries the longest applicable period per data class applies.
4. Restriction instead of deletion. Data that must still be retained is restricted (restriction under Art. 18 GDPR) until the period expires and deleted afterwards.
5. Legal hold. The Controller can set a deletion block with a reason per person or case (e.g. litigation, audit). While it applies, nothing is deleted. Every block and every deletion is recorded in the audit log without personal reference in clear text.
6. Deletion preview and log. Deletion runs show beforehand which persons are affected and are logged. For health and personnel files a four-eyes principle is intended (SPEC §4.2.5, §17.1.3; see status in Annex 2).
7. Backups. Deletion takes effect in backups through key destruction. After a restore the deletion log is applied again (SPEC §17.3). Whether this is accepted as deletion under the GDPR is open (Open points no. 13).
8. Confirmation. On request the Processor confirms deletion in text form.

§8 Transfers to third countries

1. The Processor processes the Controller's data in the territory of the European Union (hosting per Annex 3, subject to confirmation in Open points no. 7). For services that process data outside the EEA, paragraph 2 applies.
2. A transfer to a third country takes place only where provided for in Annex 3, where the requirements of Chapter V GDPR are met and, where it occurs only at the Controller's initiative (AI receipt recognition), the Controller has activated the feature. The Processor documents the transfer basis per sub-processor.
3. Receipt recognition via Anthropic (USA). The feature is off by default. It can be activated only if the Controller has confirmed conclusion of this DPA (enforced in the system). Only the receipt image and a fixed prompt are transmitted, no names, personnel numbers or tenant data; sick notes never enter this processing (ADR-009 no. 5). According to ADR-009 the processing location is not limited to the EU. The transfer basis is open (Open points no. 1 and 2). The permitted description toward employees is: "stored in the EU, receipt recognition via Anthropic (USA)", never "all data in the EU".
4. Support from third countries. Support access to the Controller's data takes place only from the EU or Switzerland or with a transfer basis, because remote access from a third country counts as a transfer (SPEC §17, docs/legal/datenschutz-mitbestimmung.md §3.10).
5. The Processor informs the Controller before any change of the transfer basis (§4 para. 2).

§9 Addendum for controllers based or processing in Switzerland (revDSG)

1. This addendum applies where the Swiss Federal Act on Data Protection (revDSG) applies to the processing. It supplements the provisions of this agreement.
2. Processing by a processor is governed by Art. 9 revDSG: the Processor processes personal data only as the Controller itself would be permitted to, and only if no statutory or contractual duty of secrecy prohibits it. The Controller remains responsible for ensuring that the Processor guarantees data security. Passing processing on to a sub-processor requires the Controller's prior authorisation (Art. 9(3) revDSG). §4 counts as that authorisation within the general authorisation with information and right to object. Whether this general authorisation satisfies Art. 9(3) revDSG is to be checked (Open points no. 11).
3. Data breaches. The Processor notifies the Controller of a breach of data security as soon as possible (Art. 24(3) revDSG). Notification to the Federal Data Protection and Information Commissioner (FDPIC, EDÖB) is the Controller's task and takes place as soon as possible if the breach is likely to lead to a high risk to the personality or fundamental rights of the data subjects (Art. 24(1) revDSG). The notice period from §5 para. 4 also applies to Swiss controllers.
4. Access and release. The Processor assists with access requests under Art. 25 revDSG (30 days under Art. 18(1) DSV) and with release and transfer requests under Art. 28 revDSG (docs/legal/ch-verifikation.md, section Datenschutz).
5. Abroad. Disclosure of personal data abroad follows the revDSG and the DSV. According to Annex 1 DSV, EU/EEA states count as states with adequate data protection. For the USA the Swiss-US Data Privacy Framework (in force since 15 September 2024, Annex 1 DSV) applies only to certified companies (docs/legal/datenschutz-mitbestimmung.md §3.10 [V-CH]). Whether and how Anthropic falls under it is open (Open points no. 1).
6. Register. The register of processing activities follows Art. 12 revDSG and Art. 24 DSV. The exemption for small enterprises does not apply where particularly sensitive personal data is processed on a large scale (docs/legal/datenschutz-mitbestimmung.md §5 no. 18); the case-by-case assessment is not complete.
7. Where Swiss employment law sets stricter requirements (Art. 328b OR, Art. 26 ArGV 3), the Controller remains responsible for configuring the functions accordingly.
8. For the competence of the FDPIC and for venue and governing law, §11 and, where mandatory, Swiss provisions apply.

§10 Liability

1. Draft, placeholder. The parties' liability follows the statutory provisions, in particular Art. 82 GDPR, unless otherwise agreed.
2. A limitation of liability between the parties (e.g. to [BETRAG/VIELFACHES] of the annual fee) and the treatment of damage arising from the Controller's instructions or from acts of sub-processors are not yet determined (Open points no. 9).
3. Liability for intent, gross negligence, injury to life, body or health, and under mandatory law remains unaffected.
4. No contractual penalty is agreed (Open points no. 10).

§11 Term and final provisions

1. The agreement begins on conclusion and ends with the contract for use. The right to terminate for cause remains unaffected, in particular in case of serious breaches of data protection duties.
2. Obligations which by their nature continue beyond the end of the contract (confidentiality, deletion, liability) remain in force.
3. Amendments and additions require text form. This also applies to changing this clause. Changes to Annexes 2 and 3 follow §3 para. 4 and §4.
4. If individual provisions are invalid, the rest of the agreement remains valid. The parties replace the invalid provision with a valid one that comes closest to its purpose.
5. In case of conflict between this agreement and the contract for use, this agreement prevails insofar as it concerns the processing of personal data.
6. Governing law and venue: [ANWENDBARES RECHT UND GERICHTSSTAND – noch festzulegen]. Mandatory data protection provisions remain unaffected.
7. Parties, contact persons and signatures: the agreement is concluded electronically with the account (SPEC §17.1.4). Conclusion is logged with time and person.

Annex 1 Subject matter, duration, nature, purpose, data subjects, data categories

1.1 Subject matter and purpose per product

Sources: SPEC §5 to §8, ADR-016.

Nature of processing for all products: collecting, recording, storing, organising, linking, calculating, retrieving, querying, transmitting (to authorised users and, where configured, to target systems and the payroll office), restricting, deleting.

1.2 Categories of data subjects

• Employees of the Controller (staff, including part-time, with several employments or in several countries).
• Departed employees (restricted access for access requests, payslips and withdrawal of consents, SPEC §2.2.11).
• Users with administrative roles: administrators, HR, IT administrators, team leads, data protection and works council roles.
• Payroll office staff (user accounts of the Controller; they see exactly one tenant per session).
• Applicants: not covered (see Open points no. 14).

1.3 Categories of personal data

1.4 Special categories (Art. 9 GDPR)

• Health data: for sick leave only period and type (minimal type catalogue), no diagnosis (SPEC §5.4.8, §17). A photo of a certificate is optional and off by default (in Germany the duty to submit it lapses for statutorily insured persons thanks to eAU; docs/legal/datenschutz-mitbestimmung.md §3.4). If the Controller enables attachments, they are stored with their own retention class (health_attachments) and never form part of receipt recognition.
• Protection periods (maternity protection, breastfeeding time, disability) are health data and stored in isolation: only type, from, to, without diagnosis; visible only to HR and the person themselves (SPEC §6.1.6).
• Biometrics: the Processor does not store or process biometric data. If the Controller operates a terminal with biometrics, the template stays in the terminal; kloq receives only the user ID from the terminal. The Controller nevertheless remains controller under Art. 9 GDPR (docs/legal/datenschutz-mitbestimmung.md §1 no. 5, §3.3).

Annex 2 Technical and organisational measures (TOM)

As of 2026-10-10, derived from the code, migrations and specification in the repository. The "Status" column has three values:

• implemented: demonstrable in code or migrations (source given). This does not confirm operations, only the software capability.
• partly: building blocks exist, the complete measure does not yet.
• planned: foreseen by the SPEC, not demonstrable in code or operations. This is a target, not a statement of the actual state.

Several operational measures (hosting, backups, access management at the provider) cannot be demonstrated from the repository. They are therefore not marked "implemented".

2.1 Physical access control and hosting

2.2 System access control (authentication)

2.3 Data access control (authorisations)

2.4 Encryption

2.5 Pseudonymisation and crypto-shredding

2.6 Integrity

2.7 Availability and recoverability

2.8 Separation control

2.9 Input and order control

2.10 Further measures

Annex 3 Sub-processors

As of 2026-10-10. The authorisation under §4 covers the following entries. Changes are notified 30 days (proposal) before taking effect, in text form; the Controller may object for an important data protection reason (§4 paras. 2 and 3).

Notes:

• The Controller can switch push notifications off (retrieval when opening the app). For Apple and Google it must be clarified whether they are processors or independent controllers; until then the entry is a precaution.
• The Controller's own service providers named in §4 para. 6 (SSO providers, target systems, payroll office) are not sub-processors of the Processor.
• No further sub-processors (e.g. error reporting, monitoring, support tools) are currently foreseen. Telemetry is free of personal data by default (SPEC §4.2.6).

Annex 4 Instructions, contacts, deletion periods

4.1 Instructions

1. Documented instructions. The following count as documented instructions: first, the configuration by the Controller in the product (settings, rights, retention classes, activation of optional functions such as location and receipt recognition, exports, deletions and legal holds) and second, written instructions in text form to [DATENSCHUTZKONTAKT].
2. Oral instructions are to be confirmed in text form without undue delay.
3. Instructions going beyond the standard functions may trigger reasonable additional costs (Open points no. 10).

4.2 Persons entitled to instruct and recipients of instructions

4.3 Contact for data breaches

Notification is made without undue delay in text form (§5 para. 4). For Swiss controllers "as soon as possible" applies (§9 para. 3).

4.4 Deletion periods (retention classes)

Starting values, to be confirmed. The values are rule data (packages/rules, with legal reference and valid_from), adjustable per Controller within plausibility limits. The former default of 7 years for all payroll-relevant data has been dropped. For persons with several countries the longest applicable period per data class applies. The start of the period is to be defined per class. Source: SPEC §17.2, docs/legal/datenschutz-mitbestimmung.md §3.7, §5 nos. 8 and 9.

The periods for time bookings in AT and DE are not derived from a statutory period (AZG § 26 contains none; ArbZG § 16(2) and MiLoG § 17(2) apply only to a subset) and rest on limitation and forfeiture. The result of location capture follows the period for time_records.