Data Processing Agreement (DPA/AVV)
pursuant to Art. 28 para. 3 GDPR
Based on the template provided by the Bavarian Data Protection Authority (BayLDA). Adapted for the SaaS service Tuurio ID.
Processor (Data Processor): Tuurio GmbH, Muehlenstr. 8a, 14167 Berlin. Managing Directors: Marcus Jueptner, Daniel Kraus. HRB 180639, Amtsgericht Berlin-Charlottenburg. USt-IdNr.: DE305850010 (hereinafter "Processor").
1. Subject matter and duration
Provision of the SaaS solution "Tuurio ID" (id.tuurio.com) for identity management and authentication, including: OAuth 2.0/OIDC authentication and authorization of the controller's end users, storage and management of user identities, provision of token endpoints (Authorize, Token, UserInfo, JWKS), logging of authentication events (audit logs), provision of the vault module (encrypted data storage), and provision of the admin dashboard for tenant management.
The service is provided exclusively within a member state of the European Union (Hosting: STACKIT, Germany). Any relocation of the service or parts thereof to a third country requires the prior consent of the controller and may only take place if the conditions of Art. 44 ff. GDPR are met.
The agreement is concluded for an indefinite term and applies for the duration of the controller's use of the Tuurio ID service. It ends automatically upon termination of the service contract.
2. Type and purpose, data categories, data subjects
Purpose of processing: Authentication, identity verification, and user management within the Tuurio ID platform for the controller's applications.
Data categories
| Category | Examples | Retention |
|---|---|---|
| Master data | Name, email address, profile picture, custom profile fields | Duration of contract + 30 days |
| Authentication data | Password hashes (Argon2id), MFA seeds, passkey credentials | Duration of contract |
| Session/token data | Access tokens, refresh tokens, session IDs | Max. 30 days (token lifetime) |
| Log data | Login timestamps, IP addresses, user agent strings, failed auth events | 90 days |
| Vault data | AES-256 encrypted arbitrary data stored by the controller | Duration of contract + 30 days |
| OAuth data | Client IDs, redirect URIs, scopes, permissions, roles | Duration of contract |
Passkey-only: purpose, retention and return to password login
Prepared operating-policy addition, 8 October 2026. This describes the intended contract for the approved rollout; it does not assert that the remaining functions are already available or grant legal, release or activation approval.
During passkey-only, existing native and imported password verifiers are blocked and retained solely for a possible return to password login. They remain in their original storage; no separate password archive is created. Retention is not an additional recovery method and never authorizes a password-only bypass.
The original recorded activation starts a 30-day period of exactly 720 hours. A bounded automatic deletion process removes the retained old verifiers from active storage from the end of that period only while the same activation remains enabled. Saving or retrying an enabled policy does not extend it. If an older activation has no evidenced start, its age is unknown; deployment time is not used to invent a deletion deadline.
Switching passkey-only off before deletion makes surviving original verifiers usable again under the normal account and authentication checks. A later genuine activation starts a new period. Switching off never restores deleted password material or revoked sessions and tokens. Deletion ends the old-password return path; access through passkeys and configured recovery remains.
A user with a currently usable passkey and configured recovery can request deletion of their own old password at any time within this retained-password contract. After policy OFF, this requires proof that the unchanged password stock predates the original activation; new OFF passwords or unproven history are refused. An authorized tenant admin can deliberately remove retained verifiers early while passkey-only is active, with audit. The irreversible effect on the password return path is explained beforehand and requires explicit confirmation. This process does not silently remove the only current login factor outside the retained-password contract.
New accounts created through a passkey-only path receive no password. New tenants still start with passkey-only disabled; enabling it remains an explicit tenant decision subject to readiness checks.
Separate, restricted deletion records contain account and tenant identifiers, comparison identifiers for removed verifiers and original activation and deletion metadata, not reusable password verifiers. They prevent removed material being accepted again even after account deletion. These are personal security records, not anonymous data. The prepared technical implementation has no automatic expiry or deletion process for these records. The 720-hour period for old password verifiers is not a claim that these records are erased at the same time; their purpose and retention must be assessed separately before release.
Deleting active database rows does not immediately remove copies from existing encrypted backups; those copies follow the actual backup-retention policy. A restore must remain isolated from authentication and writers until original deletion records, activation state and revocations have been reconciled. Restoring a complete old backup that discards the deletion history cannot be made safe by the cleanup worker alone. It must not silently reactivate deleted verifiers or revoked sessions and refresh tokens.
The intended session rules end all other user sessions and refresh tokens after recovery setup, and all non-passkey sessions and tokens in the tenant on opt-in. Returning the policy to off does not revive them. Only Tuurio performs an application rollback: commit policy off, stop affected writers, end the specifically affected sessions, then restore the recorded prior application image. A backup restore and an application-image rollback are different operations.
Data subjects
- End users of the controller's applications (natural persons who authenticate via Tuurio ID)
- Administrators and employees of the controller (who manage tenants and configurations)
- Technical contacts and API users
3. Rights of the controller
The controller has the right to issue instructions regarding data processing at any time, audit the processor's compliance with this agreement (including on-site inspections with reasonable notice), and request information about processing activities. The processor must immediately inform the controller if an instruction, in the processor's opinion, violates data protection regulations.
4. Obligations of the processor
The processor processes personal data only on documented instructions from the controller, ensures that all persons authorized to process personal data have committed themselves to confidentiality, implements and maintains technical and organizational measures pursuant to Art. 32 GDPR, assists the controller in fulfilling data subject requests (Art. 12-22 GDPR), assists with data protection impact assessments (Art. 35 GDPR) and prior consultations (Art. 36 GDPR) where applicable, and makes available to the controller all information necessary to demonstrate compliance.
5. Notification obligations
The processor notifies the controller without undue delay (and in any case within 24 hours) of any personal data breach pursuant to Art. 33 GDPR. The notification includes the nature of the breach, affected data categories and approximate number of affected persons, likely consequences, and measures taken or proposed. Contact: security@tuurio.com.
6. Sub-processors
The current list of sub-processors is available at /public/legal/sub-processors. The controller agrees to the sub-processors listed there. Changes are notified at least 30 days in advance by email. The controller may object within 14 days for important data protection reasons.
7. Technical and organizational measures
The processor implements appropriate technical and organizational measures pursuant to Art. 32 GDPR. Details are described on our security page. Key measures include: AES-256 encryption at rest, TLS 1.2/1.3 in transit, Argon2id password hashing (64 MB RAM hardness), tenant isolation via tenant-scoped application and authorization controls supplemented by ORM-level tenant filters, automated encrypted daily backups (30-day retention), RS256 JWT signing with tenant-specific key rotation, comprehensive access logging and audit trails.
8. Obligations upon termination
After contract termination, the controller can export all data within 30 days via the dashboard in a common, machine-readable format (JSON, CSV). After the 30-day export period, all personal data is irreversibly deleted within 30 additional days, unless legal retention obligations apply (e.g., tax records pursuant to GoBD: 10 years). The processor confirms deletion in writing upon request.
Version 1.0, March 9, 2026