SharePoint Records Management


In an interesting development since we last spoke about records management and a hybrid cloud solution, the US Department of Energy has teamed up with that wacky bunch of engineers at the National Nuclear Security Administration to develop a secure, hybrid cloud solution that they plan to make available to other departments, as well as potentially other federal agencies.  You can read more about it here.

So why does this development matter to SharePoint records managers?  Admittedly, adoption of cloud-based solutions hasn’t exploded in the manner that so many experts had been predicting.  The same publication that reported the story above also reports that when they asked organizations, ‘What are your company’s plans for cloud computing?’, only 33% of the companies said they were receiving services today from a cloud provider.  This figure is up from 31% last year, but not a particularly high number given that the survey asks only if the company is using cloud computing somewhere within the organization. 

However, the US Federal government – which, for better or worse, tends to be in front of these types of technology trends – is committed to cloud computing and actively promoting it through its ‘Cloud First’ strategy.  And Fortune 500 companies seem to be falling right behind them given my own personal observations.  Add to that the cloud focus that Microsoft is pushing for…well… everything and you have a very compelling argument for developing your own SharePoint cloud-based records management strategy.

Email records management is a critical component of the Integrated Information Lifecycle Management model and an absolute requirement from a preservation/e-discovery perspective, but it is not – despite what some consultants may tell you – rocket science.  In fact, if you fight the urge to demand a perfect solution, a very good solution is really pretty simple.

First (and most importantly), get yourself a good third-party email management solution that provides the simplest declaration strategy available.  Basically, this means drag-and-drop into a managed Outlook folder and filling out one or two (and no more than three) required metadata properties to help determine the correct record classification into your SharePoint records repository.

Next, work with your Legal Counsel on an acceptable email archiving policy.  This policy should apply throughout your organization to all email, both incoming and outgoing and would be your first line of defense when it comes to email discovery.  (Be sure to thoroughly document how you developed this policy and what data you used to form your decisions.)

Ideally, this policy would require that all emails are stored for one to two years from the day they are sent or received.  If you can get your legal team to agree on less than a year, great.  (Maybe you should have been a lawyer.)  If they want you to store them for more than two years, put the pressure on them to justify the added risk and additional storage costs you are certain to incur.

Though I certainly can’t speak for every organization’s email archiving requirements, I will say that Exchange has some excellent out-of-the-box archiving features that should be suitable for implementing a simple archiving policy like this one.

Finally, work with the propeller-heads in your IT Department to develop two more policies.  The first policy will ensure that email backups are managed in line with the new archiving policy.  For the most part, this means no emails are stored on backup media longer than the standard archiving period.

The second policy would limit the space allocated to your users’ Outlook Inboxes.  This limit would force your users to eventually declare a small number of emails as records and delete any other emails they considered transitory.

I can’t suggest exactly how much space your users should be allocated, everyone’s mileage varies.  But I can suggest you work with your Exchange Administrator and choose an amount you are sure is too low.  Trust me, it’s much easier to start with a number that is too restrictive and increase it as necessary then to have a number that is too high requiring further restrictions. 

And just some final advice.  You can’t possibly document this stuff too much.  Especially from an e-discovery perspective.  And once your email records management policies are set, make every effort to ensure they are implemented and followed.  As I frequently tell my clients, in the eyes of the law, it is much better to have no policy at all than to have a policy that is not enforced.

I’ve spoken to two different groups over the last couple of days and both groups asked me the same question about Content Types and SharePoint Information Management Polices.  Essentially, they wanted to understand why simply applying a retention and disposition schedule directly to each unique Content Type wouldn’t meet their records management requirements. 

This is an excellent question that addresses a fundamental understanding of SharePoint records mangement and is vital to a successful solution implementation, so I thought it might be a good idea to post my response here. 

Many retention and disposition requirements (indeed, most retention and disposition requirements at some organizations) are determined by an event rather than the type of record being managed, so a record’s Content Type is usually not enough information to accurately apply the correct Information Management Policy to it. 

This is probably best explained by an example.  Suppose you manage mortgages at a large financial institution.  With each new mortgage a new corresponding folder is created in your records repository.  Over the life of the mortgage, hundreds of records with dozens of different record types – Mortgage Agreements, Property Assessments, etc., etc. – will be added to the folder.  And most (or more likely, all) of these records will have their own Content Type.  Internal corporate policy and outside regulations require that these records are maintained for 10 years after the mortgage is paid off, at which point all the records in the folder, as well as the folder itself, are destroyed. 

From this example – known as case based records retention – it is easy to see why a record’s Content Type alone  wouldn’t provide adequate information for applying the appropriate retention and disposition schedule.  If you were to simply apply a 10-year expiration to, say, all Mortgage Agreement Content Types, SharePoint wouldn’t have any way of knowing when the record’s mortgage was paid off, so it wouldn’t ever trigger the record’s 10 year expiration period.   

This example also explains why the addition of Content Organizer was so critical to successful records management in SharePoint 2010.  Using Content Organizer, we can configure SharePoint to route a record to a folder in the Records Center based on its Content Type (e.g. ‘Mortgage Agreement’) and one or more metadata values (e.g. ‘Mortgage #12345′).  Once the records are properly classified into the correct folder, an Event Date can be applied to all the records it contains upon payoff of the mortgage and the 10 year expiration period can begin in compliance with corporate and external requirements.

Change is good and the New Year brings a new focus for this blog.  As many of you know, I am a Certified Records Manager and I’ve spent the better part of my career promoting effective electronic records management practices.  None of that has changed.  I firmly believe that the role of a Records Manager is far more important today than it ever was and I will continue to fully support and promote what has traditionally been called ‘electronic records management’ until the last person stops listening to me. 

That said, I’ve reached a point where I don’t believe I can continue to speak in terms of records management as a separate notion from managing the lifecycle of all unstructured content.  As I’ve said in a number of interviews, I never fully bought into the idea that content can be divided into ‘records’ and ‘documents’.  This is a misleading concept that evolved almost by accident in the mid-90′s when document management applications (e.g. Documentum, OpenText, etc.) were developed separately from records management applications (e.g. TrueArc, Meridio, Tower TRIM, etc.), leading to the idea that is was perfectly acceptable to manage one but not the other. 

The fundamental flaw with this notion is that you can call one piece of content a ‘document’ and another piece of content a ‘record’, but none of that matters because in the eyes of the law it is all evidence.  Which, of course, means it is all discoverable and its unnecessary retention – or its premature disposition – can put an organization at tremendous risk.

So what does this mean to professional Records Managers?  It means our responsibilities have become much more far reaching than they have ever been before.  It means, quite simply, that we must take ownership of the entire lifecycle of our organization’s content.  We can no longer be content to sit back and let content come to us so we can manage it through its final end state.  Instead, we must be proactively involved in every phase of the information’s lifecycle.  From cradle to grave. 

This also means we should no longer speak in terms of ‘records management solutions’.  This term is simply no longer relevant.  We must now focus on information management solutions that address every phase of the information lifecycle.  And this must be done across the entire enterprise.  This is what I refer to as the Integrated Information Lifecycle Management (IILM) model and it includes all of the traditional records management functions, but also incorporates many features long considered outside standard records management responsibilities.  These include, but certainly aren’t limited to, the following:

  • eDiscovery and information preservation orders
  • Solution governance
  • Retention and disposition of transitory content
  • Email archiving policies
  • Shared drive management and cleanup
  • Enterprise taxonomy and metadata design
  • Workflows
  • Software obsolescence
  • Hardware obsolescence
  • Long term storage
  • Physical records management
  • Backup and recovery
  • Continuity of Operations, vital records and disaster recovery
  • Legacy solution integrations
  • Document template creation
  • Structured data lifecycle management
  • Information Rights Management
  • Privacy and security
  • Social media best practices
  • Web content management
  • Many, many more…

So you’re probably thinking, ‘Sure, Don, that’s great and all, but isn’t this a SharePoint records and information management blog?’  To which I reply, ‘Yes.  Yes, it is.  Thank you for keeping me focused.’

I have a great deal of experienced with a number of the major enterprise content and records management solutions and I can honestly say that, with a few exceptions, they are terrific applications.  I also believe that most of them could be leveraged to implement the IILM model with varying levels of effort.  But I honestly believe that no other existing platform is in a better position to manage enterprise content from its creation, through its retention and to its final disposition than SharePoint.  And going forward into the New Year it will be my goal to demonstrate to you why I believe this is true.

I’ve posted a number of articles on SharePoint records management and the ‘cloud’ and I’ve spoken at length on the subject with a whole host of people, both pro-cloud and anti-cloud.  I can honestly say both camps make strong arguments for or against managing records in a cloud environment. 

Personally, I’m a little torn by the whole ‘cloud’ thing, but it reminds me a lot of the transition from mainframe computers to the client/server model we all went through 20 years or so ago.  (Yes, I’m that old.)

I can remember a lot of people I worked with who resisted the change for a long time.  And they often did so with fairly compelling arguments.  But eventually the obvious benefits of the client/server model overwhelmed even the most ardent opponents of change and, in the end, the new way of doing things was almost universally accepted. 

I don’t think operating in the cloud is a whole lot different.  There are plenty of good reasons not to do it.  But my sense is, over time, vendors will devise ways to mitigate those risks to the point that the anti-cloud argument will become more and more difficult to make.

Easily the most compelling argument I hear against a cloud-based solution from a Records Manager’s perspective is this: How do I manage my records repository pursuant to location-based compliance requirements when it’s not completely clear where my records repository even is?  Records Managers are very reluctant to give up control of their record repository.  This shouldn’t be surprising given it’s their neck that gets choked if regulations get violated or data sovereignty is beached.

So how can this risk be mitigated?  Enter Office 365 and the hybrid cloud model.  In a nutshell, a hybrid cloud model allows you to combine your current on-premises SharePoint records repository (and all the compliance and security that goes with it) with the cloud-based efficiency of Office 365. 

If your organization is contemplating a cloud computing strategy (and it should be) and you have concerns about your SharePoint records repository, I encourage you to learn more about hybrid cloud environments.   A great place to start is a terrific whitepaper on the subject by Paul Robinson of Microsoft, UK.  You can find it here.

Next Page »

Follow

Get every new post delivered to your Inbox.

Join 61 other followers