Privacy Policy

Your school is the data controller. It decides which children are enrolled on which route, which staff may see the roll, which guardians are contacted and what they are told.

Fleetr Edge Technologies Ltd is the data processor. It provides and runs School Run for your school and processes personal data only on the school's documented instructions, under the Data Processing Agreement.

Loopy Labs Ltd is a sub-processor. It develops School Run and manages the infrastructure it runs on, which gives its named engineers technical access to production. It does not deal with schools, guardians or children directly. It is listed in full on the sub-processors page.

This policy describes the processing that happens inside School Run. It does not replace your school's own privacy notice, which covers everything else the school does with a family's information.

About a child

• First and last name, and an admission number if the school records one.
• Class or stream name.
• The bus route assigned to the child and the name of the stop they use.
• Enrolment status — whether the child is currently riding, or has left the service.
• A photograph, if the school uploads one. Optional; many schools never do.
• Boarding and alighting events: the run, the stop, the time, who confirmed it, an optional note, and the bus's position at that moment. These are append-only — a correction is a new entry, never an edit over the old one.

About a guardian

• Name, and a phone number and/or an email address.
• Which children they are linked to, the relationship, and whether they are the primary contact.
• Account credentials — a password hash, or a passkey if they register one. Passwords themselves are never stored.
• Notification preferences, and a log entry for each message sent to them.

About school staff

• Name, email address, phone number, role (administrator, transport manager or matron) and account status.
• Account credentials, as above.
• A record of the actions they take that matter later: which attendance entries they confirmed, and which reports they exported.

About buses and drivers

• Vehicle registration and identifying details, and the driver assigned to a bus, mirrored from the school's core Fleetr account.
• The latest reported position of each bus — latitude, longitude, speed, bearing, ignition state and the time of the fix.

Technical data

• Session records, which include the IP address and browser user-agent of a signed-in device.
• Cookies: a session cookie, a cross-site-request-forgery token, and a "keep me signed in" cookie if that box is ticked. All three are strictly necessary. School Run sets no analytics, advertising or tracking cookies of any kind. The light/dark preference is kept in the browser, not in a cookie.
• Application error and delivery logs. Message bodies and provider credentials are deliberately kept out of them.

• From the school. Children, guardians, routes and stops are entered by school staff, either one at a time or by uploading a spreadsheet.
• From the bus. A matron or driver confirms each child at each stop, in the app.
• From core Fleetr. Bus positions arrive as signed webhook events from the school's own Fleetr fleet-tracking account, which in turn receives them from the GPS device fitted to the vehicle. School Run verifies the signature on every event and rejects anything it cannot verify.
• From the person. A guardian or staff member can update their own name, contact details and password on their account page.

School Run buys no data, and it enriches nothing from third-party sources.

• To run the school's bus service: building routes and stops, planning runs and producing a manifest for each bus.
• To take and keep a school run, so the school can answer who was on which bus, on which day, and who said so.
• To show school staff where the school's buses are.
• To notify a child's own guardians when the bus is approaching their stop, when the child boards or alights, and when a run is delayed or a route changes.
• To alert school staff to operational problems, such as a bus that has stopped reporting or a run left open.
• To let guardians sign in and see their own children's status and history.
• To secure the service — authentication, rate limiting and audit trails.

School Run does not use this data for marketing, does not sell or rent it, does not share it with advertisers, and does not use it to train machine-learning models.

There is no automated decision-making with legal or similarly significant effects. In particular, attendance is never inferred from GPS: telemetry can move a run along and name the stop a bus is standing at, but only a named person can record that a child boarded or alighted.

The lawful basis is the school's to determine, because the school is the controller. Fleetr Edge Technologies Ltd does not choose it and cannot rely on one of its own. Under section 30 of the Data Protection Act 2019, the bases a school normally relies on for School Run are:

• Performance of a contract — the transport service the school agreed to provide to the family. This covers the roll call, the manifest and the notifications a parent signed up for.
• Legitimate interests of the school in operating a safe bus service and in being able to account for a child afterwards, balanced against the interests of the child.
• Consent, where the school has chosen to rely on it — most commonly for a child's photograph, which is optional in School Run precisely so a school can leave it out.
• Vital interests, in an emergency where a child's location has to be established.

Where a school relies on consent, the school obtains and records that consent. School Run does not collect it and does not evidence it, so a school that relies on consent should keep that record in its own admissions process.

Most of what School Run holds is about children, and section 33 of the Data Protection Act 2019 sets a higher bar for it: processing must safeguard the best interests of the child, and requires the consent of a parent or guardian. Meeting that bar is the school's responsibility as controller. These are the things the software does to make it easier to meet:

• A guardian sees only their own children. Every guardian-facing page is checked against the child–guardian link on each request; there is no school-wide list a parent can reach.
• Parents never see the roll. The attendance records surface — which shows where children were and who handled them — is staff-only on the route and again in every request that reaches it.
• Notifications reach the guardians of that child only. A message about one child is never sent to another family, and the message names the child and the stop and nothing more.
• Photographs are private. A child's photograph is never served from a public address. It is stored on a private bucket and read back through the application, which re-checks who is asking on every single fetch.
• Children have no accounts. School Run has no pupil login and collects nothing from a child directly.
• A child who leaves is marked as left, not deleted, so the history the school may need later is not silently destroyed. Deletion is a decision the school takes deliberately.

Within a school, access follows role: administrators and transport managers run the service, matrons take the roll on their own bus, and guardians see their own children. Schools are separated from one another in the database and no school can see another's data.

Outside the school, data reaches only the parties listed in the sub-processor list, each engaged for a single, stated purpose. Two of them deserve naming here:

• Your school's own SMS gateway. Text messages to parents go through a provider the school chooses and contracts with, configured in the school's own settings. The message — the child's name, the stop, the time, and the parent's phone number — passes through that provider. Fleetr Edge Technologies Ltd has no agreement with it and cannot make commitments on its behalf. Choosing that provider, and having a written processor agreement with it, is the school's responsibility.
• Core Fleetr. Bus location comes from the school's own Fleetr fleet-tracking account. School Run also embeds core Fleetr's live tracking page for a bus, and share links to that page are issued from the bus's own page and can be revoked there.

Data may also be disclosed where the law requires it — a court order, or a lawful request from a competent authority. Fleetr Edge Technologies Ltd will refer such a request to the school and will not answer it on the school's behalf unless it is legally forbidden from doing so.

The School Run application and its PostgreSQL database run on infrastructure operated by Fleetr Edge Technologies Ltd. Uploaded files — children's photographs on a private bucket, school crests on a public one — are held in S3-compatible object storage in the region the deployment is configured to use.

Some of that infrastructure is outside Kenya. Section 48 of the Data Protection Act 2019 permits a transfer outside Kenya where there are appropriate safeguards, or where the transfer is necessary for the performance of a contract. The current regions and providers, and the safeguard relied on, are set out in the sub-processor list and in clause 8 of the Data Processing Agreement. A school that requires data residency in Kenya should raise it before signing.

Every period, and — just as importantly — whether a scheduled job actually enforces it, is set out in the retention schedule. That page is deliberately explicit about which periods are enforced automatically and which are not yet, so that nothing here is a promise the software does not keep.

In outline: the notification log expires after a fixed period and is deleted nightly; exported files are deleted after a week while the record of who exported them survives far longer; and the attendance record itself is kept for as long as the school needs to answer for it. Read the schedule for the actual numbers.

• All traffic is over HTTPS.
• Passwords are hashed with bcrypt. Passkeys are supported as a phishing-resistant alternative.
• Each school's data is separated by a database-level scope that fails closed — a query with no school in context returns nothing rather than everything.
• The largest tables are physically partitioned per school.
• Authorisation is enforced on the route and again in the request handler, so a URL typed directly is refused before any page renders.
• Children's photographs are stored privately and re-authorised on every fetch.
• Records are encrypted at rest on the hosting provider's storage, and every request to School Run travels over HTTPS.
• An SMS gateway's credentials are encrypted at rest, hidden from API output, and never written to a log.
• Message bodies are never logged. The notification log keeps a short summary line, a masked recipient and a delivery status — not the wording sent.
• Webhooks from core Fleetr are authenticated by HMAC signature with a timestamp tolerance; unsigned or stale deliveries are rejected.
• Sign-in, invitation and SMS-test endpoints are rate limited.
• A school's outbound endpoint is checked against a guard that refuses private and internal network addresses.
• Attendance is append-only. There is no route anywhere in the application that edits or deletes an attendance entry.

No system is perfectly secure. If a personal data breach occurs, Fleetr Edge Technologies Ltd notifies the affected school without undue delay so the school, as controller, can meet its own obligation to notify the Office of the Data Protection Commissioner and, where required, the people affected.

Under Part IV of the Data Protection Act 2019, a data subject — a guardian, a member of staff, or a child acting through a parent or guardian — has the right:

• to be informed of the use to which their personal data is put;
• to access the personal data held about them;
• to object to the processing of all or part of it;
• to correction of false or misleading data;
• to deletion of false or misleading data about them;
• to receive their personal data in a structured, commonly used format, where that right applies; and
• not to be subject to a decision based solely on automated processing which produces legal effects — a right School Run does not engage, because it makes no such decisions.

These rights are not absolute. A school may refuse deletion of an attendance record that is accurate, because it is the school's evidence of how a child was handled on a given day and may be needed to answer a later question about that child's safety.

Address the request to your school. The school is the controller and holds the record. Write to the school's transport office or its data protection contact, saying who you are, which child the request concerns if it is not about you, and what you are asking for.

Section 26 requests must be answered by the controller within the timeframes set out in the Act and its regulations. The school may need to verify your identity and your relationship to the child before answering — the answer to "where was this child" cannot be given to someone who has not been checked.

If a school needs help retrieving or exporting data in order to answer a request, Fleetr Edge Technologies Ltd assists as set out in clause 10 of the Data Processing Agreement. Fleetr Edge Technologies Ltd does not answer a data-subject request directly: a request sent to it is referred to the school.

Complain to the school first — it is the controller, and most questions are answered fastest there.

You also have the right to lodge a complaint with the Office of the Data Protection Commissioner (ODPC), Kenya's supervisory authority, at odpc.go.ke.

Material changes are notified to subscribing schools in advance, in writing, as required by the Data Processing Agreement. The effective date at the top of this page is changed only when the text changes.

Parents and guardians: contact your school's transport office. The school holds your child's record and answers for it.

Schools: Fleetr Edge Technologies Ltd can be reached at hello@fleetr.co.ke.