Why ANPR Triggers UK GDPR the Moment a Plate Is Read
The instant your system reads a vehicle registration mark (VRM), UK GDPR applies. The ICO is explicit on this point: in most circumstances, a VRM is personal data. It is a unique mark linked to a specific vehicle, and when your ANPR system processes it as part of a surveillance or parking system with the intent of identifying an individual or taking some action against them, it becomes personal data at the point of collection. The purpose of the system means you are likely, at some stage, to link that plate to a registered keeper or driver, even if you never personally perform that lookup yourself.
ANPR systems also commonly supplement the plate string with additional information such as the date, time and location of the vehicle. That combination makes the personal data picture considerably richer. The Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025 and amends the UK GDPR and the Data Protection Act 2018, keeps this legal framework firmly in place. Its provisions are being commenced in stages, with the main data protection changes taking effect from late 2025 and into 2026, but the core obligations described in this article apply in full now. The ICO's video surveillance guidance explicitly names ANPR alongside CCTV, body-worn video and facial recognition as technologies that must comply with UK GDPR and the DPA 2018.
This checklist walks through every decision point a development team hits when wiring up a number plate recognition API: from choosing a lawful basis before the first line of code is committed, to answering a Subject Access Request (SAR) within the required timeframe.
Section 1: Is a DPIA Mandatory? Yes, Always
The ICO's ANPR guidance states plainly that regardless of the sector you operate in, if you are using or intend to use an ANPR system, you must undertake a Data Protection Impact Assessment (DPIA) prior to deployment. This is not discretionary. Article 35 of the UK GDPR requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of individuals. ANPR meets that threshold on its face: it involves technology capable of systematic monitoring of individuals, large-scale processing of personal data, and automated decision-making that can produce real-world effects such as a parking charge notice or a gate that refuses entry.
Critically, the DPIA must be completed before processing begins. Conducting a retrospective DPIA to document a decision already implemented does not satisfy the requirement and does not cure the breach that arose when processing started without one. The ICO has issued enforcement notices for this kind of failure, treating the absence of a DPIA as a standalone breach independent of whether any harm to an individual actually occurred.
Your DPIA for an ANPR integration must cover: the purpose and necessity of the processing; which personal data fields are captured and retained; who has access; the lawful basis relied upon; the risks to data subjects and how those risks are mitigated; and the Data Processing Agreement you have in place with any third-party API provider. The DPIA is a living document and should be reviewed whenever the system changes materially, for example when you add the vehicle data enrichment flag to your API calls or extend a retention period.
Section 2: Choosing Your Lawful Basis
UK GDPR Article 6 requires you to identify a lawful basis before processing begins. For ANPR deployments, three bases are most commonly relevant.
Legitimate Interests
Legitimate interests is the most widely used basis for private-sector ANPR. You must complete a three-part test: identify a legitimate interest, demonstrate that processing is necessary to achieve it, and balance your interest against the rights and reasonable expectations of the individuals being scanned. For a car park operator enforcing a two-hour limit, that balance is usually achievable. For a retailer building marketing profiles from footfall patterns derived from plate reads, it almost certainly is not. Document the balancing test in your DPIA.
Contractual Necessity
Where a driver has entered into an agreement, for example a workplace parking permit scheme or a fleet telematics contract, contractual necessity may be the cleaner basis. The processing must be genuinely necessary to perform that contract, not merely convenient. Fleet operators tracking vehicle location for proof of delivery will often rely on this basis, combined with legitimate interests for ancillary uses such as route optimisation.
Legal Obligation and Public Task
Forecourt fuel theft prevention, where a retailer is legally entitled to retain plate data to report drive-offs to police, typically relies on legal obligation or legitimate interests. Operators subject to statutory duties, such as councils running congestion charge schemes, may rely on a public task basis. In each case, the basis must be recorded before go-live and communicated to data subjects in the privacy notice.
Section 3: Data Minimisation in Practice
UK GDPR's data minimisation principle requires that personal data processed is adequate, relevant and limited to what is necessary for the purpose. For an ANPR integration, this translates into a set of concrete architectural decisions.
The most important decision is what to do with the source image. In most private-sector deployments, the image itself serves no ongoing compliance purpose once the plate string has been extracted and a confidence score returned. Retaining raw image files of every vehicle that passes a camera creates a data store far larger in scope than your purpose requires. Each image may also capture vehicle occupants, introducing an additional category of personal data your system never intended to hold.
A cloud number plate recognition API that processes images transiently and returns only the plate string, confidence score and optional structured vehicle data offers a cleaner architecture. When you POST an image to the recognition endpoint, the recognition happens server-side. If the API vendor operates a zero-retention model, no image is stored on their infrastructure after the response is returned. Your application receives a JSON payload containing the fields you need, and the raw image never persists beyond the request lifecycle. This is data minimisation by design, not by policy.
On the application side, only log what your purpose demands. For parking enforcement, you need the plate string, the entry timestamp, the exit timestamp and, where an overstay is detected, a record sufficient to issue a charge notice. You do not need the source image or any supplementary data fields you are not actively using. If you enable the vehicle=true parameter to retrieve make, model and colour from DVSA data, only retain those fields if your stated purpose requires them. Enabling enrichment flags and immediately discarding the output is better than storing data you have no need for, but enabling flags you have no use case for at all should be avoided entirely.
Section 4: Retention Periods and Deletion Schedules
The ICO does not prescribe a fixed retention period for ANPR data. It is the purpose of your processing that must determine your retention period. You should keep data only for the minimum period necessary and delete it once you no longer need it.
The ICO's own worked example makes this concrete. A gym uses an ANPR system to monitor its car park with a two-hour parking limit. The system retains details for vehicles that exceeded the limit and also for vehicles that did not. The ICO's position is that there is likely no need to retain information for an extended period for vehicles that adhered to the time limit, and that doing so would be unnecessary and excessive unless there was a justifiable reason. The gym would need to amend its system to delete data about vehicles that are not of interest as soon as appropriate.
Translate this into engineering terms: your retention logic should be event-driven, not schedule-driven. A vehicle that exits within the permitted period should have its record purged automatically on exit confirmation, or within a short grace window. A vehicle that triggers an enforcement action should have its record retained only for the duration of the enforcement process and any reasonable appeal period, after which it too should be deleted. Do not determine your retention period based on available storage capacity. Do not retain data just in case. Build automated deletion jobs and test them. Document the retention schedule in your DPIA and your privacy notice.
Section 5: Confidence Scores and Misidentification Risk
Every number plate recognition system produces a confidence score alongside the plate string. In the NPR API response, this is returned as an integer between 0 and 100. This figure is not merely a performance metric; it is a compliance data point.
A low-confidence read that triggers an automated enforcement action, a gate refusal or a charge notice creates a concrete risk of harm to a data subject who was misidentified. UK GDPR's accuracy principle requires that personal data is accurate and, where necessary, kept up to date. Taking enforcement action on a read with a confidence score of, say, 60 is likely to result in inaccurate processing, and any downstream effect on the misidentified individual is a foreseeable harm your DPIA should have assessed.
The engineering response is to define a minimum confidence threshold below which no automated action is taken. Reads below the threshold should be flagged for human review rather than fed directly into enforcement or access-control logic. Where automated decisions produce legal or similarly significant effects, Article 22 of the UK GDPR imposes additional requirements: you must inform data subjects that such decisions are being made, offer a route to human review, and be able to explain the logic. The Data (Use and Access) Act 2025 introduces a revised framework for automated decision-making that permits wider use of such decisions provided appropriate safeguards are in place; your DPIA should reflect whichever regime applies at the point of your deployment. Document your threshold, the rationale for it and the human review process in your DPIA. If you adjust the threshold later, treat the change as a material system change and update the DPIA accordingly.
In multiple-plate mode, the API returns a plates array where each entry includes a registration, a confidence integer and a country field in ISO 3166-1 alpha-2 format where the plate origin is identifiable. Apply the same confidence threshold logic to each entry in the array before any of those results feed downstream systems.
Section 6: Signage, Transparency and Privacy Notices
Transparency is not optional and it cannot be retrospective. The ICO states that the best way to inform individuals that ANPR processing is taking place is through clear and visible signage explaining the recording, together with the name of the controller collecting the information.
Signage must be in place before a vehicle enters the ANPR zone, not after. For car parks, this means signs at every entrance point. For road-based deployments, signs must be positioned with enough lead time for a driver to read them before the camera reads the plate. The ICO specifically notes that the reading time available to drivers on high-speed roads is a material consideration. Signs must be clear, legible and unobscured by other notices or vegetation.
The sign itself is a condensed privacy notice. It should state: that ANPR is in operation; the identity of the data controller; the purpose of the processing; and how to access the full privacy notice, typically via a website URL. The full online privacy notice must include all the information required by Articles 13 and 14 of UK GDPR: the lawful basis, the retention period, data subject rights (access, erasure, objection, restriction) and the right to complain to the ICO. If you are enriching plate data with vehicle information via the API, the privacy notice must reflect that enrichment.
Social media posts and website notices are recognised supplementary channels, but they do not replace physical signage for in-person ANPR deployments. If your integration serves a product that drivers encounter without prior digital engagement, physical signs are non-negotiable.
Section 7: Subject Access Requests and the Right to Erasure
A data subject can exercise their right of access under Article 15 of UK GDPR, requesting a copy of all personal data you hold about them, including ANPR records. The standard response deadline is one calendar month from receipt. The Data (Use and Access) Act 2025 introduced refinements to the SAR framework, including that searches need only be reasonable and proportionate, but the one-month deadline and the obligation to respond fully remain. Extensions for complex or numerous requests are available provided you notify the requester within the first month.
Build your system to support this from day one. Your data store must be queryable by VRM so that you can retrieve all records associated with a given plate within the response window. You must also be able to provide the processing context: when the read occurred, the purpose, the lawful basis and any third parties with whom the data was shared. If your architecture is event-driven and you have followed the minimisation principles above, the data held will be limited and retrieval straightforward. If you have retained source images, you will need to consider whether those images fall within the scope of the SAR and, if they contain images of vehicle occupants, whether redaction is required before disclosure.
The right to erasure under Article 17 applies where the data subject objects to processing based on legitimate interests and there are no overriding grounds, or where the data is no longer necessary for the purpose for which it was collected. Your deletion jobs, tested and documented as part of your retention schedule, should make erasure requests mechanically simple. Log erasure events with a timestamp so you can demonstrate compliance during an ICO audit.
The ICO's ANPR guidance explicitly requires efficient governance procedures to retrieve stored data and process it for subject access requests or onward disclosures where required. This is an audit expectation, not merely good practice.
Section 8: Third-Party Data Processors and API Vendors
When you send an image to a cloud recognition API, you are engaging a data processor. Article 28 of UK GDPR requires a written Data Processing Agreement to be in place before processing begins. That agreement must specify what personal data is being processed, the purposes and duration of processing, the nature and type of processing, the data subject categories involved, and the obligations of the processor. It must also require the processor to implement appropriate technical and organisational security measures, to assist you in fulfilling data subject rights, and to return or delete personal data at the end of the contract.
From a compliance architecture standpoint, the single most important contractual question to ask an API provider is whether they retain submitted images or any extracted personal data after returning the response. A zero-retention model, where the image is processed in memory and deleted immediately after the JSON response is generated, means the processor's exposure to your data subjects' personal data is minimal and time-limited. This has a direct impact on your DPIA risk assessment: the risk profile of a processor that retains no data is substantially lower than one that stores submitted images, even temporarily.
Review the API vendor's sub-processor list, their data residency commitments (relevant for UK GDPR international transfer compliance), their incident response obligations and their audit rights provisions. Ensure the agreement explicitly covers what happens to personal data if you terminate the contract. A vendor who can provide a completed Article 28 Data Processing Agreement, clear documentation of their zero-retention processing model, and evidence of appropriate security certifications gives your DPO the paper trail needed to support your DPIA and to answer regulator questions confidently.
ANPR and UK GDPR: Compliance Checklist for Developers and DPOs
Share this checklist with your DPO before go-live. Each item maps to a UK GDPR obligation or ICO expectation.
Legal foundation
☐ Confirmed that VRMs processed by your system constitute personal data in context.
☐ Identified and documented the lawful basis under Article 6 for each processing purpose.
☐ Completed and signed off a DPIA before any live data was processed.
☐ DPIA reviewed and updated whenever the system changes materially.
Data minimisation and retention
☐ Source images discarded immediately after plate extraction, or confirmed not stored by the API vendor.
☐ Only data fields actively required by the stated purpose are retained in your application database.
☐ Retention schedule documented, purpose-driven and enforced by automated deletion jobs.
☐ Deletion jobs tested and deletion events logged with timestamps.
☐ Data for vehicles not of enforcement interest deleted promptly after their session ends.
Accuracy and automated decisions
☐ Minimum confidence threshold defined and enforced before any automated action is triggered.
☐ Reads below the threshold routed to human review, not automated enforcement.
☐ Article 22 obligations assessed and documented where automated decisions produce legal or significant effects.
Transparency
☐ Clear, legible ANPR signage at every entry point, present before cameras capture any plate.
☐ Signs include controller identity, processing purpose and a link to the full privacy notice.
☐ Full privacy notice published and accessible, covering lawful basis, retention period and data subject rights.
Data subject rights
☐ System queryable by VRM to support Subject Access Requests within the one-month window.
☐ Erasure request process documented and tested.
☐ Audit log of all erasure events maintained.
Third-party processors
☐ Article 28 Data Processing Agreement in place with the API provider before the first live API call.
☐ API vendor's zero-retention model confirmed in writing and reflected in the DPIA.
☐ Sub-processor list, data residency and security posture reviewed.
☐ ICO registration up to date, covering ANPR processing activities.
Testing Your Integration Before Sign-Off
NPR API operates a zero-retention processing model: submitted images are processed in memory and not stored after the response is returned, directly supporting the data minimisation and processor obligations described in this article. A free tier is available at nprapi.com to test the integration before your DPIA goes for sign-off. The recognition endpoint accepts a multipart/form-data POST to https://nprapi.com/api/v1/recognise with the image sent as the image field and your key in the X-API-Key header. Add vehicle=true as a form field or query parameter to receive DVSA make, model and colour data alongside the plate string and confidence integer. Full documentation is at https://nprapi.com/docs.