Security & Data Protection

1. Org-scoped by design

Every record in the platform — every outlet, visit, user, order, and message — carries the owning organisation's ID, and every query the application issues is scoped to the authenticated caller's own organisation. A tenant's data is architecturally unreachable from another tenant's session; it is not a display-layer filter that a bug could bypass.

Platform-operator access (for support and onboarding) is a separate, explicitly-audited role tier — never the same credential a tenant's own users hold.

2.1  Role-based hierarchy

Access follows the tenant's own reporting line — field officer, supervisor, regional manager, zonal manager, head of sales, and organisation admin/CEO — each tier seeing exactly its own team's data and no further, with a dedicated super-admin tier for platform operation kept structurally separate from every tenant role.

Session tokens are signed and time-bounded; every request is authenticated independently, and a compromised token cannot be extended by simply staying active.

2.2  Scoped automation credentials

System-to-system access (scheduled jobs, integrations) uses purpose-scoped API keys rather than a shared master credential — a key issued for one function cannot be used for another, and every key can be individually rotated or revoked without affecting the rest of the platform.

2.3  Configurable approval controls

A tenant can require supervisor sign-off before a field-level record edit takes effect, or allow direct field edits when speed matters more — the choice is the tenant's own, set per organisation, not fixed by us.

3.1  GPS-verified, geofenced visits

A visit can only be started and completed within a tenant-configured distance of the outlet's real coordinates — a field officer cannot check in remotely and claim a visit that did not happen.

The platform separately detects two specific spoofing patterns: identical coordinates reused across different outlets, and travel between two check-ins faster than is physically possible — both are flagged to the officer's supervisor automatically, in real time.

3.2  Real field time, even offline

A visit recorded with no network connection keeps the moment it actually happened once it syncs — never the moment the device happened to reconnect. Combined with a visit-to-visit gap check, this closes the specific loophole where sparse check-ins are used to make a partial day look like a full one.

3.3  Photo verification

Tenants can require an in-store photo to complete a visit, enforced server-side — a photo requirement that only lives in the mobile app UI can be bypassed; this one cannot.

4.1  Immutable audit trail

Account changes, permission edits, record edits, and administrative actions are logged with the acting user, organisation, timestamp, and the before/after values — available to a tenant's own admins for their organisation, not just to us.

4.2  Escalation, not silence

Flagged issues (a compliance concern, a safety report, a data-integrity anomaly) route to the responsible line manager immediately and automatically escalate up the reporting chain if left unacknowledged — nothing sensitive is left to wait for someone to notice it.

5.1  Encrypted in transit

All traffic between the field app, the web console, and our servers is carried over HTTPS/TLS. The database is reachable only by the application layer, never directly from the public internet.

5.2  Offline-first, not offline-fragile

The field app is a Progressive Web App built to keep working through East Africa's real connectivity conditions — data queued while offline is delivered exactly once when connectivity returns, with the true capture time intact (see Field Data Integrity above).

5.3  A local team, not a support ticket queue

We are based in Tanzania and build for tenants here directly. A genuine security question or an operational concern reaches the people who wrote the code — not a distant support tier reading from a script.