Fort Pierce police announced on September 8, 2026 the arrest of former officer Josepher Crutchfield on four felony counts of unauthorized computer access. Between October 2025 and July 2026 he ran one license plate through the department's Flock automated license plate reader 382 times, police say — most while off duty, and the plate belonged to a woman he had dated. Investigators say he searched for her in FCIC, NCIC, DAVID and TLO too, some of that going back to 2023. He resigned August 18, before the investigation concluded.
The system asked him to justify every one of those queries, and he did. Fort Pierce's account, reported by Vero News, is that he "used multiple different 'reason' categories, which were for no legitimate law enforcement purposes." The department opened its investigation on August 10, three days after members of the media contacted it.
It is not one department. Vero Beach placed an officer on paid leave on September 18, stating that it "was recently contacted by a news organization regarding allegations involving the potential misuse of the Flock Safety system by a department member." An Indian River County sergeant was placed on leave the same week, though that agency says its Flock audit had already begun.
The log was complete, correct, and unread
A mandatory justification field creates a record. It does not create friction. It is validated for presence — the query will not run with the box empty — and never for plausibility. Nothing rejects a search for having an implausible reason, and nothing aggregates reasons per user. The field's whole value sits downstream of suspicion: good evidence once you know whom to look at, nothing before.
The count was the signal, not the reason. Three hundred eighty-two queries against one identifier over nine months averages ten a month against a plate attached to no case. Query by query each looks fine: valid user, working credential, selected reason. The anomaly exists only in aggregate, and aggregate is exactly the view an attestation field does not produce.
Cross-system access makes it worse. Flock's audit trail holds those 382 rows; DAVID, FCIC and NCIC hold their own. The pattern that identifies the conduct — four systems queried against the same subject by one operator — exists in no single system's log, so four agencies can each run a clean audit and none sees it. This is the same state driver database seen from the inside that FLHSMV could not control from the outside; in both cases the control that survives is noticing how much one account pulls.
The practice: sort your query logs by volume, not by date
Pick the interfaces where one authenticated person can look up one arbitrary person: CRM export, admin console, support impersonation, log search, EHR record lookup. Monthly, compute per-user and per-user-per-subject query counts, and read the top of that list.
The sort order matters more than the audit's existence, and Fort Pierce is the evidence. Chief David Smith said he had begun a one-year audit of database usage before the media raised Crutchfield, and that it "was already working backward month by month when the media tip came in." He believes it would have got there — eventually. A backward chronological walk is ordered by date, and date order finds a nine-month pattern last. The same auditor, over the same data, sorted by volume descending, finds it on the first screen. Smith's own assessment: "the safeguards that were in place were not sufficient."
The cost is that it is dull and has no owner — a job that produces nothing most months, which is why it gets dropped when the quarter is busy, and why "we have audit logging" gets read as "we audit." Fort Pierce's answer was to make it somebody's title: a new Office of Professional Standards position running monthly quality assurance audits of every law enforcement database officers touch, not just Flock. That is the honest price — a fraction of a headcount, permanently.
If you cannot compute per-user counts at all — write-only log storage, or a platform that will not group them — the cheaper substitute is a threshold alert on repeat access to the same record by the same user inside a window. It misses the slow cases and catches the dense ones, which most of these are. And correlate on the subject identifier rather than per system, or you get four clean reports and one blind spot, the same way six days of database reads produced no alert while every uptime signal stayed green.
None of this is visible to a scanner, and a questionnaire asking "is audit logging enabled?" scores it as a yes.
What to check this week
- Pull one month of per-user query counts from your highest-privilege lookup interface. If nobody has ever run that query, the log is evidence, not a control.
- Sort it by volume descending, not by date. Does the account at the top have a case, ticket, or customer record behind each query?
- For your top three users, what share of queries landed outside their scheduled hours?
- Take one subject identifier that appears heavily in one system and look it up in the others holding the same subjects. Does the same operator come back?
- If your interface requires a justification, read twenty entries at random. If you cannot tell a true one from a false one, the field is a record, not a control.
North InfoSec runs AI-assisted penetration testing and security assessments, including review of who can query privileged interfaces and whether anyone reads what those queries record. northinfosec.com