Blogs

Technology Vendors, RM and IT: Collaborate to Ensure that Electronic Records Management Requirements are Met

By Susan Goodman CIP, IGP, CRM, CIPP posted 04-25-2012 17:39

  

I presented a session at the AIIM Conference in San Francisco  entitled “Having a Regulatory and Standards-Based Approach to ERM IS Possible.” (It was a great conference, by the way).

I recall that while attending the many other excellent presentations at the conference about, for example, cloud, mobile devices, etc., I noticed how little discussion there was about electronic records management (ERM). Several other presenters and attendees expressed their view that ERM is not on the radar of many ECM/cloud providers. (Of course, several ECM vendors offer strong ERMS products). ERM was thought to be even less on the radar of some e-mail, social networking, and cloud storage providers who have relatively recently begun providing document storage services to mid-sized and larger business customers.

This gap is easy to understand. Not long ago, hard-copy records (paper, microfilm, fiche) were considered the "official records" (subject to all related requirements).  Electronic documents and other data were considered to be duplicates and/or data/documents that supported official records. Their retention was considered to be at the discretion of the business (I could argue the accuracy of that, even then...). 

The Information Technology (IT) focus within organizations that corresponded with ERM included, for example, data access controls, security, efficient retrieval, and use of information for enhanced ROI (the latter is a relatively new active area of RM community focus).

Many IT professionals say that they always dealt with data and records – that this is nothing new - because they have managed both for years. Many RM professionals say that they have been dealing with electronic records, because RM policy usually includes records in all media and they were also responsible for storing containers that contained electronic media. In fact - until recently – most IT professionals have not had to deal with many critical electronic records requirements. They typically partnered with internal business clients and legal (as needed), but not with RM. And.. most Records Management professionals have not truly practiced electronic records management within their programs. This is rapidly changing. 

As we all know, our world has changed. For example:

  • Organizations want to move into a digital environment for their official records
  • Many electronic records were "born electronic" and have no hard-copy counterpart
  • A wider scope of electronic data is expected to be produced during legal discovery than in the past
  • More and more data is being moved into and managed “in the cloud,”
  • A broad range of social and mobile technology that houses data is being utilized by businesses and
  • Service offerings for electronic communication and for document and data storage have, in many instances, merged.

These changes have resulted in truly new services areas for technology vendors providing e-mail, document storage, social networking, ECM, cloud and other services that businesses increasing use. And...new practice areas for IT professionals and Records Managers. With that, therer is a critical need for strategic and tactical partnership among all of these groups.  

There seemed to be informal agreement at the conference that, that as businesses include ERM in their requirements, vendors will begin to satisfy those requirements - directly or through interfaces with with other products (e.g., Records Management Governance software) that do. The ability to provide ERM functionality will become a greater and greater differentiator among technology firms that help organizations communicate, collaborate, create and store information content. 

Following are some of the ERM detailed requirements (emanating from RM standards and best practices) that technology vendors, businesses, records management teams and internal IT staff should consider (there are many more):

  • A firm’s records (including e-records) should adhere to requirements for trustworthiness and admissibility, for example per the dictates of ISO 15489 and Rules of Evidence, respectively.
  • For records that have a retention period linked to a triggering event (e.g., X years after e.g., expiration; termination), a mechanism should exist to provide the applicable triggering event date for particular records to enable the clock to start toward disposition (except for permanent – or archival – records). Otherwise, many records will likely be retained many years longer than necessary and for some non-permanent records, destruction would never occur.

 

  • Statutory, regulatory, contractual and business requirements that apply to an organization’s electronic records and systems should be met (e.g., for retention, filing, privacy, storage, etc.), Beyond actual and/or defacto standards that are potentially applicable to all types of organizations (e.g., ISO, MoReq, DoD) there are often unique requirements related to specific industries and functions (e.g., SEC requirements for securities and investment banking and other firms).  
  • All required systems metadata fields should be included and populated properly. These are metadata that are built into the system and include, among others, metadata related to the retention schedule, file plan and legal holds.

 

  • Records-specific metadata requirements should be determined. Some metadata should be included for all records; others only if applicable to a given record or function. Some of these metadata should be included when records are created/captured; others may only be known thereafter (e.g., for most legal holds).  Some data can be incorporated behind the scene; others may need to be me manually populated. See MoReq and other sources of needed and/or useful metadata.
  • Retention schedule updates (to descriptions, disposition rules) should be incorporated and applied to relevant records and updated as needed.

 

  • Audit trails should include all needed data
  • Data needed for e-discovery must be able to be readily located, preserved (overriding the retention rule), retrieved and produced.

 

  • Legal hold parameters must be able to be associated with specific electronic records. All of the holds associated with a record should be individually tagged and released, so that it is clear which holds apply and records that are released from a final legal hold are returned to a disposition queue.
  • Methods must exist to ensure that only records that are eligible for destruction (e.g., have met retention requirements; have no associated holds) are destroyed.

 

  • “Destruction eligible” records should be destroyed per an organization’s retention schedule. Retaining records longer (or inconsistently) can incur risk.
  • Duplicate records, working documents that are not needed for specific time periods dictated by an organization’s retention schedule and its procedures, and email that do not contain content that requires longer retention, should be destroyed when business need is satisfied. This reduces risk and cost. It also helps to ensure that the “official records” can be readily identified and used and that duplicates are not retained after the official records are purged.

And…very importantly:

  • Processes to enable organizations to monitor and audit compliance with their own ERM requirements should be built in to systems and processes (via searching; reporting, etc.). Thus, an RM team must be able to monitor a system to make sure that, for example:

 

  • records are and remain authoritative (what was sent is the same as what was received; records have not changed; only authorized parties accessed or received data/records).
  • legal holds “stick”
  • records that are not eligible for destruction are not on a destruction eligibility list and are not destroyed
  • changes in the retention schedule are accurately applied to records

If a third party is given responsibility to help clients demonstrate compliance, these monitoring and auditing services must be explicitly built into contracts and performance should be monitored and audited by the client.

To conclude, technology vendors that store client data should be aware of electronic records related requirements (such as those above) and work with their clients to ensure that their ERM related needs are met. Technology vendors and business RM teams and IT should  proactively (and enthusiastically) collaborate to derive appropriate solutions. 

Regards,

Susan

The opinions expressed above are those of the author and not necessarily those of her employer or AIIM



#records #management" #e-discovery #Collaboration #destruction #"trustworthy #Capture #records" #content #"e-mail" #retention #ElectronicRecordsManagement #disposition #requirements #"social #media" #"records #management" #InformationGovernance #metadata #"content #"electronic #management"
#AIIM12
#Retention
#IntelligentInformationManagement
#eDiscovery
#EmailManagement
#TaxonomyandMetadata
#AIIM2012
#Records
#Disposition
#Content
#Destruction
4 comments
29 views

Permalink

Comments

Glad it was helpful!
Thanks John. At this point, I'm also in the position of potential customer...but many customers need to push for this. From what I hear, some of the major players are starting to get the message...

05-08-2012 09:55

I am in the middle of an article now on the disaster recovery planning and the amazing lack of involvement by RM. You have summed up the same types of issues beautifully.

05-07-2012 03:15

Susan,
Very interesting and thorough post. However, I wonder if those of us that know these things need to be addressed and call for them (push them) will be as effective as when customers begin to call for them (pull them). I think when customers begin to differentiate among vendors of cloud services that do or do not address these issues they will be more likely to take note. Unfortunately, those customers may need to get "bitten" by an inability to produce e-records during litigation before they demand that vendors address these issues.
John