Editor’s note: This article is part of ALPRs in Focus, a Police1 editorial series examining how agencies use automated license plate reader technology, the investigative value it can provide, and current concerns surrounding privacy, data access, retention and misuse.
By Colton Overcash
A chief can write the strongest ALPR policy in the country and still discover two years into a multiyear contract that the system no longer supports the safeguards it requires.
Policy governs the agency. The vendor agreement defines what the technology provider must continue delivering, who may access agency data, how product changes will be handled, what the vendor must do when it detects activity the agency cannot see and who bears responsibility when something goes wrong.
Those questions need answers before an agency purchases or renews an ALPR system. Once the contract is signed, it helps determine whether the safeguards leadership expects will hold up for the life of the system.
Once a chief has decided what safeguards the department expects, the next job is making sure the agreement supports those expectations throughout the life of the system.
Identify which contract documents control
ALPR systems may be purchased through local solicitations, state contracts, cooperative purchasing vehicles or other public procurement mechanisms. Those options can simplify the buying process, but they do not eliminate the need to understand the agreement governing the relationship.
Before signing, identify which documents govern the relationship. The order form, master agreement, data terms, privacy provisions, acceptable-use rules and other incorporated documents may contain conflicting provisions. An agency policy or language added to a purchase order also may not override a vendor’s standard terms.
If the department negotiates an ALPR-specific rider or schedule, the agreement should state clearly that those provisions control when they conflict with the standard terms.
This may sound technical until a dispute occurs. Then counsel’s first question will be straightforward: What did the parties actually agree to?
Chiefs do not need to become contract lawyers. But procurement staff, counsel or both should confirm that the protections leadership expects appear in the agreement that controls the relationship.
Protect safeguards when the product changes
Law enforcement technology does not remain static after installation. Software is updated, interfaces change, and new features and integrations are introduced. Vendors modify workflows and improve security controls. Agencies should not try to freeze a platform in place, but they should ensure that an update does not weaken the safeguards they relied on when approving it.
If auditability, authentication, search justification, sharing restrictions or misuse detection were influenced the department’s decision to deploy an ALPR platform, the contract should identify those required capabilities.
The agreement does not need to tell the vendor how to engineer them. It can, instead, require the vendor to maintain the same level of protection throughout the contract. If a safeguard cannot be maintained, the agreement should require advance notice and specify the agency’s options or remedies..
That gives both sides flexibility. The vendor can continue innovating while the agency knows the protections it relied on will remain substantially available.
The same principle should apply when new functionality changes the risk profile of the platform. If an update adds a major data source, expands external sharing or materially changes how agency information can be accessed, the contract should establish when the agency must receive notice, be allowed to configurate or decline the featured, or provide affirmative consent are appropriate.
The procurement decision should not end on the day the cameras go live.
Make auditability a vendor deliverable
Once an agency decides what it expects supervisors and auditors to review, the contract should ensure the platform provides the information needed to so it.
Saying the platform “has audit logs” is not enough. The agreement should specify whether every search can be attributed to an individual user, whether relevant activity can be exported or reviewed by the agency, how long audit information remains available, and whether the vendor can preserve records when an internal investigation begins.
Chiefs should also ask about vendor access. Technology providers sometimes need privileged access to customer systems for support, maintenance, security or troubleshooting. The contract should define when that access is permitted, which vendor personnel may use it and whether their activity is logged. If questions later arise about whether information was accessed by someone inside the department or on the vendor side, that distinction matters.
Networked platforms create a similar issue. An agency can see what users inside their department are doing, but only the provider may be able to identify certain abnormal patterns occurring across a larger network of agencies, accounts or integrations.
If the platform offers network-level anomaly or misuse detection, the agreement should define what happens when that functionality generates a serious alert. Depending on the platform, that might include preserving the relevant audit record, notifying an agency administrator, temporarily restricting suspicious credentials under defined circumstances or escalating repeated activity.
That does not make a technology company responsible for determining whether every police search was appropriate. The agency remains responsible for its personnel and investigative decisions. It does mean the agreement should define the monitoring, record-preservation and notification functions that only the vendor can perform across the broader network.
Define data rights beyond “we own the data”
Many public safety technology agreements say the customer owns its data. That is important, but ownership is not the end of the conversation. Before signing, agencies should know what rights the agreement gives the vendor and other parties.
When may vendor personnel access agency information? Can subcontractors or cloud service providers process it? What categories of agency information, if any, may be used for product improvement or model training, and under what consent or deidentification requirements? Can the vendor create derivative information from the agency’s data? What happens when the vendor receives a subpoena or another government request for information?
The right answer may vary by product and agency. What matters is that the answer is clear.
If agency information may be used only to provide, secure and support the contracted service, say that. If some deidentified information may be used for product improvement, define the boundary. If another use requires affirmative agency approval, put that decision in writing.
Subcontractors deserve attention too. Agencies increasingly rely on technology delivered through several companies even when they sign a contract with only one.
The agreement should make clear whether the primary vendor remains responsible for ensuring that subcontractors handling agency information meet the same security, confidentiality and data-use requirements.
A chief should not have to reconstruct the data chain after an incident.
Address retention, deletion and the end of the relationship
The agency decides how long it needs ALPR information, consistent with applicable law and policy. The vendor agreement determines whether the system can reliably carry out that decision. Those are different responsibilities.
The contract should distinguish routine retention from evidence preservation. An agency may want ordinary observations deleted on a defined schedule while preserving a specific record that has become evidence in an active investigation.
It should also define what deletion actually covers.
Deleting information from the active interface does not necessarily answer what happens to backups, exported records or other copies. The agreement should explain how those are handled and allow the agency to obtain confirmation that deletion occurred according to the agreed retention schedule, subject to documented backup cycles, legal holds and other applicable retention obligations.
The same planning should occur before termination.
If the department changes providers, it should know in advance how to retrieve records it is legally required to maintain, what export formats are available, how long the retrieval window lasts, what transition costs apply, whether audit records remain available and when the former provider will delete what remains.
Exit terms are easy to ignore when everyone is excited about deployment. They become considerably more important when the relationship ends.
Make liability follow control and causation
Contracts also need a sensible answer to the most difficult question: Who owns the failure? A useful starting point is that liability should follow control and causation.
If an employee deliberately misuses a properly functioning system, r esponsibility should generally rest with the agency.
If the agency provides inaccurate information, responsibility should generally rest with the agency.If a vendor employee improperly accesses agency data, responsibility should generally rest with the vendor.If the provider expressly agrees to maintain a security, authentication, deletion or auditing control and fails to do so, responsibility should generally rest with the vendor.Not every incident will divide that cleanly. If both parties contributed to a failure, the agreement should allocate responsibility according to each party’s role rather than force every event into an all-or-nothing category.
The point is not to transfer every risk to the technology company. That would be commercially unrealistic and could ultimately make procurement more difficult.
Likewise, risks arising from functions exclusively controlled by the provider should be addressed expressly rather than left ambiguous under general software terms.
Ordinary commercial disputes can continue to have ordinary contractual limits. Procurement officials, counsel and risk managers can separately decide how the agreement should handle defined vendor-caused security incidents, unauthorized vendor access, breaches of specific data protections or failures of controls the vendor expressly promised to maintain.
That may involve different liability limits, indemnification, cyber insurance, incident costs or other remedies appropriate to the agency and contract.
The important part is deciding before the failure occurs.
A better contract should work for both sides
None of this requires turning procurement into a hostile negotiation. Good vendors benefit when responsibilities are clear.
A well-structured agreement reduces disputes over what the agency thought it was buying, gives product and legal teams clearer expectations, and rewards companies that have invested in security, privacy, auditability and responsible data practices.
It also helps protect the agency’s investment in the technology.When misuse or another high-profile failure occurs, chiefs and elected officials need to be able to explain not only what the department’s policy requires but also what protections the technology provider is contractually obligated to maintain.
That gives agency leaders a stronger basis for deciding whether an incident calls for employee discipline, stronger controls, a contractual remedy or reconsideration of the system itself.
A chief’s policy defines how the department expects ALPR technology to be used.
The vendor agreement determines whether the technology must continue supporting those expectations after the purchase is made.
That is why procurement should not be treated as paperwork that comes after ALPR governance. It is where part of that governance becomes durable.
About the author
Colton Overcash is the founder of Vertex Strategies, a Charlotte-based government relations and strategic advisory firm with a presence in Washington, D.C. He regularly writes and comments on technology, public safety, and national security. He previously held two presidential appointments at the U.S. Department of Homeland Security during the Trump administration and served on the staffs of U.S. Sen. Thom Tillis and U.S. Rep. Virginia Foxx.
