Vereinbarung zur Auftragsverarbeitung (AVV)

Hinweis zur Ausgangslage: Es existieren bisher keine unterschriebenen Tenant-AVVs. Dieses Dokument ist deshalb kein Nachtrag, sondern ein vollständiger AVV, der die gesamte 34a-Manager-Plattform und die Datenkategorien des Partner Hub abdeckt. Bestandskunden stimmen ihm durch eine vertretungsberechtigte Person aktiv per geschäftlicher E-Mail zu; ein späterer Dialog in der Anwendung ist optional. Eine stillschweigende Einbeziehung durch Weiternutzung ist nicht vorgesehen.

Diese Seite gibt die verbindliche Vertragsfassung wieder. Die konkrete Gegenpartei wird nicht auf dieser Seite eingetragen, sondern über den dokumentierten Zustimmungsnachweis zum jeweiligen Kunden identifiziert.

§ 1 Parteien

Auftragsverarbeiter („Anbieter“):

Verantwortlicher („Kunde“ / „Tenant“): das Sicherheitsunternehmen, das 34a-Manager als Mandant nutzt. Die Identifikation erfolgt über den dokumentierten Zustimmungsnachweis.

§ 2 Gegenstand, Dauer, Art und Zweck

1. Der Anbieter stellt dem Kunden die SaaS-Plattform „34a-Manager“ bereit (Personalverwaltung, Dienst- und Schichtplanung, Qualifikationsverwaltung, Abrechnung und Rechnungsstellung, Statistiken) sowie den „34a Manager Partner Hub“ für die Zusammenarbeit mit Nachunternehmern.
2. Der Kunde ist Verantwortlicher für alle personenbezogenen Daten, die er in seiner Mandanten-Instanz und im Hub-Kontext verarbeitet; der Anbieter verarbeitet sie ausschließlich im Auftrag.
3. Dauer: Laufzeit des Nutzungsvertrags. Datenkategorien, betroffene Personen und Fristen ergeben sich aus Anlage A.

§ 3 Weisungsgebundenheit

1. Der Anbieter verarbeitet die Daten nur auf dokumentierte Weisung des Kunden. Die Nutzung der Plattform-Funktionen durch den Kunden (z. B. Anlegen von Personal, Besetzen einer Schicht, Freigabe eines Korrekturvorschlags) gilt als dokumentierte Weisung.
2. Weisungen außerhalb des Funktionsumfangs bedürfen der Textform (z. B. E-Mail an den Support) und werden auditiert.
3. Hält der Anbieter eine Weisung für rechtswidrig, informiert er den Kunden unverzüglich und darf die Ausführung bis zur Klärung aussetzen (Art. 28 Abs. 3 UAbs. 2 DSGVO).

§ 4 Vertraulichkeit

Der Anbieter stellt sicher, dass sich alle zur Verarbeitung befugten Personen zur Vertraulichkeit verpflichtet haben oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO).

§ 5 Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

1. Der Anbieter trifft die in Anlage B beschriebenen technischen und organisatorischen Maßnahmen und entwickelt sie fort. Maßnahmen dürfen durch gleichwertige oder bessere ersetzt werden; wesentliche Änderungen werden dokumentiert.
2. Besonders schutzbedürftige Felder (Bewacher-ID, Geburtsdatum) unterliegen der strikten Zweckbindung aus Anlage A: kein generischer Suchpfad, keine Anzeige in Listen, auditierter Zugriff auf Detailansichten.

§ 6 Unterauftragsverarbeiter (Art. 28 Abs. 2, 4 DSGVO)

1. Der Kunde erteilt die allgemeine Genehmigung zur Einschaltung der in Anlage C genannten Unterauftragsverarbeiter.
2. Beabsichtigte Änderungen (Hinzufügen oder Ersetzen) teilt der Anbieter mindestens vier Wochen vorab in Textform mit (E-Mail an die Administratoren des Kunden und Hinweis in der Anwendung). Der Kunde kann aus wichtigem, datenschutzbezogenem Grund widersprechen; im Widerspruchsfall kann jede Partei die Plattform-Nutzung beenden, wenn keine zumutbare Alternative besteht.
3. Mit jedem Unterauftragsverarbeiter besteht ein Vertrag, der dieser Vereinbarung im Schutzniveau entspricht.

§ 7 Unterstützungspflichten

Der Anbieter unterstützt den Kunden im Rahmen des technisch Möglichen:

1. Betroffenenrechte (Art. 12–23 DSGVO): über die in Anlage A Abschnitt 5 beschriebenen Werkzeuge (Datenexport, Löschung und Anonymisierung, Sperrvermerk, Berichtigung). Anfragen betroffener Personen leitet der Anbieter unverzüglich an den Kunden weiter, ohne selbst inhaltlich zu antworten.
2. Sicherheit und Meldepflichten (Art. 32–36 DSGVO): Der Anbieter meldet dem Kunden Verletzungen des Schutzes personenbezogener Daten unverzüglich, spätestens innerhalb von 48 Stunden nach Kenntnis, mit den Angaben nach Art. 33 Abs. 3 DSGVO, soweit verfügbar.
3. Datenschutz-Folgenabschätzung (Art. 35, 36 DSGVO): mit den Informationen aus dem Verarbeitungsverzeichnis, der Beschreibung der technischen und organisatorischen Maßnahmen und der Schwellwertprüfung zur DSFA-Pflicht.

§ 8 Kontrollrechte (Art. 28 Abs. 3 lit. h DSGVO)

1. Der Anbieter stellt dem Kunden alle erforderlichen Informationen zum Nachweis der Einhaltung dieser Vereinbarung zur Verfügung; vorrangig durch aussagekräftige Dokumentation (Beschreibung der technischen und organisatorischen Maßnahmen, Audit-Konzept, Zertifikate der Unterauftragsverarbeiter).
2. Prüfungen vor Ort oder durch beauftragte Dritte sind nach angemessener Ankündigung (mindestens 14 Tage) während der Geschäftszeiten möglich; sie dürfen den Betrieb und die Rechte anderer Kunden (Mandantentrennung) nicht beeinträchtigen.

§ 9 Löschung und Rückgabe (Art. 28 Abs. 3 lit. g DSGVO)

1. Nach Ende der Plattform-Nutzung werden die Daten des Kunden nach dessen Wahl herausgegeben (Export) und anschließend nach den Fristen der Anlage A gelöscht oder anonymisiert.
2. Gesetzliche Aufbewahrungspflichten (z. B. § 147 AO für Abrechnungsbelege) bleiben unberührt; betroffene Daten werden für die operative Nutzung gesperrt (Art. 18 DSGVO) und nach Fristablauf gelöscht.
3. Die Löschung und Anonymisierung erfolgt automatisiert durch einen täglichen Retention-Lauf; der Nachweis des Laufs wird protokolliert.

§ 10 Ort der Verarbeitung, Drittlandübermittlung

1. Die Verarbeitung der Plattformdaten erfolgt in Rechenzentren innerhalb der Europäischen Union (Deutschland, siehe Anlage C).
2. Über die in Absatz 3 geregelte Push-Zustellung hinaus findet eine Übermittlung in Drittländer nicht statt. Sollte sie künftig erforderlich werden, erfolgt sie nur auf Grundlage der Kapitel-V-Instrumente der DSGVO und nach dem Verfahren aus § 6.
3. Firebase Cloud Messaging (FCM): FCM wird auf globaler Infrastruktur betrieben; eine Verarbeitung außerhalb der EU ist möglich. Google LLC ist die dokumentierte Vertragsgesellschaft. Die Firebase Data Processing and Security Terms in der Fassung vom 21.08.2024, das EU-US Data Privacy Framework und die einbezogenen EU-Standardvertragsklauseln werden als Transferinstrumente herangezogen. Der projektspezifische Vertrags- und Transfernachweis ist Bestandteil der Datenschutzdokumentation; Google und FCM sind in Anlage C aufgeführt. Bei iOS wird der Apple Push Notification Service (APNs) als eigenständiger Empfänger und Zustellinfrastruktur eingesetzt.

§ 11 Haftung, Laufzeit, Schlussbestimmungen

1. Die Haftung richtet sich nach Art. 82 DSGVO und den Allgemeinen Geschäftsbedingungen.
2. Diese Vereinbarung gilt für die Dauer der Plattform-Nutzung; die Pflichten aus § 9 bestehen darüber hinaus fort.
3. Änderungen dieser Vereinbarung erfordern eine neue Fassung mit neuer Fassungsnummer und erneuter dokumentierter Zustimmung. Rein redaktionelle Änderungen erfordern keine erneute Zustimmung.
4. Für diese Vereinbarung und alle sich aus oder im Zusammenhang mit ihr ergebenden vertraglichen Rechtsverhältnisse gilt das Recht der Republik Kroatien unter Ausschluss des UN-Kaufrechts. Zwingende Vorschriften des Unionsrechts, insbesondere der Datenschutz-Grundverordnung (EU) 2016/679, bleiben unberührt. Der Gerichtsstand richtet sich nach Ziffer 8.2 der AGB.

---

Anlage A – Gegenstand der Verarbeitung

1. Kategorien betroffener Personen

• Beschäftigte des Kunden (Sicherheitsmitarbeiter, Verwaltung, Disposition)
• Nutzer des Kunden in der Plattform
• Ansprechpartner von Auftraggebern und Objekten des Kunden
• Personal von Nachunternehmern des Kunden (im Hub-Kontext, als Empfänger von Snapshots – Verantwortlicher hierfür ist primär die Partner-Organisation)

2. Datenkategorien

a) Kernplattform (je Mandanten-Datenbank)

b) Partner-Hub (zentrale Hub-Datenbank)

Für die Hub-Kategorien gelten strikte Zweckbindungs- und Fristenregeln; insbesondere sind Bewacher-ID und Geburtsdatum keine Suchfelder, sie werden nicht in Listen angezeigt und der Detailzugriff wird auditiert.

3. Lösch- und Anonymisierungsfristen

Kernplattform:

• Daten werden für die Dauer der Vertragsbeziehung verarbeitet; nach Vertragsende Export auf Wunsch, anschließend Löschung der Mandanten-Datenbank binnen 90 Tagen. Gesetzliche Aufbewahrungspflichten (§ 147 AO: 8 Jahre für Buchungsbelege) bleiben unberührt.
• Push-Gerätedaten: Token während der aktiven Geräteregistrierung; sofortige Token-Löschung bei einer dem Backend gemeldeten Deaktivierung, bei ungültigem Token, Entzug des App-Zugangs oder Löschung des Benutzerkontos; automatische Deaktivierung nach 90 Tagen ohne App-Kontakt; Löschung tokenfreier Gerätedaten nach weiteren 30 Tagen. Nicht zugestellte FCM-Nachrichten erhalten eine maximale Lebensdauer von 24 Stunden.

Hub-Kategorien:

4. Übermittlung an Auftraggeber

Die Übermittlung von Besetzungsdaten (Assignment-Snapshots) an den jeweiligen Auftraggeber ist eine Übermittlung zwischen zwei Verantwortlichen und erfolgt auf Veranlassung der Partner-Organisation. Die Partner-Organisation legt und dokumentiert die einschlägige Rechtsgrundlage je Zweck, insbesondere § 26 BDSG sowie – soweit anwendbar – Art. 6 Abs. 1 lit. c oder f DSGVO in Verbindung mit den Prüf- und Nachweispflichten aus § 34a GewO.

5. Unterstützung bei Betroffenenrechten

• Auskunft und Datenübertragbarkeit: personenbezogener Export der technisch zugeordneten Daten auf dokumentierte Anfrage; erforderliche Ergänzungen werden bei Bedarf manuell zusammengestellt.
• Löschung: harte Löschung oder Anonymisierung gemäß Fristentabelle; ein Soft-Delete gilt nicht als Löschung.
• Einschränkung und Widerspruch: Deaktivierung zuzüglich Sperrvermerk; keine weitere operative Nutzung bis zur Klärung.
• Berichtigung: durch den Kunden in der Anwendung; Korrekturen an Auftraggeber-Snapshots über den Korrekturvorschlagsprozess.

---

Anlage B – Technische und organisatorische Maßnahmen

Fassung v1.0 · Stand: 03.09.2026

Gegliedert nach Art. 32 Abs. 1 DSGVO. Maßnahmen dürfen durch gleichwertige oder bessere ersetzt werden; wesentliche Änderungen werden mit Datum nachgeführt.

1. Vertraulichkeit

1.1 Zutritts- und Infrastrukturkontrolle

• Betrieb ausschließlich in Rechenzentren der Hetzner Online GmbH in Deutschland (Nürnberg/Falkenstein); physische Sicherheit gemäß den Maßnahmen des Hosters (zertifiziert nach ISO 27001), mit dem ein Auftragsverarbeitungsvertrag besteht.
• Kein Betrieb produktiver Daten auf lokalen Arbeitsrechnern; reguläre Dateiablagen erfolgen in Object Storage bei Hetzner. Personenbezogene Auskunftsexporte werden derzeit vorübergehend im nicht öffentlich erreichbaren Anwendungsspeicher erzeugt und nach der geschützten Übergabe manuell gelöscht.

1.2 Zugangskontrolle (Systeme)

• Server-Zugang nur per SSH mit Schlüsselverfahren; administrativer Zugriff nur durch einen dokumentiert kleinen Personenkreis.
• Anwendungszugang über personengebundene Konten; Passwort-Hashing (bcrypt), Invite-basierte Registrierung im Hub, Rate-Limits auf Login- und Reset-Routen.
• Eigener Auth-Guard für den Hub; Hub-Konten sind von Tenant-Konten getrennt.

1.3 Zugriffskontrolle (Least Privilege)

• Rollen- und Rechtemodell je Organisation beziehungsweise je Team; serverseitige Prüfung über Policies.
• Datenbank-Rechtetrennung: getrennte Datenbankrollen für Laufzeit (nur lesende und schreibende Datenoperationen, kein DDL) und für Migrationen; keine Superuser-Rechte.
• Fail-closed Runtime-Gates: Verarbeitung von Identity- und Personaldaten nur bei strikt geprüftem Freigabewert; unklare Werte gelten als geschlossen.
• Organisationsübergreifender Supportzugriff ist produktiv deaktiviert; eine Aktivierung ist nur mit benannter Rolle, strukturierter Pflichtbegründung und Pflicht-Audit je Zugriff möglich.

1.4 Trennungskontrolle (Mandantentrennung)

• Je Tenant eine eigene Datenbank; der Hub nutzt eine eigene, getrennte Datenbank; keine datenbankübergreifenden Fremdschlüssel.
• Organisations-Scope in allen Hub-Abfragen; Auftraggeber sehen nur die für sie bestimmten Snapshots.

1.5 Pseudonymisierung und Datenminimierung

• Feldfreigabe-Katalog mit Bewertungsstufen (erlaubt / zweckgebunden / transient / verboten); nicht freigegebene Verarbeitungen sind technisch nicht vorhanden.
• Bewacher-ID und Geburtsdatum: kein generischer Suchpfad, keine Anzeige in Listen oder Karten, nur auditierte Detailansichten.
• Suchbegriffe werden in Audit-Logs nie im Klartext gespeichert, sondern nur als Vorhandensein, Länge und kryptografischer Fingerabdruck mit Server-Geheimnis.
• Event- und Queue-Payloads werden auf die zwecknotwendigen Felder reduziert.
• Push-Inhalte sind standardisiert und enthalten keine Namen, freien Notizen, Einsatzorte oder vollständigen Nachrichteninhalte; FCM-Nachrichten verfallen nach spätestens 24 Stunden.

2. Integrität

2.1 Übertragungskontrolle

• TLS-Verschlüsselung für alle Web-Zugriffe.
• Datenbankverbindung zum Hub mit SSL-Pflicht.
• Übermittlung an Auftraggeber ausschließlich über definierte, geprüfte Snapshot-Pfade; keine Ad-hoc-Exporte.

2.2 Eingabekontrolle (Nachvollziehbarkeit)

• Pflicht-Audit für alle schreibenden Personaldaten-Vorgänge (Anlage, Änderung, Deaktivierung, Löschung, Import, Matching, Korrekturvorschlag, Assignment-Submit).
• Read-Audit für Detailansichten mit sensiblen Feldern, für Exporte und Downloads sowie für jeden organisationsübergreifenden Zugriff; Sampling ist unzulässig, jedes Ereignis wird protokolliert.
• Audit-Einträge enthalten Actor, Organisation, Aktion, Objekt, Zeitpunkt und minimierte technische Metadaten.

3. Verfügbarkeit und Belastbarkeit

• Produktivbetrieb hinter Loadbalancer mit mehreren Anwendungs-Hosts.
• Automatisierte, reproduzierbare Deployments mit Release-Verifikation.
• Datenbank-Backups: Alle Datenbanken werden täglich automatisiert gesichert. Die Wiederherstellbarkeit wird regelmäßig durch automatisierte Restore-Proben überprüft; Sicherung und Probe werden täglich überwacht, ein Fehlschlag löst eine Benachrichtigung aus. Die zuletzt durchgeführten Restore-Proben waren erfolgreich und deckungsgleich mit dem Ausgangsbestand.
• Täglicher Retention-Lauf mit Fehlerüberwachung und Benachrichtigung.

4. Löschkonzept

• Aufbewahrungsfristen sind als Code-Konstanten hinterlegt und bewusst nicht per Umgebung verstellbar, damit die dokumentierte Datenschutzentscheidung nicht spurlos änderbar ist.
• Täglicher automatisierter Lösch- und Anonymisierungslauf für alle Retention-Kategorien; der Betriebsnachweis wird protokolliert.
• Für Partner-Personal beginnt die Sechsmonatsfrist individuell mit der dauerhaften Deaktivierung beziehungsweise Entfernung; eine Reaktivierung hebt die laufende Frist auf.
• Werkzeuge für Betroffenenrechte: personenbezogener Export der technisch zugeordneten Hub-Daten mit manueller Ergänzung bei Bedarf, harte Löschung und Anonymisierung sowie Sperrvermerk in der Partner-Oberfläche.
• Die Anonymisierung schließt Re-Identifikationsmerkmale ein (auch externe Personalnummern); ein Soft-Delete gilt nicht als Löschung.
• FCM-Token werden bei Deaktivierung, ungültiger Provider-Meldung, Entzug des App-Zugangs oder Löschung des Benutzerkontos physisch aus dem Datensatz entfernt. Ein täglicher Lauf deaktiviert Registrierungen nach 90 Tagen ohne App-Kontakt und löscht tokenfreie Gerätedaten nach weiteren 30 Tagen.

5. Organisatorische Maßnahmen und Überprüfung

• Dokumentierte Datenschutzentscheidung mit Feldfreigaben, Zweckbindung und Fristen; Änderungen nur über neue dokumentierte Entscheidungen.
• Externe Datenschutzberatung; Beratungsunterlagen werden in der Geschäftsdokumentation archiviert.
• Secret-Scanning im Entwicklungsprozess; keine Secrets im Code; Konfigurationsdateien mit Zugangsdaten sind nicht versioniert.
• Mehrstufiger Qualitätsprozess je Feature (Definition, Design, Umsetzung, QA, Review) mit verpflichtenden Tests für Rechteprüfung und Modul-Gating.
• Kleiner, benannter Personenkreis: Verantwortlich ist die Geschäftsführung; kompensierend wirken die technischen Kontrollen (Audit-Pflicht, Gates, Datenbank-Rechtetrennung).

---

Anlage C – Unterauftragsverarbeiter

Fassung v1.0 · Stand: 03.09.2026

Genehmigte Unterauftragsverarbeiter im Sinne von Art. 28 Abs. 2, 4 DSGVO:

Produktiv eingesetzter Push-Dienst

Firebase Cloud Messaging (FCM) ist als optionaler Push-Dienst für die Staff App produktiv aktiviert. Übertragen werden:

• der FCM-Registration-Token des Geräts,
• ein standardisierter Benachrichtigungstitel und -text,
• Inbox-ID, Ereignistyp, Kontexttyp und -ID, gegebenenfalls Kontextdatum und Priorität,
• technisch anfallende Verbindungsdaten.

Bei iOS leitet FCM die Nachricht über den Apple Push Notification Service (APNs) weiter. Apple ist deshalb als weiterer Empfänger und eigenständige Zustellinfrastruktur zu dokumentieren. Apple wird für APNs nicht als Unterauftragsverarbeiter in dieser Anlage geführt. Die APNs-Bedingungen enthalten keine Weisungsbindung nach Art. 28 DSGVO und erlauben Apple die Verarbeitung technischer Daten für eigene Betriebs-, Sicherheits- und Compliance-Zwecke.

Hinweise

• E-Mail-Versand: Der Versand erfolgt über einen eigenen SMTP-Dienst innerhalb der bereits aufgeführten Hetzner-Infrastruktur; deshalb ist kein zusätzlicher Unterauftragsverarbeiter für den E-Mail-Versand aufgeführt.
• Änderungen dieser Liste folgen dem Verfahren aus § 6 dieser Vereinbarung: Vorabinformation mindestens vier Wochen in Textform, Widerspruchsrecht aus wichtigem, datenschutzbezogenem Grund.

---

Fragen zu dieser Vereinbarung

Für Datenschutzanliegen und Fragen zu dieser Vereinbarung erreichen Sie uns unter [Protected] .