UK GDPR storage limitation is not a single number of days or years. Data should not be kept longer than needed for the purpose.
UK GDPR
Old parking data is not a permanent shortcut.
This page looks at what happens after a parking company or debt collector has personal data: how long they can keep it, whether it must be accurate, whether old records can be reused for a new ticket, and what to ask when a file may be full of false data.
Finding
A messy database is not a defence. It is an audit risk.
UK GDPR principles require personal data to be accurate where necessary, kept up to date, limited to what is needed, and not kept in identifiable form for longer than necessary. A large unorganised parking database can make false tickets worse because old keeper details, old addresses, cancelled charges, debt notes, and wrong vehicle records can keep being treated as live facts.
Retention
There is no single UK GDPR parking time limit. There must be a reason.
The key test is necessity for a specific purpose. ICO storage-limitation guidance allows a limited record where the purpose is justified, but a company should not keep everything forever because it might be useful later.
DVLA's January 2026 vehicle-record guidance says request evidence and audit trail must be kept for at least two years from the date of enquiry.
Simple contract claims in England and Wales are commonly linked to the six-year Limitation Act period, but that is not permission to keep excessive or false live data.
ICO guidance says organisations normally have one calendar month to respond to rectification and other individual-rights requests.
If data is false, misleading, excessive, or no longer needed, the public should ask for correction, restriction, deletion, and recipient notice.
Valid reasons
What could justify keeping parking data?
A reason must be real, documented, and proportionate. These are possible reasons, not automatic permission.
Appeal, complaint, or dispute
Keeping enough data to investigate a live parking appeal, data complaint, or landowner complaint can be valid.
Establish, exercise, or defend claims
A company may keep a limited file where a genuine legal claim is being pursued or defended, but the file still needs accuracy and status markers.
DVLA and code audit
DVLA guidance requires evidence and an audit trail to support the request. That supports keeping the evidence file for the required period.
Cloned plate or abuse prevention
Where a vehicle was cloned or fraud is alleged, a limited record may be needed so the same false data is not reused against the wrong person.
Payment and finance records
If money was paid or refunded, some accounting records may need to be kept. That does not mean all ANPR or debt-chasing data stays live.
Proof a rights request was handled
A company may keep a minimal suppression or rights-log record so deleted data is not accidentally restored or reused.
Not enough
These reasons should be challenged.
- "We might need it someday" without a specific purpose, lawful basis, and retention period.
- Keeping a cancelled or false charge as an unpaid debt without a clear correction note.
- Keeping old keeper data from a previous ticket and using it for a different parking event without proving accuracy and purpose compatibility. If the old data came from DVLA KADOE, the published KADOE contract says the data is tied to the particular date, event, and purpose requested.
- Passing a disputed or false file to debt collectors while accuracy is being investigated.
- Using debt collector or group-company databases as a way around DVLA controls, event-specific KADOE checks, or audit trails.
- Blaming database size or poor organisation for failing to find, correct, restrict, or delete inaccurate data.
DVLA bypass risk
Can they fall back on old records instead of checking DVLA?
The safest public position is this: old records are not a general shortcut. The current DVLA KADOE API is built around an event date, reason code, registration or VIN, enquirer ID, and reference number. DVLA's published KADOE contract, although on a withdrawn GOV.UK page, says data supplied through that route must not be reused for another date, event, or purpose. UK GDPR also requires accuracy, purpose limitation, data minimisation, and storage limitation.
No public source found in this pass says every possible contact must always involve a fresh DVLA lookup in every circumstance. But if a company or debt collector is using an old database instead of event-specific DVLA data, it should be asked to prove the data source, lawful basis, accuracy check, retention reason, recipient list, and why the reuse is fair.
| Route | What was found | Audit question |
|---|---|---|
| KADOE event request | The current KADOE API schema is event-specific. The published KADOE contract says supplied data is for the requested date, event, and purpose and should not be reused for another one. | Was this exact event requested, and if old DVLA data was reused, where is the lawful permission for that reuse? |
| Manual DVLA parking request | DVLA guidance asks for incident details, ATA membership, landowner authority, ticketing or ANPR evidence, and a two-year audit trail. | Can the company show evidence existed before it got keeper data, and was the data deleted once finished with? |
| Debt recovery route | DVLA guidance lets parking debt agents request keeper-at-date-of-event data only with authority, an ATA-issued ticket route, evidence, and audit records. | Did the debt collector make a lawful event-specific request, or only inherit an unverified file? |
| Old operator database | Old records may be stale. Keeper, address, vehicle, land status, and debt status can change. DVLA-derived KADOE data is especially sensitive because the contract model is purpose-bound. | What is the source, collection date, lawful basis, retention period, last accuracy check, and DVLA permission if relevant? |
| Old debt collector database | A debt collector receiving data for one charge does not automatically prove it can use that data for a different charge or keep it as a live debt after correction. | Was the new processing compatible with the original purpose, necessary, accurate, and fair? |
| False ticket file | A record that a mistake happened may sometimes be retained, but the current status must not be misleading. | Is the file marked cancelled, false, wrong keeper, paid, restricted, deleted, or still showing as collectible? |
Ask this
Questions for the operator or debt collector
- Was my data obtained from DVLA for this exact parking event? Give the request date, event date, reference, and reason code.
- If not from DVLA, what source was used, when was it collected, and why do you say it was accurate for this ticket?
- What lawful basis are you relying on now: contract, legitimate interests, legal claim, public task via DVLA disclosure, or something else?
- What retention period applies to each data type: ANPR image, keeper address, payment record, appeal record, debt note, legal file, and complaint file?
- Has the file been shared with a debt collector, solicitor, tracing agent, group company, landowner, or software provider?
- If the charge is false or cancelled, have all recipients been told to correct, restrict, or delete the data?
Plain wording to adapt
I am challenging the accuracy, retention, and continued processing of my personal data. Please confirm whether my data was obtained from DVLA for this exact parking event. If not, identify the source and date of the data you are using. The charge is disputed or false because [reason]. Please restrict processing while accuracy is reviewed, stop onward sharing, correct the file, notify all recipients, and erase any data that is no longer needed or was not lawfully processed. If you refuse, explain the lawful basis, retention period, legal claim reason, and why your interests override my rights.
Sources used here