Of all the risk-laden tasks that comprise the processes of eDiscovery and evidence exchange, perhaps the most perilous is the transfer of data itself.
The terms "risk-laden" and "perilous" may strike you as scare-mongering. And if they do, consider the lifecycle of a typical discovery collection.
In the course of exchanging evidence, it is not unusual for data to be passed from the client, where it is collected, to the client's law firm; from the law firm to a vendor; from the vendor back to the law firm; and from the law firm to an opposing party. Fortunately, all this movement occurs through secure, encrypted channels.
But getting a production out the door is only half the story. Once that data "crosses over" to the opposing party, it is then potentially shared far and wide within the opposing party's own network of co-counsel, service providers and others.
This "workflow" -- if such a cheesecloth approach can so be called -- creates a pollen cloud of unsecured ESI that can land pretty much anywhere, and in the hands of pretty much anyone. Among the most well-known recent examples of this arose in the high-profile Apple-Samsung patent disputes, where Samsung attorneys who, through the course of discovery, had come into possession of a confidential Apple licensing agreement accidentally uploaded it to a company-wide intranet. Samsung was sanctioned for its carelessness -- an outcome of little consolation to Apple, whose executives no doubt lost sleep with the knowledge their corporate secrets had gone viral within the offices of their biggest competitor.
The casualties of the existing eDiscovery framework are many. A more recent example comes from the town of Saugus, where a harassment suit brought by a government employee inexplicably surfaced social security numbers of other employees whose most private information had been swept up in the discovery dragnet. A similar embarrassment befell prosecutors in the so-called "Oregon Standoff Case," where mounds of Facebook evidence belonging to several defendants that should have remained sealed was accidentally shared with all remaining defendants.
Stories like this are a dime a dozen. In fact, these days, pretty much anything that "comes to light" emerges, intentionally or not, through discovery.
Clearly, then, the existing way of doing things, which was backward to begin, cannot withstand the continuing rise in data volumes, nor should it be tolerated given the sensitivity of the data at issue and the increasingly prevalent attempts on it.
So, insecure data flow is one problem and, in the context of discovery, the other side of that coin is data incompatibility.
Because there are so many types of information and so many different proprietary systems used to search and review it, the transfer of data is often stifled by the fact that receiving systems don't speak to each other -- or that data that has been manipulated so it can be used in one tool must be manipulated further to use in another (or else, it is unusable). Hence, the dreaded "load file" -- a Tower of Babel construct where data that should have ideally remained in its native state is subjected to mutation so it can be reviewed, and then finagled again, ironically, so that it can be spit back out in a form that bears resemblance to its original. It's the ultimate in jamming a square peg into a round hole -- and then hammering it back into a peg.
Data Copy is the first step toward the end of load files, and the beginning of sanity
It goes without saying that these issues drive up risk and cost, that we can do better and that, at Logikcull, we are trying to do just that - better. This week, we announce our newest feature, Data Copy, which is the first step toward both completely eliminating load files and tying the knots on the network of loose ends that makes up the existing e-discovery workflow.
The mechanics of Data Copy are powerfully simple, allowing you to carve out and share subsets of existing datasets without having to reassemble or reprocess any of that data. So, for example, if you uploaded documents belonging to several custodians for Case A, you can copy all the documents associated with one of those individual custodians to a separate Logikcull project, Case B, without having to re-upload those materials.
This is of potentially great value to, among others, serial litigants who routinely face requests for ESI belonging to a select group of custodians. But another use case, when you begin to think about where that data will ultimately end up, is to be able to, in seconds, transfer materials that are tagged as responsive and non-privileged to opposing parties within Logikcull. This is the holy grail, discovery in its purest form: performing the entire search and review within a secure system, then sharing the production with another party within that system without the data ever leaving the secure hub in which it was originally collected. All data, no matter with whom it is shared, resides in a remotely accessible discovery hub. Always.
This "closed-circuit sharing" described here eliminates the following unnecessary steps, and the associated risk and cost:
It also solves the load file problem... because Logikcull doesn't require its own load files. It is certainly capable of receiving them -- from Concordance, Relativity, Summation and other systems. But it doesn't need its own. It ingests and automatically processes just about everything. It's democratic in that way.
So this is where discovery is headed and it can't get there soon enough: Client invites law firm into Logikcull; client's law firm performs the document review; client's law firm shares data within Logikcull to an opposing party with permissions such that the party can access only that which has been designated for it to see; and, finally, the opposing party conducts a review of materials it has received... yep, within Logikcull. That's the future. It's powerfully simple. And, we can all sleep easier knowing, it doesn't include load files.