GDPR Checklist for Shared Mobility Operators

A GDPR checklist for a shared mobility operator comes down to ten questions: what personal data you hold, where it lives, why you may use it, how little you can collect, who can see it, how riders use their rights, how long you keep it, which vendors touch it, what you do after a breach, and how AI tools use it. The table at the end turns each one into something you can tick off.

This is practical guidance from a software company, not legal advice. Every business and country is different, so check your own set-up with a data protection lawyer or your data protection officer.

What personal data does a sharing service handle?

More than most apps. A scooter, bike, moped or car sharing service links a named person to where they went, when, how they rode and how they paid. Start by listing every type of data you hold:

For each line, note where the data is stored, who can see it, which vendors receive it and how long you keep it. This list, often called a record of processing, is the base for every other step below.

Where should rider data be hosted?

GDPR does not forbid storing data outside the EU, but moving personal data to other countries needs extra steps, such as checking whether the country is recognised as protecting data well enough, or signing standard contractual clauses with the receiver. Hosting data for EU riders inside the EU keeps your main platform out of those questions, and makes it easier to answer riders, partners and cities who ask where their data goes.

EU hosting does not replace the rest of GDPR, and it only covers the systems hosted there. Check backups, support tools, email tools and analytics too. Our security page explains how.

What lawful basis do you need?

GDPR says you need a lawful reason, called a lawful basis, for each way you use personal data. There are six. The ones sharing operators rely on most are:

• Contract: data you need to give riders the service they signed up for, such as their account, the ride’s location data and the payment.
• Legal obligation: data the law makes you keep, such as invoices and tax records.
• Legitimate interests: uses riders would reasonably expect, such as preventing fraud or protecting vehicles, once you have weighed your interest against the rider’s privacy and written that down.
• Consent: uses riders are free to refuse, such as promotional messages. Consent must be a clear yes, given for a specific purpose, and as easy to withdraw as it was to give.

Two mistakes are common. The first is asking for consent for something the service cannot run without: if a rider who says no cannot ride, the consent was not really free. The second is one tick box that covers everything. Explain each use in plain words in your privacy notice instead.

In Axons Mobility, riders’ acceptance of the terms and privacy policy is recorded, promotional notifications go only to riders who opted in, and riders control each kind of notification with its own switch.

How can you collect less data?

GDPR expects you to collect only what you need. Data you never hold cannot leak, needs no retention rule and never appears in an access request. Practical ways to collect less:

• Check on the phone where you can. The Axons Mobility helmet photo check runs on the rider’s phone, so the picture never leaves it. You learn that the rider has a helmet without storing a photo of them.
• Ask only when a check is needed. Decide which riders and vehicles need an ID check, and explain why at the moment you ask.
• Tie location to a purpose. A ride needs route data. For every other use of location, ask whether you really need it and for how long.
• Limit exports. Every spreadsheet of riders on a laptop is another copy to protect and delete. Export only what a task needs, and remove the file afterwards.
• Protect what you keep. In Axons Mobility, rider phone numbers are always stored encrypted, for every operator.

Who on your team can see personal data?

Many privacy problems inside a business are ordinary ones: too many people can see too much. Give each person only the access their job needs. A support agent needs a rider’s history; a field technician needs vehicles, not riders’ phone numbers.

The Axons Mobility operator console has four role levels and fine-grained permission groups. You can hide riders’ personal data and revenue figures for a whole group, limit people to the fleets you choose, which matters when sub-operators or contractors share one console, and keep sensitive actions such as remote unlock and refunds for people whose permissions allow them. An activity log records who changed what and when, and you can open any team member to see their changes. Whatever software you use, remove access on the day someone leaves.

How should you handle rider rights requests?

GDPR gives riders rights over their data. The requests you will see most often are:

• Access: a copy of the personal data you hold about them.
• Portability: their data in a common format they can take elsewhere.
• Erasure: deleting their data, where you have no legal reason to keep it. It is often called the right to be forgotten.
• Correction: fixing data that is wrong.
• Objection: stopping certain uses, and always stopping direct marketing when asked.

Answer without undue delay, and generally within one month. Confirm who is asking before you send any data: a request from inside the rider’s own signed-in account is the simplest proof.

Self-service saves your team time. In the Axons Mobility rider app, riders can download a copy of their personal data and delete their account themselves. The account is anonymised: personal details such as name, email address and phone number are removed. Anonymising rather than wiping every record lets you keep the financial records the law may require without keeping who the rider was. Operators see privacy requests in one GDPR request queue in the console.

How long should you keep rider data?

GDPR sets no single period. You may keep personal data only as long as you need it for the purpose you collected it for. Write a retention schedule that covers at least:

• ID check images and results
• trip routes and vehicle data linked to riders
• parking photos and dispute evidence
• support conversations
• payment and invoice records, where tax law in your country often sets a minimum
• staff activity logs
• data from closed accounts

For each, write the purpose, the period, what happens at the end (delete or anonymise) and who checks that it happened. Keep dispute evidence at least as long as riders can dispute a charge. Review the schedule once a year.

What should you ask your vendors?

Every company that handles personal data for you is a processor: your software platform, payment provider, identity check provider, email and support tools, analytics and AI tools. GDPR requires a written agreement with each one, usually called a data processing agreement. Ask every vendor:

• Where is our data stored, and where is it accessed from, including backups and support staff?
• Which other companies do you use to process it, where are they, and how will you tell us about changes?
• Will you sign a data processing agreement?
• How is the data encrypted, and who at your company can reach it?
• How quickly will you tell us about a breach?
• How do we export our data, and how is it deleted when we leave?

Ask Axons Mobility the same questions. With Axons Mobility, riders pay into your own Stripe account, so you also have your own agreement with the payment provider; read its data terms too.

What should you do if there is a data breach?

A breach is any security incident where personal data is lost, destroyed, changed, or seen by someone who should not see it. A lost staff laptop with a rider export counts. Write the plan before you need it:

1. Name who decides. One person owns the response, with a named backup.
2. Contain it. Remove access, reset passwords and revoke keys. In Axons Mobility, a connected device’s encryption keys can be rotated or revoked remotely, for example when a device is lost.
3. Find out what happened. Which data, how many riders, since when. The activity log shows who changed what, and when.
4. Report it where required. Unless the breach is unlikely to put people at risk, tell your data protection authority within 72 hours of becoming aware of it. If the risk to riders is high, tell them too, without undue delay.
5. Record every breach, including the ones you did not have to report, and what you changed afterwards.

Can you use AI tools with rider data?

AI assistants are good at questions like “which zones lost the most trips last week?”. The risk is pasting rider exports into a general chat tool, which sends personal data to a new processor, possibly outside the EU and without an agreement. A few rules keep AI use safe:

• Keep personal data out of prompts. Ask about totals and trends, and remove names, phone numbers and emails.
• Use tools that follow permissions. The Axons Mobility AI assistant answers from your data, and only from the data the person asking is allowed to see.
• Keep a log. Every question asked of the Axons Mobility assistant is recorded.
• Keep a person in charge. The assistant can propose an action, but nothing runs until a person confirms it.
• Control outside connections. You can connect your own Claude or ChatGPT to your Axons Mobility workspace with approval and a full log of every call. Check the AI provider’s own terms on where prompts are processed and kept.

GDPR checklist for shared mobility operators

Much of this list is easier when the software handles the routine parts. For the checks that create identity and driving data in the first place, see our guide to rider safety in shared mobility. To see the privacy tools, and roles described here on your own vehicles, start a free 15-day trial.