Security & data handling

Your riders’ data, and what we do with it.

You bill a government payer and you handle protected health information. Before you care whether our dispatch is any good, you need to know where that data sits and who can reach it. This page answers that in plain language.

What the system actually does

Each operator’s data is fenced from every other operator’s

Every ride, client, driver and invoice row carries the company that owns it, and every query filters on it server-side. A dispatcher at one company cannot read another company’s board even by guessing an id — the filter is applied before the database is asked, not after the answer comes back.

The browser never talks to the database directly for anything sensitive

Client records, driver records and rides are read and written through server routes that check the session first and run with credentials the browser never sees. Row-level security is enabled on those tables as a second fence behind the first.

Rider phone numbers are unique per company, enforced by the database

Two riders cannot share a phone number, because ride confirmations and reminders text that number — a collision sends one member’s trip details to a different household. That is a constraint in the database, not a check in the code, so no import or script can work around it.

Call recordings are private and access is time-limited

Recordings of confirmation calls are held in private storage. Playback goes through an authenticated route that mints a link valid for five minutes and checks the recording belongs to the company asking. A link that works for a week outlives the reason someone was given it.

Operational history cannot be quietly rewritten

Once a driver has worked a ride, their assignment to it is immutable — enforced by the database, so it holds against any route, script or console. Deleting a driver who has ride history is refused outright rather than silently detaching their pay record.

Staff access is role-based and least-privilege

What a dispatcher, an admin, a fleet user and a driver can each reach is decided in one place and checked on the server. A driver signing in reaches their own schedule and nothing else.

HIPAA, straight

The security page is where a vendor is most tempted to oversell — usually by implying a certification that does not exist. Here is the version without that.

HIPAA applies to us, directly

Handling your riders’ data makes us a Business Associate, and since the HITECH Act a Business Associate is directly liable under the HIPAA Security Rule — not merely on the hook to you by contract. That is the right answer to want from a vendor: it means the obligation is ours whether or not you ever audit us.

There is no such thing as a HIPAA certificate

HHS does not certify software, so no vendor can be "HIPAA certified" — a badge saying otherwise is a training receipt. What is real: a signed BAA, a documented risk analysis, and controls someone can actually inspect. Judge us and everyone else on those three, not on a logo.

We sign a BAA before your first real rider

Not after go-live, not "once we scale". Ask for it on the demo call. And ask the same question one level down: which of our own providers have signed BAAs with US, because your riders’ data sits on their infrastructure too and a chain is only as good as its weakest link.

Questions worth asking us — and our competitors

Where is the data physically hosted? Which of your own providers have signed BAAs with you? Who on your team can read my riders’ records, and is that logged? What is your breach notification window? Can I export everything and leave, and what happens to my data if I cancel?

A vendor who cannot answer those in writing has given you an answer.

Something look wrong? Tell us.

If you believe you have found a security issue, email security@ultranavis.com. We would far rather hear it from you than from a customer. We will confirm receipt, and we will not take legal action against anyone reporting a genuine issue in good faith.

Request a demo Talk to a person