Flock Safety has become one of the most controversial names in security technology.
Automated license plate readers record vehicle data to help police investigate crimes, locate wanted vehicles, and trace movements. Supporters cite solved cases and missing people found; critics warn the system can track innocent citizens.
But the debate has become too focused on the cameras.
Flock is not the underlying problem. The deeper problem is acquiring powerful technology before deciding why it is needed, what it may do, who may use it, and what controls will prevent abuse.
Capability Is Not a Requirement
Security technology is often purchased backward.
A vendor demonstrates a system that identifies plates, describes vehicles, generates alerts, and searches for activity across multiple locations. Leaders hear about recovered stolen vehicles and identified suspects.
The demonstration answers one question: What can the system do? But it does not answer the more important question: What does the organization need the system to do?
Before purchasing Flock—or any surveillance platform—an organization should conduct a risk assessment. What problem is the organization trying to solve? Does the organization need real-time alerts, retrospective evidence, or both? Who will receive an alert, and what can that person legally and practically do with it?
Without that analysis, the organization is not buying a defined security solution. It is acquiring a powerful capability and hoping useful applications will emerge later.
A Vendor Demonstration Is Not an Assessment
Flock is responsible for explaining its products. It is not responsible for determining whether a community, school, business, or property owner needs them.
A proper assessment should consider crime history, operations, traffic patterns, existing safeguards, response capabilities, privacy, legal constraints, and the consequences of misuse. It should also compare alternatives.
Could better access control address the problem? Would improved lighting reduce opportunities for crime? Are the existing cameras poorly positioned or inadequately monitored? Is the problem serious enough to justify collecting information on every passing vehicle?
That decision should emerge from the risk—not from the product demonstration.
Requirements Must Come Before Procurement
When did a police department last publicly set performance requirements for purchasing security cameras?
Needed are requirements—not a vendor brochure, spending authorization, or officers’ assurance—that define the problem, performance targets, error limits, operational constraints, privacy protections, and success measures.
Too often, the unstated justification amounts to: We are the police. We understand crime. Therefore, we know which security technology to buy.
Law-enforcement experience is valuable, but it doesn’t replace security engineering, systems analysis, privacy review, or disciplined procurement. Investigating crimes doesn’t qualify an agency to design surveillance networks, assess technologies, or govern data.
The same applies to the private sector. Experience does not eliminate the need for documented requirements. Neither does a vendor demonstration or a story about a crime the product helped solve.
Requirements should define what may be collected, monitored, or searched; who is authorized; how long information is retained; when it may be shared; and how use will be audited. They should also specify what the system must not do.
Without written requirements, there’s no objective basis for comparing products, assessing performance, or holding anyone accountable. The organization is asking vendors to define the problem, design the solution, and evaluate their own work.
That is not procurement. It is an invitation to be conned.
Controls Do Not Operate Themselves
Flock says its platform creates audit records, supports role-based permissions, and requires a reason for every search. It has announced stronger safeguards, including shorter default retention periods, expanded case-code requirements, automated detection of unusual searches and possible account lockouts pending review. www.flocksafety.com
Those controls are useful, but they are not substitutes for customer governance.
A system can record every search without anyone reviewing the records. It can require a reason while accepting vague explanations. It can generate a misuse alert that is ignored or assigned to someone without the authority to investigate it.
The existence of a control does not prove that it is effective or working.
Recent cases have involved personnel allegedly using ALPR systems for personal purposes, including searching the records of spouses, former partners, and acquaintances. Investigations have also found agencies with policies but no routine audits. gbi.georgia.gov
The larger failure is deploying the capability without the oversight necessary to detect misuse.
Governance requires more than an acceptable-use policy gathering dust on a shelf. It also requires clear ownership, restricted access, separation of duties, training, supervisory review, regular audits, documented investigations, and meaningful consequences.
The Private Sector Has the Same Responsibility
Businesses, schools, houses of worship, residential communities, and property owners increasingly have similar capabilities.
Private organizations need policies covering acceptable use, administrator privileges, data sharing and retention, legal requests, audits, and incident reporting. Contracts should define data ownership and vendor access, and specify requirements for breach notification and data destruction when the relationship ends.
Someone must be accountable not only for keeping the cameras operational but also for ensuring the program remains necessary, proportionate, and controlled.
The Real Test
The question isn’t whether Flock is good or bad, but whether its deploying organization can demonstrate that it addresses a defined risk, was objectively selected, operates under clear requirements, and is subject to enforceable oversight.
Can leadership explain why each camera is located where it is? Who has access? When was the activity last audited? Who receives the information? How long is it retained, and why?
If those answers are unavailable, the organization lacks a governed security program. It has technology.
An assessment must lead the acquisition process. Resulting requirements must precede procurement. Policies, procedures, and controls must be established before any system is commissioned, goes live, or is granted. Auditing must be continuous rather than triggered by scandal.
Powerful technology deserves equally powerful governance.
Without it, the problem is not merely what the system can see. It is that nobody is watching the watchers.