Auftragsverarbeitungsvereinbarung (AVV)
gemäß Art. 28 Abs. 3 DS-GVO
Basierend auf der Formulierungshilfe des Bayerischen Landesamtes für Datenschutzaufsicht (BayLDA). Angepasst für den SaaS-Dienst Tuurio ID.
Auftragnehmer (Auftragsverarbeiter): Tuurio GmbH, Muehlenstr. 8a, 14167 Berlin. Geschäftsführer: Marcus Jueptner, Daniel Kraus. HRB 180639, Amtsgericht Berlin-Charlottenburg. USt-IdNr.: DE305850010 (nachfolgend „Auftragnehmer“).
1. Gegenstand und Dauer der Vereinbarung
Bereitstellung der SaaS-Lösung „Tuurio ID“ (id.tuurio.com) zur Identitätsverwaltung und Authentifizierung, insbesondere: OAuth 2.0/OIDC-Authentifizierung und -Autorisierung der Endnutzer des Auftraggebers, Speicherung und Verwaltung von Benutzeridentitäten, Bereitstellung von Token-Endpunkten (Authorize, Token, UserInfo, JWKS), Protokollierung von Authentifizierungsereignissen (Audit-Logs), Bereitstellung des Vault-Moduls (verschlüsselte Datenspeicherung) und Bereitstellung des Admin-Dashboards zur Tenant-Verwaltung.
Die vertraglich vereinbarte Dienstleistung wird ausschließlich in einem Mitgliedsstaat der Europäischen Union erbracht (Hosting: STACKIT, Deutschland). Jede Verlagerung in ein Drittland bedarf der vorherigen Zustimmung des Auftraggebers und darf nur erfolgen, wenn die Voraussetzungen der Art. 44 ff. DS-GVO erfuellt sind.
Der Vertrag wird auf unbestimmte Zeit geschlossen und gilt für die Dauer der Nutzung des Tuurio ID Service durch den Auftraggeber. Er endet automatisch mit Beendigung des Service-Vertrags.
2. Art und Zweck, Datenkategorien, betroffene Personen
Zweck der Verarbeitung: Authentifizierung, Identitätsprüfung und Nutzerverwaltung innerhalb der Plattform Tuurio ID für die Anwendungen des Auftraggebers.
Datenkategorien
| Kategorie | Beispiele | Aufbewahrung |
|---|---|---|
| Stammdaten | Name, E-Mail-Adresse, Profilbild, benutzerdefinierte Profilfelder | Vertragsdauer + 30 Tage |
| Authentifizierungsdaten | Passwort-Hashes (Argon2id), MFA-Seeds, Passkey-Credentials | Vertragsdauer |
| Session-/Token-Daten | Access Tokens, Refresh Tokens, Session-IDs | Max. 30 Tage (Token-Lebensdauer) |
| Protokolldaten | Login-Zeitstempel, IP-Adressen, User-Agent-Strings, fehlgeschlagene Auth-Ereignisse | 90 Tage |
| Vault-Daten | AES-256-verschlüsselte beliebige Daten des Auftraggebers | Vertragsdauer + 30 Tage |
| OAuth-Daten | Client-IDs, Redirect-URIs, Scopes, Permissions, Rollen | Vertragsdauer |
Passkey-only: Zweck, Aufbewahrung und Passwort-Rückweg
Vorbereitete Ergänzung zum Betriebsvertrag, 8. Oktober 2026. Beschrieben ist der vorgesehene Vertrag für den freigegebenen Rollout; dies behauptet keine bereits verfügbare Restfunktion und erteilt keine rechtliche, Release- oder Aktivierungsfreigabe.
Bei Passkey-only werden vorhandene native und importierte Passwortnachweise gesperrt und ausschließlich für einen möglichen Rückweg zum Passwort-Login aufbewahrt. Sie bleiben im ursprünglichen Speicher; es entsteht kein zusätzliches Passwortarchiv. Die Aufbewahrung ist keine weitere Recovery-Methode und erlaubt keinen Passwort-only-Umweg.
Die ursprünglich protokollierte Aktivierung startet eine Frist von 30 Tagen, genau 720 Stunden. Ein begrenzter automatischer Löschprozess entfernt die aufbewahrten alten Nachweise ab Fristablauf aus dem aktiven Speicher nur dann, wenn dieselbe Aktivierung weiterhin eingeschaltet ist. Speichern oder Wiederholen einer eingeschalteten Policy verlängert die Frist nicht. Ohne belegten Beginn einer älteren Aktivierung bleibt ihr Alter unbekannt; das Deploymentdatum erzeugt keine erfundene Löschfrist.
Wird Passkey-only vor der Löschung ausgeschaltet, sind erhaltene ursprüngliche Nachweise unter den normalen Konto- und Anmeldeprüfungen wieder verwendbar. Eine spätere tatsächliche Aktivierung beginnt eine neue Frist. Ausschalten stellt niemals gelöschtes Passwortmaterial oder widerrufene Sitzungen und Tokens wieder her. Die Löschung beendet den Altpasswort-Rückweg; Passkey-Zugang und eingerichtete Recovery bleiben bestehen.
Mit aktuell nutzbarem Passkey und eingerichteter Recovery kann der betroffene Nutzer jederzeit die Löschung seines eigenen alten Passworts innerhalb dieses Altpasswort-Vertrags auslösen. Nach Policy-OFF muss belegt sein, dass der unveränderte Passwortbestand vor der ursprünglichen Aktivierung bestand; neue OFF-Passwörter oder unbewiesene Historie werden abgelehnt. Ein berechtigter Tenant-Admin kann aufbewahrte Nachweise bei aktivem Passkey-only mit Audit bewusst früher löschen. Die unumkehrbare Auswirkung auf den Passwort-Rückweg wird vorher erklärt und muss ausdrücklich bestätigt werden. Außerhalb dieses Altpasswort-Vertrags wird nicht still der einzige aktuelle Anmeldefaktor eines Kontos gelöscht.
Neue Konten, die über einen Passkey-only-Weg angelegt werden, erhalten kein Passwort. Neue Tenants starten weiterhin mit ausgeschaltetem Passkey-only; die Aktivierung bleibt eine ausdrückliche Tenant-Entscheidung nach Readiness-Prüfung.
Getrennte, zugriffsbeschränkte Löschvermerke enthalten Konto- und Tenant-Kennungen, Vergleichskennungen entfernter Nachweise sowie ursprüngliche Aktivierungs- und Löschmetadaten, keine wiederverwendbaren Passwortnachweise. Sie verhindern die erneute Annahme entfernten Materials auch nach Kontolöschung. Dies sind personenbezogene Sicherheitsvermerke, keine anonymen Daten. Der vorbereitete technische Stand enthält für diese Vermerke keinen automatischen Ablauf oder Löschprozess. Die 720-Stunden-Frist für Altpasswortnachweise verspricht keine gleichzeitige Löschung dieser Vermerke; Zweck und Aufbewahrung sind vor dem Release gesondert zu bewerten.
Das Löschen aktiver Datenbankzeilen entfernt Kopien aus vorhandenen verschlüsselten Backups nicht sofort; diese folgen der tatsächlichen Backup-Aufbewahrung. Ein Restore bleibt von Anmeldung und Schreibern isoliert, bis ursprüngliche Löschvermerke, Aktivierungszustand und Widerrufe abgeglichen sind. Der Cleanup-Worker allein kann ein vollständiges altes Backup ohne Löschhistorie nicht sicher machen. Ein Restore darf gelöschte Nachweise oder widerrufene Sitzungen und Refresh-Tokens nicht still reaktivieren.
Die vorgesehenen Sitzungsregeln beenden nach Recovery-Einrichtung alle anderen Nutzersitzungen und Refresh-Tokens sowie beim Opt-in alle Nicht-Passkey-Sitzungen und -Tokens im Tenant. Policy-OFF belebt sie nicht wieder. Einen App-Rollback führt nur Tuurio aus: Policy-OFF committen, betroffene Schreiber stilllegen, gezielt betroffene Sitzungen beenden und erst dann das notierte vorherige App-Image wiederherstellen. Backup-Restore und App-Image-Rollback sind unterschiedliche Vorgänge.
Betroffene Personen
- Endnutzer der Anwendungen des Auftraggebers (natuerliche Personen, die sich über Tuurio ID authentifizieren)
- Administratoren und Mitarbeiter des Auftraggebers (die Tenants und Konfigurationen verwalten)
- Technische Ansprechpartner und API-Nutzer
3. Rechte des Auftraggebers
Der Auftraggeber hat das Recht, jederzeit Weisungen hinsichtlich der Datenverarbeitung zu erteilen, die Einhaltung dieser Vereinbarung durch den Auftragnehmer zu überprüfen (einschließlich Vor-Ort-Inspektionen mit angemessener Vorlaufzeit) und Auskunft über die Verarbeitungstätigkeiten zu verlangen. Der Auftragnehmer hat den Auftraggeber unverzüglich zu informieren, wenn eine Weisung seiner Ansicht nach gegen datenschutzrechtliche Vorschriften verstoesst.
4. Pflichten des Auftragnehmers
Der Auftragnehmer verarbeitet personenbezogene Daten ausschließlich auf dokumentierte Weisung des Auftraggebers, stellt sicher, dass alle zur Verarbeitung befugten Personen zur Vertraulichkeit verpflichtet sind, setzt technische und organisatorische Maßnahmen gemäß Art. 32 DS-GVO um und pflegt diese, unterstützt den Auftraggeber bei Anfragen betroffener Personen (Art. 12-22 DS-GVO), unterstützt bei Datenschutz-Folgenabschaetzungen (Art. 35 DS-GVO) und Vorabkonsultationen (Art. 36 DS-GVO) und stellt dem Auftraggeber alle erforderlichen Informationen zum Nachweis der Einhaltung zur Verfügung.
5. Mitteilungspflichten
Der Auftragnehmer meldet dem Auftraggeber unverzüglich (und in jedem Fall innerhalb von 24 Stunden) jede Verletzung des Schutzes personenbezogener Daten gemäß Art. 33 DS-GVO. Die Meldung umfasst Art der Verletzung, betroffene Datenkategorien und ungefähre Anzahl betroffener Personen, wahrscheinliche Folgen sowie ergriffene oder vorgeschlagene Maßnahmen. Kontakt: security@tuurio.com.
6. Unterauftragsverhältnisse
Die aktuelle Liste der Unterauftragsverarbeiter ist unter /public/legal/sub-processors einsehbar. Der Auftraggeber erklaert sich mit den dort aufgeführten Unterauftragnehmern einverstanden. Änderungen werden mindestens 30 Tage im Voraus per E-Mail mitgeteilt. Der Auftraggeber kann innerhalb von 14 Tagen aus wichtigem datenschutzrechtlichem Grund widersprechen.
7. Technische und organisatorische Maßnahmen
Der Auftragnehmer setzt angemessene technische und organisatorische Maßnahmen gemäß Art. 32 DS-GVO um. Details sind auf unserer Sicherheitsseite beschrieben. Wesentliche Maßnahmen umfassen: AES-256-Verschlüsselung im Ruhezustand, TLS 1.3 bei der Übertragung, Argon2id-Passwort-Hashing (64 MB RAM-Hardness), Mandantentrennung auf Datenbankebene (Hibernate-Filter mit tenant_id-Scoping), automatisierte verschlüsselte tägliche Backups (30 Tage Aufbewahrung), RS256-JWT-Signierung mit mandantenspezifischer Schlüsselrotation, umfassende Zugriffsprotokollierung und Audit-Trails.
8. Pflichten nach Beendigung
Nach Vertragsende kann der Auftraggeber innerhalb von 30 Tagen alle Daten über das Dashboard in einem gängigen, maschinenlesbaren Format (JSON, CSV) exportieren. Nach Ablauf der 30-tägigen Exportfrist werden alle personenbezogenen Daten innerhalb von 30 weiteren Tagen unwiderruflich gelöscht, sofern keine gesetzlichen Aufbewahrungspflichten bestehen (z.B. steuerrechtliche Belege gemäß GoBD: 10 Jahre). Der Auftragnehmer bestätigt die Löschung auf Anfrage schriftlich.
Version 1.0, 09. Maerz 2026