GDPR compliance in MobilityManager
MobilityManager gives administrators the tools they need to meet core GDPR (DSGVO) obligations for the personal data your fleet holds about users and drivers. This overview explains the two building blocks the platform provides — the right to erasure and the audit trail — and where the relevant personal data lives.
The two GDPR building blocks
Compliance in MobilityManager rests on two capabilities that work together:
- Right to erasure (GDPR Art. 17) — a user's personal data is pseudonymized, meaning identifying fields are replaced with a non-reversible placeholder such as
Deleted User #00042-58391. The record structure is preserved so that history and reporting stay intact. - Audit trail — every create, update, and delete on tenant data is recorded automatically in an append-only log that captures who changed what, when, and the before/after values. Audit entries are immutable.
Where personal data is stored
Because MobilityManager is multi-tenant, personal data is spread across two kinds of database, and erasure must reach both:
| Location | Personal data held |
|---|---|
| System database | The login account: username, email, first and last name, password hash, password-reset tokens, and OIDC identifiers. |
| Per-tenant databases | The tenant-specific Driver record, the DriverLicenseProfile (the regulated Führerschein / driver-license number), and AuditEntry rows that reference the user's email. |
Pseudonymization scrubs personal data in every tenant the user belonged to, not just the current one.
Who can perform GDPR actions
GDPR erasure actions require the users:manage permission, and the requesting account must also hold the SystemAdmin role. Reading the audit trail requires the settings:view permission. Roles in MobilityManager are SystemAdmin, FleetManager, and Driver, plus any custom roles your organization defines.
Note: Pseudonymization is irreversible by design. Once a user is pseudonymized, the original identifying values cannot be recovered.
What is preserved
Erasure removes personal data but keeps the surrounding structure so your organization can still demonstrate compliance. For example, audit entries keep their timestamp, action, entity type, and entity ID — only the user's email is replaced with the pseudonym. This lets you prove that a change happened and when, without exposing who the person was.
Tip: Before submitting an erasure request, use the eligibility check to confirm the account can be pseudonymized. This avoids failed requests for system administrators or already-erased accounts.
Related
- Pseudonymize a user (GDPR right to erasure)
- Check whether a user can be pseudonymized
- The audit trail and what it captures
- Why audit entries cannot be edited or deleted
