Files
MobilityOps/docs/18-privacy-governance.md
T
NuklearRabbit 00191e9b54
MobilityOps acceptance / backend (push) Failing after 20s
MobilityOps acceptance / frontend (push) Successful in 28s
MobilityOps acceptance / e2e (push) Skipped
M48: harden demo operations and offsite recovery
2026-08-21 22:17:49 +02:00

3.0 KiB

Privacy and data governance

Scope and ownership

MobilityOps stores operational users, customers, bookings, vehicle inspections, maintenance, data-quality issues, workflow state and audit events. The deployed demo contains synthetic data only. Before introducing real data, the deploying organisation must document its controller/processor roles, lawful bases, contact point and approved retention values. Operations Managers are the only role permitted to export or anonymise.

Retention policy

  • Customer PII may be anonymised only when no reserved or active booking exists and the newest booking is older than PRIVACY_MINIMUM_BOOKING_RETENTION_DAYS (default 30).
  • Audit events are configured for 2,555 days by default. They are immutable operational evidence; changing this period requires legal approval and a separate, audited purge implementation. MobilityOps reports the policy but never silently deletes audit data.
  • Database backups default to 30 days with at least seven newest recovery points. The demo's optional OneDrive off-site copy contains the same synthetic dataset and follows the same retention intent; remove that folder when retiring the demo. Real personal data remains out of scope and must not be introduced merely because cloud backup is available.
  • Logs are bounded by Docker rotation. They must not contain request bodies, passwords, OIDC tokens or customer fields.

Data-subject request procedure

  1. Verify the requester's identity outside MobilityOps and record the case reference.
  2. In Privacy management, download the customer JSON. The export action is audited.
  3. Review active/recent booking blockers and applicable legal retention obligations.
  4. Enter a reason and the exact customer reference to anonymise. The operation is irreversible and row-locked. It clears name, email, phone, address and birth date but preserves the stable reference and operational bookings so financial/operational evidence is not corrupted.
  5. Verify the resulting audit event. Its before/after payload records only anonymisation state; erased PII is deliberately not copied into the audit log.
  6. Handle verified backups according to their bounded retention; never mutate individual dump files.

Audit export and access review

Audit CSV exports are manager-only, limited to a maximum 90-day range and a configurable row cap. Every export is itself audited. Review manager accounts, external OIDC bindings, failed sign-ins, privacy exports and anonymisations periodically. Deactivate access at the canonical MobilityOps user record; this invalidates subsequent operational requests.

Incident handling

Preserve relevant JSON logs, correlation IDs and audit exports; do not overwrite the database or backups. Rotate affected secrets, disable OIDC or external integrations when needed, assess notification obligations and restore only through the guarded runbook. Record all incident decisions outside the application in the organisation's incident system.