53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
# 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.
|