Native Redactions – An Emerging Trend

It is a commonly accepted practice within the eDiscovery industry to image documents for production.  Likewise, it is now a commonly accepted practice, and indeed even a preferred practice, to exempt spreadsheets (and some other file types) from that requirement, instead producing those documents natively.  The idea being that parties would rather obtain native spreadsheets allowing them to work with and view the content in a meaningful manner rather than receive spreadsheet images that can be useless, cumbersome, or exceedingly difficult to accurately use and understand.  There is a nascent trend of not only producing spreadsheets in native format, but redacting them in native format as well (the concept has existed for years but is becoming an increasing point of emphasis as of late).  

The inherent nature of a spreadsheet means that it often contains complex data located in multiple rows, columns, and tabs. The data often includes or involves the use of formulas, sorting, or filtering amongst other features.  Macros, pivot tables, and hidden content add to the complexity.  If printed, the data often falls across multiple pages in a less than complete and less than orderly manner resulting in a confusing mess that is difficult to cobble together, let alone read and use.  The fact of the matter is that images simply are unable to capture the complexities many spreadsheets contain, so if the document and its content are to be useful and meaningful, you must produce them natively.  Most litigants now recognize this and are comfortable with, and often require, the native production of spreadsheets.  Yet, traditionally they have been less than enthusiastic about redacting spreadsheets in native format. 

Given that it is an accepted practice to produce spreadsheets natively, because that is how they will be most useful, why should redactions change that?  The answer is that it should not, and more and more practitioners are beginning to realize this.  Redacting changes the data in the spreadsheet, but it does not change the nature of the spreadsheet, the functionality of it, or how one uses the spreadsheet.  If a spreadsheets needs to be produced natively to be useful in its non-redacted original state, then logically it should be produced natively to be useful in a redacted state.

Anecdotally speaking, as time goes on, I am seeing much more acceptance and understanding of the native redaction practice across the industry.  My colleagues are telling me that they are seeing the same thing.   I am confident that it is only a matter of time before redacting spreadsheets in native format is the norm and an accepted standard and practice by courts and litigants alike; native redactions simply make the most sense for spreadsheets.

One of the hang-ups for those who are unfamiliar with native redactions lays in the subconscious or gut feeling associated with making redactions to a native document.  Redacting (i.e. deleting) content from native format documents that you are producing somehow feels inherently wrong, as if there is somehow a difference between covering up the data in an image redaction and deleting it in a native redaction.  In reality, and despite this feeling, if done properly, there is no meaningful difference between image and native redactions, or between covering up and deleting.  With each method, you are hiding data in an attempt to ensure the opposing party does not see it.  Whether the data is hidden beneath a box or darkened out area on an image, or deleted from a native document, the goal and result (hopefully) is the same: the data is not visible or searchable.  As long as you redact properly, and are open and honest with the opposing part about what type of redactions you are making, why, and how, there should be very little issue when redacting spreadsheets natively rather than via image.

Of course there are risks with native redactions, and native productions in general, including the loss of metadata, loss of formulas, changing dependencies (e.g. cell values based on formulas or the values in other cells) and the risk of manipulation by the opposing party to name a few.  However, there are methods and mechanisms for addressing these risks, and you can, and should, discuss them with your eDiscovery experts and the opposing party, before taking action.

However, from a strictly results perspective, if done properly there is no reason why the native redaction of spreadsheets should not be acceptable.  This argument carries even more weight if the parties are producing non-redacted spreadsheets natively; in that instance the parties identified value in producing non-redacting spreadsheets natively, and that same value would exist for redacted spreadsheets.  Driven by this logic and the comfort that will come as litigants gain familiarity with native redactions, more and more parties will turn to native redactions for documents like spreadsheets.  In the not so distant future, natively redacting spreadsheets will be a commonly accepted practice and standard in the eDiscovery industry.

Privilege Waived: Insufficient Privilege Log Entries Doom Defendant’s Privilege Claims

Occasionally I run into clients or an opposing party who will attempt to use a metadata privilege log. And although this approach may save money (but even that point is debatable), I always advise against using them largely because, any such log will invariably be overbroad, inaccurate, incomplete, and potentially cause your opponent and the court to lose trust that you are being honest and straight forward with them. Most importantly, as the recent case ePlus, Inc. v. Lawson Software, Inc., No. 3:09cv620 (E.D. Va) makes clear, you risk waiving privilege.

Metadata privilege logs are created and populated using the metadata available within them, sometimes with little or no human input or modification. The results vary from case to case and even document to document. In some instances, a document may not contain data for some or all fields, or it may contain inaccurate or even non-intelligible information. As a result, the deliverable privilege log may have blank fields or incorrect data.

In ePlus, the Court analyzed several privilege log entries to determine if the defendant had waived privilege as a result of the entry itself. Basing its argument in part on Federal Rules of Civil Procedure Rule 26(b)(5) that a party asserting privilege must “’describe the nature of [privileged] documents, communications, or tangible things . . . and do so in a manner that, without revealing information itself privileged or protected, will enable other parties to assess the claim[]’” the Court held as follows:

1. As to log entries that do not contain author and recipient information, privilege was waived.
2. As to communications received by ten or more non-attorneys, the entries did not demonstrate that the non-attorneys had a “need to know” the information, and privilege was waived.
3. As to communications by non-attorneys that reflect legal advice, these documents are not privileged, since defendant did not “establish that these are communications from or to an attorney or that they are communications made at the direction of an attorney.”
4. As to entries missing date information or failing to assert privilege type, those are mere “minor deficienc[ies]” that do not prevent the opponent from attacking the privilege claim, so privilege was not waived.
5. The court also held that knowingly producing documents and later deciding they are privileged does not constitute “inadvertent” disclosure, and therefore, those documents cannot be clawed back; privilege has been waived for those documents.

The ePlus case should serve as a warning to those who think they can cut corners when creating privilege logs. While minimizing human involvement in privilege log creation and leaving fields blank may save you time and perhaps money, those same actions may waive privilege and make the whole privilege log exercise (even when shortened) superfluous. Defendants Lawson Software learned this the hard way. I hope that others will learn from their mistake; at the end of the day, the dollars saved by using a metadata log, or skimping on quality control of a human created log, simply are not worth the risk of waiving privilege and perhaps exposing the very core of your case.