GDPR for driving schools: what to log, what not
A practical UK GDPR primer for driving schools and ADIs — controller vs processor, the data you keep, the data you must not, and the audit trail that matters.
UK GDPR is one of those topics with two common failure modes: over-complicating it (“I need a £400 Data Protection Officer”) or under-thinking it (“we’re small, it doesn’t apply”). Both are wrong. This post is the practical middle: what actually applies to a small driving school, what to log, what not to, and the audit trail that matters if anyone ever asks.
This is not legal advice. The Information Commissioner’s Office (ICO) is the authority on this — their guide to UK GDPR for small organisations is the reference, and is genuinely well-written. What follows is a practitioner’s distillation, not a substitute for it.
Step 1: register with the ICO
If you process personal data (you do — every student record is personal data) you have to register with the ICO and pay the data protection fee. As of 2026, the small-organisation tier is around £40-£60/year, paid annually. This is non-negotiable.
The registration takes ~10 minutes online. You get a registration number. Put it on your privacy policy and your /security or /privacy page. Done.
If you’re a sole-trader ADI with under £632k turnover and fewer than 10 employees, you’re tier 1. If you’re growing, the tier rises with you.
Step 2: understand controller vs processor
Controller = the entity that decides why and how personal data is processed.
Processor = the entity that processes data on the controller’s behalf.
For a driving school running on Passdesk:
- The school is the controller for student records, lesson notes, payment metadata, and rubric data. The school decides what to collect and why.
- Passdesk Ltd is the processor — operating the platform on the school’s behalf, under a written processor agreement (the Data Processing Addendum, attached to the terms).
- Stripe is a separate processor for payment data.
- Postmark is a sub-processor for transactional email.
This matters when a student exercises a GDPR right (subject access, erasure, etc.). The school answers it. The school can ask the processor for help, but the legal duty is on the controller.
Step 3: lawful basis
Every piece of personal data you process needs a lawful basis. For driving schools the practical answers are short:
- Performance of contract for everything tied to delivering the lesson — student name, address, package balance, lesson notes, rubric.
- Legal obligation for anything HMRC or DVSA requires you to keep — invoices, lesson records for the duration HMRC requires (currently 6 years).
- Legitimate interest for things like sending end-of-term feedback emails, in-product analytics. You should be able to articulate why your interest doesn’t override the student’s rights.
- Consent for marketing email to people who haven’t started a course yet — and only if you can prove it (timestamp, IP, double-opt-in).
You should never need a lawful basis to do something that genuinely doesn’t need to be done. If you can’t articulate the basis, that’s a hint you don’t need the data.
What to log
The minimum honest record-keeping for a UK driving school:
- Student records. Name, contact details (phone, email, address), DOB, licence number (provisional or full), package status, instructor allocations, lesson history.
- Payment metadata. What they paid, when, for what package. Card data does not live in your system if you use Stripe — it lives at Stripe, and you reference it by token.
- Lesson + rubric records. Date, duration, instructor, progress rubric scores, notes.
- Consent records. When they accepted your privacy policy, when they opted in to marketing (if applicable).
- Audit trail. Who in your team viewed or modified a student’s record, and when. This is your defence if there’s ever a dispute.
Passdesk maintains the audit trail automatically; if you’re on a spreadsheet, you don’t have one — and that’s a real gap.
What not to log
A short list of what you should not store, even though you might be tempted:
- Card numbers, CVVs, or full expiry dates. Use Stripe. Storing card data turns your school into a PCI-DSS scope, which you do not want.
- Full medical history. Some students share medical context (epilepsy, anxiety, eyesight). Note only what’s directly relevant to the lesson — “needs short breaks”, not the full diagnosis.
- Photographs without consent. A photo on your website needs the student’s written consent.
- Special-category data without explicit consent. Religion, politics, sex life, biometrics. These trigger Article 9 and are almost always not relevant to your lessons.
- WhatsApp screenshots in the student record. Even if useful, they tend to contain conversation context the student didn’t intend to be saved. If a chat record matters, transcribe the relevant fact.
The four rights you’ll actually be asked about
There are eight rights under UK GDPR; in practice driving schools see four:
-
Right of access (subject access request). A student asks “what data do you hold on me?”. You have one calendar month to respond. Free. Most platforms can dump it as a JSON or CSV — Passdesk does this from the student profile in two clicks.
-
Right to rectification. “You’ve got my address wrong.” Fix it.
-
Right to erasure. “Delete me.” You can — unless you have a legal obligation to keep the data (e.g. invoices for HMRC). The right answer is usually: archive the lesson + payment records (legal basis: legal obligation), but actually delete contact details and any free-text notes that are no longer needed.
-
Right to data portability. “Send my records to another driving school.” If you’re processing under contract or consent, you have to. A clean export of student + lesson history covers it.
You should be able to fulfil any of these in under 30 minutes. If you can’t, the data architecture is the problem.
What if it goes wrong
If you have a personal data breach (lost laptop, hacked email, accidentally CC’d the whole class on a private email), you have 72 hours to notify the ICO if there’s a likely risk to the affected people. Affected people get notified directly if the risk is high.
Have a plan written down. It can be one page. The plan covers:
- Who decides it’s a breach (probably you).
- Who you call (the ICO breach reporting line, your insurer, your software providers).
- What you tell affected people.
- What you do to stop it happening again.
A breach handled well usually doesn’t even result in a fine. A breach hidden or mishandled does.
The pragmatic posture
GDPR for a small driving school is not the Big Scary Thing it’s made out to be. The pragmatic operational posture:
- Register with the ICO.
- Use a system that maintains an audit trail by default.
- Don’t store what you don’t need.
- Have a privacy policy that’s actually accurate (not copied from a template that mentions data you don’t process).
- Be ready to respond to a subject access request within a month.
If you’re on Passdesk, the audit trail, export tooling, and processor agreement are part of the platform. If your records live across a spreadsheet and a few chat threads, the audit trail is the gap you’ll need to close.
Curious how Passdesk handles processor scope, audit logs, and subject-access exports? See the security page for the architecture, or the privacy policy for the controller/processor split.