email storage-3A common issue in almost any case involving the production of electronically stored information (“ESI”) is the format in which the parties will produce the ESI. Typically, ESI may be produced in one of four formats: native (the format in which it is maintained on the producing party’s system – e.g. a Microsoft Word or Excel file), near-native (files that need to be converted to a different file type for production purposes – e.g. converting emails from a .msg file to a .html file), image (e.g. TIFF images or PDF files), or hard copy. A main difference between these formats is the amount, if any, of metadata that is produced with the file. In layperson terms, metadata is information embedded in the ESI that describes certain characteristics of the electronic file (e.g. how, when and by whom it was received, created, accessed, and/or modified and how it is formatted). The production of native files typically includes most metadata associated with a document; near-native may include some or most; image format does not include metadata but may include a load file that contains certain select fields of metadata; and hard copy paper productions generally do not include any metadata. 

Rule 26(f) of the Federal Rules of Civil Procedure provides that the parties’ discovery plan must address the form(s) in which ESI should be produced. Rule 34 of the Federal Rules provides that, while a party may specify the form(s) in which ESI is to be produced, the responding party may object to the requested form. Parties often agree on the form for an ESI production; however, occasionally, this is a contested matter and must be taken to the judge for resolution, as was recently done in Mitchell v. Reliable Security, LLC.

The plaintiff in Mitchell, who sued her employer for pregnancy discrimination, requested that the defendant produce its ESI in native format, asserting that a native production was necessary given that the ESI that supported the defense theory was susceptible to post hac manipulation. The production of native files – with its accompanying metadata – was necessary, plaintiff asserted, to allow plaintiff to verify that the defense’s key documents had not been altered after the litigation began. The defense objected, asserting that a PDF format production was more appropriate due to the additional $3,000 cost the defendant would incur in producing native files. The defense further asserted that the additional cost was disproportionate to the $10,000 in expected damages.

The Mitchell court rejected the defendant’s arguments and ordered it to produce its ESI in its native format. In addition to the defendant’s failure to explain why producing native files would be more expensive, the court reasoned that “it is not at all unreasonable for Plaintiff to wish to verify herself whether the emails or spreadsheets had been subsequently manipulated, modified, altered, or changed.” The court further reasoned that “while it does appear that Plaintiff’s suit is unlikely to be of an especially high dollar value, the Court finds that the public value of allowing a civil-rights plaintiff opportunity to access information relevant and quite possibly necessary to her pregnancy-discrimination suit far outweighs the asserted $3,000 cost.”

Litigants faced with a request for production of native files, like the defendant in Mitchell, should be aware of the pros and cons of this production type. While native file productions allow the parties to access potentially-important metadata or other “hidden” information (e.g. hidden rows or columns in Excel or comment bubbles in Word), there are other concerns to bear in mind. For example, producing native files provides the receiving party with the ability to manipulate the document, which may place a significant burden on the producing party to verify that the recipient did not engage in such deceptive practices. Additionally, a party that needs to redact privileged or confidential information from its document production must convert the native file to a TIFF or PDF file before redacting; otherwise, the receiving party can simply remove the redactions from the native file to see the omitted information.

For these reasons, the Mitchell decision is an important one for parties facing disputes about production format. Where metadata may play an important role in the resolution of the case – as the plaintiff in Mitchell argued it would – a party can rely on Mitchell in support of its production request. Conversely, where a native file production may place a significant burden on the producing party, it should be prepared to adequately explain to the court (which the defendant in Mitchell failed to do) the additional costs attendant with this production format.