The Policy Update is a Confession

Flock Safety is tightening its camera policies. This move follows the Governor of Utah expressing he's "deeply troubled" by the technology and an Itasca police officer losing his job after misusing license plate readers.

In the compliance world, this is usually framed as "proactive governance." The company identifies a friction point—in this case, users doing things they shouldn't—and updates the rulebook to forbid it. They tell their clients and the public that they’ve addressed the concern by refining the policy.

They're wrong. A policy update isn't a fix; it's a written confession that the product was built without actual controls.

When a company "tightens policies" in response to misuse, they are admitting that the system allowed the misuse to happen in the first place. If an officer can use a surveillance tool to stalk a neighbor or track someone for personal reasons, the flaw isn't in the officer's ethics. The flaw is in the software architecture.

This is where we get into the gap between "privacy by design" as a marketing slogan and GDPR Article 25.

Article 25 requires data protection by design and by default. This doesn't mean writing a PDF that tells employees not to be creeps. It means implementing technical and organizational measures—like hard-coded access logs, purpose-limitation triggers, and automated deletions—that make the forbidden action technically impossible or instantly detectable.

If you can "fix" a privacy leak by updating a policy, it means you never actually designed for privacy. You just designed a tool and then hoped the people using it would be honest.

The counter-argument is always the same: "We cannot predict every possible misuse case, and we cannot lock down a system so tightly that it becomes useless for legitimate law enforcement."

That's a lazy excuse. You don't need to predict every crime to build an immutable audit log. You don't need a crystal ball to ensure that a query for a license plate requires a linked case number before the data is revealed. When those guards are missing, you haven't built a professional tool; you've built a toy with high-stakes consequences.

The second-order effect here hits the municipal governments and police departments buying these cameras. These agencies think they're purchasing "compliant" technology. In reality, they're inheriting a massive liability. They are relying on the vendor's policy to protect them from lawsuits, but policies don't stop data misuse—they only provide the evidence needed to prove the misuse was possible.

We see this pattern across the board. GDPR fines hit €225 million in the second quarter of 2026. While the headlines focus on the totals, look at the specific failures. Look at the Data Protection Office ordering the board of Mukumu Girls school to pay Ksh 300,000. That fine wasn't just about a "breach"; it was for the fundamental failure to protect student data from unauthorized exposure.

The lesson is simple: if your primary response to a privacy scandal is to update your Terms of Service or your Internal User Guide, you haven't solved the problem. You've just documented the vulnerability for the next regulator who comes knocking.

Regulators don't care about the rules you wrote after the fact. They care about the controls you failed to build at the start.

I'll change my mind when I see a vendor announce a feature that physically prevents the misuse they previously tried to forbid with a policy. Until then, every "updated policy" is just a map for the auditors.

The Itasca officer didn't fail the policy; the system failed to stop him.