Friday, May 11, 2012

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.

3 comments:

  1. I really believe you will do much better in the future I appreciate everything you have added to my knowledge base. Admiring the time and effort you put into your blog and detailed information you offer! Hosted PBX

    ReplyDelete
  2. Interesting concept, but you don't mention HOW this would be accomplished? How do you redact native documents?

    ReplyDelete
  3. Evolver Legal Services has a web based tool that reviews, redacts and produces native excel files: http://evolverlegal.com/xlerator.html

    ReplyDelete