Peter Mai, CISSP, shares his views and experiences of law enforcement operating in the cybersecurity space and the challenges, opportunities and observations of trying to deliver cybersecurity outcomes with civilian applications and services.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
I was running a product demo. A criminal intelligence analyst – experienced, senior, not the kind of person who says things for effect – watched me while I pulled a source spreadsheet into the platform, mapped the relationships and had them render as connected nodes on a knowledge graph. It looked clean; it looked like progress. He looked at the screen and said to me, very plainly: “This isn’t analysis.” It stung. Not because he was wrong, but because he was right and I already knew it.
That moment captures a problem I spent years trying to solve: the need to reduce the distance between a technically functional tool and one that works for the people whose job depends on it. In cybersecurity, we talk often about skills shortfalls, or the tooling shortfall, or the resourcing shortfall. What I want to talk about is the issue between what commercial cybersecurity platforms are designed to do and what law enforcement analysts need them to do. It’s larger than most of us realize, and understanding it matters beyond law enforcement.
The cybersecurity tooling market is mature, well-funded and impressive. There are excellent platforms for SOC analysts, threat hunters, incident responders and red teams. Most share a design assumption: the user is trying to protect systems. The data is logs, alerts and network traffic. Success is prevention or detection.
But criminal intelligence analysis operates on almost none of those assumptions. The analyst is trying to build a case, while the adversary is a person or a network of people. The data is human intelligence, reports, intercepts and years of investigative history spread across formats, languages and jurisdictions. Success here is a conviction, meaning the data must be auditable, attributable and defensible in court. That’s not as a compliance requirement, but as the whole point.
A [U.S.] National Institute of Justice assessment found that “in a commercial software market flush with security products, the development of investigative solutions for law enforcement has been limited.” Research analyzing nearly 742,000 investigative tasks found that investigators routinely face information overload, with manual processing dominant even where analytical platforms exist. More data means more analytical burden, not less, unless the tooling matches how analysts actually reason. Most commercial tools do not.
What I Was Actually Doing and Four Things Commercial Tools Get Wrong
For several years, I served as product owner on a criminal analysis platform built for a major international law enforcement body, funded by the U.S. Department of State and supporting investigators across nearly 200 countries. The platform was built on knowledge graph architecture, natural language processing and entity extraction. My job was to be the bridge between what the technology could do and what analysts actually need.
International law enforcement is genuinely international: there are different legal traditions, different standards of evidence and different institutional instincts about what ‘done’ means. So, while my role sounds like a standard product role, in practice it was an exercise in navigating two communities that didn’t share a common language and occasionally didn’t even share a definition of basic terms. Someone had to translate, accurately, in both directions, under pressure. Here’s what I learned.
Chain Of Custody Is the Foundation, Not A Feature
In enterprise security, audit logs support forensics and compliance; useful, but secondary. In criminal intelligence, every analytical step is potentially evidence. If I run a query, draw a connection or generate a report, that action must be documented: who did it, when, using which tools and why. U.S. Federal Rules of Evidence require that evidence be proven original and free from tampering; the Daubert Standard demands a methodology reliable enough for courtroom scrutiny. Enterprise tools treat auditability as configurable, but in our context it was load-bearing from day one. I spent more time on this single requirement than on almost anything else in the project.
The Ontology Problem Is Harder Than Anyone Admits
By ‘ontology’ I mean the formal definition of what things are and how they relate; for example, what counts as an entity, what counts as a link and how definitions interact when data crosses systems. I identified this early and pushed for dedicated work; what developed was a subproject aimed at supporting interoperability across agencies. We consulted with Europol, which had encountered the same challenge with its SIENA platform: When structured criminal intelligence crosses dozens of legal frameworks, the question of what a ‘person’ or a ‘relationship’ means becomes surprisingly difficult. Academic researchers studying EU law enforcement interoperability identified the root cause precisely: there is no consolidated definition of what “organized crime” is and the phenomenon itself keeps changing. We couldn’t build a reliable data model for a concept inconsistently defined across the legal systems contributing to it.
Domain experts were eventually brought in, and that was the right call. Get the ontology wrong and downstream analysis is distorted, sometimes silently. And, in my world, silent errors are the ones we discover in court.
Analysts Don’t Trust Black Boxes
When the system surfaced a connection between entities, analysts needed to understand why – not as a UX preference but as a professional obligation. An analyst who acts on a connection they cannot explain has a problem; so does the prosecution that relies on their work. The US Department of Justice’s December 2024 report on AI in criminal justice confronts this directly, stating that “AI should support, not replace, human decision-making, especially in high-stakes cases.” Peer-reviewed research confirms that systems must provide the ability to “correct or override” automated decisions.
Explainability had to be designed in from the start; functioning software and useful software are not the same thing.
Legacy Data Migration Is an Ontological Argument, Not A Technical Task
Law enforcement agencies run on history, sometimes involving decades of case data in systems that predate modern platforms. Moving that data means making design decisions with analytical and legal dimensions that cannot be delegated to engineers.
One argument in particular consumed significant time: should a source document be its own node on the knowledge graph or merely an attribute of an entity? Analysts wanted documents visible and navigable – to be part of the analytical picture not metadata. But treating a document as an entity introduced modelling complications. The most experienced analysts disagreed with each other and with me. It wasn’t an engineering problem, but an analytical question; the wrong answer, implemented cleanly and at scale, is worse than a messy right answer.
Why This Matters Beyond Law Enforcement
Most ISC2 members and cybersecurity professionals more widely don’t work in law enforcement. But the same structural issue exists in any situation where the cost of getting the design wrong exceeds the cost of shipping slowly: think critical infrastructure, or healthcare security, or election integrity, as examples. In each domain, ‘technically correct’ and ‘operationally trustworthy’ are different standards.
The policy architecture recognizes this. Executive Orders 14028 and 14144 establish cybersecurity as a national imperative; the DoJ’s AI report signals that the U.S. federal government is codifying human oversight requirements for AI in law enforcement. But ISC2’s 2024 Cybersecurity Workforce Study put the perceived need for cybersecurity professionals at 4.8 million more than the active workforce, while 52 percent of cybersecurity leaders said that the real issue isn’t headcount per se, but finding people with the right skills. Cross-domain practitioners with experience of building for high-stakes operational environments are among the scarcest.
So, the shortage is not of tools, or of analysts or engineers; it’s of practitioners who have genuinely operated on both sides of that line and who understand that the line itself is harder to stand on than to stand either side of it.
What would I tell someone crossing into this work? That the deepest difference I encountered was epistemological. Our cybersecurity instinct is probabilistic: something is suspicious, a confidence level applies and the response is investigation. The law enforcement requirement is often evidentiary: something either happened or it didn’t and we need to demonstrate, in front of a judge, which it was. These are incompatible defaults and, unaddressed, leads to tools that security professionals consider complete but which operational analysts consider unusable.
The analyst who told me that “This isn’t analysis” wasn’t criticizing the software; he was telling me what the work actually is. It took me longer than it should have to hear it as the gift it was.
Peter Mai, CISSP, has more than 16 years of experience in law enforcement cybersecurity, including at the Australian Federal Police and INTERPOL. He has held technical and product management roles, with responsibility for criminal intelligence platform design and delivery at international scale. His cybersecurity work spans cloud infrastructure, compliance frameworks, and cross-border law enforcement interoperability.
