Collection

Date Searching for Emails and Loose Files Can Be Tricky: eDiscovery Best Practices

I recently had a client that was searching for emails and loose files based on a relevant date range.  However, because of the way the data was collected and the way the search was performed, identifying the correct set of responsive emails and loose files within the relevant date range proved to be challenging.  Let’s take a look at the challenges this client faced.

Background

The files were collected by client personnel with the emails placed into PST files and loose files from local and network stores all put into folders based on custodian.  The data was then uploaded and processed using CloudNine’s Discovery Client software for automated data processing and placed into the CloudNine Review platform.

Issue #1

Before they retained us for this project, the client placed copies of loose files into the custodian folders via “drag and drop”.  If you have been reading our blog for a long time, you may recall that when you “drag and drop” files to copy them to a new location, the created date will reflect the date the file was copied, not the date the original file was created (click here for our earlier post on whether a file can be modified before it is created).

As a result, using created date to accurately reflect whether a file was created within the relevant date range was not possible, so, since it was too late to redo the collection, we had to turn to modified date to identify potentially responsive loose files based on date/time stamp within the relevant date range.

Issue #2

With the data processed and loaded, the client proceeded to perform a search to identify documents to be reviewed for responsiveness to the case that included the agreed-upon responsive terms for which either the sent date or the modified date was from 1/1/2014 to present.  Make sense?  In theory, yes.  However, the result set included numerous emails that were sent before 1/1/2014.  Why?

One of the first steps that Discovery Client (and most other eDiscovery processing applications) performs is “flattening” of the data, which includes extracting individual files out of archive files.  Archive files include ZIP and RAR compressed files, but another file type that is considered to be an archive file is Outlook PST.  Processing applications extract individual messages from the PST, usually as individual MSG (individual Outlook message) or HTML files.  So, if a PST contains 10,000 messages (not including attachments), the processing software creates 10,000 new individual MSG or HTML files.  And, each of those newly created files has a created date and modified date equal to the date that individual file was created.

See the problem?  All of the emails were included in the result set, regardless of when they were sent, because the modified date was within the relevant date range.  Our client assumed the modified date would be blank for the emails.

Solution

To resolve this issue, we helped the client restructure the search by grouping the terms within CloudNine so that the sent date range parameter was applied to emails only and the modified date range parameter was applied to loose files only.  This gave the client the proper result with only emails sent or loose files modified within the relevant date range.  The lesson learned here is to use the appropriate metadata fields for searching specific types of files as others can yield erroneous results.

So, what do you think?  Have you ever experienced search issues when searching across emails and loose files at once?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Has Gone to the Dogs: eDiscovery Trends

If I had known that yesterday was National Dog Day, I would have posted this then, instead of today, but it’s a great story any day.

As reported by ABA Journal, Discover Magazine and NBC News, there is a new type of forensic collection device being used in criminal forensic investigations.  His name is Bear and he’s a black Labrador.

This 2-year-old rescue dog played a key role in the arrest of former Subway pitchman Jared Fogle on child-porn charges, finding a thumb drive that humans had failed to find during a search of Fogle’s Indiana house in July, several weeks before he agreed to plead guilty to having X-rated images of minors and paying to have sex with teenage girls.

According to the Discover article, Bear also helped officers locate 16 smartphones, 10 flash drives and six laptops during an 11-hour search last month of Fogle’s home.  His training relies on the work of chemist Jack Hubball, who tested flash drives, circuit boards and other electronic components and found a chemical that is common to all of them.  Hubball previously identified the accelerants (e.g., gasoline) dogs sniff out to identify arson, and also helped train dogs to find narcotics and bombs.

According to the NBC article, Bear has taken part in four other investigations, including this week’s arrest of Olympics gymnastics coach Marvin Sharp. And he’s just been sold to the Seattle Police Department for $9,500 (basically the cost of the training) to help investigate Internet crimes.  The NBC article includes a video of Bear in action, with Bear’s “dog whisperer” Todd Jordan providing a demonstration of his abilities.

After helping with the Fogle investigation, Bear’s trainer says he’s received some 30 inquiries from police who want to buy their own electronics-sniffing dog.  I can see why.  Labradors not only have particular sniffing skills, they also make great pets, too!  And, although I have so far been unable to train our black Labrador Brooke to keep from jumping on guests to our house, we still love her and are glad we were able to rescue her last year.  Here’s a picture of her, with her favorite Kong ball:

In the future, criminal forensic investigators may show up at a suspect’s residence with a subpoena, a copy of Forensic Toolkit (FTK) and their trusty lab.  As in Labrador.

So, what do you think?  Do you have a unique ESI collection story?   Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Pitfalls Associated with Self-Collection of Data by Custodians: eDiscovery Best Practices

Last week, we covered the Burd v. Ford Motor Co. case where the court granted the plaintiff’s motion for a deposition of a Rule 30(b)(6) witness on the defendant’s search and collection methodology involving self-collection of responsive documents by custodians based on search instructions provided by counsel.  In light of that case and a recent client experience of mine, I thought it would be appropriate to revisit this topic that we addressed a couple of years ago.

I’ve worked with a number of attorneys who have turned over the collection of potentially responsive files to the individual custodians of those files, or to someone in the organization responsible for collecting those files (typically, an IT person).  Self-collection by custodians, unless managed closely, can be a wildly inconsistent process (at best).  In some cases, those attorneys have instructed those individuals to perform various searches to turn “self-collection” into “self-culling”.  Self-culling can cause at least two issues:

  1. You have to go back to the custodians and repeat the process if additional search terms are identified.
  2. Potentially responsive image-only files will be missed with self-culling.

It’s not uncommon for additional searches to be required over the course of a case, even when search terms are agreed to by the parties up front (search terms are frequently renegotiated), so the self-culling process has to be repeated when new or modified terms are identified.

It’s also common to have a number of image-only files within any collection, especially if the custodians frequently scan executed documents or use fax software to receive documents from other parties.  In some cases, image-only PDF or TIFF files can often make up as much as 20% of the collection.  When custodians are asked to perform “self-culling” by performing their own searches of their data, these files will typically be missed.

For these reasons, I usually advise against self-culling by custodians in litigation.  I also typically don’t recommend that the organization’s internal IT department perform self-culling either, unless they have the capability to process that data to identify image-only files and perform Optical Character Recognition (OCR) on them to capture text.  If your IT department doesn’t have the capabilities and experience to do so (which includes a well-documented process and chain of custody), it’s generally best to collect all potentially responsive files from the custodians and turn them over to a qualified eDiscovery provider to perform the culling.  Most qualified eDiscovery providers, including (shameless plug warning!) CloudNine™, perform OCR as needed to include image-only files in the resulting potentially responsive document set before culling.  With the full data set available, there is also no need to go back to the custodians to perform additional searches to collect additional data (unless, of course, the case requires supplemental productions).

Most organizations that have their custodians perform self-collection of files for eDiscovery probably don’t expect that they will have to explain that process to the court.  Ford sure didn’t.  If your organization plans to have its custodians self-collect, you’d better be prepared to explain that process, which includes discussing your approach for handling image-only files.

So, what do you think?  Do you self-collect data for discovery purposes?  If so, how do you account for image-only files?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Quality Control, Making Sure the Numbers Add Up: eDiscovery Best Practices

Having touched on this topic a few years ago, a recent client experience spurred me to revisit it.

Friday, we wrote about tracking file counts from collection to production, the concept of expanded file counts, and the categorization of files during processing.  Today, let’s walk through a scenario to show how the files collected are accounted for during the discovery process.

Tracking the Counts after Processing

We discussed the typical categories of excluded files after processing – obviously, what’s not excluded is available for searching and review.  Even if your approach includes technology assisted review (TAR) as part of your methodology, it’s still likely that you will want to do some culling out of files that are clearly non-responsive.

Documents during review may be classified in a number of ways, but the most common ways to classify documents as to whether they are responsive, non-responsive, or privileged.  Privileged documents are also often classified as responsive or non-responsive, so that only the responsive documents that are privileged need be identified on a privilege log.  Responsive documents that are not privileged are then produced to opposing counsel.

Example of File Count Tracking

So, now that we’ve discussed the various categories for tracking files from collection to production, let’s walk through a fairly simple eMail based example.  We conduct a fairly targeted collection of a PST file from each of seven custodians in a given case.  The relevant time period for the case is January 1, 2013 through December 31, 2014.  Other than date range, we plan to do no other filtering of files during processing.  Identified duplicates will not be reviewed or produced.  We’re going to provide an exception log to opposing counsel for any file that cannot be processed and a privilege log for any responsive files that are privileged.  Here’s what this collection might look like:

  • Collected Files: After expansion and processing, 7 PST files expand to 101,852 eMails and attachments.
  • Filtered Files: Filtering eMails outside of the relevant date range eliminates 23,564
  • Remaining Files after Filtering: After filtering, there are 78,288 files to be processed.
  • NIST/System Files: eMail collections typically don’t have NIST or system files, so we’ll assume zero (0) files here. Collections with loose electronic documents from hard drives typically contain some NIST and system files.
  • Exception Files: Let’s assume that a little less than 1% of the collection (912) is exception files like password protected, corrupted or empty files.
  • Duplicate Files: It’s fairly common for approximately 30% or more of the collection to include duplicates, so we’ll assume 24,215 files here.
  • Remaining Files after Processing: We have 53,161 files left after subtracting NIST/System, Exception and Duplicate files from the total files after filtering.
  • Files Culled During Searching: If we assume that we are able to cull out 67% (approximately 2/3 of the collection) as clearly non-responsive, we are able to cull out 35,618.
  • Remaining Files for Review: After culling, we have 17,543 files that will actually require review (whether manual or via a TAR approach).
  • Files Tagged as Non-Responsive: If approximately 40% of the document collection is tagged as non-responsive, that would be 7,017 files tagged as such.
  • Remaining Files Tagged as Responsive: After QC to ensure that all documents are either tagged as responsive or non-responsive, this leaves 10,526 documents as responsive.
  • Responsive Files Tagged as Privileged: If roughly 8% of the responsive documents are determined to be privileged during review, that would be 842 privileged documents.
  • Produced Files: After subtracting the privileged files, we’re left with 9,684 responsive, non-privileged files to be produced to opposing counsel.

The percentages I used for estimating the counts at each stage are just examples, so don’t get too hung up on them.  The key is to note the numbers in red above.  Excluding the interim counts in black, the counts in red represent the different categories for the file collection – each file should wind up in one of these totals.  What happens if you add the counts in red together?  You should get 101,852 – the number of collected files after expanding the PST files.  As a result, every one of the collected files is accounted for and none “slips through the cracks” during discovery.  That’s the way it should be.  If not, investigation is required to determine where files were missed.

So, what do you think?  Do you have a plan for accounting for all collected files during discovery?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Quality Control By The Numbers: eDiscovery Best Practices

Having touched on this topic a few years ago, a recent client experience spurred me to revisit it.

A while back, we wrote about Quality Assurance (QA) and Quality Control (QC) in the eDiscovery process.  Both are important in improving the quality of work product and making the eDiscovery process more defensible overall.  With regard to QC, an overall QC mechanism is tracking of document counts through the discovery process, especially from collection to production, to identify how every collected file was handled and why each non-produced document was not produced.

Expanded File Counts

Scanned counts of files collected are not the same as expanded file counts.  There are certain container file types, like Outlook PST files and ZIP archives that exist essentially to store a collection of other files.  So, the count that is important to track is the “expanded” file count after processing, which includes all of the files contained within the container files.  So, in a simple scenario where you collect Outlook PST files from seven custodians, the actual number of documents (emails and attachments) within those PST files could be in the tens of thousands.  That’s the starting count that matters if your goal is to account for every document or file in the discovery process.

Categorization of Files During Processing

Of course, not every document gets reviewed or even included in the search process.  During processing, files are usually categorized, with some categories of files usually being set aside and excluded from review.  Here are some typical categories of excluded files in most collections:

  • Filtered Files: Some files may be collected, and then filtered during processing. A common filter for the file collection is the relevant date range of the case.  If you’re collecting custodians’ source PST files, those may include messages outside the relevant date range; if so, those messages may need to be filtered out of the review set.  Files may also be filtered based on type of file or other reasons for exclusion.
  • NIST and System Files: Many file collections also contain system files, like executable files (EXEs) or Dynamic Link Library (DLLs) that are part of the software on a computer which do not contain client data, so those are typically excluded from the review set. NIST files are included on the National Institute of Standards and Technology list of files that are known to have no evidentiary value, so any files in the collection matching those on the list are “De-NISTed”.
  • Exception Files: These are files that cannot be processed or indexed, for whatever reason. For example, they may be password-protected or corrupted.  Just because these files cannot be processed doesn’t mean they can be ignored, depending on your agreement with opposing counsel, you may need to at least provide a list of them on an exception log to prove they were addressed, if not attempt to repair them or make them accessible (BTW, it’s good to establish that agreement for disposition of exception files up front).
  • Duplicate Files: During processing, files that are exact duplicates may be put aside to avoid redundant review (and potential inconsistencies). Some exact duplicates are typically identified based on the HASH value, which is a digital fingerprint generated based on the content and format of the file – if two files have the same HASH value, they have the same exact content and format.  Emails (and their attachments) may be identified as duplicates based on key metadata fields, so an attachment cannot be “de-duped” out of the collection by a standalone copy of the same file.

All of these categories of excluded files can reduce the set of files to actually be searched and reviewed.  On Monday, we’ll illustrate an example of a file set from collection to production to illustrate how each file is accounted for during the discovery process.

So, what do you think?  Do you have a plan for accounting for all collected files during discovery?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Judge Recommends Default Judgment Sanctions Against Defendants, Even Though Some Deleted Files Were Recoverable: eDiscovery Case Law

In Malibu Media, LLC v. Tashiro, Case No. 13-cv-00205 -WTL-MJD (S.D. Ind. May 18, 2015), Indiana Magistrate Judge Mark J. Dinsmore issued a Report and Recommendation on Plaintiff’s Motion for Sanctions, recommending that the Court grant the plaintiff’s motion against the defendants for spoliation of evidence and perjury and enter default judgment against the defendants.

Case Background

In 2013, the plaintiff retained a German company to investigate whether certain internet users were infringing plaintiff’s copyrights by uploading and/or downloading its copyrighted adult movies via a BitTorrent client and, after monitoring the BitTorrent file distribution network, the provider identified certain IP addresses that were being used to distribute Plaintiff’s copyrighted movies.  The plaintiff initially filed suit against an unidentified defendant, but amended the complaint to name the defendants after the plaintiff subpoenaed the alleged infringer’s ISP.

During discovery, one of the defendants agreed to provide her computer hard drives for forensic imaging.  The plaintiff’s expert examined each of the images of the hard drives for evidence of BitTorrent use, finding evidence on one drive that the “hard drive was repeatedly used to download BitTorrent files and also had BitTorrent software installed on the hard drive.”  He also determined that numerous files and folders associated with BitTorrent use had been deleted the night before the drive was turned over for imaging.  In addition, the expert determined that three additional drives had been connected to the defendant’s laptop computer, but had not been turned over for imaging.  As a result, the plaintiff filed a motion for sanctions alleging spoliation of evidence and perjury in the form of misrepresentations by defendants at their depositions and in their responses to various discovery requests.  The defendants argued that because the files were recoverable, spoliation had not occurred, but the contention that all the deleted files were recoverable was disputed by the plaintiff.

Judge’s Ruling

With regard to the recoverability of the files, Judge Dinsmore stated “Based on the relative credentials of the parties’ experts, the Court concludes that Patrick Paige’s testimony is more accurate and more credible. As such, the Court finds it highly likely that thousands of files were deleted and were unrecoverable. This confirms that Defendant Charles did not temporarily delete relevant evidence; instead, he permanently destroyed that evidence. As a result, Charles is liable for spoliation.”  He also noted that “even if the files that Charles deleted had been recoverable, this would not absolve Charles of liability” as the metadata associated with those recovered files would have been altered, which “would impede Plaintiff’s use of those files in proving its underlying claim of copyright infringement”.

As for the perjury claim, while finding some of the defendants’ answers not to constitute perjury, Judge Dinsmore failed to reach that conclusion regarding at least one of the drives that the defendant failed to disclose.  He stated that “At best, her omission of the XPS 600 from her discovery responses resulted from an egregious failure to reasonably investigate whether her interrogatory answers were complete. At worst, her failure to include the XPS 600 was a knowing and intentional omission that indicates that she did in fact commit perjury.”

Finding that “a sanction short of default would not appropriately address the goals of deterrence and punishment”, Judge Dinsmore recommended that the Court grant the plaintiff’s motion against the defendants for spoliation of evidence and perjury and enter default judgment against the defendants.

So, what do you think?  Was the recommendation of severe sanctions appropriate in this case?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

You Almost Can’t Have a Divorce without Smartphone Evidence These Days: eDiscovery Trends

If you think the NSA is tough, hell hath no fury like a suspicious spouse scorned.

According to the American Academy of Matrimonial Lawyers (AAML) – not to be confused with the National Organization of Matrimonial Attorneys Nationwide (or N.O.M.A.N.) from the Coen Brothers movie Intolerable Cruelty (whose motto was “let N.O.M.A.N. put asunder”, get it?) – almost every divorce attorney works with smartphone evidence these days.

According to the AAML survey (press release here), a whopping 97% of members have seen an increase in divorce evidence being taken from smartphones and other wireless devices during the past three years. In addition, an almost universal number of 99% of respondents have cited a rising number of text messages being used in cases, while 67% have noted more evidence being gathered from apps. Not surprisingly, the top three apps for divorce evidence are also the most popular social media sites, with 41% citing Facebook, 17% choosing Twitter, and 16% identifying Instagram as sites where evidence was obtained.

“In the past, a suspicious spouse might have turned to a private investigator for this kind of detailed information, but nowadays most people willingly carry around some kind of wireless tracking device everywhere they go,” said James McLaren, president of the American Academy of Matrimonial Lawyers. “As with almost every aspect of our lives, smart phones and other wireless devices are having a big impact on the ways in which couples divorce.”

Overall, 97% of the attorneys cited an increase in the number of cases using evidence taken from smartphones and other wireless devices during the past three years, while 2% said no change and only 1% noted a decrease. The most common types of evidence gathered were cited by 46% as “texts,” while 30% said “emails,” 12% “phone numbers/call history,” 7% “Internet browsing/searches,” and “GPS” was noted by 4% of the respondents. In total, 99% cited an increase of cases using text messages during the past three years, while 1% noticed no change.

An increase in the number of cases using evidence taken from apps during the past three years was cited by 67% while 28% chose no change, and 5% noted a decrease. In addition to the top three apps listed for divorce evidence, the next selections included Find My iPhone and Snapchat at 6% each, 4% choosing Google Maps, Google+ at 3% and WhatsApp and Tinder each picked by 1% of the respondents.

So, if your divorce attorney is going to nail your spouse’s ass(ets), it will probably be with help from the ESI on his or her smartphone and social media accounts.

Once again, thanks for the tip from Sharon Nelson and her excellent Ride the Lightning blog!

So, what do you think? Do your cases include more ESI from smartphones? Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

When Collecting Emails, Make Sure You Have a Complete Outlook: eDiscovery Best Practices

I’m out of the office this week, taking the kiddos on a family vacation (can you guess where?). Instead of going dark for the week (which we almost never do), I decided to use the opportunity to give you a chance to catch up on cases we’ve covered so far this year with a couple of case law pop quizzes, sandwiched around a popular post from the past that you may have missed. Today’s post takes a look back at Outlook files and the different forms they take. How many do you know?

Most discovery requests include a request for emails of parties involved in the case. Email data is often the best resource for establishing a timeline of communications in the case and Microsoft® Outlook is the most common email program used in business today. Outlook emails can be stored in several different forms, so it’s important to be able to account for each file format when collecting emails that may be responsive to the discovery request.

There are several different file types that contain Outlook emails, including:

EDB (Exchange Database): The server files for Microsoft Exchange, which is the server environment which manages Outlook emails in an organization. In the EDB file, a user account is created for each person authorized at the company to use email (usually, but not always, employees). The EDB file stores all of the information related to email messages, calendar appointments, tasks, and contacts for all authorized email users at the company. EDB files are the server-side collection of Outlook emails for an organization that uses Exchange, so they are a primary source of responsive emails for those organizations. Not all organizations that use Outlook use Exchange, but larger organizations almost always do.

OST (Outlook Offline Storage Table): Outlook can be configured to keep a local copy of a user’s items on their computer in an Outlook data file that is named an offline Outlook Data File (OST). This allows the user to work offline when a connection to the Exchange computer may not be possible or wanted. The OST file is synchronized with the Exchange computer when a connection is available. If the synchronization is not current for a particular user, their OST file could contain emails that are not on the EDB server file, so OST files may also need to be searched for responsive emails.

PST (Outlook Personal Storage Table): A PST file is another Outlook data file that stores a user’s messages and other items on their computer. It’s the most common file format for home users or small organizations that don’t use Exchange, but instead use an ISP to connect to the Internet (typically through POP3 and IMAP). In addition, Exchange users may move or archive messages to a PST file (either manually or via auto-archiving) to move them out of the primary mailbox, typically to keep their mailbox size manageable. PST files often contain emails not found in either the EDB or OST files (especially when Exchange is not used), so it’s important to search them for responsive emails as well.

MSG (Outlook MSG File): MSG is a file extension for a mail message file format used by Microsoft Outlook and Exchange. Each MSG file is a self-contained unit for the message “family” (email and its attachments) and individual MSG files can be saved simply by dragging messages out of Outlook to a folder on the computer (which could then be stored on portable media, such as CDs or flash drives). As these individual emails may no longer be contained in the other Outlook file types, it’s important to determine where they are located and search them for responsiveness. MSG is also a common format for native production of individual responsive Outlook emails, though HTML is also used (as Outlook emails, by default, are already HTML formatted files).

Other Outlook file types that might contain responsive information are EML (Electronic Mail), which is the Outlook Express e-mail format and PAB (Personal Address Book), which, as the name implies, stores the user’s contact information.

Of course, Outlook emails are not just stored within EDB files on the server or these other file types on the local workstation or portable media; they can also be stored within an email archiving system or synchronized to phones and other portable devices. Regardless, it’s important to account for the different file types when collecting potentially responsive Outlook emails for discovery.

So, what do you think? Are you searching all of these file types for responsive Outlook emails? Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

For a Successful Outcome to Your Discovery Project, Work Backwards: eDiscovery Best Practices

Based on a recent experience with a client, it seemed appropriate to revisit this topic. Plus, it’s always fun to play with the EDRM model. Notice anything different? 🙂

While the Electronic Discovery Reference Model from EDRM has become the standard model for the workflow of the process for handling electronically stored information (ESI) in discovery, it might be helpful to think about the EDRM model and work backwards, whether you’re the producing party or the receiving party.

Why work backwards?

You can’t have a successful outcome without envisioning the successful outcome that you want to achieve. The end of the discovery process includes the production and presentation stages, so it’s important to determine what you want to get out of those stages. Let’s look at them.

Presentation

Whether you’re a receiving party or a producing party, it’s important to think about what types of evidence you need to support your case when presenting at depositions and at trial – this is the type of information that needs to be included in your production requests at the beginning of the case as well as the type of information that you’ll need to preserve as a producing party.

Production

The format of the ESI produced is important to both sides in the case. For the receiving party, it’s important to get as much useful information included in the production as possible. This includes metadata and searchable text for the produced documents, typically with an index or load file to facilitate loading into a review application. The most useful form of production is native format files with all metadata preserved as used in the normal course of business.

For the producing party, it’s important to be efficient and minimize costs, so it’s important to agree to a production format that minimizes production costs. Converting files to an image based format (such as TIFF) adds costs, so producing in native format can be cost effective for the producing party as well. It’s also important to determine how to handle issues such as privilege logs and redaction of privileged or confidential information.

Addressing production format issues up front will maximize cost savings and enable each party to get what they want out of the production of ESI. If you don’t, you could be arguing in court like our case participants from yesterday’s post.

Processing-Review-Analysis

It also pays to make decisions early in the process that affect processing, review and analysis. How should exception files be handled? What do you do about files that are infected with malware? These are examples of issues that need to be decided up front to determine how processing will be handled.

As for review, the review tool being used may impact how quick and easy it is to get started, to load data and to use the tool, among other considerations. If it’s Friday at 5 and you have to review data over the weekend, is it easy to get started? As for analysis, surely you test search terms to determine their effectiveness before you agree on those terms with opposing counsel, right?

Preservation-Collection-Identification

Long before you have to conduct preservation and collection for a case, you need to establish procedures for implementing and monitoring litigation holds, as well as prepare a data map to identify where corporate information is stored for identification, preservation and collection purposes.

And, before a case even begins, you need an effective Information Governance program to minimize the amount of data that you might have to consider for responsiveness in the first place.

As you can see, at the beginning of a case (and even before), it’s important to think backwards within the EDRM model to ensure a successful discovery process. Decisions made at the beginning of the case affect the success of those latter stages, so working backwards can help ensure a successful outcome!

So, what do you think? What do you do at the beginning of a case to ensure success at the end?   Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Simply Deleting an Email Doesn’t Mean It’s Gone, Even When It’s Hillary Clinton’s Emails: eDiscovery Trends

Early in the life of this blog, we published a blog post called eDiscovery 101: Simply Deleting a File Doesn’t Mean It’s Gone to try to help our readers understand how disk drives keep track of files and how “deleted” files often can still be recovered. Something tells me that basic forensic concept will become a big issue in the coming weeks and months regarding Hillary Clinton’s deleted emails.

As reported by Politico in Hillary’s emails: Deleted but not gone (by Joseph Marks and Rachael Bade), Clinton’s attorney David Kendall on Friday wrote Benghazi Committee Chairman Rep. Trey Gowdy (R-S.C.), declining the committee’s request for the personal server that she used for emails while she was Secretary of State (which we discussed previously here) to be turned over to an independent third party. The committee said it wants a third party to verify that all Benghazi-related emails were in fact turned over to the panel – especially after Clinton acknowledged deleting anything determined to be “personal” messages. Kendall called the request pointless, saying Clinton’s IT staff had confirmed to him the messages are gone for good (Gowdy, in a statement, said that Clinton “unilaterally decided to wipe her server clean and permanently delete all emails from her personal server”).

But, are the emails really gone? According to my colleague, Michael Heslop, Vice President of Computer Forensics at CloudNine, that depends on what they mean by “wiped”. “If they forensically wiped the server, then it’s likely not recoverable from there”, said Heslop. “But, the data might still be available via other sources, such as backups or an offline storage table (OST) file on the computer that was used for email.”

As an example, the Politico article references the case of former Internal Revenue Service official Lois Lerner, who came under scrutiny over charges that the IRS targeted tea party groups for heightened scrutiny, after the IRS said that a 2011 hard-drive crash rendered her emails irretrievable. The agency trashed the hard drive and said it had over-written back-up tapes, yet other recovered back-up tapes appears to have yielded the missing emails.

Not surprisingly, the conservative group Freedom Watch has filed a racketeering lawsuit against Clinton that accuses her of failing to produce documents under the Freedom of Information Act (FOIA). So, expect efforts to scrutinize the deletion of Clinton’s emails to intensify. And, that’s no April Fools joke.

So, what do you think? Have you ever had to recover deleted emails? Were you successful in doing so? Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscoveryDaily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.