RouteRound Privacy Notice

Last updated: 10 August 2026 Applies to: the RouteRound app, the client portal, and the RouteRound marketing website.

1. In one paragraph

RouteRound is a job-scheduling app for field-service businesses. Two very different kinds of people read this notice, and we hold their data in two very different ways:

If you subscribe to RouteRound (you are the contractor, the business paying for it), we hold your account details and we look after the data you put in. For your account details we are the "controller" — we decide what to do with them. For everything you type or photograph in the app about your staff, your customers and their sites, you are the controller and we are only the "processor": we hold it and move it around on your instructions, and we do not use it for our own purposes.
If your details are in RouteRound because a contractor put them there — you are one of their staff, one of their customers, or a facilities manager logging into the portal — then that contractor is responsible for your data, not us. Ask them first. Section 13 tells you what to do if you can't get an answer. There is exactly one exception, and it runs the other way: if you use the portal to invite another firm onto your page, those introduction records are ours to answer for, not your contractor's — section 3.5.

2. Who we are

Desultory Ltd, 133 Berrall Way, Billingshurst, England, RH14 9PQ (registered in England and Wales, company number 17361684).

Contact for anything in this notice: privacy@routeround.co.uk.

ICO registration number: 00015711872. You can check it yourself on the ICO's public register of fee payers at ico.org.uk/ESDWebPages/Search.

We have not appointed a statutory Data Protection Officer. We are not required to. privacy@routeround.co.uk reaches the person responsible for data protection.

3. What we collect, and where it comes from

3.1 Your subscriber account (we are the controller)

What	Where it comes from
Email address	You type it when you sign up or sign in
Password	You choose it. It is handled by our authentication provider and stored as a hash — we never see or store the password itself
Your organisation's name ("workspace" name) and the role of each member (owner / admin / field)	You set it in the app
Invitation records when you invite a colleague: their email address, the role you gave them, an invite token, when it expires, when it was used, which account sent it and when it was created	You type the email; the app generates the rest
A short description of the device — the first 120 characters of your browser's user-agent string. It is stored on the current backup and on every retained snapshot of it, so it amounts to a short history of which devices saved your data	Captured automatically each time your data is backed up, so you can tell which device saved last
The account id of the member who saved each retained snapshot. On a shared workspace this records which member pushed which backup, and when	Captured automatically each time a backup is saved
The time your data was last backed up, and the time each retained snapshot was saved	Automatic. Nothing records a restore — the software does not log when a backup is restored, so we cannot tell you that even if you ask
Your subscription record: a Stripe customer id, a Stripe subscription id, the subscription status, the price id, the renewal date, and whether you have cancelled	Created the first time you tap a billing button — Subscribe or Manage billing — and not when you actually pay. At that moment we create a Stripe customer for you and store its id, even if you abandon checkout without entering a card. Then kept up to date automatically from Stripe. We hold no card details

3.2 What you put into the app (we are the processor; you are the controller)

Everything below sits in your own local copy of the app on your device, and — only if you sign in to a RouteRound cloud account — is also copied to our cloud backup so you can reach it from another device or share it with a colleague. If you never sign in, none of it leaves your device except where sections 5 and 6 say otherwise.

Sites and customers

Site name, site code, type of asset, service, postcode, full address, what3words address, latitude and longitude
Access notes — this is a free-text field, and in practice it holds gate codes, key-safe codes, parking instructions, hazard and dog-on-site warnings
Your customer's name, contact name, contact phone number, contact email address
Whether the site is active, how often it is visited, required qualifications, tags, and the result of any tree-preservation-order check

Customer records, separate from the sites

A record for the customer as an organisation: their name, a contact name, contact email address and contact phone number, and a free-text notes field — this sits over and above the contact details held on each site
Compliance requirements recorded against a customer or against a site: the name of the thing a worker must hold, what kind of thing it is, and a free-text note giving the detail. The kinds the app offers are certificate, site induction, vetting or clearance, permit and briefing
Being direct about that middle one, because it matters more than the others: the "vetting" kind is there for things like a DBS Basic or Enhanced check, NPPV, BPSS or CTC clearance, and the app's own example prompt in that field reads "e.g. DBS Enhanced". A record that a named individual holds — or is required to hold — a criminal-records clearance is personal data relating to criminal convictions and offences under Article 10 UK GDPR, which carries its own conditions. Section 8 says what that means for a subscriber who uses the field that way

Jobs (visits)

Date, category, job type, status, due date, completion time and free-text notes
GPS check-in and check-out: latitude, longitude, accuracy in metres and a timestamp, recorded when a worker taps to check in or out on site
Photographs taken before and after the work — these are photographs of private property
Checklists, the reason a job was skipped, notes written for the customer, and a record of any job completed with paperwork outstanding — that record is the time, the list of documents that were outstanding, and a free-text reason if one was typed. It does not name the person who overrode the paperwork; the software does not record that, so nobody should treat the override note as identifying an individual
Which staff members were logged as on site

Safety and compliance paperwork

Point-of-work risk assessments: hazards, controls, the assessor's name, their drawn signature and the sign-off time
Waste transfer notes: waste description, EWC codes, quantities, the names, addresses and permit numbers of the business handing waste over and the business receiving it, waste-carrier registration numbers, transfer place and date, and the drawn signatures of both parties
Equipment and vehicle checks: the check items, defects found, vehicle registration, odometer reading, the operator's name and their drawn signature
Custom forms you build yourself: whatever fields you choose to add, including free text, photos and signatures

Your staff register

Name, role, email address, phone number
Qualifications: the name of the ticket or card, its expiry date, notes, and a photograph or scan of the certificate or card itself

Money

Quotes and invoices: reference numbers, customer name, line descriptions, quantities, prices, VAT rate, PO numbers, payment terms, and the dates issued and paid

Stock

Chemical and consumable records including product names, MAPP numbers, active ingredients, quantities held, and a ledger of every use linked to the job and the spraying record that consumed it

Your business settings

Company legal name, address, SIC code, waste-carrier licence number and expiry, logo, phone, email, website
Depot label, postcode, address and coordinates
Your saved signature image and signatory name
Saved email addresses you send completion reports to
The list of customers you share a schedule with, and their portal email addresses

3.3 The client portal (we are the processor; the contractor is the controller)

If a contractor shares a schedule with you, we hold:

Your email address, and your name if the contractor entered one
When you first signed in and when you last signed in
Whether your contractor set an initial password for you, when they did it, which of their accounts did it, and whether you have since replaced it with one of your own. We never store the password itself — not the one they set and not the one you choose; only the dates, so the software knows to stop offering you a password you have already replaced, and so a password set by a contractor who later closes their account can be retired automatically
Other people at your organisation that you have added to your portal account, their email addresses, whether they are an owner or a member, when they were added, and the email address of whoever invited them — that last one is deliberately kept as an audit trail the portal account's owner can read
A read-only mirror of the schedule the contractor publishes: site names, full addresses, postcodes, visit dates, job status and category
Records of jobs completed for you: site name, completion time, which safety paperwork was done, and how many photographs were taken
Any request you send the contractor through the portal: the site name, postcode, address, your notes and any date you asked for

If your contractor gave you a password, they know it. A contractor can set an initial password on your portal account and read it out to you, so you can sign in straight away instead of waiting for an emailed link. Two consequences, said plainly because they are not obvious: the account was created for you rather than by you — a contractor deciding to share is what brings it into existence, and you were never asked — and until you replace that password, the person who set it still knows it. Nothing forces you to change it, and there is no need to if you only use it here. If you have used that same password anywhere else, change it, either from "Forgotten your password?" on the portal sign-in page or from the notice shown when you sign in.

Two things we do not allow, because they would make this a way of taking over somebody's account rather than a convenience: a contractor cannot set a password on an address that already has its own RouteRound subscriber account, and cannot set one on an address that has been invited to join a RouteRound account and has not yet accepted. Both are refused outright.

When a contractor closes their RouteRound account, any password they set that you have not replaced is changed to a value nobody has, so a former contractor cannot keep signing in as you. Your account itself survives — other contractors may still be sharing with you — and you get back in with a login link or "Forgotten your password?".

What the schedule mirror actually contains, which is not what most people assume. The share is scoped to the contractor's team, not to you. When a contractor publishes to your portal, the software copies across every active site on that team and its dated visits — including the site names, full addresses and postcodes of that contractor's other customers, if any of them are on the same team. Your name on the share is the label on your login, not a filter. The software does not separate one customer's sites from another's; the only way a contractor can keep two customers from seeing each other's sites is to put them on separate teams, which is a decision they have to make and which nothing in the app makes for them.

We are setting this out here because it is the largest disclosure of personal data the product makes and it is easy to miss from either side. If you are a portal user, you may be seeing addresses that are nothing to do with you. If you are a contractor, you are the controller of that disclosure and it is yours to justify to your customers — please check which team each shared client is on before you publish.

We also create a sign-in account for your email address at the moment a contractor first shares with you, so that the magic link works when you click it. Section 11 explains what happens to that account afterwards, because the answer is not what most people assume.

3.4 Technical data

IP address. Our tree-preservation-order lookup uses the calling IP address to apply a fair-use limit. Our hosting and database providers also log IP addresses as part of running the service.
Our own server-side error logs. Separately from the providers' request logs, when one of our server functions fails it writes the error and its stack trace to the hosting platform's log. We deliberately return only a generic message to the browser so that database detail is not handed to whoever triggered the error — but that detail does reach the log, and a database error can carry column names, constraint names and sometimes values from the row that failed. These logs are not read routinely; they are read when something is broken. How long they survive is our suppliers' answer rather than ours, and the two publish it very differently. Supabase gives a figure per plan for its API and database logs — one day on Free, seven days on Pro, twenty-eight on Team, ninety on Enterprise. Netlify publishes no per-plan figure at all: its documentation says only that function logs are kept for at least 24 hours and shown for up to seven days, with the exact period depending on the plan, and its pricing page does not break that down. Both checked on 10 August 2026.

Our plans, so you can read those figures against something concrete: the Supabase project is on the Free plan, so its API and database logs are kept for one day. Netlify is on the Pro plan, whose function logs fall inside the "at least 24 hours, shown for up to seven days" range Netlify publishes without breaking it down further. If we move plans we will update this line; a longer log retention is a change in how long your data survives, and it should not happen silently.
Storage on your own device. RouteRound works offline, so most of what it holds sits in your browser rather than on our servers. Section 4 lists that in full.

3.5 Introducing another firm to your portal (we are the controller)

If you use the client portal, you can create a link that invites another firm working on your sites — a fencing contractor, a drainage firm, whoever else turns up — to publish their dates onto the same page. You send that link yourself, from your own email or WhatsApp. RouteRound does not send it, does not chase it, and does not send a reminder afterwards. We could not do any of those things if we wanted to, for the reason set out under the table below.

What we hold for each link you create:

What	Where it comes from
Your own private label for the firm you are inviting ("Dave's Tree Care"), so you can tell several live links apart. It is never shown to them and never leaves your account	You type it
The name you want them to see — normally your name and your organisation's, "Sarah Jenkins, Acme Facilities Management"	You type it; we suggest the label already on your share
One optional line of your own text shown to them, such as "for the Cheltenham sites"	You type it
The email address of whoever on your portal account created the link	Taken from your sign-in, as an audit trail, and re-checked when the link is opened so that removing someone from your portal account also kills the links they created
A random single-use token — the `?t=…` on the end of the link — and the date the link stops working	Generated by us
Timestamps: when you created it, when it was first opened, when it was claimed, when you withdrew it, and when you recorded that the firm said no	Automatic, except the last one, which only the owner of your portal account can record — never the firm you invited, and never us

We store no email address, no contact name and no phone number for the firm you are inviting. This is not a policy we apply, it is a shape we built: the table has no column to put them in. It follows from you sending the link yourself — we never need a way to reach that firm, so we never ask for one and never hold one. The practical effect is that if you invite a firm and they never reply, the only trace of them anywhere in RouteRound is the label you typed for your own list.

Three further things we would rather state than let you infer:

"Opened" is one timestamp, and it does not tell us who. Mail scanners and link previewers open links on their own, so the portal says the link was opened, never that a particular person read it. No IP address, no count and no browser is recorded against it — there is nowhere to put them either.
If the firm accepts, we record which RouteRound account accepted, and when. That is an internal identifier for the account and for the firm it belongs to, not anything they typed for you. From that moment they are a RouteRound subscriber in their own right, and section 3.1 describes what we hold about them.
Other people on your portal account can see the list, including your private labels — the same people who can already see the schedule. They can only read it: creating a link, withdrawing one, recording a refusal and deleting a record are all reserved to the owner of the portal account, and the software refuses the others rather than merely hiding the buttons. The contractor whose schedule you are reading cannot see any of it, and no invited firm is ever told that another firm was invited.

We are the controller of these records, and your contractor is not. Everywhere else in the portal the position is the other way round (section 3.3): the contractor decides and we process. Introductions are ours — your contractor did not ask for them, cannot see them and has no say in what is held — so the responsibility is ours too, and you should bring any question about them to us rather than to them. Our lawful basis is in section 8.

How long we keep them: 120 days from the day you created the link, used or not. Then the honest part, in the same spirit as the backup pruning in section 11: that clear-out is not a scheduled job. It runs opportunistically, as a side effect of somebody, somewhere, opening or claiming an introduction link — so on an installation where nobody uses the feature at all, nothing sweeps and old rows stay until somebody does. Your own deletion does not depend on it: the owner of the portal account can delete any introduction from it at any time — the same person who created it, and the only person who can withdraw one or record a refusal. If you are on the account but are not its owner you can see the list and not change it, so ask the owner, or email privacy@routeround.co.uk and we will remove the record for you. Either way it goes; the difference is only who presses the button.

4. Information stored on your device

UK law (regulation 6 of the Privacy and Electronic Communications Regulations) covers anything stored on or read from your device, not only cookies. Here is everything RouteRound puts there.

Where	What	Why
IndexedDB (the browser's database)	One database per account that has signed in on this device, plus one for use without an account. Each holds that account's entire working dataset: sites and access notes, jobs, photographs, drawn signatures, risk assessments, waste transfer notes, custom forms, your staff register and their certificate scans, your customer records and their notes, the compliance requirements recorded against a customer or a site (see section 3.2 on the vetting/clearance kind), quotes and invoices, stock records, and a cache of postcode/coordinate lookups you have already done	This is the product. RouteRound is offline-first: a van in a field with no signal reads and writes here, and the cloud copy is a backup of it, not the other way round. Separate databases are what let several people use one shared computer without seeing each other's work — and it means signing one account out no longer removes the others
Local storage	The signed-in session, if you use a cloud account — an access token, a refresh token, and the account record they belong to, which includes your email address. It is written when you sign in and stays until you sign out, so you are not asked to sign in again every time you open the app	Keeping you signed in
Local storage	Your theme choice (`rr-theme`: light, dark or follow the system) and your trade colour palette (`rr-trade`)	So the right theme is applied before the first paint instead of flashing the wrong one
Local storage	A flag recording that you chose "Continue without signing in" (`rr_auth_skipped`)	So a field worker who works offline is not shown the sign-in gate on every launch
Local storage	Two sync markers per account: how far this device has synced (`rr_cloud_synced…`, a timestamp) and which photo/signature/certificate files it has already uploaded (`rr_blobs_up…`, a list of internal file ids). Removing one account leaves another account's markers alone	So a routine sync sends only what is new instead of re-uploading everything
Local storage and IndexedDB	Which account this browser is currently showing, and a list mapping each account to its database (`rr_active_user`, `rr_db_map`, and a small `routeround_registry` database). This includes your account's internal user id — not your email	So the app opens the right account's data, and so that clearing one kind of browser storage cannot strand the other and make your work look deleted
Local storage	An introduction token and the time it was saved (`rr_intro_token`), if you opened a link a customer sent you asking your firm to publish its schedule to their portal (section 3.5). It is ignored once it is 24 hours old, so a stale invitation left on a shared van phone is not a live one	So the invitation survives signing up and confirming your email address — the confirmation link usually opens in a different tab, or a different browser, where session storage is empty by definition
Local storage	A team-invite token and the time it was saved (`rr_join_token`), if you opened a link inviting you onto somebody's RouteRound team. It is ignored once it is 24 hours old, so a stale invitation left on a shared van phone is not a live one	So the invitation survives signing in — on a phone the app is closed and reopened between the link arriving and you getting round to it, and session storage does not survive that
Local storage	A flag that you have dismissed the one-line prompt offering help if you arrived from a customer's introduction link (`rr_intro_hint_seen`). It is the character `1` and nothing else — no token, no customer, no date, no record of whether you ever accepted anything	So a prompt you have already waved away does not reappear every time you open the app
Local storage	If you use the client portal, which contractors' schedules you last chose to look at (`rr_portal_focus`). It is our internal identifiers for those firms, not their names — one identifier if you narrowed the calendar to a single firm, or several separated by commas if you narrowed it to a few — and it is removed when you switch back to showing all of them	So someone looking after a site through several firms is not made to re-pick the ones they are chasing on every visit
Local storage	If you use the client portal, how much detail you asked the calendar to show (`rr_portal_density`). One word describing a view setting — it names nothing and nobody	So a board with several firms' work on it stays at the density you chose, rather than resetting every morning
Session storage (cleared when you close the tab)	The words your customer typed for her own organisation when you accept an introduction link — for example "Sarah Jenkins, Acme Facilities Management", which may well include a person's name — together with whether your own schedule was empty at that moment (`rr_intro_welcome`, section 3.5). This is the one item in this table that is somebody else's personal data sitting on your device. It is written once, at the moment you accept, so that the screen you land on can name the customer who asked you instead of saying "someone"; it is removed as soon as you dismiss that message, and in any case when you close the tab	So the next screen can tell you who is waiting for your dates and what to do about it, which is the whole point of the message
Session storage (cleared when you close the tab)	A flag that you have seen the welcome screen (`rr_welcome_seen`), and a flag that a portal user has waved away the question about how many firms work on their sites (`rr_portal_expect_dismissed`)	So neither the welcome screen nor that question reappears all session
Service worker cache	A copy of the application itself — code, styles, icons. No personal data	So the app opens and runs with no signal

No consent banner, and here is why. Every item above is strictly necessary to provide the service you asked for, so the exemption in regulation 6(4) applies and consent is not required. We therefore do not show a cookie banner — not because we forgot, but because there is nothing here that needs one. There are no analytics, advertising, tracking or measurement cookies of any kind, and no third-party analytics or tracking code anywhere in RouteRound. We do not profile you, and we do not sell or share anything for advertising.

What a local wipe actually clears. There are two different removals, and the difference matters on a shared computer. Being precise, because "wipe" is a word people trust:

"Sign out and remove this account" — also what runs when you delete your account.

Cleared: that account's IndexedDB database (all of the data in the first row above, including cached photographs and signatures), that account's two sync markers, its entry in the account list, and any unspent team-invite token (rr_join_token).
Not cleared: any other account's data on the same computer, including data saved before anyone signed in. That is deliberate — one person signing out of a shared laptop must not delete a colleague's work — but it does mean this button no longer empties the machine.
Not cleared by the wipe itself: your theme and trade preferences, the "continue without signing in" flag, the dismissed-prompt flag (rr_intro_hint_seen), which contractors a portal user last chose to look at (rr_portal_focus), how dense they asked the calendar to be (rr_portal_density), and an unused introduction token (rr_intro_token), which is ignored once it is 24 hours old in any case. These are settings and one-shot markers, not records about you or anyone else. The second button below removes them.
The session: both paths that offer the wipe sign you out first, and signing out is what removes the session token and the account record it holds. The wipe routine does not remove them on its own.

"Remove all RouteRound data from this computer" — for a machine you are selling, returning or handing on.

Cleared: every account's database, the account list, all rr_ browser storage including the theme, trade and sign-in-skip settings, and all session storage.
Not cleared: the service worker cache of the app's own code. It holds no personal data.
Not backed up first. Some of what it removes may belong to accounts you cannot sign into, so nothing unsynced can be recovered afterwards.

How long another account's data stays on a computer. Until someone removes it with one of the two buttons above. RouteRound does not age it out on a timer, because a seasonal or part-time worker returning after months would find their round gone. If a computer is shared, treat "Remove all RouteRound data from this computer" as part of handing it on.

To remove absolutely everything including the cached app code, clear the site's data in your browser settings as well.

5. Who we share it with

We do not sell data and we do not share it for anyone else's marketing.

We use a small number of suppliers who process data on our behalf, listed in full — including exactly what reaches each one — in our sub-processor list. In summary:

Supabase — the database, sign-in system and file storage behind cloud accounts and the portal. Its sign-in system also sends its own emails — sign-in links, sign-up confirmations and password resets — which is a separate mail path from the one in the Resend bullet below and does not depend on it.
Netlify — hosting for the app and the small server-side functions.
OpenStreetMap — supplies the background map on the tree-protection checker, and only there. When a user taps "Show the boundary on a map", their browser fetches map tiles directly from tile.openstreetmap.org, which tells the OpenStreetMap Foundation the approximate location being looked at and the browser's IP address. Nothing else is sent — no site name, no customer, no account. It is behind a button rather than loaded automatically, precisely so that checking whether a tree is protected does not disclose where you are unless you ask to see the map. No key or account is involved, and no cookie is set. The protection data itself comes from the Planning Data platform via our own server, not from OpenStreetMap.
Stripe — takes payment for the Pro subscription. Stripe receives your own email address and an internal identifier for your RouteRound account as soon as you tap Subscribe or Manage billing — before any payment, and whether or not you ever go on to buy anything — plus whatever billing address and card details you enter into Stripe's own hosted checkout and customer portal. Card numbers never reach RouteRound: we store only a Stripe customer id, a subscription id, the status, the price id and the renewal date. Nothing about your staff, your customers or their sites is sent to Stripe. Stripe keeps its own customer and invoice records under its own retention rules, and deleting your RouteRound account does not delete them — section 12 sets out what that leaves behind and how to ask us to deal with it.
Resend — sends our emails: schedule-change notices, completion reports and team invitations. A completion report carries far more than most people expect, and it arrives in two parts. The attachment, on the normal path, is not the photographs — it is completion-report.pdf, a page-image of the entire Proof-of-Service sheet exactly as it appears on screen. That carries, on top of the site name and code and what was done: the site's full address, postcode and what3words; the customer's contact name and phone number; the GPS check-in coordinates to five decimal places (about a metre) alongside the times the crew arrived and left; the free-text job notes; the waste-transfer counterparties' names, addresses and permit numbers; the vehicle registration and odometer reading; the before-and-after photographs; photographs or scans of staff qualification certificates; and every drawn signature — client acceptance, risk-assessment assessor, waste-transfer transferor and transferee, and the operator who signed an equipment or vehicle check. The before-and-after photographs are attached instead of the PDF, and only in the rare case where generating it fails. The email body goes every time either way, and it names the staff who were logged as on site, with each of their certificates by name and expiry month — shown in red and marked EXPIRED where it has lapsed — alongside the site postcode, the EWC waste codes, the skip reason, the paperwork-override banner and its free-text reason, and the free-text notes on the work done. The contractor picks the recipients, up to five per report, and in practice that usually includes their customer. Section 9 says what subscribers should do about that. If Resend is not configured for an installation, none of those emails are sent — but that is not the same as no email at all, and we would rather say so than let the sentence be read that way: Supabase Auth still sends its own, whether or not Resend is configured — the client-portal sign-in link (without which the portal cannot be entered at all), the contractor magic link, the sign-up confirmation and password resets.
Google Maps — the mapping and address-lookup integration would be used for maps and for turning an address into coordinates, but only if a Google Maps key is configured, and none is. Checked against the live production build on 31 July 2026: with no key the code makes no call at all, so no address, postcode or coordinate is sent to Google by the app itself and none of Google's code runs in your browser. postcodes.io does the geocoding instead. The code path still exists and would start working if a key were ever added, so this line has to be re-checked if one is. This is separate from the "Navigate" buttons, which are ordinary links you choose to open — section 6 explains what those carry.
what3words — would convert between coordinates and three-word addresses, but only if a what3words key is configured, and none is. Checked against the same build: the key is the only credential in the request, so with no key there is no request, and no coordinates and no three-word address are sent. Re-check this line if a key is ever added.
postcodes.io — a free UK postcode lookup, used when there is no Google Maps key. Your browser sends the postcode or address text you are searching for.
Open-Meteo — a free weather service, used for the weather overlay on the planning board. Your browser sends the coordinates of the place you are looking at.
planning.data.gov.uk — the government's national planning data platform, used by the tree-preservation-order checker. The check runs on our server, and sends the coordinates of the site being checked.

One recipient that is not a supplier, and that the list above would otherwise hide. Where a contractor shares a schedule with more than one customer on the same team, each of those customers receives the whole team's active site names, full addresses and postcodes in their own portal — including the sites belonging to the others (section 3.3). That disclosure is made by the contractor, who is the controller of it, and not by us as a decision of our own. We name it here anyway, because a list of suppliers that quietly omitted the largest recipient would be a list designed to mislead.

We may also disclose data where the law requires it, or to establish or defend a legal claim.

6. Links to other sites

RouteRound opens a small number of external websites. When you follow one you leave RouteRound, this notice stops at that boundary, and the site you land on is governed by its own privacy policy. We have no control over what those sites do and we cannot answer for them.

There are three, and this is all of them:

Google Maps — the "Navigate" buttons and the day-sheet route links. These are plain links to google.com/maps, opened only when you tap one. Be aware of what the link carries: the site's latitude and longitude are in the URL (or, when a site has no coordinates saved, its postcode, or failing that its name). A whole day's route link carries the coordinates of your depot and of every stop on it, in order. So although the app makes no request to Google on its own (section 5), tapping Navigate does send that location to Google, along with whatever your browser normally tells Google about you. If that matters for a particular site, copy the address instead of tapping the button.
Council websites, from the tree-preservation-order checker. When a check returns a result, we show the responsible council and link to the council's own website. That address comes from the government's planning data platform, not from us; we check it is an ordinary web link before displaying it, and open it without passing a referrer. The link is to the council's own website and carries nothing about the job you were looking at.
The Open Government Licence page on nationalarchives.gov.uk, linked from the tree-preservation-order screens because that is the licence the planning data is published under.

7. Where your data is held

The app runs on Netlify's hosting network. Cloud accounts, the client portal database and every uploaded photograph, signature and certificate scan live in a Supabase project hosted on AWS in eu-west-3 (Paris, France).

So your data at rest is held in the European Economic Area, not in the UK. We state that plainly because a UK business buying a UK product might reasonably assume otherwise, and we do not claim UK-only hosting anywhere in this notice.

The transfer of personal data from the UK to France is covered by the UK's adequacy regulations for the EEA — the UK government has determined that the EEA provides an adequate level of protection, so no International Data Transfer Agreement, no standard contractual clauses and no transfer risk assessment are required for that leg. Nothing more is needed and we are not going to imply that we have done more.

Two things that paragraph does not settle, which we would rather name than let it cover:

Where the database sits is a different question from where a request is served. Netlify's content delivery network and our small server-side functions run on Netlify's platform, which serves requests from edge locations rather than from one place. That is not the same thing as the region the data at rest is stored in, and we do not want the answer above read as covering it.
Supplier access from outside the EEA. Where the data sits is also a different question from who can reach it, and neither of our two suppliers is the UK or EEA company the Paris answer might suggest. Our contract for the database and file storage is with Supabase Pte. Ltd, a Singapore company, whose own data processing agreement says it staffs support and monitoring on a follow-the-sun basis from employees placed around the world. Our contract for hosting is with Netlify, Inc. of San Francisco. So support and engineering access to the systems holding your data does come from outside the EEA, and what governs it is each supplier's own agreement rather than the region the database runs in. Both agreements cover that leg. Supabase's applies the EU Standard Contractual Clauses and, for UK data, the addendum the Information Commissioner issued under section 119A of the Data Protection Act 2018 (template version B.1.0). Netlify's relies first on the EU-US Data Privacy Framework and its UK Extension, and falls back to the Standard Contractual Clauses and that same Information Commissioner's addendum if the framework is struck down or Netlify's certification lapses — we have taken Netlify's word for the certification and not checked the public register ourselves. Neither is a separate agreement we had to sign: each says on its face that it forms part of the terms we are already on. Both read on 10 August 2026, at supabase.com/legal/dpa and netlify.com/pdf/netlify-dpa.pdf. The other suppliers, and what reaches each of them, are in the sub-processor list.

8. Why we are allowed to process it (lawful bases)

We do not rely on consent for the main workings of the app. Consent would be the wrong basis: you cannot meaningfully withdraw consent to your employer holding your risk assessment, and a contractor cannot run a job scheduling system on a basis their staff can revoke at will.

What we do	Our lawful basis
Run your subscriber account, sign you in, hold your data and let you reach it from your devices	Contract — Article 6(1)(b). We cannot provide what you signed up for without it
Send service emails you have asked us to send (schedule changes to your customers, completion reports, team invitations)	Contract — carrying out a feature you switched on
Keep the service secure and available: rate limiting, refusing writes that would overwrite another account, investigating abuse	Legitimate interests — Article 6(1)(f). Our interest is running a service that is not abused; this is what any user would expect
Hold the introduction links a portal user creates for the other firms working on their sites (section 3.5)	Legitimate interests — Article 6(1)(f). Two interests, and we will name both: yours, in getting the firms who visit your sites onto one page instead of ringing round; and ours, in RouteRound reaching new firms through the customers who want them on it. We think that is a fair balance because the only thing we hold about a firm that has not accepted is the label you typed for your own list — no address, no contact name, no phone number — we never contact them, and the owner of your portal account can delete any link at once. If you disagree, you can object — email us — and deleting the link is the immediate remedy
Deal with complaints, requests and disputes, and keep records to defend a legal claim	Legitimate interests, and legal obligation where a law requires the record
Comply with data protection, tax and accounting law	Legal obligation — Article 6(1)(c)

For data our subscribers hold about their own staff and customers, the lawful basis is the subscriber's to choose and record — we process on their instructions. For most of it the natural bases are contract (performing the work) and legitimate interests (running the business, proving the work was done safely), plus legal obligation for waste, pesticide and health-and-safety records. Subscribers: see section 5 of the DPA, and ask us for the retention schedule if you need it.

A note on browser permissions. When RouteRound asks for location or camera access, that is your device's permission prompt, not GDPR consent. It controls whether the feature can run at all. The lawful basis for the resulting data is the one in the table above, or the subscriber's own basis where the subscriber is the controller.

A note on special category data. RouteRound is not designed to hold health data, biometric data used to identify someone, or any other special category data. Drawn signatures are stored as images to evidence a document was signed; we do not analyse them to identify anyone. Subscribers should not upload medical records, health information about staff, or identity documents into notes, forms or certificate photos. If you do, you become responsible for the additional conditions in Article 9.

A note on criminal-records data, which is a separate thing and which the product does invite. The compliance-requirements feature (section 3.2) offers "vetting / clearance" as one of its kinds, and the example prompt in that field is "e.g. DBS Enhanced". Recording that a named person holds, or must hold, a DBS check, NPPV, BPSS or CTC clearance is personal data relating to criminal convictions and offences under Article 10 UK GDPR. That is not a special category under Article 9, but it has its own rule: you may only process it under the control of official authority or where UK law authorises it, and the Data Protection Act 2018 requires an appropriate policy document for most of the conditions a business would rely on. We do not tell subscribers not to use the field — checking clearances is a real part of the work it was built for — but if you do use it, that condition and that policy document are yours, not ours, and you should be sure you have them before you type someone's clearance status into it. Storing the outcome ("holds an enhanced DBS, expires March 2027") is a far smaller step than storing the certificate itself or any detail of what a check disclosed; do not put the latter into a note or a certificate photo.

9. Monitoring staff

RouteRound records a worker's location only at the moment they tap to check in or out of a job. It takes a single position fix at that moment. It does not track anyone continuously, does not follow a vehicle, and has no background or live-tracking mode — we have confirmed this against the source code, which uses a one-shot position request and never a continuous watch.

There is one more moment the app reads the device's position, and we would rather name it than let the sentence above be read as a complete list. The "Re-optimise from here" button on the Today screen takes a single fix so it can re-order the stops still to do starting from where the worker actually is, rather than from the depot. That fix is used to sort the list and then discarded — nothing about it is written to the database, the backup or anywhere else — so "records" above remains accurate. But it is a position read, it happens when the worker taps that button, and staff should be told about it alongside check-in and check-out.

We do not consider this to require a Data Protection Impact Assessment on our side. Subscribers should still tell their staff, in writing, that check-in and check-out record a location fix, and should assess for themselves whether their own use of it needs a DPIA — particularly if you use it to manage performance or discipline.

Two related points subscribers should know, because both are easy to miss.

Backups record who saved them. Every cloud backup records the device that saved it and, on a shared workspace, the member who saved it (section 3.1). That is a record of employee activity, however incidental, and if you use it to check up on staff rather than to recover a bad save, you should tell them.
Completion reports send staff data out of the business. When you email a completion report, the body names every staff member logged as on site and lists each of their certificates with the expiry month, marked EXPIRED in red where one has lapsed. The attached PDF carries considerably more about the same people, because it is a page-image of the whole Proof-of-Service sheet: the photograph or scan of each of their certificates, their drawn signatures, the times they arrived and left, and the GPS coordinates of their check-in to about a metre (section 5 lists the sheet in full). Those emails go to whoever you choose — usually your customer. A worker's name, their tickets, their signature and where they stood therefore leave your company and reach your customer every time a report is sent. That is a normal and often necessary thing to do in this trade, but it is a disclosure of their personal data to a third party, and your staff should be told it happens and why — including the certificate images and the location fix, which are the parts people do not expect. Not logging the crew on the visit removes the names and certificates block, but it does not remove the check-in coordinates, the signatures or the rest of the sheet from the attachment.

10. Children

RouteRound is sold to businesses and is not directed at children. We do not knowingly collect personal data about anyone under 13, and there is no part of the service intended for a child to use. If you believe a child's data has reached us, email privacy@routeround.co.uk and we will look into it.

There is one case where a child's data could genuinely appear, and we would rather name it than pretend otherwise: a subscriber's staff register can hold anyone the subscriber employs, including a young apprentice — their name, role, phone number, email address and a scan of their training card. Where that happens the subscriber is the controller, not us. It is their responsibility to have a lawful basis for holding it, to tell that person what they hold, and to answer any request about it. We only hold it on their instructions.

11. How long we keep it

The short version, and we would rather state it plainly than print a schedule describing a system we have not built. Two things the software does delete on its own:

You can delete your whole account from inside the app (section 12). On a solo account that removes your cloud backup, every retained snapshot of it, the photographs and other files you uploaded, and the data mirrored to your customers' portals. On a shared workspace it removes less than that, and the difference matters: when you are in a workspace with colleagues, your uploads go into the workspace's file storage, not your own, and the workspace — its backup, its snapshots and its files — survives you and stays with the people still in it. What is deleted in that case is your own login, your own personal backup, and the customer-portal data published from your account. Section 12 sets this out in full, including what account deletion does not reach at all.
Backup snapshots are pruned — but only at the moment a new one is pushed. The rule applied at that moment is: keep the 20 most recent snapshots for that account, plus the newest snapshot of each day for the last 30 days, and delete the rest.

Read that second point carefully, because it is not a 30-day ceiling and we do not want it read as one. Two consequences we would rather state than let you infer:

The pruning runs only as a side effect of a new backup being saved. There is no scheduled job that sweeps old snapshots. So if an account goes quiet — the contractor stops using RouteRound, or a workspace is abandoned — nothing prunes anything, and the snapshots already there stay indefinitely. A dormant account is the case where retention is longest, not shortest.
The 20 most recent are kept whatever their age. An account that backs up rarely can still be holding its twentieth-newest snapshot years later.

The honest answer to "how long is a backup snapshot kept?" is therefore: until twenty newer ones exist and it is no longer the newest snapshot of its own day within the last 30 days — which on a busy account is days, and on a dormant one may be never. Deleting the whole account (section 12) removes them all at once, and that is the only bounded answer we can give you.

Everything else is still kept until it is deleted by hand. In particular, deleting a single item inside the app does not reliably remove that item from our cloud backup or from file storage. Section 12 sets out exactly how far a deletion travels and where it stops, because the answer is more complicated than "the next sync overwrites it". The retained snapshots taken before a deletion still contain the item under the rule above; and photographs, signatures and certificate scans that have already been uploaded stay in file storage until the whole account is deleted or an operator removes them manually — the app can upload and download those files but has no way to delete one.

The full schedule, and the manual procedure we follow when someone asks to be erased, is set out in an internal retention-and-erasure procedure. Ask us at privacy@routeround.co.uk if you want to know how a particular kind of record is handled. In outline:

Your subscriber account: for as long as you have an account. If you close it, or you instruct us to delete it, we complete deletion within 30 days — the same commitment we make in clause 10.3 of the DPA. If you delete the account yourself in the app, the parts the software reaches happen immediately; the parts it does not reach — listed in section 12 — are a manual step and fall under the 30-day commitment.
Data you put in the app: for as long as your account is open, or until you ask us to delete it. Some records must legally be kept for a minimum period even if you ask us to erase them — waste transfer notes for two years, hazardous waste consignment notes for three years, and pesticide application records for three years.
Completed-job records in a customer's portal: for as long as the share exists. While a share is live, the mirrored sites and visits are re-pruned on every push to match what the contractor currently has — but the completed-job records are deliberately never pruned. That is a design decision, not an oversight: a finished job is treated as a permanent proof-of-work record, so it survives the visit dropping out of the shared window. The practical effect is that if a contractor deletes a completed job from their own copy of the app, the record of it — site name, completion time, which paperwork was done, how many photographs — stays visible in that customer's portal. Only tearing the whole share down removes it.
Portal accounts and shared schedules: removing a share deletes the mirrored schedule, completed-job records and requests for that customer immediately — and if that fails, the app says so and warns that the customer can still see the schedule, rather than reporting a revocation it did not achieve. What removing a share does not touch is the customer record itself. Their email address, their name, when they first and last signed in, and the colleagues they added to their portal account (each colleague's email address, and the email of whoever invited them) all survive the share being torn down, and nothing in the software ever removes them afterwards. Deleting your whole account does delete that record — but only for the customers you were still sharing with at the moment you deleted, and then only where no other contractor shares with them either. A customer you stopped sharing with at any earlier point is never looked at, so their record survives your account deletion too, even though by then nobody shares with them at all. In no case is the portal login itself deleted. The sign-in account we created for that customer when the first share was made is a real account in our authentication system, and it holds their email address. Nothing in the software removes it: deleting it is a manual step an operator performs, so until they do, that account continues to exist. If you are a portal user and you want your sign-in account, your customer record and your colleague list actually deleted rather than just emptied, email privacy@routeround.co.uk and ask; we will do it by hand.
Introduction links a portal user creates (section 3.5): 120 days from the day the link was created, whether it was ever used or not — but cleared out opportunistically rather than on a schedule, so on an installation where nobody uses the feature nothing sweeps and the rows stay. Section 3.5 says so plainly, for the same reason section 11 says it about backup snapshots: an unrun sweep is not a retention period. The person who created a link can delete it from their portal at any time, which does not depend on the sweep.
Your billing record at Stripe: kept by Stripe under its own retention rules, and not touched by anything in RouteRound. If you have ever tapped a billing button — Subscribe or Manage billing, whether or not you ever paid — Stripe holds a customer record with your email address and an identifier for your RouteRound account, plus whatever billing address it collected at checkout and any invoices. Read that population carefully, because it is wider than "subscribers": abandoning checkout does not undo it. Nothing in the account-deletion routine reaches it — we checked, and there is no Stripe call in that code at all — so it survives your RouteRound account until someone removes it by hand. Email privacy@routeround.co.uk and we will deal with it, bearing in mind that invoice and payment records are among the things tax and accounting law requires us to keep for a minimum period regardless of an erasure request.

12. Your rights

Under UK GDPR you have the right to:

be told how your data is used — this notice;
get a copy of it (a subject access request);
have mistakes corrected;
have it deleted, where no other law requires us to keep it;
restrict what we do with it while a dispute is sorted out;
object to processing we base on legitimate interests;
take it elsewhere (portability) where we process it by automated means under contract or consent;
not be subject to solely automated decisions with legal or similarly significant effects. RouteRound does not make any such decisions. Route ordering and scheduling suggestions are planning aids that a human accepts or ignores.

How to exercise them. Email privacy@routeround.co.uk. If you are a subscriber there are two you may not have to wait for us on — taking a copy of your data, and deleting your account outright — and both are described at the end of this section. We will respond within one month. If your request is complex we may extend that by up to two further months and will tell you why within the first month. We do not charge, unless a request is manifestly unfounded or excessive.

If your data is in RouteRound because a contractor put it there, ask that contractor first — they are the controller and the decision is theirs, not ours. But be realistic about what they can do quickly, because the software's limits are theirs too, and those limits are larger than people expect. Setting them out honestly:

They can delete your record from the copy of the app on their own device, and that much always works.
Whether the deletion travels any further is not reliable. The sync that moves data between devices merges: it adds rows and updates them, and it has no way to record that something was removed. If the contractor pushes straight from that device to the cloud, the deletion is carried up and the live cloud copy no longer holds you. But if another device is ahead, that push is refused — and the only way past the refusal is to pull and merge, which re-adds the record that was just deleted, after which the next push sends it back up to the cloud. So deleting a staff member, a customer record, a job or a document does not reliably propagate across devices, and can come back. (Marking a site inactive is the exception: that is recorded as a change to the site rather than a removal, so it does travel.)
They cannot remove you from the backup snapshots we have already retained. There is no way for anyone to delete a snapshot from inside the app. Snapshots are pruned only when a newer backup is pushed, under the rule in section 11 — which on an account that has gone quiet means not at all, indefinitely.
They cannot delete an uploaded photograph, signature or certificate scan from our file storage. The app has no delete for those files. Worse, deleting the image on one device does not keep it deleted: a pull downloads back every file in the storage folder the device is missing, so the picture reappears.
They cannot remove a completed job from a customer's portal by deleting it locally. Completed-job records in the portal are never pruned (section 11); only removing the whole share takes them down.

Erasing one individual from any of those places is a manual procedure we carry out, so your contractor may need to instruct us — and the honest answer is that the parts they control take effect at once where the sync carries them, while the rest takes us up to 30 days. If you contact us instead of them, we will pass your request on to them without undue delay and tell you we have done so, because we are not permitted to act on their data without their instruction.

Subscribers can export their own data from the app — provided your role on the account is owner or admin. Settings → Data tools → Export backup gives you a JSON file of everything in that device's database, photographs, signatures and certificate scans included. One caveat if you are on a team account, because it decides whether the file is actually complete: the export reads the device you run it on, not the cloud. Files captured on a colleague's device only arrive on yours when someone uses Pull or Restore in the app — a routine automatic sync uploads photographs but never downloads them. So if you are answering a subject access request from the office machine, pull first, or you may hand over a file missing the certificate scans taken on a van phone. If your role is field, the app deliberately hides the data tools and tells you that backups, import and export are handled by your team's office; that is a deliberate restriction, not a fault. In that case ask an owner or admin on your account, or email us and we will provide your copy — you do not lose the right just because the button is not shown to you.

Subscribers can also delete their whole account themselves, at any time, from Settings → Data tools → Delete my account. You type your account email to confirm, and we then remove your cloud backup and every earlier snapshot of it, the photographs, signatures and certificate scans held in your own storage folder, the schedule data mirrored to your customers' portals, and the login itself; this device's local copy is wiped at the same time (section 4 says exactly what that wipe clears). "Your own" is load-bearing there: if you are in a shared workspace, your uploads go into the workspace's folder rather than yours, and the first limit below explains what happens to those instead. It cannot be undone, so export first — and any record you are legally required to keep, such as a waste transfer note or a spray record, is yours to retain before you delete. If any step of the deletion fails, the request stops there and reports a failure rather than success, and you can email us to have the remainder completed by hand; we would rather leave you with a failed erasure you can retry than a confirmation we cannot withdraw. Four limits worth knowing:

A shared workspace survives you. If colleagues are still in it, we hand the workspace over rather than destroy it: ownership passes to another member — an existing owner first, then an admin, then the longest-standing member — you are removed from the membership, and the workspace's shared backup, its snapshots and its uploaded files stay with the people still using it. What is deleted in that case is your own login, your own personal backup, and the customer-portal data published from your account. If for some reason nobody can inherit, we refuse the deletion outright — the check runs before anything is touched, so nothing at all is deleted and you can put it right and try again — and we tell you so, rather than take a team's records down with your account. Email us and we will sort it out.
Portal logins are not included. As section 11 explains, the sign-in accounts belonging to your customers are real accounts in our authentication system, and nothing in the software deletes them. Removing one is a manual step. The same goes for the customer record of anyone you had already stopped sharing with: the routine only looks at shares that are still live when you delete, so an earlier customer's email address, name, sign-in history and colleague list survive as well. Ask us and we will remove those by hand too.
Stripe is not included. Nothing in the deletion routine touches Stripe, so if you have ever tapped a billing button — Subscribe or Manage billing, whether or not you ever paid — the customer record Stripe holds — your email address, an identifier for your account, any billing address it collected at checkout, and any invoices — survives your RouteRound account. Ask us and we will deal with it by hand, subject to the tax and accounting records we are required to keep (section 11).
Other devices keep their own copy. Any other device you have used holds its own local database until that device is cleared.

13. Complaints

Please tell us first — privacy@routeround.co.uk — so we have a chance to put it right.

You can also complain to the UK's data protection regulator:

Information Commissioner's Office Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF Helpline: 0303 123 1113 ico.org.uk/make-a-complaint

You can complain to the ICO without going to us first, and it costs nothing.

14. Security

What we actually do is described honestly in section 6 of the DPA. In brief: every table in our database enforces row-level security so one account cannot read another's; files are held in a private storage bucket scoped to your account or your team; the privileged database key exists only on the server and is never sent to a browser; and everything travels over HTTPS with strict transport security.

What we do not have, and will not claim: multi-factor authentication, audit logging of who read what, and any ISO or SOC certification.

If you have found a security problem, please tell us: security@routeround.co.uk, or see /.well-known/security.txt for how we handle reports.

15. If something goes wrong (a personal data breach)

A personal data breach is any security failure that leads to data being lost, destroyed, altered, or disclosed to or accessed by someone who should not have it. Here is what we commit to.

We assess it without delay. As soon as we become aware of something that may be a breach, we establish what happened, what data is involved and who it belongs to. We do not sit on it while we decide whether it is embarrassing.
We tell the ICO within 72 hours where the law requires it. For the data we control — subscriber accounts, sign-in details, subscription records — we report to the Information Commissioner within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to anyone. If we have to report late, we say why.
For the data a subscriber controls, we tell the subscriber. For everything a contractor has put into the app about their staff, their customers and their sites, they are the controller and we are the processor: our duty is to notify them without undue delay so they can decide whether to report it to the ICO and whether to tell the individuals. We will give them what we know and help them do it. We will not make that call on their behalf or go around them.
We tell affected people directly where there is a high risk. Where a breach is likely to result in a high risk to someone's rights and freedoms, they get told directly and in plain language — what happened, what it means for them, and what to do about it.
We tell you what we do not know. Read the previous section again: we have no audit logging. That has a specific and uncomfortable consequence for a breach investigation. From our database rules, the account's role and its membership rows we can establish what an account was entitled to reach — which workspace, which sites, which files. We cannot establish what was actually read, opened or downloaded, because nothing records that. So if an account is compromised, the honest answer we will give you is the scope of what was exposed, not a list of what the intruder looked at. We would rather tell you that up front, and in a notification, than imply a certainty we do not have.

Report a suspected breach or a security problem to security@routeround.co.uk.

16. If the business is sold

If Desultory Ltd is sold, merges with another company, or sells the part of the business that runs RouteRound, the personal data described in this notice would transfer with it — the service cannot be handed over without the accounts and data that make it work. Being straight about what that means:

The buyer would take on the role we have now: controller of subscriber account data, processor of everything a subscriber has put into the app.
This notice would continue to apply until it was lawfully changed. A new owner can change a privacy notice, and we cannot promise on their behalf that they never will. What we can say is that they would inherit the obligations in it and in the DPA, that any change would have to comply with UK GDPR, and that a material change means telling subscribers (section 17).
Subscribers would be told, by email to the account address, that ownership had changed and who the new operator is.
Data would also be disclosed during due diligence before any sale, if it happens at all — but only what is genuinely necessary, under a confidentiality agreement, and kept to aggregate and account-level information rather than the contents of anyone's schedule wherever that is possible.

If you would rather not continue under a new owner, you can export your data and delete your account (section 12) at any time, including after such an announcement.

17. Changes to this notice

If we change it materially we will update the date at the top and tell subscribers by email. Continuing to use RouteRound after a change means the updated notice applies.