Security & RLS

CollectiveMiles is designed as a multi-tenant service: operators use shared application infrastructure while their records remain scoped to their own organisation. Tenant identity is carried through authorised requests and checked again when protected data is accessed.

Separation is not treated as a visual dashboard feature. It is enforced at the data-access layer as part of a defence-in-depth model.

PostgreSQL Row-Level Security (RLS) policies restrict which database rows a request is allowed to read, create, change, or delete. Policies use the authenticated user and tenant context so that a valid login alone does not grant access to another operator's records.

RLS complements—not replaces—application validation, permissions, secure configuration, and testing. Administrative access is limited to authorised operational purposes and should follow least-privilege procedures.

Access is designed around authenticated accounts and role-appropriate permissions. Operators are responsible for inviting only authorised users, choosing suitable roles, protecting credentials and devices, and removing access promptly when a person leaves or changes duties.

Security-sensitive actions and important operational changes may be recorded to support investigation and accountability.

Controls are designed to protect data in transit, reduce unnecessary access, validate inputs, and separate production data from public interfaces. Service logs and monitoring support detection of unusual behaviour and troubleshooting.

We do not describe any control as making compromise impossible. Security is a continuous process involving configuration, patching, review, provider management, and response planning.

The platform includes operator-controlled export and local continuity features for supported records. These features help an operator retain access to essential information during connectivity problems and support its own recovery planning.

Downloaded exports are under the Operator's control. They should be stored securely, restricted to authorised staff, retained only as needed, and deleted safely when no longer required.

Security review should accompany changes to authentication, tenancy, permissions, database policies, and public forms. Testing includes checking expected access and deliberate cross-tenant denial paths before release.

Dependencies and hosting providers form part of the security boundary and are reviewed and updated according to risk and operational requirements.

Suspected incidents are assessed and contained, relevant evidence is preserved, affected credentials or access may be restricted, and recovery actions are prioritised. Notifications are made when required by applicable law and the circumstances of the incident.

Operators should report suspected unauthorised access without delay and avoid sending sensitive records in ordinary email unless requested through an approved secure channel.

Send security concerns to support@collectivemiles.com with the affected URL or feature, a clear description, steps to reproduce, and your contact details. Do not access another tenant's data, degrade the service, use automated high-volume testing, or publish sensitive findings before they are addressed.

For privacy requests or concerns about personal information, contact privacy@collectivemiles.com.