Controllers normally pay a data protection fee unless exempt
The ICO publishes a register of fee payers and guidance on the data protection fee. That is a baseline identity check, not an outcome dashboard.
ICO data protection feeTransparency register
Do not make the public beg for basic system data.
Instead of a right-of-reply page, the stronger standard is this: parking operators, debt collectors, appeal bodies, and trade bodies should publish the data that proves their systems are fair. ICO registration is only the starting point.
ICO minimum
A fee-register entry is not enough transparency.
The ICO register of fee payers can show that an organisation has paid the data protection fee and list basic controller details. It does not, by itself, show false-positive rates, DVLA request outcomes, debt referral rates, app-fault handling, disability adjustments, or court results.
Public website standard
Every parking-sector website should publish a plain data-use register.
This is a transparency demand, not a claim that the law currently forces every table below to be public. It is what a fair high-volume system should be willing to show.
| Public item | What should be published | Why the public needs it |
|---|---|---|
| ICO registration | Controller name, ICO registration reference, fee expiry, trading names, DPO or data contact, and link to the ICO register entry. | People should know which legal entity controls their data before appeal, debt, or court pressure starts. |
| Privacy and processing table | Purpose, lawful basis, data categories, recipients, processors, retention periods, and rights route in plain English. | UK GDPR transparency should be visible without digging through vague privacy wording. |
| DVLA data access | Annual KADOE requests, request reason codes, evidence checks before lookup, wrong-keeper corrections, and cancelled-after-DVLA figures. | A DVLA lookup proves access, not ticket accuracy. False positives should be counted. |
| Appeals and cancellation | First appeal cancellations, POPLA/IAS appeals, non-contests, lost appeals, disability adjustment cancellations, app/payment cancellations, and landowner cancellations. | If many charges disappear only after pressure, the public should know the burden caused by each operator. |
| Debt and court route | Debt collectors, solicitors, letters sent, added sums, Letters Before Claim, claims issued, default judgments, discontinuances, defended wins/losses, and set-asides. | Debt wording and court threats can make weak charges look authoritative before facts are tested. |
| Accessibility and vulnerability | Non-visible disability route, reasonable adjustment policy, alternative formats, phone support, pause rules, training, and outcome data. | A system that cannot see dyslexia, ADHD, autism, anxiety, low literacy, medical distress, or app barriers should show human safeguards. |
| Technology error controls | ANPR double-visit checks, grace periods, app outage logs, machine fault logs, typo policy, wrong-location-code policy, and manual review rules. | Technology can convert ordinary error into money unless correction controls are visible. |
| Supplier and money route | Landowner, managing agent, trade body, appeal handler, debt collector, solicitor, payment app, ANPR/software supplier, and fee-sharing route where lawful to disclose. | The public should see who is paid, who decides, who can cancel, and who benefits from escalation. |
Legal baseline
What the sources already support.
People should receive privacy information
ICO guidance on the right to be informed expects organisations to tell people who they are, why they process data, recipients, retention, rights, and complaint routes.
ICO right to be informedProcessing should be documented
ICO Article 30 guidance sets out records of processing activities. The public version can be simpler, but the company should be able to show the structure.
ICO Article 30 documentationWebsite wording
Suggested public-page structure for operators.
Who controls your data
Legal entity, company number, ICO registration reference, data contact, DPO where appointed, trade body route, and appeal route.
When we request DVLA data
Reasonable-cause test, evidence checked first, landowner authority, ANPR or ticket route, audit trail, and false-positive reporting.
How we correct mistakes
Paid-but-fined, app fault, machine fault, double visit, wrong registration, wrong location, wrong keeper, cloned plate, non-visible disability, and accessible communication route.
Who receives your data
Debt collectors, solicitors, landowners, managing agents, payment processors, ANPR/software suppliers, appeals bodies, and retention periods.
Our public outcomes
Ticket count, cancellation count, appeal outcomes, debt referrals, court claims, default judgments, complaints upheld, sanctions, and vulnerability pauses.
Sources