I had written recently that in building our Digital Records
Program, we are looking at the impact that occurs and actions that
should be taken when there are changes in records series codes -
including, but not limited to, changes in retention periods. I indicated
my experience and opinion(s) on the subject. I asked group members for
concurrence and/or diverging opinions. Thanks to those of you who
responded.
Below is an update for your information and use.
Results and summary of changes:
*
Several company RM representatives responded, indicating
concurrence with all points.
*
Two RMs said that his company usually doesn't lower retention
periods retroactively when a retention period is lowered.
*
I added a section in the update related to the addition of new
codes.
*
Several persons addressed the difficulty/impossibility of
applying lowered periods to certain WORM repositories.
As a result of assessment that results in updating a retention schedule,
it's possible that:
1. A retention period is lowered.
Impact: The new retention period is applied to the records; records that
have outlived the new retention period are destroyed (barring any
litigation hold requirements). Two exceptions: A. One company that
doesn't typically lower retroactively; others do.
2. A retention period is lengthened.
Impact: The new retention and disposition requirement typically goes
into effect immediately and all records that exist within that code are
retained for the new, longer period.
Typically, a relational database underlying RM software enables the
update to the retention period associated with a code. The field
containing the retention period value for the records series code is
modified. Links to specific records (boxes, electronic records) -
associated with that code - enable application of the new requirements.
Disposition dates are (re)calculated per the new retention value for the
code. For example a report can be run listing all records that have
exceeded their retention period that are eligible for destruction under
the new time period. Note: In cases in which an actual date was input
into the destruction date field without retaining a link between the
code and the retention period, additional work would be required to
recalculate and apply the new retention period. The logistics depends
upon the actual system and how data is entered.
3. A records series code is split.
This is a more complex scenario and is most often accomplished to
differentiate between two or more record types that require different
retention periods. There are other reasons and scenarios. In the paper
world, records stored under the original code typically continue to be
retained under that code, because it is not cost effective to sort
through and divide the contents. The retention period for those records
would either stay the same - or be lengthened or lowered, to - in most
cases match the LONGEST time period of either of the new codes.
In an electronic records world, because of the ability to capture
"record type" metadata, there is an opportunity to actually make the
needed changes on a record type basis, when a split in a record series
occurs.
4. New retention codes are added.
On a going forward basis, records are coded with the new (usually better
fitting) codes. Typically, because the codes didn't exist in the past,
records had been coded (e.g., for offsite storage) with codes that
didn't fit as well - hopefully, with retention periods that were fine.
When the system allows for easy identification of records falling under
the definition of the new codes (and they are not intermingled with
other records), they are recoded in the system. On rare occurrences,
records that fall within these new codes but had been part of another
codes are separated out and recoded (expensive - only advised when risk
of not doing so is great).
Implementation exceptions related to WORM repositories: It may be
impossible to retrofit WORM archives on various storage repositories.
Note: One Records Manager discussing EMC Centera WORM storage wrote that
"We employ Compliance Plus mode which is not changeable or able to
accept any override commands. The solution for any retention schedule
compression would be applied on day forward ingestion by making changes
to the Application Group assignments.... which would not be cost
prohibitive." Another Records Manager wrote: Records written to WORM are
written with their retention period, and the nature of these subsystems
makes it impossible to lower the retention period, or attempt
disposition prior to the existing retention period. A third wrote that,
for consistency, a solution should be derived such that there are no
media based exceptions (This will likely spark another discussion :) ).
Best regards,
Susan
Susan K. Goodman
MLS, CRM, ERM,PECMP
Senior Vice President
Digital Records Program
Bank of America
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
