19 January 2009

Cyberspace February 2009

Document management

Too much information can be a bad thing for many reasons - you experience this when you do a search on the Internet and can't find useful information because of the vast amount of useless information.

Corporate information is the same, and so it may be prudent to destroy information that is wrong, misleading or of no commercial value. There are, however, a number of issues to consider before destroying information. Some information must be kept pursuant to specific legislation (eg s286 Corporations Act 2001, Crimes (Document Destruction) Act 2006 (Vic) and Evidence (Document Unavailability Act), 2006 (Vic)) or the general law relating to destruction of documents which may be required for legal or other proceedings (eg Registrar of Supreme Court of New South Wales v. McPherson [1980] 1 NSWLR 688).

Having useless information in information systems can lead to acting on wrong information, increased costs of storage, increased backup periods (or even the inability to backup within a reasonable window), and difficulty in finding useful information. It therefore makes a lot of sense to have well-crafted retention and destruction rules. This implies that you consider triggers that will start a sentence prior to destruction. For example, you might decide that employee records shall be maintained until the relationship is terminated. The termination triggers the start of a retention period of, say, seven years, after which the documents will be destroyed.

If you legitimately destroy documents you should probably consider the adequacy of destruction. Just deleting them from a live IT system doesn't mean they disappear from backups or disaster recovery systems. Those records or documents may exist on dozens of backup tapes or other media. That information is now of no use to you and there is no legal requirement to keep it, but is still capable of being caught by discovery or similar processes. Recovering information from such systems is almost always very expensive and consumes valuable employee resources.

The USA Court of Appeals dealt with a case (In Re: Fannie Mae Securities Litigation No. 08-5014 (6 Jan 2009)) where the regulator of Fannie Mae (a participant in the USA mortgage market) was required to disclose certain documents on live and backup systems. It hired 50 contract lawyers, spent USD$6m (9% of its annual budget) on the process and was still found not to have tried hard enough! Litigation support service providers have told me of similar examples in Australia.

It follows that if you are going to destroy out of date information legitimately you will want to maximise the benefit of such destruction. If a document is removed from a live system yet is retained on backups or disaster recovery systems then all you have done is increase the expense of providing that document pursuant to subpoena or discovery. Retrieving information from backup tapes is, without exaggeration, extraordinarily cumbersome.

Comprehensive destruction can avoid expensive discovery exercises, provided you ensure that you have business processes in place to ensure that you do not destroy anything you should keep, but otherwise destroy all copies. Those processes need to address common law, statutory and prudent commercial retention requirements, including "holds" or "freezes" on documents that may be required for judicial or other inquiries.

If you have a good document management system and get retention right you will be able to readily locate responsive documents and easily determine whether documents have been destroyed pursuant to business rules, and know, without expensive searching, that they do not exist anywhere else. This implies that you have carefully considered what your backup regime should be, whether it involves backup tapes (there are options), and, where appropriate, how often media is rotated. Getting this right involves a thorough understanding of your IT systems and taking a fresh approach to backup and disaster recovery - not just blindly doing what has been done in the past.

No comments:

Post a Comment