Consumer Data Protection: California Plus, Compliance Minus

Flock Safety's boilerplate denial doesn't survive the statute it claims to follow.

As of 2025, Consumer Data Protection Acts (CDPAs) have been enacted in twenty states.¹ Some share language, others don’t, but all leave the obvious tension between “consumer data protection” and “privatized mass surveillance” unresolved.

I recently received a copy of a response to a CDPA request from Flock Safety, a provider of AI-enabled roadside mass surveillance cameras. Its response was predictable: obfuscate, misdirect, and deny.

In this article, we’ll pick it apart, because the Attorney General hasn’t. Yet.

CDPA 101: It’s GDPR Lite

The CDPAs adopted by the various states broadly follow a pattern inspired by Europe’s General Data Protection Regulation (GDPR). What they protect varies a little from state to state, but the general idea is “information that is linked, or linkable, to persons.”

In equally broad terms, whenever a “person” (government, business, natural person, etc.) collects or maintains protected data, they are a “controller” and someone merely handling the data is a “processor.”

In states with a CDPA, you typically can do things like request your data from the controller, opt out of certain data collection, find out how it’s being shared, and correct incorrect information.

Corporations in general, but mass surveillance corporations in particular, enjoy existing in liminal spaces. Even though various state laws require the separation to be clearly defined in contracts, the terms are often purposely left out, or, if included, left ambiguous.

That problem is compounded for government-funded corporate surveillance because the surveillance devices (cameras, microphones, what have you) and software are often said to be private, while the funding and operational infrastructure (permits, land use, and so on) is provided by the government.

A fun fact — and we’ll get to why it’s “fun” in a minute — is that the government itself is exempt from the CDPA.

A Response, Annotated

With respect to any systems over which Flock is a controller, we did not locate any data in such systems that matched the information provided in your request

It is unclear what systems Flock refers to, but clearly it admits it is a controller of some systems.

But let’s gloss over that really, really quickly.

With respect to any data which may temporarily be stored on Flock Safety devices, such data is consistently written over on a rolling basis due to limited memory space on the devices and is not stored or maintained on such devices in a manner that allows Flock Safety to directly identify, link, or associate the data with an identifiable person. This can only be done via the Flock Safety software systems, where, as described further below, all data is owned and managed by Flock Safety’s customers.

This sounds sort of meaningful, but isn’t. At least not in the way Flock would like you to believe. Ownership and management are not factors, nor is whether Flock “identifies, links, or associates” the data with an identifiable person. Whether the data is stored “temporarily” or whether it’s overwritten on a rolling basis are all technical implementation detail that neither the CDPA, nor the requester cares about.

What they do care about is the admission in the middle of the technobabble: Flock stores or maintains “such data.”

With respect to any systems where Flock Safety processes data on behalf of our customers, please note that Flock Safety’s customers are owners and controllers of the data Flock Safety processes on their behalf. Flock Safety is a service provider and processor for our customers and as a result, we are unable to directly fulfill your request. We recommend contacting the organization that engaged Flock Safety’s services to submit your request, as they are responsible for assessing and responding to it.

This paragraph is Flock’s key assertion. It is boilerplate crafted to dismiss requests under many states’ CDPAs, which share the “processor” language. But it’s lazy boilerplate, because it also uses “service provider” from California’s CCPA/CPRA.

If it’s too much work to craft a form letter specific to California — the most populous state in the nation — it’s probably a safe assumption that it’s too much work to actually look for the data requested.

Here are a few additional points about Flock Safety’s data collection and privacy practices:

Okay, let’s hear ‘em.

Customer Contracts: Flock Safety’s processing activity as a service provider and processor is governed by the contract we have with our customers, which captures their instructions and the limitations on how Flock Safety may process their data. Flock Safety’s customers own the data and make all decisions around how such data is used and shared.

The same boilerplate “California-plus” language: “service provider and processor.”

The paragraph itself — its activity is governed by the contract it has with its customers — is meaningful. Hang on to that tidbit, we’ll come back to it.

No Sale of Data: Because Flock Safety’s customers own the data, Flock Safety may only process the data in accordance with our customer’s instructions, as outlined in our contracts with customers. Flock Safety is not permitted to sell, publish, or exchange such data for our own commercial purposes.

Again, the causal link Flock suggests here does not exist. The CDPA places restrictions on the sale of data, but it does not consider “ownership.” That’s deliberate, because it’s not how data sales work in practice: people rarely sell data, they license it.

And while “for our own commercial purposes” is technically correct, it is misleading. As a processor, Flock would not be permitted to “sell, publish, or exchange such data” for any reason. It can follow the express instructions of the controller. That’s it.

Instead, its business model requires it to schlep around buckets full of data between customers, and between its own systems to offer a Surveillance-as-a-Service product.

Information Collected: Where Flock Safety’s customers leverage License Plate Reader (LPR) technology, the LPRs do not process sensitive information like names or addresses. Instead, LPRs only capture images taken in the public view of publicly available and visible vehicle characteristics

Flock’s response focuses on “LPR” cameras. Which is the most well-known of its product, but still only a subset. Its other products, like Condor PTZ cameras, Raven microphones, and even Nova (which “combin[es] CAD, RMS, video footage, LPR data, and even open-source intelligence [which includes things like consumer credit reports, and, according to independent security research, SSNs and other dark web data] in one unified experience​”) go unmentioned.

That its roadside cameras don’t process “sensitive information” is false. That term is defined by the CDPA; in Delaware, it includes “precise geolocation data”, in Minnesota it includes “specific geolocation data.” Both are statutorily defined terms describing a type of data captured by Flock’s roadside cameras.

To make the claim true, Flock attempts to substitute its own definition of “sensitive data” for the one provided by the statute.

But what matters more for the response is not whether a specific Flock product handles a specific type of information, but whether Flock, as a company, has protected data.

The answer to that is “yes.”

Purpose: Flock Safety customers use data for security purposes, including managing public safety or responding to safety concerns and reports. Additionally, such data may be used to help solve crimes and provide objective evidence.

Close, but not quite. Flock’s standard contract says: “‘Permitted Purpose’ means a legitimate public safety and/or business purpose, including the awareness, prevention, and prosecution of crime; investigations; and prevention of commercial harm, to the extent permitted by law.”

The purpose itself is mostly irrelevant. The point is that the “Permitted purpose” is defined by Flock, in its standard terms and conditions, which it can unilaterally modify. Determining the purpose makes Flock the controller.

Retention: By default, Flock Safety’s systems only retain data for 30 days, which means that any data collected on behalf of customers is permanently hard deleted on a rolling 30-day basis. Flock Safety customers may shorten or lengthen this retention period based on their local laws or policies.

This is an equally relevant admission: Flock sets the default retention period, and it determines that it “permanently hard deletes” the data. Its customers can influence those terms later, but it is, again, Flock making controller decisions.

Processors vs. Controllers

From Flock’s lazy boilerplate, it’s already sufficiently clear that the company (a) has the data requested, and (b) is the controller of that data. Its response does not survive. But let’s double-tap.

All the States, None of the Work

The response above was from Minnesota, but we’ll use the CDPA from Flock’s state of incorporation — the Delaware’s Personal Data Privacy Act (DPDPA) — to walk through it. DPDPA is not only the most fun to say, it is also functionally identical to Minnesota’s MCDPA in every way that matters here.

If Flock gets to write a California-plus denial, I get to write a Minnesota-plus indictment of it.

Flock’s California-plus language is telling in its laziness. If Flock were a processor, it would have an obligation, under the MCDPA or DPDPA, or some other CDPA, to assist the controller with the request. If it were a service provider, it would have that same obligation, but to the business.

What Flock does instead is punt, without even identifying who it claims the controller is or are — presumably all of its Minnesota clients.

Minnesota gives consumers the right to a list of every third party who received their data. Flock’s response does not even mention it. As a processor, Flock has the duty to assist the controller to locate the list and provide it as a response.

That Flock’s response is lazy is unsurprising when the contact information listed on its CDPA form is “Generitech Privacy 123 Main Street Capital City, ST, USA 10001 +1-800-000-0000 emailprivacy@generitech.com”

The laziness shows that it does not even attempt the bare minimum to fulfill the role it claims for itself. The only thing it does is send out form letters as generic as 123 Main Street.

The Missing Contract

Remember the relevant contract claim. Flock claims there is one, which is good. But the DPDPA and MCDPA (and others) not only require that there be a contract between a controller and a processor, they require it to have specific content.

Flock's contracts, as we have reviewed them, do not contemplate this. Here is an example of such a missing requirement — you can look for it in the terms Flock publishes on its website:

A contract between a controller and a processor must govern the processor’s data processing procedures with respect to processing performed on behalf of the controller. . . . The contract must also require that the processor to do all of the following: . . . Allow, and cooperate with, reasonable assessments by the controller or the controller’s designated assessor, or the processor may arrange for a qualified and independent assessor to conduct an assessment

Flock’s contracts do not contemplate this at all. Not even close.

The DPDPA requires that the division of labor between a controller and processor is laid out in the contract to avoid exactly the type of shell game Flock attempts to play.

That requirement is not without teeth — the law spells out the consequence of omission:

Determining whether a person is acting as a controller or processor with respect to a specific processing of data is a fact-based determination that depends upon the context in which personal data is to be processed. A person who is not limited in such person’s processing of personal data pursuant to a controller’s instructions, or who fails to adhere to such instructions, is a controller and not a processor with respect to a specific processing of data.

Flock’s prize for failing to have an adequate contract in place is that it becomes the controller.

The Government as Controller

Even if Flock's contracts were perfect, its position would still fail. As stated earlier, the CDPA does not apply to the government. That doesn’t mean that it is optional for the government, it means that the statute, as a whole, does not apply to the government.

This chapter does not apply to any of the following entities: Any regulatory, administrative, advisory, executive, appointive, legislative, or judicial body of the State or a political subdivision of the State, including any board, bureau, commission, agency of the State or a political subdivision of the State, but excluding any institution of higher education.

Even if a police department were to want to assume the role of the controller, which it doesn’t, it could not. That’s why the language is not in the contract.

“A person who is not limited in such person’s processing of personal data pursuant to a controller’s instructions . . . is a controller and not a processor”.

Someone who is not the controller can’t provide “a controller’s instructions.” Without those instructions, Flock is not “limited” by them.

And because Flock is not limited, it is the controller, as a matter of fact as well as law.

Minnesota’s cure period expired January 31, 2026.

File your requests. Collect your California-plus denial. Encourage your AG to act.

1. California (2018), Virginia (2021), Colorado (2021), Connecticut (2022), Utah (2022), Delaware (2023), Indiana (2023), Iowa (2023), Montana (2023), Oregon (2023), Tennessee (2023), Texas (2023), Kentucky (2024), Maryland (2024), Minnesota (2024), Nebraska (2024), New Hampshire (2024), New Jersey (2024), and Rhode Island (2024).