What’s Your eDiscovery Process?

When you buy/build a house, do you set up completely separate garages—one for cars, one for bikes, one for pickups, one for boats? No. Because itemized storage isn’t the goal. You also don’t make your motorcycle more like a bike so they can share the same garage space, because they’re similar but different tools.

We live in an increasingly complex digital world. It would be difficult to find anyone who disagrees with that statement. In regards to employee communications, this is as true as anywhere else. Communications went from simple P2P to a complex web of interactions that can become confusing and disjointed when looked at after the fact, simply because they’re so widely distributed.

When an eDiscovery request comes in, how many places/systems do you have to touch? How much conversion and analysis is required to reconstruct a conversation stream that involves (for example) email, IM and voice?

Many archival and discovery systems will take communications from non-email sources, place them into the format they were designed for—email—and then allow searching across them. This can cause problems, as email conversion is the key. High quality with a care for all original system metadata makes for a good conversion, a quick “bash it into email format” can lose context and even order of communications.

This is important for several reasons. The number of hours invested in eDiscovery activities can rapidly grow if there is a lot of manual rebuilding of communications over time, or a need to find all communications by a single individual and then try to organize them chronologically across systems. For organizations that have a heavy compliance burden of proof or are served more than a few eDiscovery notices a year, the cost adds up quickly.

I recently spoke with Actiance about the need to cover a growing number of communications channels and the changing requirements of eDiscovery archival and responses. It’s pretty simple to implement email archiving these days, but other forms of communications are not as clear cut.

Actiance’s approach is to use an OO database to store communications with metadata in a form that allows one to follow the conversation as it moves across channels. Which makes the most sense from a time-to-discovery/overtime perspective, in my opinion. If you’ve ever been involved in a discovery request, it’s painful at the least. Anything that can lighten that burden should be considered as a tool.

Another interesting bit is the ability to stop unwarranted conversations before they start. Now any determined folk can get around any security mechanism, but for conscientious employees to be reminded, “This was blocked because you said XX,” when they go to send an IM, that should be enough to get them thinking about what they should and shouldn’t say. The typical example of this is when a financial advisor uses the word “guaranteed” in a communication. It’s an easy example, but each vertical has their own requirements.

Nothing is going to make eDiscovery fun. If you’re embroiled in something that requires eDiscovery, it generally (thought certainly not always) means someone in the org is in some kind of trouble—or the whole org might be. But tools to make it less resource-intensive are kind of mandatory for some verticals, and can lessen the pain for any vertical.

No matter what your architecture, and who your vendors, it’s worth looking at your eDiscovery process—how frequently is it needed, and what are the costs of performing an eDiscovery, particularly in terms of hours invested in an activity that is really just responsive post-risk management work. Technology is advancing all of the time, so it’s worth considering if the balance has tipped in favor of an upgrade project yet.

Sponsored Content
Upcoming Webinar
Not All Flaws Are Created Equal: The Difference Between a Flaw, a Vulnerability and an Exploit

Not All Flaws Are Created Equal: The Difference Between a Flaw, a Vulnerability and an Exploit

According to Gartner, the application layer contains 90% of all vulnerabilities. However, do security experts and developers know what’s happening underneath the application layer? Organizations are aware they cannot afford to let potential system flaws or weaknesses in applications be exploited, but knowing the distinctions between these weaknesses can make ... Read More
May 29, 2018
Don Macvittie

Don Macvittie

20 year veteran leading a new technology consulting firm focused on the dev side of DevOps, Cloud, Security, and Application Development.

don-macvittie has 1 posts and counting.See all posts by don-macvittie