Auftragsverarbeitungsvertrag (AVV)
Entwurf – vor Veröffentlichung von einer Rechtsanwältin/einem Rechtsanwalt prüfen lassen
Dieser Text ist ein Entwurf und keine Rechtsberatung. Er ist noch nicht juristisch geprüft und darf nicht als verbindlich verstanden werden. Firmendaten des Anbieters stehen als Platzhalter in eckigen Klammern.
Version 2026-1-entwurf
Offene Punkte
Diese Punkte sind vor der Veröffentlichung zu klären.
- Transfermechanismus Anthropic (USA). Die Belegerkennung über Anthropic PBC ist nur nutzbar, wenn der Kunde sie aktiviert (ADR-009). Der Verarbeitungsort der Claude API ist laut ADR-009 nur
usoderglobal, keine EU-Region. Offen: Ist Anthropic unter dem EU-US Data Privacy Framework zertifiziert, und reicht das, oder sind zusätzlich Standardvertragsklauseln (Art. 46 DSGVO) samt Transfer-Risikoprüfung nötig? Das Rechtsmittel gegen die Abweisung der Klage Latombe (EuG T-553/23, Rechtsmittel C-703/25 P) ist lautdocs/legal/datenschutz-mitbestimmung.md§3.10 mit Stand offen. Vorgesehen ist, dass die Funktion standardmäßig aus bleibt, bis der AVV steht (ADR-009 Nr. 5; im System erzwungen, siehe Anlage 2). Keine Aussage dieses Entwurfs gilt als Bestätigung einer Transfergrundlage. - Zero Retention und Trainingsverbot bei Anthropic.
docs/legal/datenschutz-mitbestimmung.md§3.10 fordert für OCR-Anbieter: keine Nutzung für Training, kurze oder keine Speicherung, Löschbestätigung. Ob und wie das vertraglich mit Anthropic zugesichert ist, steht nicht fest und muss geprüft werden. - Rolle von Apple (APNs) und Google (FCM). Ob beide Auftragsverarbeiter oder eigene Verantwortliche sind, ist ungeklärt (
docs/legal/datenschutz-mitbestimmung.md§3.10, §5 Nr. 11). Ebenso offen: Transfergrundlage und Transparenz. In diesem Entwurf sind sie in Anlage 3 vorsorglich mit dem Status „Rechtsstatus offen“ aufgeführt. - Rolle von kloq beim Push-Relay im Self-Host-Fall. Der Self-Host-Betrieb ist nicht Gegenstand dieses AVV. Offen ist, ob [FIRMA] für das Push-Relay und Update-Server Auftragsverarbeiter oder eigener Verantwortlicher ist (SPEC §15.5, §21,
docs/legal/datenschutz-mitbestimmung.md§5 Nr. 10). - Rolle des Lohnbüros. Das Lohnbüro (Steuerberatung, Lohnverrechnung) kann Auftragsverarbeiter des Kunden oder eigener Verantwortlicher sein; die Praxis ist in DE uneinheitlich (
docs/legal/datenschutz-mitbestimmung.md§3.10, §5 Nr. 12). Der Kunde entscheidet. Dieser Entwurf behandelt Lohnbüro-Konten in Anlage 1 als Nutzerkonten des Kunden und regelt die AVV-Kette zwischen Kunde und Lohnbüro nicht. - SMTP-Anbieter. Für den Versand von Einladungs-, Anmelde- und Benachrichtigungs-E-Mails braucht kloq einen SMTP-Anbieter. Der Anbieter ist noch nicht entschieden; der Code liest nur
KLOQ_SMTP_HOST. Anlage 3 enthält deshalb einen Platzhalter. Sitz, Transfergrundlage und AVV-Referenz sind nachzutragen. - Hosting und AVV-Referenz Hetzner. Im Repository ist Hetzner nicht dokumentiert. SPEC §21.1 (ADR-004) nennt als Hosting-Region „EU (Frankfurt/Wien), AV-Vertrag“ und führt die Entscheidung nicht als abgeschlossen. Zu bestätigen: Hetzner Online GmbH als Hosting-Anbieter, Standort der Rechenzentren (Deutschland), die AVV-Referenz mit Hetzner und die Abbildung des Unterauftragsverhältnisses. Anlage 2 kennzeichnet die Hosting-Aussagen entsprechend.
- Frist für Subprozessor-Änderungen. 30 Tage Vorabinformation sind ein Vorschlag (
docs/legal/datenschutz-mitbestimmung.md§3.10, Randfälle: „z. B. 30 T“). Die Frist, die Form der Mitteilung und die Folgen eines Einspruchs (Sonderkündigungsrecht, Ersatzlösung) sind zu entscheiden. - Haftung (§10). Die Haftungsregelung ist ein Platzhalter. Zu entscheiden: Haftungsbegrenzung auf Vertragsvolumen oder Vielfaches, Verhältnis zu Art. 82 DSGVO im Außenverhältnis, Regelung für Schäden durch Weisungen und durch Unterauftragsverarbeiter.
- Vertragsstrafe und Audit-Kosten. Offen ist, ob der Kunde Prüfungen (§6) auf eigene Kosten durchführt, ab welchem Aufwand [FIRMA] eine Vergütung verlangen darf, und ob eine Vertragsstrafe überhaupt vereinbart werden soll. Dieser Entwurf sieht keine Vertragsstrafe vor.
- CH-Zusatz (§9). Art. 9 revDSG (Auftragsbearbeitung) und Art. 24 revDSG (Meldung) sind in
docs/legal/ch-verifikation.mdals bestätigt geführt (Fedlex, Stand 7.7.2025). Nicht abschließend geprüft: das Verhältnis zur Weitergabe an einen Unterauftragsbearbeiter im Ausland (Art. 16 f. revDSG), die Zuständigkeit des EDÖB im Einzelfall und ob für einen CH-Kunden die Standardvertragsklauseln der EU-Kommission mit schweizerischer Anpassung erforderlich sind. - Aufbewahrungsfristen. Die Werte in Anlage 4 sind Ausgangswerte und laut
docs/legal/datenschutz-mitbestimmung.md§5 Nr. 8 zu bestätigen, mehrere sind als UNVERIFIZIERT markiert (z. B. AT/DE Zeitbuchungen, Bewerber CH). - Crypto-Shredding als Löschung. Ob Aufsichtsbehörden Crypto-Shredding und Partitions-Drop samt verbleibender Hash-Reste als Löschung anerkennen, ist offen (
docs/legal/datenschutz-mitbestimmung.md§5 Nr. 9). Das gilt auch für Backups. §7 formuliert deshalb Löschung als Vernichtung des Personenschlüssels und weist die Unsicherheit aus. - Bewerber:innen. SPEC §6.3 sieht keinen Bewerbungsprozess vor; die Aufbewahrungsklasse
applicantsexistiert nur als Regeldatum. Bewerberdaten sind deshalb nicht Gegenstand dieses Vertrags. Falls dies später hinzukommt, sind Anlage 1 und Anlage 4 anzupassen. - Datenpannen-Meldung. Die Meldefrist von [FIRMA] an den Kunden („unverzüglich“) ist bewusst nicht in Stunden beziffert. Ob eine feste Obergrenze (z. B. 24 Stunden) aufgenommen werden soll, ist zu entscheiden. Der Kunde muss die 72 Stunden nach Art. 33 DSGVO einhalten können (
docs/legal/datenschutz-mitbestimmung.md§5 Nr. 17). - Umsetzungsstand der Maßnahmen. Mehrere Maßnahmen in Anlage 2 sind nur teilweise umgesetzt oder geplant (Backups mit Point-in-Time-Recovery, Restore-Tests, Penetrationstest, Lösch-Job als eigener Dienst, Feldverschlüsselung der Lohnstammfelder). Vor Veröffentlichung ist jede Zeile mit dem tatsächlichen Betrieb abzugleichen; eine Maßnahme darf erst als „umgesetzt“ stehen, wenn sie nachweisbar läuft.
- Support-Zugriff. SPEC §17 verlangt Support nur aus EU/CH oder mit Transfergrundlage. Das Verfahren für protokollierte, befristete Support-Freigaben (SPEC §2, Plattform-Admin) ist in diesem Entwurf nur als Grundsatz beschrieben und muss technisch bestätigt werden.
Präambel und Parteien
Dieser Vertrag regelt die Verarbeitung personenbezogener Daten im Auftrag nach Art. 28 DSGVO zwischen
- dem Kunden, der die kloq-Dienste nutzt und im Folgenden Verantwortlicher heißt, und
- [FIRMA], [ANSCHRIFT], [FIRMENBUCHNUMMER/HANDELSREGISTER], [UID], vertreten durch [GESCHÄFTSFÜHRUNG], Kontakt: [KONTAKT], Datenschutzkontakt: [DATENSCHUTZKONTAKT], im Folgenden Auftragsverarbeiter.
Die Angaben zum Verantwortlichen ergeben sich aus dem Konto bei Vertragsabschluss. Der Vertrag wird nach SPEC §17.1.4 mit dem Konto abgeschlossen. Anlagen 1 bis 4 sind Bestandteil des Vertrags.
§1 Gegenstand und Dauer
- Gegenstand ist die Bereitstellung der Software-Dienste kloq. time, kloq. people, kloq. pay und kloq. mobile als gehostete Dienste (Cloud). Welche Produkte der Verantwortliche nutzt, ergibt sich aus seinem Konto; jedes Produkt ist einzeln nutzbar (ADR-016).
- Der Auftragsverarbeiter verarbeitet dabei personenbezogene Daten ausschließlich im Auftrag und nach dokumentierter Weisung des Verantwortlichen.
- kloq pay ist eine Lohn-Vorerfassung. Es berechnet keine Löhne und meldet nichts an Behörden (SPEC §7). Der Auftragsverarbeiter erbringt keine Lohnverrechnung.
- Die Dauer dieses Vertrags entspricht der Laufzeit des Nutzungsvertrags über die kloq-Dienste. Er endet automatisch mit dessen Ende, vorbehaltlich der Pflichten nach §7.
- Der Betrieb von kloq im Selbstbetrieb des Verantwortlichen (Self-Host) ist nicht Gegenstand dieses Vertrags (siehe Offene Punkte, Nr. 4).
§2 Art und Zweck der Verarbeitung, Datenarten, Betroffene
- Art und Zweck der Verarbeitung: Speicherung, Berechnung, Bereitstellung, Übermittlung und Löschung von Daten zur Zeiterfassung, Abwesenheits- und Dienstplanverwaltung, Personen- und Zugangsverwaltung sowie Lohn-Vorerfassung, Spesen- und Belegverwaltung, jeweils nach den Einstellungen des Verantwortlichen.
- Die Kategorien betroffener Personen und die Kategorien personenbezogener Daten sind in Anlage 1 abschließend beschrieben.
- Besondere Kategorien personenbezogener Daten (Art. 9 DSGVO) werden nur in dem in Anlage 1 beschriebenen minimalen Umfang verarbeitet. Biometrische Daten verarbeitet der Auftragsverarbeiter nicht.
- Der Verantwortliche bleibt für die Rechtmäßigkeit der Verarbeitung, die Wahl der Rechtsgrundlage und die Erfüllung seiner Mitbestimmungs- und Informationspflichten verantwortlich. Der Auftragsverarbeiter stellt mit dem Mitbestimmungs-Gate (ADR-019) einen Hinweismechanismus bereit; dieser ersetzt keine Rechtsprüfung und blockiert nicht.
§3 Pflichten des Auftragsverarbeiters
- Weisungsbindung. Der Auftragsverarbeiter verarbeitet Daten nur auf dokumentierte Weisung des Verantwortlichen (Art. 28 Abs. 3 lit. a DSGVO), auch bei Übermittlungen in Drittländer, es sei denn, er ist durch Unionsrecht oder das Recht eines Mitgliedstaats zur Verarbeitung verpflichtet. In diesem Fall teilt er dies dem Verantwortlichen vorab mit, soweit das Recht dies nicht verbietet. Weisungen ergeben sich aus Anlage 4.
- Rechtswidrige Weisungen. Hält der Auftragsverarbeiter eine Weisung für rechtswidrig, informiert er den Verantwortlichen unverzüglich und ist berechtigt, die Ausführung auszusetzen, bis die Weisung bestätigt oder geändert wird (Art. 28 Abs. 3 Unterabs. 2 DSGVO).
- Vertraulichkeit. Der Auftragsverarbeiter setzt nur Personen ein, die zur Vertraulichkeit verpflichtet sind oder einer gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO), und die nur im erforderlichen Umfang Zugriff haben.
- Technische und organisatorische Maßnahmen. Der Auftragsverarbeiter trifft die Maßnahmen nach Art. 32 DSGVO, die in Anlage 2 beschrieben sind (Art. 28 Abs. 3 lit. c DSGVO). Anlage 2 weist je Maßnahme aus, ob sie umgesetzt, teilweise umgesetzt oder geplant ist. Der Auftragsverarbeiter darf die Maßnahmen weiterentwickeln, sofern das Schutzniveau nicht sinkt. Wesentliche Änderungen dokumentiert er und teilt sie auf Anfrage mit.
- Verzeichnis. Der Auftragsverarbeiter führt ein Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 Abs. 2 DSGVO.
- Datenschutzkontakt. Der Auftragsverarbeiter benennt einen Datenschutzkontakt ([DATENSCHUTZKONTAKT]). Ob eine Pflicht zur Benennung eines Datenschutzbeauftragten besteht, prüft er in eigener Verantwortung.
- Trennung. Daten verschiedener Verantwortlicher werden logisch getrennt (Mandantentrennung, Anlage 2).
- Keine eigene Nutzung. Der Auftragsverarbeiter verarbeitet die Daten nicht für eigene Zwecke, insbesondere nicht für Profiling, Leistungs- oder Verhaltensbewertung von Beschäftigten und nicht für das Training von Modellen.
- Protokollierung des Zugriffs. Zugriffe des Auftragsverarbeiters auf Daten des Verantwortlichen im Rahmen von Wartung und Support erfolgen nur mit Freigabe des Verantwortlichen und werden protokolliert (siehe Anlage 2, Offene Punkte Nr. 17).
§4 Unterauftragsverarbeiter
- Der Verantwortliche erteilt eine allgemeine Genehmigung für den Einsatz der in Anlage 3 genannten Unterauftragsverarbeiter (Art. 28 Abs. 2 DSGVO).
- Der Auftragsverarbeiter informiert den Verantwortlichen über jede beabsichtigte Hinzufügung oder Ersetzung eines Unterauftragsverarbeiters mit einer Frist von 30 Tagen (Vorschlag, siehe Offene Punkte Nr. 8) vor dem Wirksamwerden, in Textform und durch Aktualisierung der Liste in Anlage 3 (Verzeichnis der Unterauftragsverarbeiter, SPEC §17.1.4).
- Der Verantwortliche kann innerhalb dieser Frist aus wichtigem datenschutzrechtlichem Grund Einspruch erheben. Erhebt er Einspruch, suchen die Parteien eine Lösung (z. B. Verzicht auf den Dienst, Alternativanbieter, Abschaltung der betroffenen Funktion). Ist keine zumutbare Lösung möglich, darf der Verantwortliche den betroffenen Dienst außerordentlich kündigen. Die Details sind zu bestätigen (Offene Punkte Nr. 8).
- Der Auftragsverarbeiter verpflichtet jeden Unterauftragsverarbeiter vertraglich zu denselben Datenschutzpflichten, die in diesem Vertrag festgelegt sind (Art. 28 Abs. 4 DSGVO), und haftet gegenüber dem Verantwortlichen für deren Einhaltung.
- Einzelne Unterauftragsverarbeiter werden nur auf Veranlassung des Verantwortlichen eingesetzt (z. B. die KI-Belegerkennung, die der Verantwortliche aktivieren muss). Ohne Aktivierung fließen keine Daten dorthin.
- Kein Unterauftragsverhältnis liegt vor bei Dienstleistungen, die der Verantwortliche selbst beauftragt (z. B. SSO-Anbieter wie Microsoft Entra oder Google Workspace, Lohnbüro, Zielsysteme der Connectors). Dies sind eigene Verträge des Verantwortlichen (
docs/legal/datenschutz-mitbestimmung.md§3.10, Randfälle).
§5 Unterstützung des Verantwortlichen
- Betroffenenrechte. Der Auftragsverarbeiter unterstützt den Verantwortlichen mit technischen und organisatorischen Mitteln bei der Beantwortung von Anträgen nach Kapitel III DSGVO (Auskunft, Berichtigung, Löschung, Einschränkung, Übertragbarkeit, Widerspruch). Dazu stellt kloq Betroffenenanfragen mit Fristüberwachung und Export bereit (SPEC §17.1.1). Meldet sich eine betroffene Person direkt beim Auftragsverarbeiter, leitet dieser die Anfrage unverzüglich an den Verantwortlichen weiter und beantwortet sie nicht selbst, es sei denn, der Verantwortliche weist ihn dazu an.
- Fristen. Auskunft und Export entschlüsseln mit dem Personenschlüssel, solange er existiert (ADR-018). Nach Vernichtung des Schlüssels sind die betreffenden Inhalte nicht mehr herstellbar.
- Datenschutz-Folgenabschätzung. Der Auftragsverarbeiter unterstützt auf Anfrage bei Datenschutz-Folgenabschätzungen und vorherigen Konsultationen (Art. 35, 36 DSGVO) und stellt dafür Informationen über die Funktionen, Datenflüsse und Maßnahmen bereit, insbesondere zu Standort-, Gesundheits- und Zugriffsprotokoll-Funktionen (
docs/legal/datenschutz-mitbestimmung.md§6 Nr. 6, 15). - Verletzungen des Schutzes personenbezogener Daten. Der Auftragsverarbeiter meldet dem Verantwortlichen jede Verletzung des Schutzes personenbezogener Daten, die Daten des Verantwortlichen betrifft, unverzüglich nach Bekanntwerden, so dass der Verantwortliche die Meldefrist von 72 Stunden nach Art. 33 DSGVO einhalten kann (SPEC §17.1.2). Die Meldung enthält, soweit bekannt: Art der Verletzung, betroffene Datenkategorien und ungefähre Zahl der Betroffenen, wahrscheinliche Folgen, ergriffene und vorgeschlagene Maßnahmen, Ansprechperson. Fehlende Angaben werden nachgereicht. Meldeadresse und Ansprechperson stehen in Anlage 4.
- Meldung durch den Verantwortlichen. Die Meldung an die Aufsichtsbehörde (Art. 33) und die Benachrichtigung Betroffener (Art. 34) sind Sache des Verantwortlichen. Der Auftragsverarbeiter meldet nicht selbst an Aufsichtsbehörden oder Betroffene, es sei denn, ihn trifft eine eigene gesetzliche Pflicht.
- Sonstige Unterstützung. Der Auftragsverarbeiter unterstützt den Verantwortlichen bei der Einhaltung der Pflichten aus Art. 32 bis 36 DSGVO unter Berücksichtigung der Art der Verarbeitung und der ihm zur Verfügung stehenden Informationen (Art. 28 Abs. 3 lit. f DSGVO).
- Die Unterstützung ist im Rahmen der Standardfunktionen kostenfrei. Über den Standard hinausgehender Aufwand kann angemessen vergütet werden (Offene Punkte Nr. 10).
§6 Nachweise und Kontrollrechte
- Der Auftragsverarbeiter stellt dem Verantwortlichen auf Anfrage alle Informationen bereit, die zum Nachweis der Einhaltung dieses Vertrags erforderlich sind (Art. 28 Abs. 3 lit. h DSGVO).
- Der Nachweis erfolgt vorrangig durch Dokumentation: Anlage 2, das Verzeichnis nach Art. 30 Abs. 2 DSGVO, die Liste der Unterauftragsverarbeiter und, soweit vorhanden, Prüfberichte (z. B. Ergebnis eines Penetrationtests nach SPEC §4.2.8).
- Der Verantwortliche oder ein von ihm beauftragter, zur Verschwiegenheit verpflichteter Prüfer darf nach rechtzeitiger Ankündigung (mindestens [30] Tage, Vorschlag) und während der üblichen Geschäftszeiten Prüfungen einschließlich Inspektionen durchführen. Die Prüfung darf den Betrieb nicht unverhältnismäßig stören und keine Daten anderer Kunden offenlegen.
- Prüfungen finden in der Regel höchstens einmal jährlich statt, außer bei einer Datenpanne oder einem begründeten Verdacht.
- Die Verteilung der Kosten einer Prüfung ist offen (Offene Punkte Nr. 10).
- Der Verantwortliche erhält Einsicht in das Zugriffsprotokoll seines Mandanten (Audit-Log), das schreibende Admin-Aktionen, Anmeldungen, Exporte, Einsichten in sensible Felder und Zugriffe des Lohnbüros enthält (SPEC §17). Zugriffe des Auftragsverarbeiters mit Service-Rolle werden gesondert protokolliert (Anlage 2).
§7 Löschung und Rückgabe nach Vertragsende
- Export vor Löschung. Vor Ende des Vertrags kann der Verantwortliche seine Daten exportieren. Der Auftragsverarbeiter stellt den Export in einem gängigen, maschinenlesbaren Format bereit. Der Verantwortliche ist für die rechtzeitige Durchführung verantwortlich. Die Exportfrist nach Vertragsende beträgt [30] Tage (Vorschlag, zu bestätigen).
- Löschung. Nach Ablauf der Exportfrist löscht der Auftragsverarbeiter die Daten des Verantwortlichen, soweit keine gesetzliche Aufbewahrungspflicht besteht (Art. 28 Abs. 3 lit. g DSGVO). Die Löschung folgt dem Löschkonzept nach ADR-018. Personenbezug in unveränderlichen (Append-only-)Tabellen besteht nur über Pseudonyme (
subject_ref,actor_ref). Personenbezogene Nutzlast ist mit einem Datenschlüssel pro Person verschlüsselt. Gelöscht wird, indem der Personenschlüssel vernichtet und die Zuordnung der Pseudonyme zur Person entfernt wird (Crypto-Shredding). Kurzlebige Rohdaten (z. B. Geräte-Lesungen, Standort-Rohwerte) liegen in zeitlich partitionierten Tabellen und werden durch Partitions-Drop entfernt, nicht durch einzelne Löschungen. - Aufbewahrungsklassen. Fristen richten sich nach den Aufbewahrungsklassen je Land und Datenklasse (Anlage 4, SPEC §17.2). Der Verantwortliche kann sie innerhalb von Plausibilitätsgrenzen konfigurieren. Bei Personen mit mehreren Ländern gilt je Datenklasse die längste einschlägige Frist.
- Sperren statt Löschen. Daten, die noch aufzubewahren sind, werden bis zum Fristablauf gesperrt (Einschränkung nach Art. 18 DSGVO) und danach gelöscht.
- Legal Hold. Der Verantwortliche kann pro Person oder Vorgang eine Löschsperre mit Begründung setzen (z. B. Rechtsstreit, Prüfung). Solange sie wirkt, wird nicht gelöscht. Jede Sperre und jede Löschung wird im Audit-Log festgehalten, ohne Personenbezug im Klartext.
- Löschvorschau und Protokoll. Löschläufe zeigen vorab, welche Personen betroffen sind, und werden protokolliert. Für Gesundheits- und Personalakten ist ein Vier-Augen-Prinzip vorgesehen (SPEC §4.2.5, §17.1.3; siehe Status in Anlage 2).
- Backups. Löschung wirkt in Sicherungen über die Schlüsselvernichtung. Nach einer Wiederherstellung wird das Löschprotokoll erneut angewandt (SPEC §17.3). Ob dies als Löschung im Sinne der DSGVO anerkannt wird, ist offen (Offene Punkte Nr. 13).
- Bestätigung. Auf Anfrage bestätigt der Auftragsverarbeiter die Löschung in Textform.
§8 Drittlandübermittlung
- Der Auftragsverarbeiter verarbeitet Daten des Verantwortlichen im Gebiet der Europäischen Union (Hosting laut Anlage 3, vorbehaltlich der Bestätigung in Offene Punkte Nr. 7). Für Dienste, die Daten außerhalb des EWR verarbeiten, gilt Absatz 2.
- Eine Übermittlung in ein Drittland findet nur statt, soweit sie nach Anlage 3 vorgesehen ist, die Voraussetzungen des Kapitels V DSGVO erfüllt sind und, wo sie nur auf Veranlassung des Verantwortlichen erfolgt (KI-Belegerkennung), dieser die Funktion aktiviert hat. Der Auftragsverarbeiter dokumentiert die Transfergrundlage je Unterauftragsverarbeiter.
- Belegerkennung über Anthropic (USA). Die Funktion ist standardmäßig aus. Sie kann nur aktiviert werden, wenn der Verantwortliche den Abschluss dieses AVV bestätigt hat (im System erzwungen). Übermittelt werden nur das Belegbild und ein fester Prompt, keine Namen, Personalnummern oder Mandantendaten; Krankmeldungen gelangen nie in diese Verarbeitung (ADR-009 Nr. 5). Der Verarbeitungsort ist laut ADR-009 nicht auf die EU beschränkt. Die Transfergrundlage ist offen (Offene Punkte Nr. 1 und 2). Die zulässige Beschreibung gegenüber Beschäftigten lautet: „gespeichert in der EU, Belegerkennung über Anthropic (USA)“, nie „alle Daten in der EU“.
- Support aus Drittländern. Support-Zugriff auf Daten des Verantwortlichen erfolgt nur aus der EU oder der Schweiz oder mit einer Transfergrundlage, da ein Fernzugriff aus einem Drittland als Übermittlung gilt (SPEC §17,
docs/legal/datenschutz-mitbestimmung.md§3.10). - Der Auftragsverarbeiter informiert den Verantwortlichen vor jeder Änderung der Transfergrundlage (§4 Abs. 2).
§9 Zusatz für Verantwortliche mit Sitz oder Verarbeitung in der Schweiz (revDSG)
- Dieser Zusatz gilt, soweit das Schweizer Bundesgesetz über den Datenschutz (revDSG) auf die Verarbeitung anwendbar ist. Er ergänzt die Regelungen dieses Vertrags.
- Die Auftragsbearbeitung richtet sich nach Art. 9 revDSG: Der Auftragsverarbeiter bearbeitet Personendaten nur so, wie der Verantwortliche es selbst tun dürfte, und nur, wenn keine gesetzliche oder vertragliche Geheimhaltungspflicht es verbietet. Der Verantwortliche bleibt dafür verantwortlich, dass der Auftragsverarbeiter die Datensicherheit gewährleistet. Die Übertragung auf einen Unterauftragsbearbeiter setzt die vorgängige Genehmigung des Verantwortlichen voraus (Art. 9 Abs. 3 revDSG). §4 gilt als solche Genehmigung im Rahmen der allgemeinen Genehmigung mit Information und Einspruchsrecht. Ob diese allgemeine Genehmigung den Anforderungen von Art. 9 Abs. 3 revDSG genügt, ist zu prüfen (Offene Punkte Nr. 11).
- Datenpannen. Der Auftragsverarbeiter meldet dem Verantwortlichen eine Verletzung der Datensicherheit so rasch als möglich (Art. 24 Abs. 3 revDSG). Die Meldung an den Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) ist Sache des Verantwortlichen und erfolgt so rasch als möglich, wenn die Verletzung voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Personen führt (Art. 24 Abs. 1 revDSG). Die Meldefrist aus §5 Abs. 4 gilt auch für CH-Verantwortliche.
- Auskunft und Herausgabe. Der Auftragsverarbeiter unterstützt Auskunftsbegehren nach Art. 25 revDSG (30 Tage nach Art. 18 Abs. 1 DSV) und Herausgabe- und Übertragungsbegehren nach Art. 28 revDSG (
docs/legal/ch-verifikation.md, Abschnitt Datenschutz). - Ausland. Die Bekanntgabe von Personendaten ins Ausland richtet sich nach den Vorgaben des revDSG und der DSV. Die EU/EWR-Staaten gelten nach Anhang 1 DSV als Staaten mit angemessenem Datenschutz. Für die USA gilt das Swiss-US Data Privacy Framework (in Kraft seit 15. September 2024, Anhang 1 DSV) nur für zertifizierte Unternehmen (
docs/legal/datenschutz-mitbestimmung.md§3.10 [V-CH]). Ob und wie Anthropic hierunter fällt, ist offen (Offene Punkte Nr. 1). - Verzeichnis. Das Bearbeitungsverzeichnis richtet sich nach Art. 12 revDSG und Art. 24 DSV. Die Ausnahme für kleine Unternehmen entfällt bei umfangreicher Bearbeitung besonders schützenswerter Personendaten (
docs/legal/datenschutz-mitbestimmung.md§5 Nr. 18); die Einzelfallprüfung ist nicht abgeschlossen. - Soweit das Schweizer Arbeitsrecht strengere Anforderungen stellt (Art. 328b OR, Art. 26 ArGV 3), bleibt der Verantwortliche dafür verantwortlich, die Funktionen entsprechend zu konfigurieren.
- Für die Zuständigkeit des EDÖB und für Gerichtsstand und anwendbares Recht gelten §11 und, soweit zwingend, die Schweizer Vorschriften.
§10 Haftung
- Entwurf, Platzhalter. Die Haftung der Parteien richtet sich nach den gesetzlichen Vorschriften, insbesondere Art. 82 DSGVO, soweit nichts anderes vereinbart wird.
- Eine Haftungsbegrenzung im Innenverhältnis (z. B. auf [BETRAG/VIELFACHES] der jährlichen Vergütung) und die Behandlung von Schäden aus Weisungen des Verantwortlichen oder aus Handlungen von Unterauftragsverarbeitern sind noch nicht festgelegt (Offene Punkte Nr. 9).
- Die Haftung für Vorsatz, grobe Fahrlässigkeit, Verletzung von Leben, Körper und Gesundheit sowie nach zwingendem Recht bleibt unberührt.
- Eine Vertragsstrafe ist nicht vereinbart (Offene Punkte Nr. 10).
§11 Laufzeit und Schlussbestimmungen
- Der Vertrag beginnt mit dem Abschluss und endet mit dem Nutzungsvertrag. Das Recht zur außerordentlichen Kündigung aus wichtigem Grund bleibt unberührt, insbesondere bei schwerwiegenden Verstößen gegen Datenschutzpflichten.
- Pflichten, die ihrer Natur nach über das Vertragsende hinaus wirken (Vertraulichkeit, Löschung, Haftung), bleiben bestehen.
- Änderungen und Ergänzungen bedürfen der Textform. Das gilt auch für die Änderung dieser Klausel. Änderungen der Anlagen 2 und 3 richten sich nach §3 Abs. 4 und §4.
- Sollten einzelne Bestimmungen unwirksam sein, bleibt der Vertrag im Übrigen wirksam. Die Parteien ersetzen die unwirksame Bestimmung durch eine wirksame, die ihrem Zweck am nächsten kommt.
- Bei Widersprüchen zwischen diesem Vertrag und dem Nutzungsvertrag gehen die Regelungen dieses Vertrags vor, soweit sie die Verarbeitung personenbezogener Daten betreffen.
- Anwendbares Recht und Gerichtsstand: [ANWENDBARES RECHT UND GERICHTSSTAND – noch festzulegen]. Zwingende Vorschriften des Datenschutzrechts bleiben unberührt.
- Vertragsparteien, Ansprechpersonen und Unterschriften: Der Vertrag wird elektronisch mit dem Konto abgeschlossen (SPEC §17.1.4). Der Abschluss wird mit Zeitpunkt und Person protokolliert.
Anlage 1 Gegenstand, Dauer, Art, Zweck, Betroffene, Datenkategorien
1.1 Gegenstand und Zweck je Produkt
Quellen: SPEC §5 bis §8, ADR-016.
| Produkt | Gegenstand | Zweck | Dauer |
|---|---|---|---|
| kloq. time | Buchungen (Kommen, Gehen, Pause, Dienstgang), Zeitmodelle, Zeitkonto, Korrekturen, Abwesenheiten, Urlaubskonto, Dienstplan, Geräte und Ausweise, Geofence-Ergebnis | Zeiterfassung, Abwesenheits- und Dienstplanverwaltung, Einhaltung von Arbeitszeitvorgaben | Laufzeit des Nutzungsvertrags; Aufbewahrung nach Anlage 4 |
| kloq. people | Personen- und Akte-Stammdaten, Dienstverhältnisse, Rollen, Ein-, Wechsel- und Austrittsprozesse, Zugangsverwaltung in Zielsystemen über Connectors, Postfach-Prozess ausgeschiedener Mitarbeitender (ohne Mailinhalte) | Personen- und Zugangsverwaltung, Rechtevergabe nach Rollen | wie oben |
| kloq. pay | Lohn-Vorerfassung, Meldungen, Lohnarten, Spesen und Reisen, Essenszuschuss, Übergabe an das Lohnbüro | Vorbereitung der Lohnverrechnung. Keine Lohnberechnung, keine Behördenmeldung | wie oben |
| kloq. mobile | App für Mitarbeitende (Modus Zeit und Modus Geld), Stempeln, Abwesenheiten, Belege, Lohnzettel, Push-Benachrichtigungen | Zugang der Mitarbeitenden zu den genutzten Produkten | wie oben |
| Belegerkennung (optional) | Belegbild und fester Prompt, strukturierte Ausgabe | Vorausfüllen von Belegdaten; Standard aus; Entscheidungen trifft nie das Modell (ADR-009) | nur solange der Verantwortliche die Funktion aktiviert hat |
Art der Verarbeitung für alle Produkte: Erheben, Erfassen, Speichern, Ordnen, Verknüpfen, Berechnen, Auslesen, Abfragen, Übermitteln (an berechtigte Nutzer und, wo konfiguriert, an Zielsysteme und Lohnbüro), Einschränken, Löschen.
1.2 Kategorien betroffener Personen
- Beschäftigte des Verantwortlichen (Mitarbeitende, auch in Teilzeit, mit mehreren Dienstverhältnissen oder in mehreren Ländern).
- Ausgeschiedene Beschäftigte (eingeschränkter Zugang für Auskunft, Lohnzettel und Widerruf von Einwilligungen, SPEC §2.2.11).
- Nutzerinnen und Nutzer mit Verwaltungsrollen: Administratoren, Personal (HR), IT-Administratoren, Teamleitungen, Datenschutz- und Betriebsratsrollen.
- Mitarbeitende des Lohnbüros (Nutzerkonten des Verantwortlichen; sie sehen pro Sitzung genau einen Mandanten).
- Bewerber:innen: nicht umfasst (siehe Offene Punkte Nr. 14).
1.3 Kategorien personenbezogener Daten
| Kategorie | Inhalte | Hinweise |
|---|---|---|
| Stammdaten | Name, Personalnummer, Kontaktdaten, Dienstverhältnis, Standort, Team, Rolle, Notfallkontakt, Konto- und Anmeldedaten (E-Mail, Passkeys, Sitzungen) | Privatnummer und private Adresse für die Einladung nur bis zur Aktivierung (Aufbewahrungsklasse invite_contact) |
| Eingeschränkte Stammdaten | Geburtsdatum, Schutzzeiträume | Nur Personal und die Person selbst. Planung und Clients sehen nur neutrale Einsatzbeschränkungen bzw. ein Altersband, nie Grund oder Datum. Jede Einsicht wird protokolliert |
| Zeitbuchungen | Art der Buchung, drei Zeitstempel (occurred_at, device_reported_at, received_at), Quelle, Korrekturen mit Begründung | Append-only; Begründungen sind mit dem Personenschlüssel verschlüsselt |
| Geräte- und Ausweisdaten | Verknüpfung Person zu Ausweis, Gerät, Lesungen | Rohe Ausweis-UIDs werden nie gespeichert, nur HMAC-SHA256(secret, normalisierte Kennung). Rohe Lesungen werden nach 30 Tagen entfernt |
| Standort | Nur das Ergebnis (innerhalb/außerhalb, Genauigkeit) im Moment der Buchung | Koordinaten werden standardmäßig nicht gespeichert; falls der Verantwortliche es konfiguriert, kurzlebig als location_raw. Kein Dauer-GPS |
| Abwesenheiten | Urlaub, Krankenstand (nur Zeitraum und Art), Pflegefreistellung, Sonderurlaub u. a. | Keine Diagnose |
| Dienstplan | Schichten, Tausch, Wunschfrei, Einsatzbeschränkungen (neutral) | Mitbestimmungsrelevant, Verantwortung beim Verantwortlichen |
| Spesen und Belege | Belegbild, extrahierte Felder (Betrag, Händler, Datum, Steuersatz), Reisen (Kilometer, Taggeld), Essenszuschuss | Belege unveränderbar mit Prüfsumme; mit aktivierter Belegerkennung geht das Belegbild an Anthropic |
| Lohn-Vorerfassung | Monatssummen, Zulagen, Lohnarten, Meldungen, Übergabepaket | Verschlüsselte sensible Felder: IBAN, Sozialversicherungsnummer, Steuer-ID, Gehalt (Status in Anlage 2) |
| Protokolldaten | Audit-Log (wer, was, wann, mit Pseudonymen), Anwendungslogs nur mit IDs | Beschäftigtendaten im Audit-Payload sind mit dem Personenschlüssel verschlüsselt |
| Push-Daten | Gerätetoken für Push-Benachrichtigungen | Nachrichten sind inhaltsfrei; Inhalt holt die App direkt vom Server |
| Einwilligungen | Nachweise zu optionalen Funktionen (z. B. Push-Erinnerung, Standort-Komfort, Profilfoto) | Aufbewahrungsklasse consents |
1.4 Besondere Kategorien (Art. 9 DSGVO)
- Gesundheitsdaten: bei Krankenstand nur Zeitraum und Art (Art-Katalog minimal), keine Diagnose (SPEC §5.4.8, §17). Das Foto einer Bestätigung ist optional und standardmäßig aus (in DE entfällt die Vorlagepflicht bei gesetzlich Versicherten durch die eAU;
docs/legal/datenschutz-mitbestimmung.md§3.4). Wenn der Verantwortliche Anhänge aktiviert, sind sie mit eigener Aufbewahrungsklasse (health_attachments) gespeichert und nie Teil der Belegerkennung. - Schutzzeiträume (Mutterschutz, Stillzeit, Behinderung) sind Gesundheitsdaten und abgeschottet gespeichert: nur Art, von, bis, ohne Diagnose; sichtbar nur für Personal und die Person selbst (SPEC §6.1.6).
- Biometrie: Der Auftragsverarbeiter speichert und verarbeitet keine biometrischen Daten. Falls der Verantwortliche ein Terminal mit Biometrie betreibt, bleibt das Template im Terminal; kloq erhält nur die Benutzer-ID aus dem Terminal. Der Verantwortliche bleibt dennoch Verantwortlicher nach Art. 9 DSGVO (
docs/legal/datenschutz-mitbestimmung.md§1 Nr. 5, §3.3).
Anlage 2 Technisch-organisatorische Maßnahmen (TOM)
Stand: 2026-10-10, abgeleitet aus Code, Migrationen und Spezifikation des Repositories. Die Spalte „Status“ hat drei Werte:
- umgesetzt: im Code oder in den Migrationen nachweisbar (Fundstelle angegeben). Der Betrieb ist damit nicht bestätigt, nur die Software-Fähigkeit.
- teilweise: Bausteine sind vorhanden, die vollständige Maßnahme ist es noch nicht.
- geplant: laut SPEC vorgesehen, im Code oder Betrieb nicht nachweisbar. Dies ist ein Ziel, keine Zusage des Ist-Zustands.
Mehrere Betriebsmaßnahmen (Hosting, Backups, Zugangsverwaltung beim Anbieter) lassen sich aus dem Repository nicht nachweisen. Sie sind deshalb nicht als „umgesetzt“ gekennzeichnet.
2.1 Zutrittskontrolle und Hosting
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Hosting in Rechenzentren in Deutschland bei Hetzner Online GmbH | Physische Zutrittskontrolle liegt beim Rechenzentrumsbetreiber (Unterauftragsverarbeiter). Hosting-Region EU laut ADR-004 | teilweise | SPEC §21.1 (ADR-004: „EU (Frankfurt/Wien), AV-Vertrag“); keine Betriebsnachweise im Repository; AVV-Referenz Hetzner offen |
| Zutritt Büro/Entwicklung | Kein Verarbeitungsort für Kundendaten außerhalb des Hostings vorgesehen | geplant | Zu dokumentieren |
2.2 Zugangskontrolle (Authentifizierung)
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Keine eigenen Passwörter wo SSO oder Passkey möglich | Anmeldung per SSO (OIDC), Passkey oder E-Mail-Link; Self-Host-Fallback ausgenommen | umgesetzt | packages/db/src/auth/ (oidc.ts, session.ts, Tabelle auth_passkey in 0005_auth.sql); SPEC §2.2 |
| MFA-Pflicht für privilegierte Rollen | Pflicht für Admin, Personal, IT-Admin, Lohnbüro, Datenschutz, Betriebsrat; zweiter Faktor wird pro Sitzung vermerkt (Passkey mit Nutzerprüfung, TOTP, gebundenes Gerät) | umgesetzt | packages/core/src/auth/policy.ts (MFA_REQUIRED_ROLES); 202610111100_auth_session_mfa.sql; packages/db/src/auth/mfa.ts |
| Sitzungen und Geräte widerrufbar | Sitzungen in eigener Tabelle, widerrufbar; Gerätebindung der App mit Refresh-Tokens im Secure Storage | teilweise | auth_session in 0005_auth.sql; Widerruf App-Geräte laut SPEC §15.3 |
| Rate-Limits und Brute-Force-Schutz | Zählung in der Datenbank (auth_rate_limits); PIN-Sperre am Kiosk nach 3 Fehlversuchen laut SPEC | teilweise | packages/db/src/auth/rate-limiter.ts; Kiosk-PIN-Sperre: SPEC §4.2.9 |
| Einmalige, befristete Einladungs- und Setup-Links | Links sind einmalig und befristet | umgesetzt | packages/db/src/invitations.ts, email-codes.ts; CLAUDE.md „Auth“ |
| Notfallzugang | Zwei Admins mit Passkey müssen existieren, bevor „SSO erzwingen“ aktiv werden darf | geplant | CLAUDE.md „Auth“ (Regel; Durchsetzung nicht geprüft) |
2.3 Zugriffskontrolle (Berechtigungen)
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Rollen- und Berechtigungskonzept | Rollen sind Bündel von Berechtigungen; Teamleitungen gelten nur für zugewiesene Teams | umgesetzt | SPEC §2; 202610091405_people_roles.sql |
| Row-Level-Security je Mandant | Jede Fachtabelle hat tenant_id und RLS. Die Laufzeitrolle kloq_app hat kein BYPASSRLS, besitzt keine Tabelle und darf kein DDL. Die Mandantenvariable wird je Transaktion gesetzt, Abfragen ohne Kontext schlagen fehl | umgesetzt | 0000_roles.sql, 0001_helpers.sql; ADR-001 |
| Automatischer Isolationstest | Katalog aller Tabellen mit tenant_id, Test pro Tabelle | umgesetzt | packages/db/test/db/isolation.test.ts |
| Service-Rolle nur serverseitig, protokolliert | Tenantübergreifende Jobs laufen mit kloq_service (ohne BYPASSRLS). Jede Nutzung wird mit Job und Grund in service_access_log vor der Arbeit protokolliert | umgesetzt | 0000_roles.sql; 0007a_service_log_outbox_order.sql; packages/db/src/context.ts (withService) |
| Eingeschränkte Felder | Geburtsdatum und Schutzzeiträume per zusätzlicher restriktiver RLS-Policy nur für Personal und die Person; Planung nur über abgeleitete Werte (Altersband, Einsatzbeschränkungen) | umgesetzt | 202610091020_kern_restricted.sql; packages/db/src/kern/restricted.ts |
| Lohnbüro: ein Mandant pro Sitzung | Lohnbüro-Konten sehen pro Sitzung genau einen Mandanten; Rechte als Schalter | teilweise | CLAUDE.md „Auth“; 202610111030_pay_office.sql; Vollständigkeit nicht geprüft |
| Vier-Augen-Prinzip | Entscheidungen (z. B. Abwesenheitsanträge) nicht durch dieselbe Person; für Löschläufe, Postfach-Stufe B und Admin-Rechte in Zielsystemen vorgesehen | teilweise | 202610091400_time_absences.sql (Trigger KLQ20), 202610091426_people_direct_approval_guard.sql; Löschläufe: SPEC §4.2.5 |
2.4 Verschlüsselung
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Transportverschlüsselung | HTTPS (TLS) für Web, App und API; Let's-Encrypt bzw. Anbieter-Zertifikate | geplant | SPEC §15.4; Konfiguration im Betrieb nicht nachweisbar |
| Envelope Encryption | Master-Schlüssel (Umgebung, in Produktion Pflicht, öffentlicher Dev-Schlüssel verboten) leitet per HKDF einen Mandanten-Schlüssel (KEK) ab. Darunter liegt ein Datenschlüssel (DEK) je Person. Verschlüsselung AES-256-GCM mit zusätzlich authentifizierten Daten | umgesetzt | packages/db/src/crypto.ts; packages/db/src/keys.ts; Tabelle data_subject_keys in 0003_audit_events.sql |
| KMS-Anbindung für den Master-Schlüssel | Aktuell lokaler Provider aus Umgebungsvariable; KMS ist als Austausch vorgesehen | geplant | packages/db/src/crypto.ts (Kommentar „Produktiv später durch KMS-Anbieter ersetzbar“) |
| Verschlüsselte Nutzlast in Append-only-Tabellen | Begründungen, Entscheidungen, Hinweise, Belegextraktion u. a. werden mit dem Personenschlüssel verschlüsselt gespeichert | umgesetzt | packages/db/src/pay/secure.ts (sealJson); audit_log.payload_enc in 0003_audit_events.sql |
| Feldverschlüsselung IBAN, SV-Nummer, Steuer-ID, Gehalt | Laut SPEC §4.2.3 für diese Felder vorgesehen. Die Verschlüsselungsbausteine existieren; als Speicherfelder sind IBAN, SV-Nummer, Steuer-ID und Gehalt im geprüften Schema nicht nachweisbar | geplant | SPEC §4.2.3 (Phase P5); CLAUDE.md „Sensible Felder“ |
| Verschlüsselung von Connector-Secrets und API-Schlüsseln | Tenant-eigener API-Schlüssel für die Belegerkennung wird verschlüsselt gespeichert, im Code als geheimer Wert geführt | teilweise | packages/db/src/pay/settings.ts (apiKeyEnc), pay/secure.ts (Secret); Connector-Secrets: packages/db/src/people/connectors.ts |
| Ruhende Daten auf Speicherebene | Verschlüsselung der Festplatten/Volumes beim Hosting-Anbieter | geplant | Betrieb; nicht nachweisbar |
2.5 Pseudonymisierung und Crypto-Shredding
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Pseudonyme in unveränderlichen Tabellen | Personenbezug nur über subject_ref und actor_ref (UUID). Die Zuordnung zur Person liegt in veränderbarer Tabelle | umgesetzt | ADR-018; 0003_audit_events.sql; CLAUDE.md „Harte Regeln“ |
| Personenschlüssel vernichtbar | Der Datenschlüssel einer Person kann vernichtet werden (destroyed_at), danach entstehen keine neuen Nutzdaten und bestehende sind unlesbar. Ein Trigger verhindert andere Änderungen an der Schlüsseltabelle. Bei Legal Hold wird nicht vernichtet | umgesetzt | packages/db/src/keys.ts; packages/db/src/audit.ts (shredSubject); data_subject_keys_guard in 0003_audit_events.sql; 202610091030_kern_retention.sql |
| Lösch-Job mit Vorschau, Protokoll, eigener DB-Rolle | Geplant als eigener Job nach ADR-018 mit eigener Rolle und Vier-Augen-Prinzip für Gesundheits- und Personalakten. Im geprüften Stand sind die Bausteine (shredSubject, Aufbewahrungsklassen, Partitions-Funktionen) vorhanden, ein planmäßiger Lösch-Job mit eigener Rolle nicht | teilweise | ADR-018; SPEC §17.1.3 (Phase P3); apps/worker/src/jobs.ts enthält keinen Lösch-Job |
| Partitionierte Rohdaten, Partitions-Drop | Rohe Gerätelesungen liegen in monatlichen Partitionen; Entfernen durch Funktion kloq_drop_device_reads_before | umgesetzt | 202610091210_time_devices.sql |
| Aufbewahrungsklassen als Regeldaten | Pro Land und Datenklasse mit Aktion (delete, pseudonymize, crypto_shred, restrict) und Legal Hold | umgesetzt | 202610091030_kern_retention.sql; packages/db/src/kern/retention.ts; packages/rules |
2.6 Integrität
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Append-only per Datenbank-Trigger | Kein UPDATE, DELETE oder TRUNCATE auf time_events, audit_log, provisioning_log, pay_submissions, shift_changes, leave_ledger, domain_events u. a.; Trigger gelten für jede Rolle und feuern auch bei session_replication_role = replica; zusätzlich Rechteentzug | umgesetzt | 0001_helpers.sql (forbid_update_delete, kloq_make_append_only); 0003_audit_events.sql; 202610091220_time_events.sql |
| Verkettetes Audit-Log | Jeder Eintrag enthält den Hash des Vorgängers (prev_hash); Prüfung der Kette im Trigger und in der Anwendung, Schreiben serialisiert per Advisory Lock | umgesetzt | audit_log_chain_guard in 0003_audit_events.sql; packages/db/src/audit.ts |
| Tägliche Integritätsprüfung, Alarm bei Bruch | Job audit.verify täglich 03:17 UTC prüft die Kette je Mandant, speichert das Ergebnis append-only und stellt bei Bruch ein Alarmereignis ein, das Admins per E-Mail zugestellt wird | umgesetzt | packages/db/src/audit-verify.ts, audit-alarm.ts; apps/worker/src/jobs.ts; audit_chain_checks in 0007a_service_log_outbox_order.sql |
| Idempotenz | Schreibende Anfragen von Geräten, Mobile und Connectors tragen einen idempotency_key | teilweise | SPEC §4.1.2; im Detail nicht einzeln geprüft |
| Abhängigkeits-Scan, Secret-Scan, SBOM | In der CI: Secret-Scan (gitleaks), Dependency-Audit, SBOM; monatliche Prüfung der Ausnahmen | umgesetzt | .github/workflows/ci.yml; docs/security/audit-exceptions.md |
| Signierte Releases und Container-Images | Laut SPEC §4.2.7 vorgesehen; im geprüften CI-Stand keine Signierung nachweisbar | geplant | SPEC §4.2.7 |
2.7 Verfügbarkeit und Wiederherstellbarkeit
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Backups mit Point-in-Time-Recovery | Ziel laut SPEC §4.1.5. Im Repository und Betrieb nicht nachweisbar | geplant | SPEC §4.1.5 (Phase P3) |
| Monatlicher automatisierter Restore-Test | Restore in Staging mit Prüfsummenvergleich. Ziel, nicht umgesetzt | geplant | SPEC §4.1.5 |
| Löschprotokoll nach Wiederherstellung erneut anwenden | erasure_ledger wird nach Restore erneut angewandt | geplant | SPEC §4.1.9, §17.3 |
| Offline zuerst, Wiederholbarkeit | Kiosk, App und Gateway speichern lokal und synchronisieren; Provisionierung ist wiederholbar | teilweise | SPEC §4.1.1, §4.1.6; Mobile: apps/mobile |
| Neuberechenbarkeit | Abgeleitetes ist aus Rohdaten neu berechenbar | umgesetzt (Architekturprinzip) | SPEC §4.1.4, §11.5 |
| Transaktionale Outbox | Ereignisse werden in derselben Transaktion eingestellt, strikt append-only | umgesetzt | 0003_audit_events.sql; packages/db/src/outbox.ts |
2.8 Trennungskontrolle
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Mandantentrennung | Logische Trennung durch RLS, getrennte Rollen für App, Service, Auth und Jobs; Schlüssel je Mandant | umgesetzt | 0000_roles.sql, 0004_auth_role.sql, 0007_jobs_role.sql; ADR-001 |
| Produkttrennung | Produkte importieren keinen Code voneinander; Fremdschlüssel nur auf Kern-Tabellen | umgesetzt (Architekturregel) | ADR-016; CLAUDE.md |
| Trennung Test/Produktion | Separate Umgebungen; Staging für Restore-Tests | geplant | Betrieb |
2.9 Eingabe- und Auftragskontrolle
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Audit-Log aller schreibenden Admin-Aktionen | Auch Anmeldungen, Exporte, Einsichten in sensible Felder (Geburtsdatum, Schutzzeiträume, Gesundheitsanhänge), Zugriffe des Lohnbüros und Bestätigungen des Mitbestimmungs-Gates; Akteur nur als actor_ref | teilweise | SPEC §17; packages/db/src/audit.ts, kern/restricted.ts; Vollständigkeit je Aktion nicht geprüft |
| Nachvollziehbarkeit für Beschäftigte | Beschäftigte sehen eigene Rohbuchungen und Korrekturen; Zugriffsprotokoll (Datum, Zweck) | teilweise | SPEC §17.1.5 (SOLL, Phase P3); packages/db/src/audit-view.ts |
| Weisungen | Weisungen ergeben sich aus der Konfiguration im Produkt und schriftlichen Weisungen (Anlage 4) | umgesetzt (Prozess) | Anlage 4 |
| Zustimmungsvorbehalt KI-Belegerkennung | Aktivierung nur mit bestätigtem AVV und gewähltem Anbieter, sonst Fehler avv_required | umgesetzt | packages/db/src/pay/settings.ts |
| Keine Verarbeitung durch Unterauftragnehmer ohne Genehmigung | Siehe §4 und Anlage 3 | umgesetzt (Prozess) | Anlage 3 |
2.10 Weitere Maßnahmen
| Maßnahme | Beschreibung | Status | Fundstelle |
|---|---|---|---|
| Keine personenbezogenen Daten in Anwendungslogs | Nur IDs; Logging-Hilfe gibt nur freigegebene Felder aus (keine E-Mail, Name, IBAN, Token) | umgesetzt | packages/core/src/logging.ts; packages/core/test/logging.test.ts; SPEC §4.2.6 |
| Rohe Ausweis-UIDs nie gespeichert | Nur HMAC-SHA256 der normalisierten Kennung (lookup_hash) | umgesetzt | 202610091210_time_devices.sql (Tabelle credentials); packages/db/src/crypto.ts (hmacHex) |
| Datensparsame Standorterfassung | Standard speichert nur das Ergebnis; keine Hintergrund-Ortung | teilweise | SPEC §5.1.9, §5.1.10, §8; Prüfung im App-Manifest laut docs/legal/datenschutz-mitbestimmung.md §3.2: Nachweis offen |
| Sicheres Parsen von Belegen | PDF-Parsing im Worker-Thread mit Heap- und Zeitlimit | umgesetzt | ADR-009 (Ergänzungen); apps/worker/src/pdf-extract-worker.ts |
| Datenpannen-Prozess | Erfassung, Bewertung, Meldekette an den Verantwortlichen; Workflow als Produktfunktion | geplant | SPEC §17.1.2 (Phase P3); Anlage 4 Abschnitt 4.3 |
| Verzeichnis der Unterauftragsverarbeiter | Öffentliche Liste mit Änderungsmitteilung | geplant | SPEC §17.1.4 (Phase P1); Anlage 3 |
| Penetrationstest | Extern vor dem ersten zahlenden Kunden, danach jährlich. Nicht durchgeführt | geplant | SPEC §4.2.8 (Phase P3) |
| Schulung und Verpflichtung der Mitarbeitenden | Verpflichtung zur Vertraulichkeit | geplant | Organisatorisch; nicht aus Code ableitbar |
| Support-Zugriff | Nur mit protokollierter, befristeter Freigabe des Mandanten und aus EU/CH | geplant | SPEC §2 (Plattform-Admin), §17 |
Anlage 3 Unterauftragsverarbeiter
Stand: 2026-10-10. Die Genehmigung nach §4 gilt für die folgenden Einträge. Änderungen werden 30 Tage (Vorschlag) vor Wirksamwerden in Textform mitgeteilt; der Verantwortliche kann aus wichtigem datenschutzrechtlichem Grund widersprechen (§4 Abs. 2 und 3).
| Name | Sitz | Zweck | Datenkategorien | Transfermechanismus | Status |
|---|---|---|---|---|---|
| Hetzner Online GmbH | Deutschland | Hosting der Anwendung, der Datenbank und des Speichers | Alle Datenkategorien nach Anlage 1 (verschlüsselte Nutzlast und sensible Felder nur als Chiffrat; Schlüssel bleiben bei [FIRMA]) | keiner nötig (Verarbeitung in Deutschland/EU) | Zu bestätigen. AVV-Referenz offen (Offene Punkte Nr. 7) |
| [PLATZHALTER – SMTP-Anbieter, noch nicht entschieden] | [SITZ] | Versand von Einladungs-, Anmelde-, Benachrichtigungs- und Alarm-E-Mails | E-Mail-Adresse, Name, Inhalt der Benachrichtigung (keine Zeitbuchungen oder Gesundheitsdaten) | [TRANSFERMECHANISMUS] | Offen (Offene Punkte Nr. 6) |
| Anthropic PBC | USA | Nur wenn der Verantwortliche die KI-Belegerkennung aktiviert hat (Standard: aus, ADR-009). Extraktion strukturierter Daten aus Belegbildern | Belegbild und fester Prompt. Keine Namen, Personalnummern oder Mandantendaten. Krankmeldungen nie. Das Belegbild kann zufällig enthaltene personenbezogene Daten zeigen (z. B. Name auf der Quittung, Kartenstummel) | Offene Rechtsfrage: EU-US Data Privacy Framework und/oder Standardvertragsklauseln (Art. 46 DSGVO) samt Transfer-Risikoprüfung; Verarbeitungsort laut ADR-009 nur us oder global, keine EU-Region; Rechtsmittel C-703/25 P gegen das Urteil T-553/23 anhängig, Stand offen | Offen. Nicht nutzbar ohne bestätigten AVV (Offene Punkte Nr. 1 und 2) |
| Apple Inc. (APNs) | USA | Zustellung inhaltsfreier Push-Benachrichtigungen an iOS-Geräte | Gerätetoken, Zeitpunkt; keine Inhalte (die App holt den Inhalt direkt vom Server) | Offen (Rolle, Transfergrundlage, DPF-Listing nicht geprüft) | Rechtsstatus offen (docs/legal/datenschutz-mitbestimmung.md §3.10, §5 Nr. 11) |
| Google LLC (FCM) | USA | Zustellung inhaltsfreier Push-Benachrichtigungen an Android-Geräte | wie oben | Offen (wie oben) | Rechtsstatus offen (wie oben) |
Hinweise:
- Der Verantwortliche kann Push-Benachrichtigungen abschalten (Abruf beim Öffnen der App). Für Apple und Google ist zu klären, ob sie Auftragsverarbeiter oder eigene Verantwortliche sind; der Eintrag ist bis dahin vorsorglich.
- Die in §4 Abs. 6 genannten Dienstleister des Verantwortlichen (SSO-Anbieter, Zielsysteme, Lohnbüro) sind keine Unterauftragsverarbeiter des Auftragsverarbeiters.
- Weitere Unterauftragsverarbeiter (z. B. Fehlerberichte, Monitoring, Support-Werkzeuge) sind derzeit nicht vorgesehen. Telemetrie ist standardmäßig personenfrei (SPEC §4.2.6).
Anlage 4 Weisungen, Kontakte, Löschfristen
4.1 Weisungen
- Dokumentierte Weisungen. Als dokumentierte Weisung gelten erstens die Konfiguration durch den Verantwortlichen im Produkt (Einstellungen, Rechte, Aufbewahrungsklassen, Aktivierung optionaler Funktionen wie Standort und Belegerkennung, Exporte, Löschungen und Legal Holds) und zweitens schriftliche Weisungen in Textform an [DATENSCHUTZKONTAKT].
- Mündliche Weisungen sind unverzüglich in Textform zu bestätigen.
- Weisungen, die über die Standardfunktionen hinausgehen, können angemessene Zusatzkosten auslösen (Offene Punkte Nr. 10).
4.2 Weisungsberechtigte und Weisungsempfänger
| Seite | Weisungsberechtigte / Weisungsempfänger | Hinweis |
|---|---|---|
| Verantwortlicher (weisungsberechtigt) | [NAME UND KONTAKT, vom Verantwortlichen im Konto zu hinterlegen] und Nutzer mit Rolle Admin | Konfiguration im Produkt gilt als Weisung der handelnden Person, die zur Vertretung des Verantwortlichen befugt sein muss |
| Auftragsverarbeiter (Weisungsempfänger) | [DATENSCHUTZKONTAKT] | Bei Wechsel der Ansprechperson wird der Verantwortliche informiert |
4.3 Kontakt für Datenpannen
| Richtung | Kontakt |
|---|---|
| Meldung des Auftragsverarbeiters an den Verantwortlichen | Die im Konto hinterlegte Ansprechperson für Datenschutz des Verantwortlichen, ersatzweise Admin-Nutzer |
| Meldung des Verantwortlichen an den Auftragsverarbeiter (Verdacht auf Verletzung) | [DATENSCHUTZKONTAKT], ersatzweise [KONTAKT] |
Die Meldung erfolgt unverzüglich in Textform (§5 Abs. 4). Für CH-Verantwortliche gilt „so rasch als möglich“ (§9 Abs. 3).
4.4 Löschfristen (Aufbewahrungsklassen)
Ausgangswerte, zu bestätigen. Die Werte sind Regeldaten (packages/rules, mit Rechtsgrund-Referenz und valid_from), pro Verantwortlichem innerhalb von Plausibilitätsgrenzen anpassbar. Der frühere Standard von 7 Jahren für alle lohnrelevanten Daten ist gestrichen. Bei Personen mit mehreren Ländern gilt je Datenklasse die längste einschlägige Frist. Fristbeginn ist je Klasse zu definieren. Quelle: SPEC §17.2, docs/legal/datenschutz-mitbestimmung.md §3.7, §5 Nr. 8 und 9.
| Datenklasse | AT | DE | CH | Fundstelle |
|---|---|---|---|---|
time_records (Zeitbuchungen, Korrekturen) | 36 Monate | 36 Monate | 60 Monate | Art. 73 ArGV 1 (CH); AT/DE Praxis UNVERIFIZIERT |
payroll_records (Lohnkonto, Lohnunterlagen) | 84 Monate | 72 Monate Lohnkonto, 96 Monate Buchungsbelege | 120 Monate ab Ende Geschäftsjahr | § 132 BAO; § 41 EStG, § 147 AO; Art. 958f OR |
receipts (Belege Essen/Spesen) | 84 Monate | 96 Monate (Zuordnung offen) | 120 Monate ab Ende Geschäftsjahr | § 132 BAO; § 147 AO; Art. 958f OR |
applicants | 7 Monate | 6 Monate | 3 Monate (UNVERIFIZIERT) | GlBG § 15, § 29; AGG § 15 Abs. 4. Derzeit nicht Vertragsgegenstand |
health_attachments | bis Abrechnung + 6 Monate | bis Abrechnung + 6 Monate | bis Abrechnung + 6 Monate | Produktentscheidung, Art. 9 DSGVO |
location_raw | 0 bis 30 Tage | 0 bis 30 Tage | 0 bis 30 Tage | Produktentscheidung; Standard speichert nur das Ergebnis |
device_reads | 30 Tage | 30 Tage | 30 Tage | Produktentscheidung |
audit_personal (Einsichten) | 12 Monate | 12 Monate | 12 Monate | Produktentscheidung |
consents (Nachweise) | Widerruf + 36 Monate | Widerruf + 36 Monate | Widerruf + 36 Monate | Art. 7 Abs. 1 DSGVO |
invite_contact (private Nummer) | bis Aktivierung | bis Aktivierung | bis Aktivierung | Zweckbindung SPEC §2.2 |
mailbox (gesperrt nach Austritt) | 90 Tage ohne Zugriff; Archiv nach Dokumenttyp (7 Jahre) | 90 Tage; Archiv nach Dokumenttyp (6 Jahre) | 90 Tage; Archiv (10 Jahre) | SPEC §6.4; § 132 BAO, § 257 HGB, Art. 958f OR |
Die Fristen der Zeitbuchungen für AT und DE sind nicht aus einer gesetzlichen Frist abgeleitet (AZG § 26 enthält keine; ArbZG § 16 Abs. 2 und MiLoG § 17 Abs. 2 gelten nur für eine Teilmenge) und beruhen auf Verjährung und Verfall. Das Ergebnis der Standorterfassung folgt der Frist für time_records.