Privacy policy

• Your organisation decides what goes into SpudBus and who can see it. We run the software for them.
• A driver’s location is reported only while a run is in progress, and only the latest position is stored — no history, no trail, and nothing at all once the run ends.
• We do not sell anything, we do not advertise, and we do not track anyone across other apps or websites.
• Records of who travelled where are deleted after 18 months. Notifications go after 90 days.

For everything an organisation puts into SpudBus — passengers, their contacts, routes, staff accounts, run records — the organisation is the data controller and SpudBus is its processor. They decide what is collected and why; we hold and process it on their written instructions.

This matters when you want something done about your data: for records held on their behalf, ask them. We will help them answer, but we are not permitted to disclose or erase their records on our own initiative. See your rights below.

We are the controller for a narrower set of things we collect directly: enquiries submitted through this website, and the operational logs described under service logs.

The test applied to every field is whether the system needs it to run a bus. Where the answer was no, the field was removed rather than retained — the free-text box asking why a passenger was absent is gone, because the honest answer to “why is this person not travelling today” is frequently health data, and routing only needs to know yes or no.

• Categories of personal data held in SpudBus

• Passenger record

  Name, year group or team, and the stop they use — the register a driver works from, and the list the office plans routes with.

  How long

  While enrolled, then deleted with the account.

• Notes for the driver

  An optional free-text note attached to a passenger, entered at registration — the thing a driver needs to know at the door. Whatever is typed here is visible to the drivers of that route.

  How long

  While enrolled.

• Contact details

  Name, email and phone for the person responsible for a passenger, so the office can reach someone if a run goes wrong.

  How long

  While enrolled.

• Pickup locations

  The address or map pin a passenger is collected from, and any approved alternative for particular weekdays.

  How long

  While enrolled.

• Staff accounts

  Name, email, phone and role, for sign-in and for assigning runs.

  How long

  While the account is active.

• Run and register records

  Which runs took place, who boarded and was dropped off, when, and where. Answers a safeguarding or dispute question months later.

  How long

  18 months.

• Vehicle location during a run

  So the office and waiting families can see where the bus is, and so the driver's app can navigate.

  How long

  Latest position only. Overwritten as the bus moves and cleared when the run ends.

• Where a vehicle is kept overnight

  Some organisations let a driver keep a vehicle at home, or park it off-site. We store a map pin and a label the organisation types — never a postal address, and never taken from a driver's account. It is used only to work out what time the driver must set off; it changes no passenger's stop time.

  How long

  Until the arrangement ends, or the vehicle is removed.

• Notifications

  The record of alerts sent — a bus arriving, an absence, a no-show.

  How long

  90 days.

• Audit log

  Who did what in the system: approvals, exports, erasures, changes to a pickup point. This is the accountability record.

  How long

  Kept — deleting it would defeat its purpose.

There are no photographs of passengers anywhere in SpudBus. That is a deliberate product decision, not an omission.

The SpudBus Driver app is for people driving a vehicle on behalf of an organisation. Accounts are created by that organisation and approved by an administrator — there is no public sign-up.

Location. The app asks for location permission, including in the background, because a bus route continues while the phone is locked or the screen has moved on to navigation. What that permission is used for is narrow, and worth stating precisely:

• Reporting starts when a run is started, and stops when the run ends or the app leaves drive mode. It does not run off-shift.
• Positions are sent at most once every 15 seconds, and only after the vehicle has moved at least 25 metres.
• The server keeps only the most recent position. It is overwritten by the next one and cleared when the run finishes. No route history of any driver is stored.
• Turn-by-turn navigation is rendered by Mapbox on the device.
• In the browser version of the driver view there is no embedded navigation, so the Directions button hands over to Google Maps. That sends the stop’s coordinates to Google, from the driver’s device. No passenger name goes with it.

Stored on the device. Registrations marked while out of signal are queued locally and sent when the connection returns — otherwise a boarding recorded in a dead spot would be lost. The queue holds only what is waiting to be sent.

The app does not show a driver a passenger’s contact details, guardian, or the reason for an absence. A driver needs the name, the stop, and any note the organisation recorded for them; the rest stays in the office.

A contact can be sent a link that shows their passenger’s bus without creating an account, which avoids making an account for someone who only ever wants to know if the bus is late. Those links are single-purpose: they show that passenger’s stop, the bus’s position while a run is live, and nothing else.

A link binds to the first device that opens it, can be revoked by the organisation at any time, and is deleted 30 days after it is revoked or expires. Links still in use are not deleted for age alone.

For the organisation, the basis is generally the performance of a task or contract — running the transport service a passenger is enrolled on, and employing the people who drive it — together with its legitimate interest in the safety of that service. For a school, safeguarding duties sit behind the same records.

We rely on legitimate interests for the operational logs needed to keep the service running and secure, and on consent for enquiries you choose to submit through this website.

We do not use anyone’s data for automated decision-making that produces a legal or similarly significant effect.

Not sold, not shared for advertising, not passed to data brokers. The organisations we rely on to run the service are:

• Supabase — hosts the database and handles sign-in.
• Mapbox — calculates routes and draws the maps. Our servers send stop coordinates and vehicle positions to plan routes; passenger names are not. Separately, the maps you see are drawn by your own browser fetching map imagery from Mapbox, so Mapbox receives your device’s IP address and which part of the map you are looking at. Nothing identifying a passenger is sent that way.
• Google Maps, Waze or Apple Maps — navigates a driver to the next stop when they use the browser version of the driver view, which has no navigation of its own. The driver’s device opens whichever of the three they have chosen, with the stop’s coordinates; Google Maps is the default and the choice is stored on their own device. Nothing identifying a passenger is included, and a driver using the SpudBus app instead navigates without leaving it.
• OpenStreetMap — turns a typed address into a position on the map. This happens when an administrator adds a stop, and when you choose a pickup place yourself while registering: what you type is looked up against OpenStreetMap’s address data. The request goes through our servers rather than from your browser, so OpenStreetMap is sent the words you typed but never your IP address, and we never ask them who lives there. What is then kept is listed under Pickup locations in What the platform holds above.
• Apple, Google or Mozilla — carry notifications to your phone, if you turn them on. Which one depends on the browser you use, not on anything we choose. The message itself is encrypted before it leaves us, using keys your own browser created and never shares, so they deliver something they cannot read — and neither can we, once it has gone. What they do receive is the fact that a message was sent to your device and when. Turning notifications off, here or in your browser’s settings, stops it entirely.
• Web3Forms — delivers enquiries submitted through the register-interest form on this website. The form posts to them from your browser and they forward it to our inbox. This affects people enquiring about SpudBus only — no passenger, contact or driver data is sent to them.
• Cloudflare — sits in front of our servers and passes requests through to them. Because it handles the encrypted connection, it sees each request in full, including your device’s IP address. It is also what absorbs an attack before it reaches us.
• Vercel — serves this website and the SpudBus screens to your browser, so it sees which pages you open and your device’s IP address. The data behind those screens comes from our own servers, not from Vercel.
• OVH — the data centre our servers run in. Everything the platform holds is on machines there.
• Grafana Cloud — receives operational measurements and logs so we can tell when something is broken. These carry organisation and account identifiers and never a passenger’s name. Listed here because it is what we are setting up, not because it is running yet.

Alerts are shown inside SpudBus itself. Nothing is handed to Apple’s or Google’s push services, because the app does not use them — if that changes, this section changes with it.

We will also disclose data where the law requires it, and to a buyer if the business is ever sold — in which case this policy travels with it.

The windows in the table above are the policy, and the deletion that applies them is code rather than a promise: an automated sweep, whose counts are written to the audit log every time it runs.

Eighteen months on ride history covers the current year and the one before it — long enough to answer “was my child on the bus that day?”, short enough that a breach exposes that rather than a school’s entire history. If your organisation’s own retention policy specifies a different period for transport records, it takes precedence and we will match it.

Where an organisation is a school, most passengers are children, and the ICO’s Age Appropriate Design Code applies. Three things follow, all of them already true of the system:

• No profiling, no advertising, no nudges, nothing designed to extend engagement. It is a bus timetable.
• Collection is the minimum that runs a route. There is no field anywhere for a child’s health, and the box that used to ask why a child was absent was removed for the same reason.
• Retention is justified rather than indefinite, which is what the Code asks for.

Under UK GDPR you can ask for a copy of your data, ask for it to be corrected or erased, object to processing, or ask for it to be restricted.

Ask your organisation first. For records they control, they are the ones who must answer, and they are the ones who can verify that a request really comes from you — a check we cannot make from a login alone. Their administrators have export and erasure built into their console.

Staff using the driver app can start this from Account → Request account deletion, which notifies their organisation’s office. It does not delete the account on the spot: an account erased mid-term would take the runs assigned to it with it, so a person makes that decision.

For anything we control ourselves, write to hello@spudbus.com. If you are unhappy with how a request was handled you can complain to the Information Commissioner’s Office at ico.org.uk.

Access is separated by organisation at the database itself, not only in application code, so a bug in a screen cannot expose another organisation’s records. Traffic is encrypted in transit. Administrative actions are logged with the person who took them.

No system is beyond compromise. If a breach affects you, we will tell your organisation without undue delay so they can meet their own 72-hour duty to report it.

Our servers record requests — timestamp, endpoint, response, request identifier, and the account making the call — to investigate faults and abuse. Location coordinates, credentials and access tokens are kept out of these logs deliberately.

This website sets no advertising or analytics cookies. Signing in sets a session cookie, which is what keeps you signed in.

Material changes will be notified to organisations using the platform before they take effect. The date at the top of this page is the last revision.