Last week, this blog featured highlights from the very successful SharePoint eDiscovery webinar with Reed Smith.  It is a topic that came up time and again in my tenure as an analyst; companies and government Agencies are becoming tightly bound to SharePoint and want to be sure that eDiscovery ordeals can be avoided.

Microsoft SharePoint continues to gain widespread traction in organizations large and small.  A recent Forrester Research survey found that 66% of respondents will deploy SharePoint server in the next 12 months (source: Forrester Research August 2013 Global SharePoint Usage online survey).  The attraction to SharePoint is obvious – the system creates business benefits: enabling collaboration in efficient ways; providing ways to track versions of documents edited by multiple parties; allowing non-technical business people to apply basic workflow to content-driven processes, and providing faster access to information (via search and integration with the MS Office suite of apps).

For the value it creates, SharePoint can cause eDiscovery and information governance headaches if proper planning does not take place.  It is all too easy to assume that if information is searchable, eDiscovery will be no problem when the time comes.  But, as is often the case in life, the devil is in the details.  Because SharePoint allows users to add value to content (e.g. adding workflow tasks), there is the factor of metadata to consider.

In eDiscovery, metadata is a critical component of ESI that can wreak havoc on collection efforts.  When we talk about metadata for native ESI, we are usually concerned about the Operating System (OS) fields that are kept in the File Allocation Table (FAT). Different OS formats support a wide variety of fields such as different dates, attributes, permissions and file name formats (long vs. short). These fields are not usually stored within the actual file and so are very vulnerable to alteration or complete loss when items are read or copied. Forensic collection is focused on preserving this ‘envelope’ information so that evidence can be authenticated and the context reconstructed in court. That is only half of the metadata story. Microsoft Office and other programs retain non-displayed information within the header and body of all common file types, especially with the adoption of the XML based Office 2007 file formats.

This metadata issue is only extended with SharePoint because most collection efforts are focused only on grabbing SharePoint document libraries (as they are stored on file systems).  But SharePoint is so much more than document libraries (if it weren’t, it would simply be another file share sitting out there).

A defensible SharePoint collection solution will be able to capture document libraries, metadata, and truly enable contextual preservation.  When considering a SharePoint collection tool be sure that it:

• Allows for incremental preservation, monitoring changes, identifying and preserving different document versions, and incrementally preserve to multiple matters over time
• Maps to custodian access and prevent over-preservation, collecting and preserving only what is relevant to a particular custodian, not the entire SharePoint site
• Is deployable in the same fashion as SharePoint, which tends to be highly decentralized and siloed; thus the collection solution should be deployable on-demand, directly to SharePoint sites through a highly automated, remote installation, with intuitive administration and operation performed through a standard web browser

At the end of the day, informed customers will make sure that the collection tool can get more than just SharePoint document libraries, but all metadata, as well.  Also, look for solutions that will not impact the production environment too heavily; you don’t want to bring SharePoint to its knees when it is a valuable business application.  And finally, get legal and IT together on the same page about how to reasonably prove that your SharePoint preservation and collection methodologies and tools are defensible.