Auftragsverarbeitungsvertrag (AVV)

1. Vertraulichkeit — Zugangskontrolle zu Systemen

1. Zugang nur über TLS/HTTPS; HTTP wird umgeleitet, HSTS ist aktiv.
2. Anmeldung mit Benutzername und Passwort; Passwörter ausschließlich als bcrypt-Hash. Brute-Force-Schutz: nach fünf Fehlversuchen je IP und Benutzername 15 Minuten Sperre.
3. Sitzungen über HMAC-signierte Cookies, die an den Betrieb gebunden sind; ein Cookie eines Betriebs ist in einem anderen nicht verwendbar. Jeder Betrieb hat eine eigene Adresse, sodass auch der Browser die Sitzungen trennt.
4. Zwei-Faktor-Authentisierung (zeitbasierte Einmalkennwörter, vertraute Geräte) steht zur Verfügung und ist je Person aktivierbar; sie wird nicht erzwungen.
5. Terminal (Stempeluhr): persönlicher Zahlencode je Person (vier bis sechs Ziffern, je Betrieb festgelegt), gespeichert ausschließlich als HMAC mit betriebsgebundenem Schlüssel und verschlüsselt — kein Klartext. Das Terminal wird über ein Kopplungsverfahren an den Betrieb gebunden; Codes von Personen, deren Beschäftigung geendet hat, werden am Terminal abgewiesen.
6. Automatische Sperre innerhalb der Anwendung nach Inaktivität (Web: persönlicher Code; iOS-App: Sichtschutz sofort, Face ID/Gerätecode nach kurzer Karenz).

2. Vertraulichkeit — Zugriffskontrolle und Mandantentrennung

1. Jede Datenbankabfrage der Anwendung ist auf den Betrieb des angemeldeten Nutzers (`tenant_id`) eingeschränkt.
2. Row Level Security ist auf allen Tabellen aktiviert. Sie greift für den Zugang der Anwendung selbst nicht, weil diese mit einer Dienstrolle arbeitet; die Trennung beruht auf der Filterung in der Anwendung. Diese wird durch einen statischen Wächter-Test abgesichert, der bei jedem Build jede Abfrage auf mandantengebundene Tabellen auf ihren Betriebsfilter prüft, und durch dokumentierte Live-Proben gegen fremde Betriebe (zuletzt 18.09.2026).
3. Die Rechte der öffentlichen Datenbankrollen sind auf das Minimum reduziert (30.07.2026). Datenbankfunktionen mit erhöhten Rechten sind für den öffentlichen Schlüssel nicht aufrufbar; ein Wächter-Test verlangt zu jeder solchen Funktion den ausdrücklichen Rechteentzug (23.09.2026).
4. Rollen- und Berechtigungskonzept: Storeowner, Admin, Schichtleitung, Mitarbeiter, Praktikant; Sichtbarkeit nach Rolle und Standortzuordnung. Zugriff auf Personalunterlagen anderer erfordert zusätzlich ein eigenes Aktenrecht.
5. Module werden je Betrieb einzeln freigeschaltet; nicht freigeschaltete Funktionen erheben keine Daten.
6. Zugriffe des Auftragnehmers auf einen Betrieb („als Betrieb ansehen") erfolgen nach dem Prinzip der geringsten Rechte und werden mit Identität der zugreifenden Person protokolliert; aus einer solchen Sitzung heraus sind Löschungen ausgeschlossen.

3. Vertraulichkeit — Verschlüsselung

1. In der Übertragung: TLS zwischen Endgerät, Anwendung, Datenbank, Speicher und externen Schnittstellen.
2. Gespeicherte Daten: Verschlüsselung auf Speicherebene durch den Anbieter.
3. Zusätzlich anwendungsseitig symmetrisch verschlüsselt (AES): Bankverbindung, Steuer-Identifikationsnummer, Sozialversicherungsnummer, Terminal-Codes, Zugangsdaten optionaler Integrationen. Der Schlüssel liegt nur in der Laufzeitumgebung, nicht in der Datenbank.
4. Pseudonyme im Löschkonzept werden per HMAC mit Serverschlüssel gebildet, nicht durch einfache Hashwerte (Anlage 4).

4. Integrität und Nachweisbarkeit

1. Lückenlose Änderungshistorie bei Zeitbuchungen: Zeitpunkt, ausführende Person, vorheriger und neuer Wert.
2. Aktivitätsprotokoll für sicherheits- und abrechnungsrelevante Vorgänge; Protokolltabellen sind auf Datenbankebene gegen Änderung und Löschung gesperrt (Trigger). Einzige Ausnahme: das Ersetzen eines Namens durch ein Pseudonym im Löschvorgang, selbst protokolliert.
3. Zugriffsprotokoll auf Personalunterlagen und Lohnabrechnungen: jeder Abruf — über Akte, Onboarding, Papierfassung, Steuerberater-Zugang oder Schulungsnachweis — hinterlässt eine Zeile mit Person, Zeitpunkt, Unterlage und Weg (Art. 28 Abs. 3 lit. h). Fassungen von Aktenunterlagen sind unveränderlich.
4. Datenbankseitige Konsistenzsicherung gegen Doppelbuchungen und überlappende Zeiteinträge.
5. Bestätigung des Stundennachweises durch die beschäftigte Person vor dem Monatsabschluss; Nachrichten dazu gehen über drei Wege (E-Mail, App, Startseite).
6. Änderungen aus der KI-assistierten Auswertung werden erst nach Bestätigung durch den Auftraggeber wirksam (Ziffer 6.2).
7. Stempel-Fotos (je Betrieb zuschaltbar, standardmäßig aus): Prüfung von Typ und Dateisignatur, Größenbegrenzung, nicht öffentlicher Speicher, Auslieferung nur über zeitlich befristete signierte Verweise, automatische Löschung nach sieben Tagen unabhängig vom Monatsabschluss.

5. Verfügbarkeit

1. Betrieb auf Infrastruktur professioneller Anbieter in der EU (Anlage 3).
2. Tägliche vollständige Sicherung der Datenbank (02:30 Uhr) in einen nicht öffentlichen Speicherbereich; die Wiederherstellung wurde erprobt (zuletzt beim Umzug nach Frankfurt am 24.08.2026).
3. Offline-Fähigkeit der Zeiterfassung: Terminal und App puffern Stempelungen bei Verbindungsverlust lokal und führen sie bis zu sieben Tage nach.
4. Überwachung der Terminals über Lebenszeichen mit Benachrichtigung bei Ausfall.

6. Sicherungen — Ort und Dauer

1. Ort: Frankfurt am Main (EU), im Projekt der produktiven Datenbank, in einem nicht öffentlichen Speicherbereich.
2. Aufbewahrung: 30 Tage rollierend; ältere Sicherungen werden automatisch entfernt.
3. Verwendung ausschließlich zur Wiederherstellung im Fehlerfall. Nach einer Wiederherstellung werden die Datenbankrechte geprüft und zwischenzeitliche Löschungen nachgeholt (Checkliste des Auftragnehmers).

7. Datenminimierung — bewusste Grenzen der Erhebung

1. Standortprüfung beim Stempeln ohne Bewegungsprofil: Der Vergleich mit dem Betriebsstandort findet auf dem Endgerät statt; gespeichert wird nur das Ergebnis „innerhalb / außerhalb / unbestimmt" mit Hinweis. Koordinaten der beschäftigten Person verlassen das Gerät nicht. Die Prüfung blockiert nie eine Stempelung; bei Zweifel gilt „unbestimmt".
2. Chat-Nachrichten werden nach 730 Tagen, Chat-Bilder nach 365 Tagen automatisch gelöscht.
3. Freitextfelder mit Gesundheitsbezug (Krankmeldungsnotizen, Abwesenheitsgründe) werden mit dem Ausscheiden der Person sofort gelöscht (Anlage 4, Klasse A).
4. Sensible Funktionen (Standortprüfung, Stempelfoto) sind je Betrieb zuschaltbar und standardmäßig deaktiviert.

8. Löschung und Einschränkung der Verarbeitung

1. Löschklassen und Fristen nach Anlage 4; die Zuordnung der Datenbereiche wird aus derselben Quelle erzeugt, nach der die Software löscht.
2. Eingeschränkte Daten (Art. 18) verlassen die operativen Tabellen und liegen in einem getrennten Datenbankschema ohne Schnittstellenzugang; Zugriff nur für Prüfung und Rechtsverteidigung, jeder Zugriff protokolliert.
3. Fristen laufen ab dem Austritt, nicht erst ab einem Löschverlangen; ein nächtlicher Lauf führt fällige Löschungen aus (Datenbank und Dateien) und hinterlässt ein Lebenszeichen, dessen Ausbleiben dem Storeowner angezeigt wird.
4. Benutzernamen gelöschter Personen werden dauerhaft gesperrt und nicht erneut vergeben.
5. Löschungen erfordern die Rolle Storeowner und eine Bestätigung in zwei Schritten; aktiv Beschäftigte mit laufendem Vertrag können nicht gelöscht werden, bevor der Austritt eingetragen ist.

9. Organisation

1. Verpflichtung aller mit der Verarbeitung befassten Personen zur Vertraulichkeit (Ziffer 9).
2. Meldeprozess für Datenschutzverletzungen mit Frist von 48 Stunden (Ziffer 14).
3. Prüfung und Dokumentation der Unterauftragsverarbeiter (Ziffer 11.6, Anlage 3).
4. Dokumentierte interne Sicherheitsaudits (zuletzt 18.09.2026 vollständig, 22./23.09.2026 Löschkonzept) mit Nachverfolgung der Befunde.
5. Bekannte Schwachstellen in Softwarebestandteilen werden anlassbezogen geprüft und behoben (zuletzt 18.09.2026).

10. Grenzen der Maßnahmen — ausdrücklicher Hinweis

Der Auftragnehmer stellt klar, dass folgende Maßnahmen nicht bestehen; eine gegenteilige Annahme wäre unzutreffend:

1. keine Zertifizierung nach ISO/IEC 27001 und keine SOC-2-Prüfung;
2. keine Penetrationstests durch unabhängige Dritte — die Audits sind intern;
3. keine Pseudonymisierung im laufenden Betrieb; die Daten werden mit Personenbezug verarbeitet, weil der Zweck (Lohn, Arbeitszeitnachweis) ihn erfordert. Pseudonymisiert wird erst beim Ausscheiden (Anlage 4, Klasse C);
4. keine physischen Zugangskontrollen durch den Auftragnehmer — sie liegen bei den Anbietern in Anlage 3;
5. keine personell besetzte Überwachung rund um die Uhr, kein Security-Operations-Center;
6. keine vertraglich zugesagte Verfügbarkeit oder Reaktionszeit (kein SLA);
7. keine Ende-zu-Ende-Verschlüsselung, die den Anbieter ausschließt (Ziffer 12.4);
8. keine gesonderte revisionssichere Protokollierung direkter Datenbankzugriffe durch den Auftragnehmer außerhalb der Anwendung;
9. keine automatisierte, laufende Schwachstellenprüfung der Softwarebestandteile;
10. keine getrennte Entwicklungsdatenbank: Entwicklung und Betrieb nutzen eine Datenbank. Automatisierte Tests laufen ohne Datenbank; Proben erfolgen in ausdrücklich gekennzeichneten Testbetrieben mit Testdaten;
11. Zwei-Faktor-Authentisierung wird nicht erzwungen;
12. die automatische Sperre wirkt innerhalb der Anwendung, nicht auf Betriebssystemebene;
13. das Verzeichnis nach Art. 30 Abs. 2 liegt als Sammlung vor (Anlage 1, Anlage 4, Datenschutz-Folgenabschätzung), nicht als eigenständiges Dokument;
14. kein Consent-Management-Werkzeug auf der Website des Auftragnehmers (betrifft nur dessen eigene Verantwortlichkeit).