In this post I’ll be using the following abbreviations:
RBR Rules-Based Recordkeeping
RRM Replication Records Management
RMS Records Management Software
PC Preservation Copy. The duplicate copy of the document the RMS stores in the cloud.
OC Original Copy. The original document the end user stored in the content source. Being managed by the RMS.
Before the advent of RBR around five or so years ago, we depended on users to voluntarily declare documents to be records. That way we knew which documents were the records and which ones were not. Those declared to be records could be managed by applying the classification against the retention schedule. With RBR however, we could simply write rules that automatically applied appropriate classification to documents, without any user intervention. We could also write rules that determined the timing, i.e. when the document was to be declared a record. This way, we didn’t have to depend on the user to participate in any recordkeeping activities whatsoever. Declaration, including the timing of the declaration and classification against the retention schedule were completely automated and in the background.
In the last year or so we are now seeing an advancement beyond RBR. I’m calling this RRM (Replication Records Management). RRM is very new, and is just beginning to take hold in the market. So what exactly is RRM? RRM is the business of replicating all electronic records from all content sources, and storing a duplicate of all records in the cloud. I’ll refer to each duplicate record stored in the cloud as a PC (preservation copy), in comparison to the original copy that the user created and stored in the content source, which I will refer to as the OC (original copy).
The idea behind RRM is to treat the PC as the “official record”, to which formal records management is applied throughout its lifecycle right up to and including disposition at the end of the lifecycle. The user is free to do anything they wish to the OC including revising it, and even deleting it. There is absolutely no restriction on what the user can and cannot do with the document in the content source. No matter what they do, the PC will still exist and have formal records management applied to it. Every time a changes made to the OC, the PC will be automatically updated with that change (at least that’s the theory).
So what exactly is the benefit of RRM over RBR? RRM does not lock a document down once declared. Prior to RRM, once the document was declared it was locked such that the user could no longer delete it, thus preserving it until the end of its lifecycle. With RRM however, there is no declaration and no lockdown. Users can do anything they wish, without restriction. Below are some common characteristics of RRM:
Multiple Content Sources. A typical RMS employing RRM can apply recordkeeping control to multiple content sources such as a content management system (OpenText, IBM, SharePoint, etc.), Microsoft OneDrive, dropbox, email, and more.
At disposition time the OC is deleted along with the PC, if it still exists.
If the content source happens to be a modern content management system such as SharePoint, there is a lot more to a document than just its content:
1. Metadata
2. Security permissions
3. Version history
4. Audit history of changes
The full and complete story of a single document includes these four elements above. Different RRM products have a different approach and ability to managing each of these four.
Some software vendors such as RecordPoint, allow you to operate in either RRM mode, or the traditional RBR mode where documents are locked down at declaration time.
Some RRM products only duplicate the latest version of the document as opposed to all versions in its version history.
Collabware’s Collabspace product is an example of RRM. They capture document content from a variety of sources and store it in a reserved cloud space they refer to as a “Data Lake”. RecordPoint has a similar capability in their latest Records 365 product offering. Gimmal does not currently have RRM capability as of the writing of this blog post, but I suspect market pressures will force their hand to bring it to market eventually.
There are pros and cons to RRM. The pros:
Users have no participation in recordkeeping, and their daily work is not impacted by having thousands of documents locked down that they cannot delete.
There are no records versus non-records, which has always been a point of contention. Every document that users store is treated as if it were a record. This is a very high level of information governance.
The cons:
Every single record is duplicated. This leads to two pools of records. One consisting of the originals, which are essentially unmanaged up until the point they are destroyed at disposition time by the RMS. This assumes the user hasn’t deleted them prior to the retention period.
Storage cost. Cloud storage is not free, and you’ll have to pay a storage fee for every month that each gigabyte of data remains stored in the cloud.
I believe there are two primary drivers behind RRM:
RRM frees the users from any recordkeeping considerations.
Having all documents from all sources in one place means that they can be consistently and reliably managed, free from any constraints of any one of the various content sources. It’s now possible to search, classify, apply holds, and dispose of all the documents and all the content sources, as they all reside in the same uniform space.
So there you have it. RRM appears to be where the technology is taking us for electronic recordkeeping. When you consider purchasing records management software in the future, it will be highly likely that the software will operate RRM. Below are just some of the considerations of RRM:
At disposition time, what happens if the end user has moved the OC to a different location? Will the RMS be able to track it, find it, and dispose of it?
Suppose a user revises the OC several times. Is a PC made of every single saved instance of the OC?
Suppose a user revises the OC several times, using the version tracking feature of the content source (such as a document management platform). Is a PC made of every single saved version of the OC?
Does the revision history of the PC match the version history of the OC, assuming that version tracking was used for the OC?
Suppose a user deletes the OC, and the OC subsequently resides in a recycle bin, such as a OneDrive recycle bin. Is the RMS aware of OC copies in any recycle bins, and can disposition track these down and destroy them?
Suppose a user renames the OC, without revising it or moving it. Does that trigger a new PC? Will disposition still be able to track that now renamed OC?
Suppose an end user restricts access to a given OC to just a few users. Does the RMS have the ability to punch through these restrictions, and access the OC at disposition time?
Would a legal hold applied by the RMS be applied to the OC, the PC, or both?
Assuming a legal hold is applied to an OC, can the end user delete the OC? Can the end user rename, relocate, or change security permissions of an OC covered by an RMS legal hold?
Suppose a user makes a change to the metadata in an OC stored in a content source such as a document management system. Is this metadata change reflected in the PC?
Does the RMS record the audit history of changes to the PC, the OC, or both?
RRM represents a bold new approach to managing electronic records, and no doubt will have lots to learn and experience as this technology is refined over the coming years.