License plate reader data: retention, sharing, and audits

Reference article · 5 min read

Automated license plate readers are usually bought as a hot list tool. A camera reads a plate, the system compares it against lists of stolen vehicles, wanted persons, and missing persons, and an officer receives an alert. What draws scrutiny is everything else the system keeps: the reads that matched nothing, which together form a searchable history of ordinary vehicle movement through the jurisdiction.

Nearly every hard question about an ALPR program is a policy choice, not a technical one: how long non-hit reads are kept, who may query them and on what basis, where the data goes after it leaves your system, and whether you can prove months later who ran what. Those choices belong in a written policy adopted before the cameras go live.

Retention of non-hit reads

A read that matches a hot list becomes part of an investigation and follows evidence retention rules. Non-hit reads are the policy problem: they are the bulk of the collection, and no individualized suspicion attaches to them.

Start with state law. Some states cap how long reads may be held, in some cases at a very short period. Others leave it to the agency or to a local ordinance. Requirements here have been changing, so confirm the current rule with counsel rather than copying another jurisdiction's policy. Where you have discretion, set the period from investigative reality rather than storage pricing: ask detectives how far back queries actually reach in cases that closed, then allow a margin.

• Purge automatically. Deletion should run on a schedule with no one having to act, and the vendor should be able to show that purged reads are gone from replicas and backups on a defined timeline.
• Separate evidence from the pool. Export case-relevant reads into the case file, so a routine purge never destroys evidence and a hold never forces you to preserve the whole database.
• Align with your records schedule. Reads and query logs are both records, and each needs a place in your approved schedule.

Who may query, and on what predicate

Access control is where audits usually find problems. Issue named accounts, never shared logins, tie each to a role with a defined scope, require training and a signed policy acknowledgment before credentials are issued, and remove access on transfer or separation.

Then require a predicate for every query. A structured reason code plus a case or incident number is far more auditable than a free text box, because it can be checked against the records management system. State prohibited uses explicitly: personal curiosity, checking on acquaintances, monitoring attendance at a lawful protest or a place of worship, and any purpose your state restricts. Require supervisory approval for pattern analysis, co-travel searches, and bulk exports, which support much broader inference than a single plate lookup.

Sharing, regional networks, and out-of-state access

Data leaves the agency by three paths, each needing its own decision.

• Agency to agency. Regional and statewide networks let neighboring jurisdictions query your reads. Approve partners by name, in an agreement that states permitted uses, prohibits onward sharing without your consent, and preserves your right to audit.
• Vendor operated networks. Some platforms offer broad sharing with other customers through a setting. Treat it as a leadership decision, inventory who receives your data today, and re-approve that list on a schedule.
• Commercial and private reads. Some vendors sell access to reads collected by repossession, parking, and other private operators. That data has different provenance and accuracy, and different rules may govern its use.

Out-of-state and federal access deserves its own paragraph. Several states now limit or prohibit sharing ALPR data with out-of-state or federal agencies, or bar its use in certain categories of investigation. These provisions differ and are amended often, so verify the current text with counsel and confirm your platform can enforce the limit you adopt.

The audit trail and periodic review

A program is defensible when the agency answers questions with records instead of assurances. Log for every query the user, the timestamp, the search terms, the reason code and case number, the results, and any export, and log sharing events too. Keep logs longer than the reads themselves, since questions often arrive after the underlying data is purged, and make sure logs cannot be edited by the people they cover.

Then put a recurring audit in the policy, with a named owner and a set cadence. A workable version samples queries at random, checks each against the case record its reason code names, and documents the outcome, including what happened when a query could not be justified. Report results to the chief or director, and where a surveillance ordinance applies, to the governing body. Decide in advance, with counsel, how you will handle records requests for reads, logs, and audit findings: disclosure rules vary by state, and investigative exemptions do not always cover aggregate logs.

What to ask before you sign

• Can retention be set by data category, and can the vendor evidence deletion from backups and replicas, not just from the interface?
• Are sharing relationships controlled by the agency, off by default, and visible in a list the agency can export?
• Can the system report, on demand, everything one user did over a period and everyone who searched a given plate, and can the agency export the full log?
• Who owns the data, what happens to it at termination, and does the contract bar vendor use of agency reads for product development or resale?
• Where the system handles criminal justice information such as federal hot list data, does the vendor meet the applicable CJIS Security Policy requirements?

HQT builds and integrates public safety systems for state and local agencies, including the access control, audit logging, and data lifecycle work that turns an ALPR policy into something the system enforces.

Frequently asked questions