If your police department uses Flock or another automated license plate reader system, look for its written ALPR policy.
That policy can answer important questions:
Who is allowed to use the system? What kinds of investigations justify a search? Can information be shared outside the department? How long is data kept? Are searches audited? What happens when someone violates the rules?
Those answers matter.
But a policy has limits.
A policy tells you what the agency says should happen.
It may not tell you every capability the technology has, every setting currently enabled, every outside agency with access, whether supervisors regularly review audit logs or how the system has actually been used.
Keep the four layers separate throughout your review:
vendor capability → local configuration → written policy → actual use
A good policy can reduce risk. It is not proof that the technical settings match it or that every search followed it.
Use this quick policy checklist.
Look for clear answers on:
- when a search requires a warrant, court order, case number or other threshold;
- which search reasons users can enter and whether free text is allowed;
- who can create hot-list alerts and when alerts expire;
- who approves accounts and removes access;
- whether supervisors review audit logs, how often and using what criteria;
- which agencies, networks or private partners can receive or provide data;
- routine retention, evidence preservation, downloads and exports;
- independent verification before an alert becomes enforcement action; and
- discipline, notification and correction when policy is violated.
First: make sure you have the current policy.
Check the effective date, revision date, policy number and approval authority.
If you found an older policy and the department changed its ALPR program later, keep looking.
Older policies can still be useful for understanding how the program evolved.
They should not automatically be treated as current.
Look at what the policy says its purpose is.
Policies often begin by explaining why the department uses ALPR.
That might include locating stolen vehicles, finding wanted persons, investigating crimes, locating missing or endangered people, developing investigative leads or another public-safety purpose.
Write down that stated purpose.
Later ask:
Does actual use stay within that purpose?
And:
Does the department now use capabilities that go beyond what the original policy describes?
Find the definition of ALPR.
This can reveal how broadly the department understands its own system.
A narrow definition might describe cameras capturing license plates and associated vehicle information.
A broader policy may also discuss historical searches, hot lists, alerts, vehicle characteristics, data sharing or integrated systems.
Compare the policy definition with what the actual vendor platform can do.
Who is authorized to use it?
Look for phrases such as authorized personnel, trained personnel, sworn personnel, investigative personnel or users approved by the system administrator.
Then ask what that means in practice.
Does access include patrol officers, detectives, dispatchers, crime analysts, command staff, civilian employees or task-force personnel?
You usually do not need everyone’s personal information to understand the access structure.
Does the policy require individual accounts?
It should be possible to connect searches with the person who performed them.
Look for unique credentials, password security, prohibitions on shared accounts or individual authentication.
Accountability is much weaker if several people can use the same login.
Read: ALPR Hits, Traffic Stops & False Matches →
What searches are allowed?
Look for the permitted purposes.
Examples may include active criminal investigations, stolen vehicles, missing or endangered persons, wanted persons, Amber Alerts, specific investigative leads or another documented law-enforcement purpose.
Then look for broad language such as legitimate law-enforcement purpose or official business.
Those phrases may be appropriate.
They can also leave considerable discretion.
Ask:
What qualifies?
Does every search require a reason?
Look for a case number, incident number, search-reason category, free-text explanation or another documented justification.
Then ask:
Can someone simply choose a broad category and search?
or:
Does anyone independently review the justification before access occurs?
Those are different safeguards.
Prior approval and later auditing are not the same thing.
Suppose the policy says all searches are audited.
Good.
That means searches can be reviewed afterward.
But ask whether any category of search requires approval beforehand.
The distinction is:
permission before the search
versus:
accountability after the search.
Both can matter.
What uses are prohibited?
Look for explicit prohibitions against personal use, harassment, searches based solely on protected characteristics, immigration enforcement where restricted, traffic enforcement where restricted, political activity or searches unrelated to legitimate law-enforcement purposes.
Clear prohibitions are better than vague expectations.
Then ask:
How are those prohibitions technically or administratively enforced?
A written rule is useful.
A technical restriction can be stronger.
Does the policy address sensitive investigations?
Some jurisdictions have specific restrictions around immigration, reproductive healthcare, gender-affirming care, political activity, religious activity or other legally protected or sensitive conduct.
Do not import another state’s policy and assume it applies in Michigan.
Read the actual local rule and current law.
Look for hot-list rules.
The policy should help explain which lists are authorized, who may create local alerts, how locally entered vehicles are approved, how long entries remain active and how officers should verify hits before acting.
Ask:
Can any authorized officer create an alert?
Does a supervisor approve locally entered vehicles?
When are obsolete entries removed?
Verification before enforcement matters.
An ALPR alert can be wrong because of a plate misread, stale database information, a plate attached to a different vehicle or another mismatch.
Look for language requiring officers to visually confirm the plate, check the vehicle description, verify the underlying hot-list record or otherwise corroborate the alert before enforcement action.
A policy that treats the machine as an investigative lead is much safer than one that treats an automated match as unquestionable fact.
Find the retention rule.
Record the exact local language.
Do not substitute a generic vendor number.
The local policy, configuration and contract are more useful than saying:
Flock keeps everything for X days.
Ask whether the policy distinguishes routine data from evidence.
A policy may say routine detections are deleted after a set period.
Then it may allow selected records to be preserved as evidence in an active investigation, case file, prosecution or other lawful record.
Those are different retention rules.
Make sure public descriptions do not collapse them together.
Look for sharing rules.
Search for words such as share, partner agency, outside agency, regional, network, request, dissemination or authorized law-enforcement agency.
You want to know who can receive local information, whether local users can search information generated elsewhere, who approves sharing and whether sharing relationships are reviewed periodically.
Does the policy require written sharing agreements?
Some agencies may require memoranda of understanding, written approval, mutual-aid relationships or another formal process.
Others may allow broader platform sharing under internal authorization.
Neither should be assumed.
Find the actual local rule.
Then compare it with the current sharing configuration.
Policy and configuration should match.
Suppose a policy says data may only be shared with Michigan law-enforcement agencies.
Then records show the technical system is configured more broadly.
That is a problem even if nobody intended misuse.
The reverse can happen too: the technology may technically allow broad sharing while local configuration properly blocks it.
That is why we distinguish:
what the policy permits
from:
what the software currently allows.
Find the audit section.
A strong policy should explain more than:
Searches may be audited.
Look for who reviews logs, how often, what is reviewed, how irregular searches are identified, how long audit records are retained and what happens if misuse is discovered.
“Can be reviewed” is weaker than “is reviewed.”
Compare:
Supervisors may review audit logs.
with:
A supervisor shall review audit logs quarterly.
The second creates an actual obligation.
If the policy only says review is possible, ask whether regular reviews occur anyway.
Look for misuse consequences.
A policy may say unauthorized use can result in discipline, loss of access, internal investigation, criminal referral or other consequences.
That matters.
But also ask:
How would the department know misuse happened?
Consequences have limited preventive value if nobody reviews activity.
Find the training requirement.
Who receives training? Before access? How often is refresher training required?
Does training cover search reasons, privacy, verification, sharing, auditing, hot-list use and misuse?
A technologically sophisticated system deserves more than:
Here’s your login.
Look for a system administrator.
Policies often identify someone responsible for user accounts, camera configuration, sharing, training, audits or data management.
Ask:
Who has authority to change settings?
A governing body may approve a system once, but day-to-day configuration decisions can materially change its surveillance footprint later.
Can settings change without elected-official approval?
Can department staff change retention, sharing partners, user roles, alert settings or software capabilities without returning to the governing body?
That may be lawful under local authority.
Residents should still understand where ongoing decision-making power sits.
Does the policy mention newer analytical capabilities?
An older ALPR policy may focus on plates, hot lists and alerts.
Modern platforms can also include vehicle-description searching, natural-language searching, visual search, association or convoy analysis, video integration and other analytical capabilities.
If the department has newer software but the policy still reads as though the system only matches known plates, ask whether the policy needs updating.
Silence does not automatically mean a feature is allowed.
If a policy does not mention FreeForm, Convoy Search or another newer product, do not immediately conclude officers can use it however they want.
Maybe the department does not have the feature. Maybe another general rule covers it. Maybe another policy applies.
The correct conclusion is:
This policy does not answer the question.
Then investigate further.
Does the policy address third-party or privately owned cameras?
If the platform can incorporate information generated by businesses, schools, neighborhoods, campuses or other private organizations, ask whether local policy governs access to that information.
Government use of privately generated surveillance data can expand the effective network beyond government-owned hardware.
Does the policy address federal access?
Do not assume either answer.
Look for rules governing federal agencies, task forces, immigration authorities or other external organizations.
If the policy is silent and this matters locally, find the sharing records.
Look for periodic review of the program itself.
The strongest policies may require periodic evaluation of effectiveness, privacy, training, audits, retention or continued need.
If the policy has no review requirement, officials can still request one before renewal.
A surveillance program should not become permanent merely because the policy never asks whether it should continue.
What a strong policy might include
Useful safeguards can include:
- clearly limited purposes;
- individual user accounts;
- documented search reasons;
- verification requirements;
- limited access;
- clear sharing rules;
- short routine retention;
- regular auditing;
- meaningful consequences for misuse;
- training;
- and periodic program review.
Those safeguards can reduce harm.
They do not resolve our objection to mass collection itself.
Warning signs worth questioning
A policy deserves closer scrutiny if it relies heavily on vague phrases such as law-enforcement purpose without further explanation, allows large categories of users without role distinctions, permits broad sharing without an approval process, says audits may occur but establishes no review practice, contains no verification language for alerts, has no clear retention period, does not address misuse or appears significantly older than the technology currently deployed.
One weak clause does not prove abuse.
It tells you where to ask questions.
Compare the policy with the contract.
The contract may reveal products the policy never mentions, different retention language, additional software or broader integrations.
The policy may impose stricter rules than the contract.
That is fine.
Contract = what was purchased and agreed.
Policy = how the agency says it will use it.
Neither replaces the other.
Beverly Hills demonstrates why this comparison is necessary. Its signed June 2025 order states a 90-day retention period, while its August 2026 General Order says Flock will purge hosted data after 30 days. That discrepancy does not by itself prove which setting is active or why the documents differ. It creates a precise records question: publish the current configured retention value and any amendment or administrative record that changed it.
See the Beverly Hills policy and contract comparison →
Compare the policy with the transparency portal.
If the portal and policy appear to disagree, clarify why.
Maybe the policy sets a maximum while the actual configuration is shorter. Maybe one source is outdated.
Ask.
Do not immediately assume wrongdoing.
Compare the policy with audit evidence.
This is where actual use enters the picture.
A policy alone cannot establish that every search complied with the policy.
Audit evidence can help answer that question.
Compare the policy with vendor capability.
The vendor may offer capabilities the local policy never mentions.
That does not prove local users have them.
It can produce a useful question:
Does our current subscription include this feature, and if so, what policy governs its use?
A five-minute policy review
Find these ten things:
- Current revision date
- Who may access the system
- Permitted search purposes
- Required search justification
- Hot-list and alert rules
- Verification before action
- Retention
- Sharing
- Audit requirements
- Misuse consequences
Then ask:
What important question does this policy still not answer?
That is usually your next research task.
A strong policy can still govern a system we oppose.
Imagine an agency has tight access, good training, excellent audit review, short retention, limited sharing, strong verification and responsible leadership.
That is clearly preferable to weak controls.
We can acknowledge every one of those safeguards.
And still say:
We do not believe government should routinely build searchable movement records on ordinary drivers.
Transparency and strong policy make the disagreement clearer.
They do not settle whether the surveillance infrastructure should exist.
How to Read a Flock Transparency Portal →