OneOps
Connectors

Data handling

How data is classified, why some trip-linked identifiers count as protected, what is logged, and how sensitive fields are protected.

This page describes how the platform is designed to handle personal and protected data. It is design intent, not an audit of current production behavior.

Posture document. The handling described below states the design rules. Treat them as design intent, not as a guarantee about any specific deployment. Coverage is not compliance.

Three classes of data

The platform sorts data into three working classes:

  1. Operational data. Non-personal facts about the operation: aggregate counts, route geometry not linked to a rider, configuration. Usable broadly within your authorized services.
  2. Personal data. Identifies a person but is not health-linked: a staff member's login, a contact name, an account email. Handled with access control and kept to the minimum needed.
  3. Protected health data. Health-linked identity, including anything that ties a person to a trip taken for a health-related reason. This is treated as present across the platform; every service that stores or processes it is built around it.

Why some trip-linked identifiers are protected

A common mistake is to treat vehicle identifiers as harmless operational data.

A vehicle identifier, license plate, or device identifier becomes protected the moment it is tied to a specific rider's trip. Guidance from the transportation sector itself lists these among the identifiers that make a record protected. The platform treats trip-linked identifiers as protected, not as ordinary operational data.

What is logged, and what is never logged

The logging rule is simple: log that data was accessed, never the value.

Audit entries record who accessed which record and when, so access is reviewable, without copying the protected value into a second place. The audit log is not a second copy of anyone's protected data.
  • Logged: access events (who, what record, when), staff identity, configuration changes, system health.
  • Never logged: protected values, rider identity, trip-linked identifiers, and health-related detail. These never appear in logs, error messages, page labels, or web addresses.

Protecting sensitive fields

Sensitive fields get extra protection on top of access control:

  • Field-level encryption for the most sensitive fields (signatures, medical notes, dates of birth, and similar), so they are protected even from a direct read of the underlying store. In the product, encrypted fields show as locked indicators rather than values.
  • Encryption at rest and in transit across the platform.
  • Per-organization key management, so the keys protecting one organization's sensitive fields are managed for that organization.

See also

Security

The public compliance posture: how the platform is designed to handle protected data, isolate organizations, and keep access minimum-necessary and audited.

Access and audit

Role-based access, project-scoped access, tenant isolation, and append-only audit logging as the controls that keep access minimum-necessary and reviewable.