Flock Safety Updates Policies Following Utah Privacy Probe

The firing of an Itasca police officer for misusing license plate reader (LPR) technology isn't an isolated incident of a "bad apple." It's a failure of purpose limitation. When the Governor of Utah says he's deeply troubled by Flock cameras, he's reacting to a systemic gap between how these tools are marketed and how they're actually operated in the field.

The operational idea here is Article 5(1)(b) of the GDPR—the principle of purpose limitation. It mandates that data be collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those purposes. In the surveillance sector, "public safety" is treated as a blanket justification. But there's a world of difference between tracking a suspect in a kidnapping case and an officer using a database to keep tabs on someone for personal reasons.

Flock Safety is now tightening its policies. This is a reactive move. The company sells the hardware and the software, but it doesn't sell the governance needed to ensure the data stays within its legal lane.

It's a paper shield.

We see this same pattern in other SaaS verticals. Take tl;dv, which leaked over 180,000 meeting records because of a vendor failure. They had a SOC 2 certification. The point is that a certificate proves an auditor saw a policy on a screen; it doesn't prove the policy actually stopped data from leaking into the wild. Whether it's LPR cameras in Utah or AI-transcribed meetings, there's a recurring trend of "compliance by checklist" where the actual risk—human misuse or vendor fragility—is ignored.

The strongest objection here is that the technology is neutral. The argument goes that a camera doesn't commit a privacy breach; the officer who queries the database does.

That's an easy out for the vendor. If you build a system that allows near-instant, low-friction access to sensitive movements of citizens without mandatory, logged justification for every search, you haven't built a neutral tool. You've built a temptation. True privacy by design would mean building technical friction into the query process—not just writing a policy manual that an officer can ignore until they're unemployed.

The second-order effect here will hit municipal insurers. Small towns and city governments rarely have the internal expertise to audit their own data flows. They rely on the vendor's claim that the system is "compliant." When these systems lead to civil rights lawsuits or state-level privacy probes, the insurance companies providing liability coverage for those municipalities will start looking at the indemnity clauses.

If a city can't prove it exercised due diligence in overseeing the data, insurers may refuse to cover the settlements. This shifts the financial risk from the tech provider back to the taxpayer and the local government.

We're seeing this friction bubble up everywhere. GDPR fines hit €225 million in the second quarter of 2026 alone. Even smaller entities are feeling it; the Data Protection Office recently ordered a board at Mukumu Girls school to pay Ksh 300,000 for a breach. The scale varies, but the cause is usually the same: believing that having a tool is the same thing as managing a tool.

I'll change my mind when I see a surveillance vendor implement hard-coded technical blocks that prevent queries without a verified case number. Until then, "updated policies" are just PR for a product that remains fundamentally dangerous to the public.

Watch whether Utah's review results in a ban or just another set of guidelines that will be ignored until the next officer gets fired.