Data Processing Agreement

Between:

(1) The Customer — the business that subscribes to RouteRound, named in the subscription ("you", "the Controller"); and

(2) Desultory Ltd, of 133 Berrall Way, Billingshurst, England, RH14 9PQ (registered in England and Wales, company number 17361684) ("we", "us", "RouteRound", "the Processor").

This agreement sets out the terms on which we process personal data on your behalf, as required by Article 28 of the UK GDPR. It forms part of, and is subject to, our subscription terms. Where this agreement and the subscription terms conflict on data protection, this agreement wins.

Version: 1.1, effective 15 August 2026

What changed in 1.1: clause 8.6 now names the OpenStreetMap Foundation and what the tree-preservation-order map discloses to it. Nothing was removed and no obligation of ours was narrowed — this is a disclosure that was already happening, was already described in our Privacy Notice, and should have been in this clause and on the sub-processor list from the start. It was not. Version 1.0 was therefore incomplete rather than wrong, and this is the correction.

1. Who is who

1.1 For all personal data you or your users enter into RouteRound about your staff, your customers, your customers' contacts and the sites you work on — you are the controller and we are the processor. You decide what goes in, why, and how long it stays. We act only on your instructions.

1.2 For the personal data we hold about you as a subscriber — the account holder's name and email address, sign-in credentials, organisation name, member roles, invitation records, billing details and our own service logs — we are the controller. That processing is described in our Privacy Notice and is not governed by this agreement.

1.3 Where you invite a colleague into your RouteRound organisation, that colleague's email address and role are processed by us in both capacities: as processor for your organisation's member list, and as controller for their own sign-in account.

1.4 You confirm that you have a lawful basis for every category of personal data you put into RouteRound, that you have given the required privacy information to the people concerned, and that your instructions to us will not put us in breach of UK data protection law.

2. Subject matter, duration, nature and purpose

2.1 Subject matter. Our provision of the RouteRound field-service scheduling service to you.

2.2 Duration. From the start of your subscription until it ends, plus the return-and-deletion period in clause 10.

2.3 Nature and purpose of the processing. We process personal data only to provide the service, that is to:

• store your working data on your devices and, when you sign in to a cloud account, hold a backup of it in our database and file storage;
• synchronise that data between your own devices and between the members of your organisation;
• publish a read-only schedule to the customers you choose to share with, through the client portal — which, as clause 6.1 sets out, publishes the whole of that team's schedule and not only the sites belonging to the customer you are sharing with;
• send, at your direction, schedule-change emails and completion reports to the addresses you nominate, and invitation emails to colleagues you invite. An emailed completion report is a fuller document than the portal; clause 6.1 says what it carries;
• carry out the site lookups and the route planning the app offers: postcode lookup — which, where what you typed holds no recognisable postcode, sends that text as you typed it and so may send a full street address — weather for a site's coordinates, tree-preservation-order and conservation-area checks, the google.com/maps navigation links the Navigate controls open, and — only where a key for them is set in the build we deploy — full-address geocoding and reverse geocoding through Google, what3words conversion, and route optimisation, which sends your depot's coordinates together with every stop on that day's round to Google in a single request. Clause 8.6 sets out which of these your browser contacts directly and exactly what each one receives;
• keep the service secure, available and free from abuse;
• provide support when you ask for it.

We also take payment for your subscription and manage it, using Stripe's hosted checkout and customer portal, and we record against your account which subscription you hold and whether it is current. We do that as controller under clause 1.2, not on your behalf, so it is described in our Privacy Notice rather than governed by this agreement. It is named here so that the list above is not read as an account of everything we do.

2.4 We do not use your data to train models, to build profiles, for our own analytics, or for marketing. RouteRound contains no analytics or advertising code.

3. Types of personal data

The following categories are processed, drawn from what the software actually stores:

About your customers and their sites

• Customer name; contact name; contact phone number; contact email address
• Free-text notes held against a customer record
• Site name and code; full address; postcode; what3words address; latitude and longitude
• Access notes, which in practice contain gate codes, key-safe codes, parking and hazard information
• Photographs taken before and after work, which are photographs of private property
• A drawn signature captured on site as sign-off for a completed job. The person signing here is normally the customer's representative or the occupier rather than one of your staff, and the emailed report records it as "Client sign-off"

About your staff and operatives

• Name; role; email address; phone number
• Qualifications and certificates, including certificate name, expiry date, notes and a photograph or scan of the certificate or card
• Compliance requirements and whether a named person satisfies them, including requirements of the kind the app labels "Vetting / clearance" (see clause 3.2), together with any free-text note recorded against a requirement
• Location data: latitude, longitude, accuracy and timestamp captured at check-in and check-out of a job
• Drawn signature images on risk assessments, waste transfer notes, equipment checks, vehicle checks and custom forms, plus a reusable saved signature and signatory name held in settings
• Names of assessors, operators and signatories; the names of staff logged as attending a job
• Vehicle registration and odometer readings from daily walkaround checks
• Free-text job notes, skip reasons, and records of any job completed with paperwork outstanding, including who overrode it and why

About your portal users

• Email address; name; the times they first and last signed in; the member list of their portal account
• The content of any request they submit through the portal

About your business and its documents

• Company legal name and address, SIC code, waste-carrier licence number and expiry, logo, contact details, depot location
• Quotes and invoices: customer names, references, line items, prices, VAT, PO numbers and payment dates
• Waste transfer notes, including the names, addresses and permit numbers of both parties to a transfer
• Chemical stock records, including MAPP numbers, active ingredients and a usage ledger tied to jobs
• Saved lists of email addresses kept for sending completion reports to

Technical records stored alongside the above

• The browser user-agent string of the device that made each cloud backup, truncated to 120 characters and stored on the backup itself and on every retained snapshot of it. It is a device and browser identifier attached to a named account, and it is readable by every member of your organisation. It is not a service log; it is a stored column, which is why it is listed here rather than under clause 1.2.
• Which member of your organisation pushed each cloud backup, and when. The shared backup and every retained snapshot of it store the pushing user's account id and a timestamp, resolvable to that colleague's name and email through your member list, and readable by every member of your organisation. Across the snapshots an account keeps, that is a per-member record of activity on your data. It is listed here for the same reason as the bullet above: it is a stored column on your data, not a service log. Clause 6.2's "no audit logging" means we do not record who read a record; this records who wrote one.

3.1 Special category data. RouteRound is not designed for and does not request special category data under Article 9. You must not enter health information, biometric data used for identification, or identity documents into notes, form fields or certificate photographs. If you do so anyway, you remain solely responsible for meeting the Article 9 conditions and for any resulting DPIA.

3.2 Criminal offence data. An earlier draft of this document said this was "not requested and not supported". That was wrong, and we are correcting it rather than leaving it to be discovered.

RouteRound does not hold the content of a criminal record, and there is no field for an offence, a caution or a disclosure. But it does have a first-class field for whether a named individual holds a criminal-records clearance, and the interface asks for it directly. A compliance requirement carries a kind, one of which the app labels "Vetting / clearance" and which the source describes as covering DBS Basic and Enhanced, NPPV, BPSS and CTC. The box in which you name the requirement ships with the placeholder "e.g. DBS Enhanced". A requirement is satisfied by a matching entry on a named person's qualification record, and a qualification can carry a photograph or scan of the certificate or card.

Recording that an identified person has, or has not, been vetted — and holding a scan of the certificate that says so — is personal data relating to criminal convictions and offences within Article 10 of the UK GDPR, as extended by section 11(2) of the Data Protection Act 2018. If you use this feature, and it is one of the things the app is for:

• you are the controller of that data, and you should expect to need a condition under Schedule 1 of the Data Protection Act 2018, in most cases an appropriate policy document to go with it, and to have to consider whether a DPIA is required;
• we process it only as your processor, only to store it and show it back to you, and it is covered by every other clause of this agreement — including clause 6.1's warning that anyone in your organisation can read it and clause 10.3's warning about snapshots;
• do not put the content of a disclosure, an offence history or a certificate reference number into the free-text note. The field is designed to record a cleared status, not what was disclosed.

4. Categories of data subject

• Your employees, subcontractors and operatives
• Your directors, office staff and administrators
• Your customers, and the individual contacts at those customers
• Individuals at your customers' organisations who use the client portal
• Occupiers of the properties you attend, to the extent they appear in job notes or in photographs
• Third parties recorded on waste transfer notes, such as tip and transfer-station operators

5. Your instructions

5.1 We process personal data only on your documented instructions, including on transfers, unless we are required to do otherwise by law. If we are, we will tell you before processing unless that law forbids us from telling you.

5.2 Your documented instructions are: this agreement, the subscription terms, and your use of the features of the service. Turning a feature on is an instruction to carry out the processing that feature performs — for example, adding a client share instructs us to publish that schedule and, unless you switch notifications off for that customer, to email them when it changes.

5.3 If we consider an instruction to infringe UK data protection law, we will tell you without delay. We may suspend the affected processing until it is resolved.

5.4 You may change or withdraw instructions in writing to privacy@routeround.co.uk. Where a change requires work outside the normal running of the service, we may charge a reasonable fee, and we will tell you before doing anything chargeable.

6. Security measures

We take appropriate technical and organisational measures under Article 32. Set out below is what is actually implemented, so that your assessment is based on fact.

6.1 What is in place

Separation between accounts. Row-level security is enabled on every table in the database, and access rules are enforced by the database itself rather than only by the application. A signed-in user can read and write their own account's backup and nothing else; members of an organisation can reach only their own organisation's shared data. Portal users can only read the schedule published to them — they cannot write to it at all. They do have three narrow write paths, which we set out rather than round down to "read-only": a request inbox they can add to but never edit or delete afterwards; the first- and last-seen timestamps on their own portal record, which the portal stamps automatically when they sign in; and, where a portal user is an owner of their portal account, the member list of that account — an owner can add, re-role and remove the other email addresses on it.

No separation inside an organisation. The boundary above is the only one there is, and we would rather say so than let the paragraph above be read as more than it is. Within a shared organisation the database rules key on bare membership, not on role: the read policy on the organisation's backup and the read policy on its storage folder both ask only whether the user is a member. So every member, including one you have given the lowest "field" role, can read the organisation's entire backup and every file in its folder — your customers' contact details, access notes containing gate and key-safe codes, every staff member's certificate and clearance scans, drawn signatures, quotes and invoices. Roles change what the app shows someone (they hide sales, data tools and settings) and not what the database will hand over, and every role may push changes to the shared copy. Joining an organisation also pulls the whole shared dataset, files included, down onto the joining member's device, where — see clause 6.2 — it is not separately encrypted by the app. If you have people who should not see all of it, the only control the software actually offers is a separate organisation, and you should assume when assessing this that anyone you add can see everything.

File isolation. Photographs, signatures and certificate scans are held in a private storage bucket, never a public one, in folders named after the account or organisation that owns them, with the same row-level rules applied to file access.

Server-side privileged key. The database's privileged service-role key exists only in our server environment. It is never included in the code sent to a browser. Five server functions use it: publishing a schedule, accepting a team invitation, deleting an account, starting or managing a subscription, and receiving payment events from Stripe. The first four verify the caller's session token before doing anything, and act only on data belonging to the caller's own account — with one deliberate exception. When you publish a schedule to a customer, the publishing function also creates, for the email address you nominate, a portal sign-in account and a customer record if they do not already exist, and emails that address. That is the client-portal feature described in clause 2.3 doing what you asked it to; it is rate-limited, but it is action taken on an identity other than your own, at your instruction. The Stripe webhook cannot verify a session — Stripe holds none with us — so it is authenticated instead by verifying Stripe's signature over the raw request body, before that body is parsed, and anything failing that check is rejected without reaching the database.

Passwords a subscriber sets for their customers. A subscriber can issue an initial portal password to a customer they share with, so that customer can sign in without waiting for an emailed link. What is implemented, precisely: the password is generated by the server, never chosen or typed by the subscriber; it is returned to them once and is not stored anywhere — not in the database, not on the device, not in any backup — so the only record is the date it was issued and which subscriber account issued it; the server refuses the operation for any address that already uses RouteRound in its own right — one that has published a schedule, holds a subscription, has a backup of its own, belongs to a shared organisation, or has an unaccepted invitation to join one — and also for any address another subscriber already shares with, so it cannot be used to obtain a credential on somebody else's account; a password is likewise retired automatically if the address later accepts an invitation to join an organisation, so one issued before that point cannot be used afterwards; it is refused outright once the customer has chosen their own password, so it cannot be used to lock them out; it is retired when the subscriber stops sharing with that customer; and when a subscriber deletes their RouteRound account, every password they issued that the customer has not yet replaced is rotated to an unknown value. Whether the customer has replaced it is recorded by a database trigger on the authentication table, not by anything the browser can assert.

Two things this is not, stated because the difference matters to your assessment. The customer is shown a notice when they sign in, telling them their contractor set the password and how to replace it — that is a user-interface disclosure, not an access control, and it can be dismissed. And issuance is rate-limited to six per minute per subscriber, in memory, per server instance — a brake on a stuck finger, not a guarantee.

Identity checks on privileged operations. Accepting a team invitation requires a valid, unexpired, unused token and that the accepting user's signed-in email address matches the invited address. Ownership of an organisation can never be granted by invitation.

Encryption in transit. All traffic uses HTTPS. Responses carry HTTP Strict Transport Security with a two-year max-age including subdomains, a Content Security Policy that enumerates the only external hosts the browser may contact, and X-Frame-Options: DENY, X-Content-Type-Options: nosniff and a restrictive Permissions-Policy.

Encryption at rest. Data in our database and file storage is encrypted at rest by our infrastructure providers as standard. Rather than ask you to take that on our word, here is the supplier's own commitment: Supabase, which holds both the database and the files, states that "all customer data is encrypted at rest with AES-256" and in transit via TLS (supabase.com/security). We do not operate customer-managed keys.

Rate limiting. Every server function that touches personal data applies a per-user request limit, keyed on the signed-in user id. The only per-IP limit in the service is on the unauthenticated tree-preservation-order lookup, which has no signed-in user to key on. The completion-report email path has both a tighter per-minute limit and a deployment-wide daily ceiling. The invitation-email path has neither: it runs under the same general per-user limit as the rest of that function, so the protection against a compromised session sending mail in volume from our verified domain is weaker there than on the report path. All of these limits are held in memory per function instance, which makes them a first line of defence rather than a hard cap. As at 25 August 2026 no provider-side send cap is configured at Resend, and the invitation path still has no limit of its own. We would rather record that than describe the in-memory limits as though they were a ceiling. Both are on the list to change; until they are, the honest description of the invitation path is the one above.

What the client portal publishes — and to whom. A portal share is scoped to a team, not to a customer. Publishing to one customer therefore gives that customer the whole of that team's schedule: every active site's name, street address and postcode, and every dated visit and its status — including the sites of your other customers. There is no per-site filter; the customer's name and email are the viewer's label and login, nothing more. The app's own sharing screen says the same ("they'll see this team's whole schedule"), and we repeat it here because clause 4 records that a site address can identify an occupier. If two customers must not see each other's work, they have to be on separate teams.

What a portal share does leave out is your free-text job notes, money, and anything belonging to another team; completion records in the portal carry a paperwork summary and a photograph count rather than the notes themselves.

One free-text field does leave, and by email rather than to the portal. The per-visit "Note for the client" is carried into the schedule-change email, in brackets after each new or moved visit. Because a share is scoped to a team and not to a customer, that email reports the whole team's changes — so every notified customer receives the notes written on your other customers' visits too, alongside those sites' names and dates. A note such as "no access — occupier in hospital, key with the neighbour" therefore reaches people with no connection to that site. Treat that field as text any of your customers may read, and put nothing in it you would not send to all of them.

The emailed completion report is a different and much fuller document, and nothing said above about the portal describes it. It goes out in two parts, and an earlier draft of this clause described only a fraction of the second.

The email body carries the names of the crew who attended, each crew member's certificates with expiry dates and an "EXPIRED" flag where one has lapsed, the free-text job notes in full under "Work done", any skip reason, any record of paperwork being overridden and the reason given, and the site's postcode.

The attachment is not "the photographs". By default it is a single file, completion-report.pdf, which is a page-image render of the entire Proof-of-Service sheet exactly as it appears on screen. In addition to everything in the body, that sheet carries: the staff check-in and check-out GPS coordinates, to five decimal places; every drawn signature image on the job — the client's sign-off, the risk-assessment assessor's, the waste-transfer transferor's and transferee's, and the operator who signed an equipment or vehicle check; photographs of the crew's qualification certificates; the site's address and what3words; the customer's contact name and phone number; the vehicle registration and odometer reading; the waste-transfer counterparty names, addresses and permit numbers; and the before-and-after job photographs themselves. Before-and-after photographs are attached instead of the PDF, and only when the PDF fails to generate, capped at eight. Attachments are capped in total at twelve files and 8 MB, and a report goes to as many as five email addresses the sender types — any addresses at all.

Clause 3 lists location data, drawn signature images and certificate scans among the most sensitive things this product holds, and clause 3.2 warns that a certificate scan can be Article 10 criminal-offence data. All three leave in that attachment. Sending a report is your instruction under clause 5.2. It is your decision whether a given recipient should receive that much about your staff and that site.

Refusal to overwrite. Synchronisation refuses to write over a cloud copy newer than the one a device last saw, and refuses to sync at all if the device's data belongs to a different account — so one user's data cannot be filed under, or destroyed by, another's.

Offline-first design. Your working data lives on your device. The service can be used entirely without a cloud account, in which case none of your schedule, photographs, staff records or customer records reaches our servers. Three qualifications, so this is not read as "nothing leaves the device": a tree-preservation-order check sends the site's coordinates through our server function to the national Planning Data platform; the lookups in clause 8.6 go from your browser straight to those providers, whether or not you have a cloud account; and opening a Navigate link — or a link on a printed or copied day sheet — sends Google the site's coordinates, or, for a whole day's round, your depot and every stop on it. That last one needs no API key and no cloud account and is live on every install.

6.2 What is not in place

We would rather you learn this here than in an incident:

• No multi-factor authentication. Sign-in is email and password, or an emailed one-time link.
• No audit logging. We do not record who read which record, or when. This limits how precisely we can scope an incident — see clause 9.3 and the Breach Process. The one record of member activity that does exist is the pushing member and timestamp stored on each backup and snapshot, listed in clause 3; it says who saved a copy, never who looked at anything.
• No ISO 27001, SOC 2 or Cyber Essentials certification. We hold none and do not claim any.
• No customer-managed encryption keys, and no application-level encryption of individual fields beyond what the infrastructure provides.
• No independent penetration test. None has been carried out, and we say so in our published security.txt as well as here. If we commission one we will say so here and give the date.
• On-device data is not separately encrypted by the app. It relies on the device's own security. Subscribers should require screen locks and device encryption on any phone, tablet or laptop running RouteRound.
• No retention-based automated deletion of your working data, and no scheduled job anywhere in the service. Nothing ages out job records, photographs or check-in locations on a timer — you delete them, or you delete the whole account.
• Snapshot pruning is not a timer, and "30 days" is not a ceiling. Pruning is the one automatic deletion we operate, and it runs inside the database trigger that inserts a new snapshot. It therefore prunes only the account that has just pushed, only at the instant it pushes. An account that stops syncing — a cancelled subscription, a retired device, a dormant workspace — keeps whatever snapshots it held at its last push, indefinitely. What is true is this: an account that is still syncing settles at roughly 50 snapshots (the 20 most recent, plus the newest of each day for the last 30 days); an account that has stopped keeps up to about that many for as long as the account exists. Each one is a complete copy of the schedule as it stood at that moment, not a fragment. The event that stops the pruning is the same event — you stop using the service — after which clauses 10.1 and 10.3 promise deletion, so an instruction from you is what actually clears them. See clause 10.3.
• Whole-account erasure can be started from inside the app; clause 9.1 sets out what it reaches and what it does not. See clause 10 and the Retention and Erasure runbook.

6.3 Organisational measures

• RouteRound is built and run by one person. Access to production systems is limited to that person alone. There are no employees and no contractors, so nobody else holds production credentials, and there is no internal access-review process to describe because there is nobody to review. We would rather state that plainly than imply a team. That person is the director of Desultory Ltd, contactable at jack@routeround.co.uk; a buyer who needs the individual named in a contract can have it in writing on request.
• Production credentials are held in a dedicated password manager protected by two-factor authentication, and are not shared with anyone. We deliberately do not name the product here. Which vault a sole operator's production credentials sit in is of no use to a buyer assessing our security, and of obvious use to somebody attacking it; a buyer who needs it for a supplier questionnaire can have it in writing on request.
• We review these measures at least annually and whenever we make a significant change to the service.

7. Confidentiality

7.1 We keep personal data processed under this agreement confidential.

7.2 Everyone we authorise to process it is bound by a duty of confidence, whether by contract of employment, contractor agreement or professional obligation, and that duty survives the end of their engagement.

7.3 We limit access to those who need it to provide the service or to support you.

8. Sub-processors

8.1 General authorisation. You give us general written authorisation to engage sub-processors, subject to this clause.

8.2 Current list. The sub-processors we use, what data reaches each of them and why, are set out in SUB-PROCESSORS.md, which forms part of this agreement.

8.3 Terms we impose. Before a sub-processor handles personal data we put a written contract in place imposing obligations no less protective than those in this agreement, including confidentiality and Article 32 security. Where we stand as at 25 August 2026. Supabase, Netlify and Resend each publish a data processing agreement that applies to accounts of our kind, and those documents have been read and are cited on the sub-processor list. What we have not yet done is complete each provider's own acceptance step where one exists and record the date, and — for Stripe — nothing needs accepting separately. Stripe's DPA (version dated 18 November 2025) opens "This Data Processing Agreement is subject to and forms part of the Agreement", the Agreement being the Stripe Services Agreement accepted when the account was opened, and clause 1 provides that a Stripe account outside the Americas enters that DPA with Stripe Payments Europe, Limited. It has therefore been in force since the account existed, including on the afternoon of 25 August 2026 when billing went live. What was outstanding was the record, not the agreement — checked and corrected on 26 August 2026. We would rather show you the gap than describe a filing cabinet we do not have.

8.4 Liability. We remain fully liable to you for a sub-processor's performance of its data protection obligations.

8.5 Changes. We will give you at least 30 days' notice before adding or replacing a sub-processor, by email to your account address and by updating the list. If you reasonably object on data protection grounds within that period, we will work with you in good faith; if we cannot resolve it, you may terminate the affected part of the subscription without penalty for the unused period.

8.6 What your browser sends directly, and what each party receives. Some of the third parties listed are contacted by your browser, not by our servers. We list them as sub-processors for transparency even where we never hold the data ourselves — but "we never see it" is not the same as "it is not disclosed", so here is what each one gets:

• Postcode lookup (postcodes.io) — a postcode; and, where what you typed holds no recognisable postcode, that text as you typed it, which may be a full street address. On an install with no Google Maps key — which is every install today — this is the geocoder the app actually uses for sites and for the depot, so site addresses do reach it. Clause 4 records that a site address can identify the occupier.
• Weather (Open-Meteo) — a site's coordinates.
• Google, through ordinary google.com/maps links — no key, no gate, live on every install. This is separate from the Google Maps Platform entry below and is not switched off by the absence of a key. Every Navigate control builds a google.com/maps address carrying the location in its query string: for a single job, the site's coordinates (or, where it has none, its postcode or its name); for a day's round, your depot together with every stop on that round, as coordinates to six decimal places, in one link — the same disclosure described as the largest in this list, by a different route. Printed and copied day sheets carry the same links. Opening one gives Google those locations, your IP address and whatever else your browser sends to any website.
• Google Maps Platform, only where a Maps key is set in the build we deploy — this is a build-time setting we hold, not one you can switch on or off, so clause 8.5's notice period is the control here rather than anything in your account. Three separate things: a site's full address, for geocoding; a site's coordinates, for reverse geocoding into an address; and route optimisation, which is by some way the largest disclosure in this list. Optimising a day's round posts your depot's coordinates together with the coordinates of every stop on that round to Google's directions service in a single request, so the shape of that day's work — where your customers are, and how many — leaves the app in full.
• what3words, only where a key is set in the build we deploy, on the same footing as the entry above — a site's coordinates, or a three-word address.
• Map tiles from the OpenStreetMap Foundation — no key, no gate, and nothing switches it off. On the tree-preservation-order screen, once a check has returned a result and somebody presses Show map, the browser requests map tiles directly from tile.openstreetmap.org. Each request discloses that person's IP address, their browser's user-agent string, routeround.co.uk as the referring site, and the tile coordinates themselves — which is the part that carries the weight, because a handful of tiles at that zoom identify the patch of ground being looked at to within a few tens of metres. Where the check was run from the "check this spot" control, that ground is the operative's own live position, so this is location data about your staff as well as about a site. No other screen in the app requests a tile.
• Nearest-A&E-and-defibrillator lookup (Overpass API / OpenStreetMap data) — no key, no gate. On the Emergency Action Plan form, and only when somebody taps Find nearest A&E & defib, the browser sends the site's coordinates to overpass-api.de and nothing else. It returns nearby hospitals and mapped defibrillators, which the app offers as suggestions the user must confirm. Like the tiles above, this is a disclosure to a third-party controller rather than a processor we appoint; overpass-api.de is a community-run public endpoint serving OpenStreetMap data and publishes no location, retention or transfer commitment for query data. Where the site is the crew's own working location the coordinate is location data about your staff as well as the customer.

Two clarifications on that last entry, because it does not sit in the same box as the rest of this clause. First, the OpenStreetMap Foundation is not our processor and does not act on our instructions. It publishes a standing refusal: there is no controller-to-processor relationship between an embedder and the Foundation, and using its services does not create one. So we cannot pass your instructions to it, we cannot bind it under clause 8.4, and we cannot usefully route a data subject's request to it — it states that the transience of its logs generally makes access requests infeasible to fulfil. Second, it is a UK body — a company limited by guarantee registered in England and Wales, number 05912761 — but its tiles are served over a global content delivery network, and its privacy policy expressly excludes data associated with a tile request from the commitment it gives about storing personal data in the United Kingdom and the Netherlands. For that data it publishes no location, no retention period and no transfer mechanism. We record it here rather than under clause 13 because it is a disclosure to another controller, not a transfer we make as your processor.

Tree-preservation-order and conservation-area checks are the exception: they go through our own server function, which forwards the site's coordinates to the national Planning Data platform. That request carries no account identifier and is not authenticated, but the coordinates do pass through us. Note that the boundary check and the map drawn behind it reach different parties by different routes — the check goes through us to a UK Government service, the tiles go straight from the browser to the OpenStreetMap Foundation — so a customer content with one has not thereby agreed to the other.

9. Assistance to you

9.1 Data subject requests. Taking account of the nature of the processing, we will assist you by appropriate technical and organisational measures in responding to requests to exercise rights under Chapter III of the UK GDPR.

In practice:

• You can satisfy most access and portability requests yourself, but the export is not complete and you should not tell a data subject that it is. Settings → Data tools → Export backup produces a JSON file containing everything held on that device: sites, visits, teams, staff and their qualifications, customers, compliance requirements, quotes, invoices, forms and stock records, plus the photographs, signatures and certificate scans embedded as base64. That covers the great majority of any request. What it does not contain is the personal data that exists only on our servers and is never written to a device, which includes: your portal users' first- and last-seen sign-in timestamps; the content of the requests they submit through the portal; the member list of a portal account; the snapshot history of your backups; and the device user-agent string and pushing member recorded against each backup — all of which clause 3 lists as processed. Because the file is a dump of one device, it also contains only what that device has pulled, not necessarily what the cloud copy holds. If a request needs any of that, ask us at privacy@routeround.co.uk and we will produce it; there is no charge. Data we hold about you as controller under clause 1.2, including Stripe billing records, is outside this agreement and is covered by our Privacy Notice.
• You can correct or amend any record yourself inside the app — but only the live copy. The pre-correction value survives in the backup snapshots described in clause 10.3: those are complete copies of the schedule as it stood, they are readable by every member of your organisation, and the app offers a one-click restore of any of them, so an uncorrected record can be brought back. If you are answering an Article 16 request, correct it in the app and send us the instruction so the snapshots are dealt with too, on the same 14-day commitment as erasure.
• Erasure of your whole account you can start yourself, from inside the app: Settings → Data tools → Delete my account. You type your account email to confirm — checked again on our server, not only in the browser. The server then works in three stages, in this order, and there is no undo and no charge.
  • First it reads and decides, and destroys nothing. It works out which organisations you belong to, which of them you would leave empty, and who would inherit any shared workspace you own. If a shared workspace has other members but nobody who can take it over, the whole request is refused before anything is touched and you are told to make someone else an owner or admin first. "We refuse rather than destroy your colleagues' data" means exactly that: nothing has been deleted at the point of refusal.
  • Then it hands over any shared workspace you own to a remaining member — an existing owner first, then an admin, then the longest-standing member — and that organisation, its shared backup, its snapshot history and its files all survive. This step is still not destructive.
  • Then it destroys, in a fixed order: your personal folder in file storage, and the organisation's folder as well where no other member remains; your cloud backup and every earlier snapshot of it, and the organisation's where no other member remains; the data mirrored to your customers' portal — their schedule rows, completed-job records and submitted requests — together with any customer record left with no other business sharing to it; and finally your organisation memberships and your sign-in account.
  • A failure is reported as a failure. Every deletion in the destroying stage is error-checked, including the file purge, which used to stop quietly on a storage error and report a success it had not achieved. So are the reads that work out which of your customers' records exist only because of you — the two that decide it were unchecked in an earlier version of this service, and a failure in either could leave a customer record standing that we had promised to remove, or remove one another business was still sharing with, while the request reported success. Both now fail the request rather than guess. If any step fails, the request ends with an explicit "Deletion did not finish. Some data may remain" and a record of how far it got; the app shows you that rather than reporting success. Write to privacy@routeround.co.uk and we will finish it by hand within 14 days. What we do not claim is that the whole thing is one transaction — it is a sequence of steps across file storage, several tables and the sign-in system, so a failure part-way through leaves an account genuinely half-erased, honestly reported, and finished by hand.
  • The last step now works for a solo account. The database enforces a rule that an organisation must keep at least one owner, and every cloud account is automatically made the sole owner of its own workspace — which, until it was fixed, blocked the deletion of the sign-in account in the ordinary case. That rule has since been restated so that a sole member may wind up their own workspace (the protection is unchanged where other members remain), and the change has been applied to the live database. We describe this as expected rather than as observed, because it has not yet been watched happening on the live project. A full deletion has not yet been run end to end on the live project, and until it has we will keep saying "expected" rather than "observed".
  • What this route does not reach. Three things survive it, and we would rather name them than let you find out later. (1) Your customers' portal sign-in accounts. These are real accounts in the authentication system, created automatically when you first published a schedule to that email address, and they are not deleted here — ask us and we will remove them by hand. (2) Stripe. Nothing in this path touches our payment provider, so the customer object holding your billing email, billing address and payment history remains with Stripe under clause 1.2; if you want that erased as well, tell us and we will ask Stripe to erase it, subject to the records we and they must keep for tax and anti-fraud purposes. (3) Our providers' automated backups, which expire on their own cycle — see clause 10.5.
• Erasure of a single record, or of one individual within an account, still requires us, because the app has no way to delete one row or one file from the cloud copy. Send an erasure instruction to privacy@routeround.co.uk and we will carry out the manual erasure steps set out in our internal retention and erasure procedure within 14 days, so that you can still meet your own one-month deadline to the individual. There is no charge for this.
• If a data subject contacts us directly, we will not respond substantively. We will forward the request to you without undue delay and tell the individual we have done so.

9.2 DPIAs and prior consultation. We will provide reasonable assistance with a Data Protection Impact Assessment or a prior consultation with the ICO, taking into account the information available to us. This document, the sub-processor list and the retention schedule are intended to give you most of what you need.

9.3 Security, breaches and Article 32. We will assist you in ensuring compliance with Articles 32 to 36. You should know that our ability to tell you precisely which records were accessed in an incident is limited, because we do not operate audit logging. In an incident we will provide what our providers' infrastructure logs contain and will be explicit about what we cannot determine, rather than understate the scope.

10. Deletion and return

10.1 On the end of your subscription, at your choice, we will delete or return your personal data. Unless you tell us otherwise within 30 days of termination, we will delete it.

10.2 Return. You can produce an export yourself at any time, before or after termination, using the in-app backup export. As clause 9.1 explains, that file covers the working data held on the device it is taken from — including photographs — but not the personal data that exists only on our servers: portal sign-in timestamps, the content of portal requests, portal member lists, the backup snapshot history, and the device string and pushing member recorded on each backup. Ask us and we will produce the rest, at no charge.

10.3 Deletion — how this actually works today. Be aware of the following, which we state plainly because it affects your own compliance:

• Deleting data inside the app removes it from that device only. It does not delete the cloud copy. If the device then syncs, the cloud copy is overwritten with the new, reduced set — but the row itself, keyed to your account, remains until deleted by hand.
• A deleted record can come back on its own, because our sync has no tombstones. When a device merges a copy from the cloud or from another device, the merge adds back any record present in the incoming copy that is missing locally — it cannot tell "deleted here" apart from "not yet seen here". A job you delete on one device is therefore liable to be re-added by the next merge on that device and then pushed back up. The same is true of images: the app never deletes an individual file from storage, so a photograph removed on a device is simply downloaded again. Deleting an individual record does not reliably propagate, and you should not treat in-app deletion as erasure. Sites are the one exception — a site is deactivated with a timestamp rather than removed, so that deletion does travel. If you need something actually gone, send us the instruction.
• The deleted record also survives in our snapshot history. Every sync appends a copy of the schedule to a backup-history table, so snapshots taken before you deleted the record still contain it, along with the device string of the machine that pushed each one and the member who pushed it. Each snapshot is a complete copy of the structured schedule in its own right — photographs and signatures are covered by the next bullet. An account that is still syncing settles at roughly 50 of these (the 20 most recent, plus the newest of each day for the last 30 days). An account that has stopped syncing keeps whatever it had at its last push for as long as the account exists, because — as clause 6.2 explains — pruning only ever runs at the moment of a new push and there is no timer behind it. Those snapshots are readable by you and by every member of your organisation, and the app offers a one-click restore of any of them, so a record you deleted can be brought back by anyone on your team while it is still held. If you are answering an erasure request, deleting the record in the app does not clear it from our systems — send us the instruction so the snapshots are dealt with too.
• A completed job's portal record is never cleared by a later change. When you publish to a customer, the portal copy of your sites and dated visits is trimmed to match what you sent — so deleting a site or a dated visit does clear it from the portal database on the next publish. Completed-job records are deliberately exempt from that trim, because the customer is meant to keep their proof of work. The mirrored record — site name, completion date, paperwork summary and photograph count — therefore stays in the portal database after the visit it came from has gone, for as long as the share and the account exist. It is removed when you remove that customer's share, or when the account is deleted. If you are answering an erasure request that touches a completed job, deleting the visit is not enough.
• Deleting a single photograph, signature or certificate scan does not remove it from file storage. The app can upload, list and download files but has no delete operation at all, so an image removed inside the app stays in our file storage until the whole account is deleted or an operator removes it by hand — and, because it is still there, the next sync on that device downloads it back. Whole-account deletion does remove them: it purges the account's entire storage folder, and the organisation's folder as well where no other member remains, and a failure to do so is reported as a failed deletion rather than a success.
• Removing a client share does delete the mirrored data for that customer — their schedule rows, completed-job records and requests are removed immediately and automatically. It does not delete their portal login, their client record, or the record of when they last signed in.

What you can start without us is deletion of the whole account. That runs from inside the app, at any time, and it takes the cloud backup and its snapshot history, the stored files and the mirrored portal data with it. Read clause 9.1 for the order it works in, for the fact that it refuses before touching anything where a shared workspace would be stranded, and for the three things it does not reach — your customers' portal sign-in accounts, our payment provider's record of you, and our providers' own automated backups. Ending your subscription does not by itself delete anything — cancellation only changes your subscription status, so if you want the data gone you must either delete the account or instruct us. Where you ask us to do it instead, or where what you need erased is narrower than a whole account, it is a manual procedure carried out by an operator in the provider's administration console, documented step by step in our internal retention and erasure procedure. Two different periods apply, and we would rather be held to both than to an average of them:

• An erasure instruction from you: within 14 days of a clear instruction. This is the same commitment as clause 9.1, and it is deliberately shorter than a month so that you can still meet your own one-month deadline to the individual.
• End of subscription with no instruction: within 30 days. Clause 10.1 gives you 30 days from termination to tell us to return rather than delete; where you say nothing, we delete once that period has passed.

In both cases we confirm in writing when it is done, and say what was retained under clause 10.4 and why.

10.4 We may retain personal data where UK law requires it, for as long as that law requires and for no other purpose. This includes records you may be legally required to keep — waste transfer notes for two years, hazardous waste consignment notes for three years, and pesticide application records for three years. Tell us if any of your data falls into these categories before instructing deletion.

10.5 Backups. Deleted data may persist in our providers' automated backups until those backups expire on their own cycle. What that comes to for our database is narrower than an earlier draft of this clause said, and we would rather correct it than leave the softer sentence standing. On the Supabase Free plan there are no automated daily backups at all — the provider's own documentation tells free-plan projects to export their data themselves — and point-in-time recovery cannot be enabled, because it is a paid add-on. Daily backups begin at seven days' retention on the Pro plan and fourteen on Team (supabase.com/docs/guides/platform/backups). So on the Free plan there is no provider backup for a deleted row to survive in — and, in the other direction, none to restore from either. Confirmed on 25 August 2026: the project is on the Supabase Free plan, so this clause describes our actual position rather than an assumed one.

11. Breaches

11.1 We will notify you without undue delay after becoming aware of a personal data breach affecting personal data we process for you, and in any event within 24 hours of becoming aware of it, so that you can meet your own 72-hour deadline to the ICO.

11.2 Our notification will describe the nature of the breach, the categories and approximate number of data subjects and records affected so far as we can determine, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot determine something — in particular the precise scope, given clause 6.2 — we will say so explicitly rather than estimate.

11.3 We will not notify the ICO or any data subject on your behalf unless you instruct us to in writing.

11.4 Our full step-by-step response is documented in our internal breach procedure, which we will share with you on request.

12. Audit

12.1 We will make available to you all information reasonably necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

12.2 In the first instance we will satisfy an audit request by providing this agreement, the sub-processor list, the retention schedule, our breach procedure and written answers to your security questionnaire. We do not hold a SOC 2 report or an ISO certificate to offer in place of that.

12.3 An on-site or systems inspection may be requested no more than once in any twelve months, unless a breach has occurred or the ICO requires it, on 30 days' written notice, during business hours, subject to confidentiality, and without unreasonable disruption. You bear your own costs and our reasonable costs.

12.4 We will not give an auditor access to data belonging to our other customers, or to credentials.

13. International transfers

13.1 We will not transfer personal data outside the UK except in accordance with Chapter V of the UK GDPR, using UK adequacy regulations, the UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses.

13.2 Where the data actually sits. Our database and file storage run on a Supabase project hosted in AWS eu-west-3 (Paris, France). Your data at rest is therefore in the EU, not in the UK, and we do not claim UK-only hosting anywhere in this pack. The transfer from the UK to the EEA is covered by the UK's adequacy regulations for the EEA, so for that leg we rely on adequacy alone: no International Data Transfer Agreement, no standard contractual clauses and no transfer risk assessment are required or claimed for it.

13.3 Two things the hosting region does not settle, which we separate deliberately.

• Supplier access from outside the EEA. Where the data rests is a different question from who can reach it. Supabase, Netlify and Resend are all headquartered outside the UK and the EEA, and support or engineering access from outside the EEA is governed by each supplier's own data processing agreement rather than by the hosting region. Two of the three we can state from the suppliers' own published agreements; the third we cannot, and we say which is which:

  • Supabase, which holds the database and the files, applies the EU Standard Contractual Clauses together with the ICO's UK Addendum (version B.1.0) to transfers out of the UK, and names Supabase Pte. Ltd, of Singapore, as the data importer in that schedule. It limits personnel access by least privilege and to those with a business need, but it does not undertake to keep that access inside the EEA (supabase.com/legal/dpa).
  • Resend, which carries the mail we send on your behalf, relies on the EU Standard Contractual Clauses for transfers out of the EEA and on the UK Addendum for transfers out of the UK, and contracts as Plus Five Five, Inc. of San Francisco (resend.com/legal/dpa).
  • Netlify, which hosts the site and the server functions, publishes its data processing agreement only as a PDF, and its trust centre does not state the mechanism on the page. That PDF has since been read, and the sub-processor list records what it says: Netlify certifies to the UK Extension to the EU-US Data Privacy Framework, falling back to the EU Standard Contractual Clauses as amended by the UK Addendum (netlify.com/pdf/netlify-dpa.pdf, clauses 14.2 to 14.4). This clause previously said we had not read it, which was true when it was written and is no longer; the two pages now agree.

• Netlify's functions and CDN edge locations are a separate matter from the database region and must not be read as following it.

For every sub-processor, the contracting entity, the country of processing and the mechanism relied on are set out in SUB-PROCESSORS.md.

13.4 Where a transfer mechanism requires a transfer risk assessment, we will carry one out and make it available to you on request.

14. General

14.1 Term. This agreement runs for as long as we process personal data for you.

14.2 Liability. Liability under this agreement is subject to the limits and exclusions in the subscription terms, except where UK data protection law does not permit them to apply.

14.3 Changes. We may update this agreement where the law changes or where the service changes materially, on 30 days' notice. If a change materially reduces your protection you may terminate without penalty for the unused period.

14.4 Governing law. The laws of England and Wales, and the exclusive jurisdiction of the courts of England and Wales.

14.5 Precedence. In the event of a conflict, this agreement prevails over the subscription terms on matters of data protection.

Signatures

How this agreement is executed is a commercial decision rather than a data protection one, and it is not settled. A click-accepted schedule to the subscription terms is normal for a business of this size and takes the signature bottleneck out of every sale; a countersigned copy closes more slowly, but some facilities-management buyers will not proceed without one, so the choice sets how every deal closes. Decided on 25 August 2026: a click-accepted schedule to the subscription terms. It matches how the product already works — the checkout collects an explicit terms acceptance, timestamped by Stripe against the transaction, and this agreement forms part of those terms. A countersigned copy remains available on request to any buyer whose process requires one; ask at jack@routeround.co.uk and we will sign and return it.