Why Must Investigators Know Where the Answer Lives Before They Can Ask the Question?

In most organizations, the first step of an investigation is not analysis. It is working out which systems might hold the evidence at all. That knowledge usually lives in the heads of experienced investigators rather than in the systems themselves, and it is one of the least visible costs in investigative work. When the map of where information lives depends on tenure and memory, cases start late, connections get missed, and every departure takes part of the organization’s search capability with it.

This article explains why enterprise data ends up scattered, what public reviews show about the consequences, and what a better standard looks like.

The first task is a map, not a question

Take a common example. A corporate investigator receives a tip that a facilities manager may have steered a maintenance contract to a favored vendor. Before she can write a single query, she has to answer a different question: where would evidence of this live?

A prior complaint might be in the case management system, if someone logged it formally. Correspondence with the vendor might be in the email archive. A conflict-of-interest disclosure, or its absence, sits in an HR system the investigations team can only reach through a request. Payments are in the finance ledger under a vendor code that may not match the contract name. The bid documents are on a shared drive filed under procurement’s naming conventions. None of this is a question about the facts of the case. It is a question about the architecture the case happens to sit inside.

An experienced investigator answers it from memory. A newer colleague, or one who has moved over from a different case type, cannot. The tip waits, not because the facts are hard to interpret, but because nobody yet knows where to look.

Systems fragment because departments build them

Data is not scattered by nature. It is scattered because each function, whether procurement, HR, finance, IT, legal, or security, acquires the tools it needs on its own timeline and with its own vocabulary for what counts as a case, a vendor, or an incident.

The U.S. Government Accountability Office documented this pattern at federal scale in a 2011 review of fraud detection at the Centers for Medicare and Medicaid Services. GAO found that “CMS and its program integrity contractors currently use many different means to store and manipulate data and, since the establishment of the agency’s program integrity initiatives in the 1990s, have built multiple databases and developed analytical software tools to meet their individual and unique needs.”¹

The same review offers a caution for anyone who thinks the answer is simply to build a central portal. CMS did build one, called One PI. Planning documents called for 639 program integrity staff and analysts to be trained and using it by the end of fiscal year 2010. By October 2010, GAO reported, 41 were actively using it, “less than 7 percent of the original intended users.” GAO attributed the shortfall to insufficient training. Central access had been built; the habits and skills to use it had not.¹

For an investigator, the practical effect of departmental systems is that one search becomes five or six separate searches, in five or six vocabularies, each confined to its own system. Research on how analysts work helps explain why that matters. Peter Pirolli and Stuart Card’s 2005 study of intelligence analysts describes a “foraging loop,” in which analysts find and gather material, feeding a “sensemaking loop,” in which they build and test explanations.² Sensemaking can only be as good as the foraging that feeds it. When the terrain is split across systems that the analyst may not know exist, foraging becomes guesswork about where to start.

When the center cannot see the branch

The Danske Bank Estonian branch case shows the same mechanism with much higher stakes. Danske acquired the branch through its 2007 purchase of Sampo Bank, and the branch continued to run on its own IT platform. The bank’s own commissioned investigation, carried out by the law firm Bruun & Hjejle and published in September 2018, found that the branch “was not covered by the same customer systems and transaction and risk monitoring as Danske Bank Group.” Plans in 2008 to move the Baltic banking activities onto the group platform were abandoned because they were considered too expensive and resource-intensive. Over 2007 to 2015, the payment flows of the roughly 15,000 customers the investigation examined amounted to approximately EUR 200 billion.³⁴

The report identified many failings beyond IT, and a separate platform was not the only cause of what went wrong. But it illustrates the point of this article clearly. Evidence the group needed existed, and it sat in a place the center’s tools did not reach.

Why should tenure be the index?

If the knowledge of which system holds which kind of fact lives only in senior investigators’ heads, the organization has made a design choice, even if nobody made it deliberately. The cost falls hardest on new investigators, on staff who move between case types, and on the organization the week its most experienced investigator leaves.

The broader cost of searching is not trivial either. The McKinsey Global Institute estimated in 2012 that the average “interaction worker” spends nearly 20 percent of the workweek “looking for internal information or tracking down colleagues who can help with specific tasks.”⁵ Investigators fit that description closely: their job is reconstructing events from information other people created for other purposes.

A missed connection between a procurement note, a payment anomaly, and a prior HR complaint is rarely a failure of analytical skill. More often, it is a case where nobody thought to check the system that held the missing piece.

Let the system carry the map

The answer is not forcing every department into one schema, which is expensive and, as CMS found, does not by itself change how people work. A better standard is an investigative environment that brings the relevant records together around the people, organizations, and events in a case, so an investigator can start from the question rather than from a guess about location. That has to be paired with the training and adoption effort the CMS example shows is easy to underestimate.

For corporate investigations that cross procurement, HR, finance, and security, Hubstream’s incident and investigation management solution is built around that idea. It brings case records, entities, and intelligence into one environment and links the people and organizations that appear across them, so related material is easier to find and earlier cases are not invisible to the next investigator. Deciding whether a payment, an email thread, and a personnel note actually connect still requires an investigator to weigh context and evidential value. What changes is how much she has to already know before she can begin.

Practical takeaway

Write down the map. List the systems your investigations draw on, what kind of fact each one holds, who controls access, and what each calls a “case” or a “vendor.” Give it to every new investigator, and use it to identify the two or three sources that most often hold the missing piece but are hardest to reach. Those are the first places to improve access, and the first places to measure whether people actually use what you build.