Blogs

I recently finished creating my first records classification scheme and records retention schedule [RCSRS] from scratch.  I did everything from the data gathering, interviews, legislative research, hierarchical development, etc. 

The application of the RCSRS is only intended for physical records at this time, but I wanted it to be robust enough to be used for electronic records, when and if the client decided to move in that direction.  At a former job, I spent many months learning the backend of the RM module in Content Server in order to map our retention rules to the software.  I learned a number of things about constructing records classification schemes and retention schedules. 

Even so, I definitely had some areas that I would modify for the next version.  For example, I used “Permanent” as the final disposition for a few record series.  I started to question what does permanent really mean and how is it applied?  If records are not archival quality, then they will be transferred or destroyed following an event such as a corporate dissolution (e.g. General Ledger). For that reason, even a permanent designation can and should be broken down into a retention rule with a trigger date, where the trigger is something like the dissolution to the company.  Eliminating this one variation and turning it into something more standard makes it easier to adapt to an electronic environment.    

I eliminated “S” for supersede, mostly because I have always found this rule difficult to implement and felt it could be adequately and accurately expressed with an event-based retention rule where “E” equals the document being updated.

Here are a few tips I learned about constructing records classification schemes and records retention schedules for a digital environment.  The tips can also be used to adapt existing schemes and schedules. 

1. Consistency is key.  Eliminate as many gray areas as possible between record series.  Although some records may require multiple classifications for those that are owned/used by more than one area, it’s best to have a 1:1 relationship between record series and documents. 
2. Simplify trigger dates.  By trigger date, I mean the date that starts the retention period.  In my mind, there are really only two, maybe three, trigger dates depending on how they’re defined. 
   1. Event Date = When the active life of a record is not known at the time of creation and is dependent on an event happening to start the retention period.  Contracts, agreements, employee files, and claims are all common examples of records that are dependent on an event happening (i.e. contract expiry, employee termination, claim resolution, etc.). 
   2. Calendar Year = End of the calendar year in which the record was created.  This is often used for routinely created records that are produced on a regular or semi-regular basis.  (E.g. monthly reports, quarterly reports, budgets, payroll, etc.).
   3. Fiscal Year = End of the fiscal year in which the record was created.  I consider this to be a variation on calendar year because the application of it is the same, but the date won’t always be December 31^st.
3. Simplify disposition.  By disposition, I mean the final outcome of the record.  In my mind there are only two: Destroy/Delete and Archive (the RIM definition, not the IT one).  Archival Review could be used for certain record series, but it should be regarded as an additional step before final disposition, rather than an actual disposition outcome.  

In terms of adapting a retention schedule to an electronic environment, calendar year is translated into a known date that can usually be auto-populated.  If calendar year and fiscal year are handled separately, then there are three possible options for trigger dates.  But if fiscal year is regarded as a variant of calendar year, or the retention period can be extended to account for fiscal year ends in any month other than December, then there are only two trigger dates to consider: a known trigger and one that must be populated at a later time.