Security & data handling

Last reviewed 21 August 2026

Connecting DwellWatch means handing us credentials to your ELD account. This page says exactly what we do with that access, what protects it, and — at the bottom — what we have not built yet.

We only ever read

Every operation we issue against your ELD account is a read operation. We do not create, modify or delete any record in that account, including hours-of-service logs, vehicles, drivers and groups. No action taken by this service can alter a record you may subsequently require for a compliance audit.

The scope of what we read is limited to vehicle identifiers and names, GPS positions with speed and heading, and the associated timestamps. We do not read driver records, messages or camera footage, and the service requires no action from drivers.

We do not store driver identity. Some ELD interfaces attach a driver identifier to a position record whether or not an application requests one. We remove those fields before any record is written to our database, applying the same rule to every provider we support rather than only to those known to transmit it. Detention is determined by a vehicle's position and duration; the identity of the driver is not required for that purpose and is not retained.

Your ELD credentials

Credentials are encrypted with AES-256-GCM before they are written to the database, using a key held outside it. GCM is authenticated encryption, so tampering with a stored value is detected rather than silently decrypting to something else.

They are used for one thing: reading your own fleet's telemetry on your behalf. You can disconnect at any time, which stops all further access immediately.

Keeping carriers separate

Every piece of carrier data — vehicles, telemetry, facilities, detention events, invoices — is stored against the carrier it belongs to, and every query that reads it is scoped to the carrier making the request. There is no path by which one carrier's account can read another's.

Within a carrier, permissions are enforced server-side on every request and read from the database rather than from the session, so an outdated session cannot carry outdated privileges. Unrecognised roles are denied by default. Access controls are enforced on the server; interface restrictions are not relied upon as a security measure.

Who can access production systems

Administrative access to the systems that operate DwellWatch is held by one individual, the founder of Neolite Digital Design & Development Inc., and by no one else. No employees, contractors or other third parties hold accounts on those systems. Access is granted through individually identified accounts at each infrastructure provider. No shared or generic administrative account is in use, and every administrative action is therefore attributable to a named person.

Automated components authenticate independently of any person, and each is restricted to the single function it performs. The component that generates evidence packets is able to write them and to perform no other operation, and no exportable credential for it exists: it executes within our cloud provider and is issued a short-lived identity by the platform. The application component is able to read evidence packets and to initiate one specific job; it cannot modify any schedule and cannot write to packet storage. Of six automated identities, only the two required by the application hold a credential capable of being exported.

Database credentials are held in a managed secret store and are not present in our source code. Every change to that source code is scanned across its full history for credentials before it may be merged.

Separation of duties is not achievable at our current scale. The individual who develops the software is the individual able to access production systems. We state this directly rather than permit a larger organisation to be inferred. The compensating controls are the restricted automated credentials described above and the human approval required before any claim is transmitted.

A person approves every invoice

Detention is inferred from a vehicle's position and the duration of its stay. We hold no load data and therefore cannot distinguish a vehicle waiting to unload from one parked by arrangement. For that reason no claim is transmitted to a customer automatically: a person at your company reviews and approves each one, and every such decision is recorded with the identity of the approver and the time it was made.

We never touch your money

Invoices are issued under your own billing identity and your customers pay you directly. We are not a party to any claim, hold no funds at any point, and do not act as a collections agency. Our fee is a flat monthly rate per vehicle and is not calculated as a proportion of amounts recovered.

How long we keep your data

If you evaluate DwellWatch and do not subscribe, the telemetry collected for your audit is deleted automatically. A weekly process removes position records more than 90 days old, once no new telemetry has arrived from the account for 30 days. Both conditions are required: the second distinguishes an account that has been abandoned from one that is still being evaluated, and without it a fresh audit would be eligible for deletion the day it was produced.

If you are a customer, your records are kept for as long as your account exists, and we do not delete them on a timer. Nor do we delete a former customer's history automatically: an account that lapses may be reopened, and the records behind claims already made remain relevant to you. You may ask us to delete your data at any time.

Telemetry supporting an invoice is excluded from deletion, whatever else applies. That includes invoices you subsequently voided, and it includes the position record that establishes the vehicle's departure. It is the evidence behind a claim you may still have to defend, so the retention process is built to hold it back by construction rather than by remembering to.

Who we rely on, and where your data sits

DwellWatch runs on managed infrastructure. The providers we use are listed in full below. Each receives only what it needs to perform its function, none is permitted to use your data for its own purposes, and card details pass directly to the payment processor without being handled by us.

ProviderWhat it doesWhere
NeonManaged Postgres — the database holding all carrier dataOhio, United States
NetlifyApplication hostingOhio, United States
Google CloudScheduled jobs that read telemetry and build evidence packetsOhio and Virginia, United States
Amazon Web Services (SES)Email delivery — invoices to brokers you choose, and account mail to youOregon, United States
StripeSubscription billing and card details, which never reach usUnited States

Neolite Digital Design & Development Inc. is a Canadian company, but every provider above operates in the United States, so that is where your data is processed and held — and while it is there, US law applies to it. Our Privacy Policy says more about what that means.

What we have not built yet

We disclose the following limitations so that you can assess them before connecting your fleet:

  • No third-party security audit or SOC 2 report. We have not been independently assessed.
  • An incident-response procedure exists; continuous coverage does not. Where carrier data is exposed, we will notify affected carriers within 72 hours of confirming the exposure, stating the facts known at that time rather than deferring notification until our investigation concludes. We do not maintain an on-call rotation, and an incident arising outside working hours is addressed when it is identified.

Reporting a vulnerability

Write to [email protected], describing what you found and how to reproduce it. We will acknowledge receipt and keep you informed of our response. We will not pursue legal action against researchers acting in good faith.